I have been asked this quite a bit over the years, and indeed in most of my articles where I provide PS based scripts I tend to re-iterate the process for running or scheduling them. So rather than continue to cover the process over and over again, I thought that I would put together a full post on how you can run scripts within your respective environments.

First things first, understanding Execution Policies

PowerShell was designed to be a more secure scripting platform over its main predecessors within a Windows environment (e.g. VBScript or JScript) – therefore a number of security features were built into it – the most prominent of which was the principles of “Execution Policies”.

In essence Execution Policies set a number of conditions in which scripts and configuration files can be executed from within or using the Shell. Execution Policies can be set at the following levels:

• Local Machine
• Currently Logged on User
• Specific PowerShell session

Group Policy can also be used to determine settings at a user and computer level.

There are a number of levels which Execution Policies can be set at – these are shown below (which is based upon the following information Source: http://technet.microsoft.com/en-us/library/dd347641.aspx):

On my servers I tend to run either “AllSigned” or “RemoteSigned” as those levels are sufficient to give me a good trade off between security and functionality.
You can check your PowerShell Script Execution Policy setting by opening a PowerShell Session on your machine and typing in the following command:

Get-ExecutionPolicy –List | FL

Which will produce some output similar to the following:

Given the above, if you are intending to run scripts that you have downloaded to your Local Machine you will need an Execution Policy of either “AllSigned” or “RemoteSigned” in order to run them.

For example – if you want to change the Execution Policy to “RemoteSigned” (my preferred personal level) – open a PowerShell session (you will need to run PowerShell as an Administrator) – and type the following command:

Set-ExecutionPolicy “RemoteSigned”

You should also note that if you are using “RemoteSigned” as the Execution Policy and you have downloaded a script from the Internet you will be presented with the following error upon script Execution:

You will need to “Unblock” the script in order for it to function (this is because an attempt is made to find a Trusted Publisher for the script on the web and cannot do so, as the script may not be signed) – this is done by selecting the script file using a right click and from the context menu that appears – choose properties, and then from the properties dialog click on the “Unblock” button – see below:

For more information on Set-ExecutionPolicy see the following TechNet article: http://technet.microsoft.com/en-us/library/dd347628.aspx

Executing Exchange PowerShell Script Files from the Command Line

You have a couple of options here:

1. Executing a script from within an open PowerShell session
2. Executing a script from a CMD command window

If you wish to run an Exchange PowerShell script from within an existing PowerShell session the easiest way is to do so via the Exchange Management Shell.

Open the Exchange Management Shell and then type in the path to your Exchange based PS script:

If you would like to run a script from the Windows command prompt you can:

Powershell.exe –command “& {<path to script> }”

It is important to note that if you are running Exchange based scripts from the Windows Command prompt by passing them as a parameter to Powershell.exe you should add the following line at the top of each script:

For Exchange 2010:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

For Exchange 2007:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

This will load the relevant Exchange Management Shell commands for your script from the vanilla PowerShell session.

Executing Exchange Scripts from a Batch File

You can execute your scripts by adding the the Powershell.exe command (see above) into a Windows Batch file. The batch File can then be scheduled to run as part of a scheduled task – or configured within Group Policy to execute as a start up script.

In the previous part of this series I explained what the Microsoft PST Capture tool was, described a little bit about its architecture and components, and then took you through how you can install the tool onto a server within your environment.

In this part I would like to explain how you can install the PST Capture Agent to relevant machines in your organisation, both manually and through automated distribution, and then take you through the process of a manual PST Capture to a mailbox.

Installing the PST Capture Agent Manually

One of the first things that you might be considering is – where do I (or should I) install the PST Capture Agent?

What might help you during this process is to remember that the primary purpose of the PST capture tool is to enhance compliance and discovery of e-mail data within your organisation – therefore if you start by thinking where do users store PST files?

This will vary between environments – but the following are a couple of ideas to get you going:

• Laptops
• File shares on Fileservers
• NAS locations
• Local Desktops

The PST Capture agent is available in both x32 and x64 bit versions and is available for download from the following location: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28767

In order to manually install the agent doubt click on either the PSTCaptureAgent_x86.msi or the PSTCaptureAgent.msi (x64) file which will start the installation.

From the welcome screen click on the “Next” button – see below

Tick the “I accept the terms in the License Agreement” and then click on the “Next” button – see below

You will then be prompted to confirm the installation folder for the PST Capture Agent – you can set this to a location of your own choosing or accept the defaults, when done click on the “Next” button – see below

You will then be asked to provide either the host name or IP address of the PST Capture Central Server (that you setup in part 1) – you can leave the ports at the default – when done – click on the “Next” button – see below

You will then be presented with a summary of your installation options – if you are happy with them click on the “Install” button – see below

The installer will then copy the relevant files and configure your options – see below

When setup is completed you will be presented with the following screen – click on “Finish” to exit – see below

Installing the PST Capture Agent via Automation

If you have a large infrastructure or you are looking at deploying the agent to a number of machines, you are probably not going to want to use the manual installation method for the agent.

The good news is that as the agent is packaged within an MSI file which allows for silent installation – the command syntax that is used is detailed below:

msiexec /i PSTCaptureAgent_x86.msi /q CENTRALSERVICEHOST=172.31.253.152 SERVICEPORT=6674

You can use the above command to deploy the agent via SMS, Group Policy or any other software distribution means that you have available to you. Remember you will need to ensure that you deploy the correct agent CPU architecture according to the version of Windows that is running.

If you chose to deploy via a Start-up script via group policy, I have provided a simple example below:

$PackageInstallOption = "/i"
$MSIExecMode = "/q"
$MSIx32 = "PSTCaptureAgent_x86.msi"
$MSIx64 =  "PSTCaptureAgent.msi"
$PSTCentralControlServer = "CENTRALSERVICEHOST=172.31.253.152"
$PSTControlPort = "SERVICEPORT=6674"

if (($ENV:Processor_Architecture -eq "x86" -and (test-path env:PROCESSOR_ARCHITEW6432)) -or ($ENV:Processor_Architecture -eq "AMD64")) {

    # Launch x64 installer
    & 'msiexec.exe' $PackageInstallOption $MSIx64 $MSIExecMode $PSTCentralControlServer $PSTControlPort

} elseif($ENV:Processor_Architecture -eq 'x86'){

    # Launch x32 installer
    & 'msiexec.exe' $PackageInstallOption $MSIx32 $MSIExecMode $PSTCentralControlServer $PSTControlPort

}else{

    # Dunno!
    Exit 1

}

The CPU architecture logic above is based upon following article: http://techibee.com/powershell/powershell-get-cpu-architecture-on-windows-7-computer/1012)

If you do decide to use the script above, you should change the paths in $MSIx32 and $MSIx64 to reflect a share on the network where you have stored the agent installer packages.

Performing a Manual Capture – Using the PST Capture Tool

On your Central Capture Server, open the PST Capture Console and from the “PST Searches” area select “New PST Search” – see below:

You will be asked to select the computers that you would like to include within the search – you will only be able to search computers that are online (really?) and which have the PST Capture agent installed – select each machine as required and then click on the “Next” button – see below:

You will then be asked for the locations on each machine that you would like to search, or provide areas which you would like to leave out, in the example below I have chosen only to search the X: drive of the machine(s) that I selected in the previous step, when you are done click on the “Next” button – see below

You will then based asked if you would like to run the discovery manually or via a schedule – for the purposes of this example I have chosen “No Schedule (run manually)” but you are of course welcome to schedule to scan when convenient for you. When you are done click on the “Next” button – see below

Finally you will be asked to name your scheduled scan, when you are done, click on the “Next” button – see below

The PST Capture window will then change to reflect your settings – as this is a manual scan click on the “Search All Now” button, which when complete will populate the lower pane with the PSTs that have been found on each host. From the lower pane, tick the PSTs that you would like to import and then click on the “New Import List” button and select either “Cloud Import List” or “OnPrem Import List” (for my example I am using OnPrem) – see below

The window will then change to reflect your import list selection. On each PST in the “Location” area – using the Right hand mouse button click on the PST entry and from the context menu that appears choose the “Set Destination Mailbox” (you also have the option of clicking on the “Set to file owner” button which will set each destination mailbox to that of the account which owns the file) – see below

When you click on the “Set destination Mailbox” button you will be presented with a pick list of mailboxes that you can import into, choose the relevant mailboxes and then click on the “OK” button – see below

Click on the “Import all now” button – and the process will begin – see below:

Of course there are many options that you can play with within the PST Capture tool that I have not covered within this two part series, therefore I encourage you to explore (in a test lab) to get a better feel for the tool, but I hope that you have enjoyed the basic overview.

The PST Capture Tool was released on the 30th Jan 2012 (see: http://blogs.technet.com/b/exchange/archive/2012/01/30/pst-time-to-walk-the-plank.aspx for more information) after a fairly long and highly anticipated wait by the Exchange Community.

In essence the PST Capture tool has two main tiers of operation:

1. PST Capture Central Service The PST Capture Central Service maintains the knowledge of the PST files found within your organisation and processes the data as it’s moved to your internal (on-premises) Exchange servers or Exchange Online Accounts.
2. PST Capture Agent Discovery of PST files on remote machines is performed by the PST Capture agent that is installed locally on computers within your organisation. The agent Service will also send the relevant PST files to the Central Service Server when requested for Import operations.

There is technically a 3rd tier to the PST Capture Tool which is known as the PST Capture Console – which it the primary management interface that is used by administrators to locate the relevant PST’s on machines and manage the process of PST imports into mailboxes.

Before you crack on and install the tool there are a few Pre-Requisites that you should be aware of before you begin (these are taken from: http://technet.microsoft.com/en-us/library/hh781033.aspx):

• If you intend to import the captured PSTs to an on-premises Exchange server, your organization must be running Exchange 2010

NOTE: The tool can be used with Exchange 2007, but it is important to point out that it has NOT been tested with 2007 – therefore if you run into problems then you are unlikely to be supported by Microsoft.

• If you intend to import the captured PSTs to Exchange Online, your organization must have an Office 365 or BPOS subscription.
• Microsoft .NET Framework 3.5 or 3.5 Service Pack 1 (SP1).
• 64-bit version of Microsoft Outlook 2010 (required only on the host computer where you install the PST Capture Console).
• A Central Service account. Depending on how you plan to use PST Capture, you must grant specific rights to the service account (these are detailed below).
• The server which you choose to install the Central Service must be Windows 2008 x64 or R2.

Quick Tip (from painful experience)

You should ensure that you have all of your domain controllers online and working, especially if you have a configuration that has child domains. Failure to do so could result in the PST Capture Service terminating.

Installation

Download the Tool from the following location: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28767, ensure that your chosen server which will host the Central Service meets the prerequisites mentioned above.

When downloaded double click on the “PSTCapture.msi” file which will launch the installation wizard (click on the “Next” button) – see below;

On the EULA screen, tick the “I accept the terms in the license Agreement” and then click on the “Next” button – see below:

On the “Destination Folder” screen – choose the location where you want the tool installed – personally I would leave it at the default location and then click on the “Next” button – see below:

You will then be asked to provide the details of the Central Service Account. You will need to ensure that the account that you provide has the following permissions (borrowed from: http://technet.microsoft.com/en-us/library/hh781036.aspx )

When you are happy with your choice – click on the “Next” button – see below:

You will then be presented with the Review of your installation choices – review them and if you are happy click on the “Install” button – see below

The installation process will then complete – when done click on the “Finish” button – see below:

In the next part:

I will cover the following:

• The installation of the PST Capture Agent including automated deployment.
• Using the PST Capture Tool

Just a quick post to let you know that the February edition of the www.telnetport25.com newsletter is available for viewing here.

Happy reading!

The February 2012 www.telnetport25.com newsletter is available for download from the following location:

[ February 2012 Newsletter – 400KB ]

In the last part of this series I covered my new tool – telnetMESMS which allows for SMS messages to be sent via the command line to destination mobile phones. The tool makes use of a SMS web enabled API provided by http://www.intellisoftware.co.uk (sign up information is contained in part 1).

In this part I would like to give you a sample script which can give you an idea of how the tool can be used (you are, as always free to use the tool in anyway you see fit within your Exchange environments (just not for spamming mobiles)).

Notifying users of Mailbox Quota Exceeded

This is a simple little script that will check to see which users have the value “smsEnabled” within “extendedAttribute15” – if they do the script will then check the Quota Status of the users mailbox (using Get-MailboxStatistics) and if it is over (e.g. anything other “BelowLimit”) it will call the telnetMESMS.exe program and send a text message to the user letting them know that their mailbox is potentially unusable.

Therefore given the above – if you would like to use the script against mailboxes within your environment, ensure that each of you chosen mailbox has the “smsEnabled” value in “extendedAttribute15” – see below:

The script takes the destination Mobile Phone number for the mailbox notification from the “Mobile” entry for the user in Active Directory (I am using my number below so I have removed a number of digits) – see below

I personally find this script useful, as over the years I have lost count of the amount of senior managers who have said, I never received any warning that my mailbox was about to run out of space (these are typically the people who when they see anything from the System Administrator delete it immediately) so to send them a text message is another means of letting them know that some action in their behalf is required.

# Send a text message to a user if their mailbox is over the storage limit
# Exchange 2010 only!
# Version 1.0
#
# Requires:
# * CustomAttribute15 on each monitored mailbox
#   to be set to smsEnabled
# * The MobilePhone AD Attribute to be populated
#   on the AD account
# * telnetMESMS tool
# * IntelliSoftware SMS Account with Credit
#
# Author: Andy Grogan
# http://www.telnetport25.com

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
$Mailboxes = Get-Mailbox | Select Identity,CustomAttribute15 | where {$_.CustomAttribute15 -eq "smsEnabled"}

Foreach($mbx in $Mailboxes){

    $QuotaStatus = Get-MailboxStatistics $mbx.Identity
    if($QuotaStatus -ne "BelowLimit"){
        $MobileNumber = Get-User $mbx.Identity | Select MobilePhone
        $Size = $QuotaStatus.TotalItemSize
        $Message = "Your Mailbox is over Quota: $Size"
        & 'c:\telnetMESMS\telnetMESMS.exe' $MobileNumber.MobilePhone $Message "Exchange"
    }

}

The script MUST be downloaded to the same folder where the telnetMESMS.exe tool is installed (this you would have installed from part 1) and should be scheduled to run at a interval which suites your organisation.

When the message has been sent – the recipient of the message should see something like the following – see below:

I hope that you find this useful, and it gives you some ideas of some other situations where you can use the telnetMESMS tool.

Some of you will be aware that I have recently been working on a series which takes a look at Monitoring Exchange Server using Nagios Core. Whilst doing so, I started to think about administrative notifications and the different types of channel that can be used to get key information across to you in a timely manner.

Broadly speaking, when something happens within a monitored Exchange environment – notifications can be sent to the relevant administrator via:

• E-Mail
• Pager
• SMS
• Net Send
• Visual Notification (Red, Yellow and Green)

More commonly (from what have experienced) people tend to use either e-mail or SMS.

So with those (probably incorrect) assumptions in mind I decided that I was going to have a look at sending SMS notifications when a given event occurs. The idea behind this was that in the Nagios series I would like to cover how to send both e-mail notifications and SMS from Nagios when a state change occurs. Now e-mail is pretty straightforward, however SMS is a little more involved.

I had a look around on the web and there are a plethora of ways to get SMS notifications to people, ranging from dedicated SMS gateways through to Web Based API’s. Ideally I wanted a free SMS solution, but alas whilst there are a number of “free SMS providers” on the web – none quite matched what I want to do.

In essence I wanted to code a C# console application that could accept a number of command line parameters and via a web API send them to a destination mobile – this was going to cost some money – so my search then changed to the most cost effective solution provider (that I could find). In the end I did find a provided that met all of my criteria (more on this a little later)

So therefore in this article I would like to present to you the telnetMESMS tool and in the next part show you how you can use the tool with PowerShell to send some SMS notifications based upon administrative events. I will then hand further coverage of the tool over to he Nagios Core articles that I have been doing and show you how you can integrate it show that you receive SMS messages.

Download

The telnetMESMS application can be downloaded from the following location:

[ telnetMESMS Setup – 600KB ]

Requirements

In order to use the software you will need to ensure that both your client system conforms to the following pre-requisites:

• .Net 3.5
• The client system must have access to the internet ~ and not via a proxy server (this version of the tool does not support proxy connections) – I will adding this in very soon
• A registered account with http://www.intellisoftware.co.uk and some SMS credits (you get 5 free – more can be purchased)

Before you begin

The “telnetMESMS.exe” is in essence an encapsulation of the Intelli Software SMS web API.

To be open from the start, if you would like to make use of this tool in a production scenario you will need to have signed up an Intelli Software Account which you can do from here: http://www.intellisoftware.co.uk/

Upon sign up you can get 5 complimentary SMS messages (which admittedly is not a huge amount for a trial) – but you can purchase more at a fairly reasonable rate – example below – taken from the Intelli Software website:

This would work out to be about £33.00 for 500 texts based upon their Economy plan.

Now you might be thinking – OK ~ so how much are Intelli Software paying me?, and I wouldn’t blame you for thinking that – but I can say in all honesty – nothing, not a jot, nada.

The reason(s) as to why I have chosen to advocate of their services are because:

• I have an inherent (at the moment) mistrust of “Free” SMS services – I feel more comfortable using a commercial provider (if people have any other suggestions which offer a secure service with a good web API I would be more than happy to take a look at modifying the tool)
• I needed a UK based SMS provided (to work both in my testing of the application, and for my own work purposes) – its important to note that Intelli Software will send to non-uk mobiles
• Intelli Software provide a dedicated .NET Class (located here: http://www.intellisoftware.co.uk/sms-gateway/dotnet-component/) which allows for easy development of applications such as mine

NOTE: It is important to point out that this project uses the IntelliSMSDotNet.dll which is distributed with the telnetMESMS.exe file – this dll does not belong to me, it is offered as a free runtime with your IntelliSoftware account.

Installation of the Tool

Download the setup installer from the link above to a location on your Exchange Server – double click on the “setup.msi” file which will present you with the Welcome Screen – see below:

Select the target installation path (I recommend that you leave it at the default setting) – when done click on the “Next” button – see below

You will then be presented with he “Ready to Install” screen – if you are using Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 you may be asked to elevate your privileges via UAC – click on the “Install” button – see below:

The setup software will then install the application binaries to your computer – see below:

When setup has completed – click on the “Finish” button – see below

Basic use of the SMS Tool

The default installation location of the tool is “C:\telnetmeSMS” – therefore you will need to open a Command Prompt and change to that directory. If you changed the default location during the installation you should navigate there.

All command line options for the tool can be viewed via typing the following at the command prompt:

telnetMESMS.exe ?

– see below

Before you can use the telnetMESMS tool you will need to configure you Intelli Software account information. This process will create an XML file called smsConfig.xml which contains your online account username and password.
I have written the application so that it stores the password for your account within the XML file encrypted using MD5 so it is relatively secure.

In order to setup the telnetMESMS client for the first time you need to execute the software using the “config” parameter (this will either need to be performed on each client which you use the tool on – or you can setup on one server and then copy the smsConfig.xml).

Therefore from the command line navigate to the folder in which your downloaded the telnetMESMS.exe program file and type the following command:

telnetMESMS.exe config

This will prompt you for two items of information:

1. Intelli Software User Account
2. Intelli Software Password

Provide them as per your sign up process – see below:

In order to send a text message to mobile phone via the Intelli Software gateway the program requires 3 parameters:

telnetMESMS.exe <mobile number> "<Text Message>” “<Sender ID>”

– see below:

When you have sent the text message the program will give you the following output:

If everything has worked correctly you should receive a text message on your mobile phone, similar to the example below:

In the next part – How can this be used with Exchange?

In the next part I will cover:

• How you can use the tool to send text alerts to users who have in an alert state

As the Boom Town Rats (and Sir Bob) said, I don’t like Mondays. Some of you lucky folks don’t have to work on a Monday (or indeed some other days of the week) – so are you tired of setting your Out of Office the night before you are not in the office on a regular basis?

Well the other day I posted an article that was based around some fun that you can have with the “Set-MailboxAutoReplyConfiguration” within Exchange 2010. Naturally I posted the article on Twitter and a chap called Peter De Rop came back and asked could the script be used to activate an OOF every Monday as he is not in the office.

I thought that this was a great idea – I started thinking – could I develop a Powershell script which could be scheduled to automatically set the Out of Office for people whom do not work on specific days of the week, and then turn it off on the days which they do work?

So the following is what I came up with:

# Set a users Out of Office Automatically based upon their working pattern
# Exchange 2010 only!
# Version 1.0
# Author: Andy Grogan
# http://www.telnetport25.com

$Day = Get-Date
$TodayDate = $Day.DayOfWeek
$Interim = Get-Mailbox | Select Identity,CustomAttribute15 | where {$_.CustomAttribute15 -ne ""}
[array]$CustomAttrib = $Interim.CustomAttribute15.Split(";")

Foreach($attrib in $CustomAttrib){

    if($attrib -eq $TodayDate){
        Set-MailboxAutoReplyConfiguration -Id $Interim.Identity -AutoReplyState Enabled -InternalMessage "Sorry I am out of the office I don't work on: $TodayDate" -ExternalMessage "Sorry I am out of the office I don't work on: $TodayDate"
    }else{
        Set-MailboxAutoReplyConfiguration -Id $Interim.Identity -AutoReplyState Disabled
    }
}

The script works by looking at “CustomAttribute15” of all the users within your organisation and parses the name of the day of the week which they do not work on if the value is populated correctly.

For example; if you have a test account (or normal account) who does not work on Monday,Wednesday,Friday that you would like to set a generic Out of Office for on those days – you can within the Exchange 2010 Management Console can add the names of the days (separated with a “;”) to “CustomAttribute15” – see below

The script above can then be scheduled from the Windows Task manager (probably from within a Batch file that calls Powershell and the script as a parameter) at midnight each night – and when it runs will set the Out of Office for all relevant users.

There are naturally some changes that could be made to improve the script – but it is provided to get your creative juices going – hope that you have fun!

Script Description

This Powershell script is a sample which is attached to this article.
The script performs the following functions:

• Is executed from the Exchange Management Shell
• Accepts a single mandatory parameter – 1) ReportFile
• Reports on the OOF status for each user in your organisation to a text file

Download

[ GetOOFExchange2010.ps1 – 1KB ]

Usage

Please refer to the following article:

• Exchange 2010 Out of Office Fun with Set-MailboxAutoReplyConfiguration…

Script Description

This Powershell script is a sample which is attached to this article.
The script performs the following functions:

• Is executed from the Exchange Management Shell
• Accepts two mandatory parameters – 1) Mailbox Name 2) Text file with OOF Messages
• Sets the Internal and External OOF Messages according to the text file
• Accepts two optional parameters 1) StartDate 2) EndDate – which set between which periods the messages should be displayed

Download

[ SetOOFExchange2010.ps1 – 1KB ]

Usage

Please refer to the following article:

• Exchange 2010 Out of Office Fun with Set-MailboxAutoReplyConfiguration…

In between some of the other stuff that I have been working on; I have also been thinking about the future of the OOOCTA tool. Currently OOOCTA supports both Exchange 2007 SP 1 (and above) as well as Exchange 2010, however the underling code infrastructure is a little complicated to say the least in order to accomplish the dual support.

As some of you may know, Exchange 2010 supports setting a users OOF natively via the Set-MailboxAutoReplyConfiguration cmdlet, however Exchange 2007 does not have a corresponding command – therefore the OOOCTA contains quite a lot of code logic which makes use of the EWS API to allow for Out of Office functionality to be set on Exchange 2007 mailboxes.

My current line of thinking is to make version 3.5.2 of the OOOCTA tool the last which supports Exchange 2007, and version 4 will be a pure Exchange 2010 product. Taking this route would allow for me to remove a lot of “code bloat”, as well as improve some security and reporting features – as well as make the overall installation experience much simpler.

I have already knocked up a very early version of the “outofofficeservice.exe” which uses the Set-MailboxAutoReplyConfiguration cmdlet and it works like a charm (and reduced the source code within the service executable by around 120 lines).

I have not made up my mind at the moment, and if you are using the (OOOCTA) tool with Exchange 2007 and would like me to continue with the development – then there might be a case for split versions (one for E27 and one for E210) – but please let me know!

Set-MailboxAutoReplyConfiguration

Ok so enough musing about the OOOCTA – let’s have some fun with with the Exchange 2010 Set-MailboxAutoReplyConfiguration cmdlet. Just before we get going I would like to just briefly give you an idea as to why it is so much easier than the EWS API approach in Exchange 2007?

Consider the following sample code (which is strongly based upon a script by Mike Pfeiffer) – which can be used with both Exchange 2007 and Exchange 2010 servers with the EWS 1.2 API installed (note that it is only a code sample ~ if you would like to see the complete script have a look here).

In essence the script uses the EWS 1.2 to create a function called “Set-EWSOOFSettings” that will allow for the OOF to be set on a users mailbox (either in Exchange 2007 or Exchange 2010). Its worth also noting that in order for it to work, the administrator account who calls it needs to have Full Access Permissions on the target mailbox:

function Set-EWSOofSettings() {
        [CmdletBinding()]
    param(
        [Parameter(Position=0, Mandatory=$true)]
        [System.String]
        $Identity,
        [Parameter(Position=1, Mandatory=$false)]
        [System.String]
        $State,
        [Parameter(Position=2, Mandatory=$false)]
        [System.String]
        $ExternalAudience,
        [Parameter(Position=3, Mandatory=$false)]
        [System.DateTime]
        $StartTime,
        [Parameter(Position=4, Mandatory=$false)]
        [System.DateTime]
        $EndTime,
        [Parameter(Position=5, Mandatory=$false)]
        [System.String]
        $InternalReply,
        [Parameter(Position=6, Mandatory=$false)]
        [System.String]
        $ExternalReply,
        [Parameter(Position=7, Mandatory=$false)]
        [System.String]
        $ver = "Exchange2007_SP1"
        )

    begin {
        Add-Type -Path "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"

    }

    process {
        $service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService -arg $ver
        $service.AutodiscoverUrl("administrator@seg.com")    

        if($Identity -notmatch "@") {
            $Identity = (Get-Recipient $Identity).PrimarySMTPAddress.ToString()
        }        

        $oof = $service.GetUserOofSettings($Identity)

        if($StartTime -and $EndTime) {
            $Duration = New-Object Microsoft.Exchange.WebServices.Data.TimeWindow `
            -arg $StartTime,$EndTime
            $PSBoundParameters.Duration = $Duration
            $PSBoundParameters.State = "Scheduled"
            [Void]$PSBoundParameters.remove("StartTime")
            [Void]$PSBoundParameters.remove("EndTime")
        }

        foreach($p in $PSBoundParameters.GetEnumerator()) {
            if($p.key -ne "Identity") {
                $oof."$($p.key)" = $p.value
            }
        }
        $service.SetUserOofSettings($Identity,$oof)
    }
}

Now, compare the above to the “Set-MailboxAutoReplyConfiguration” cmdlet which performs pretty much the same function as the code above:

Set-MailboxAutoReplyConfiguration -id Alan.Reid -InternalMessage "Blah" -ExternalMessage "Blah"

As you can see there is a massive difference, plus the command will execute against target Mailboxes as the account that you are logged on with (which would be your Exchange Administration Account) even if it is not the Mailbox owner (e.g. does not have Full Access Permissions).

Expanding on the “Set-MailboxAutoReplyConfiguration” the following is a sample script that can be executed from the Exchange Management Shell which can take the “Internal” and “External” Out of Office settings for a user from a text file:

# Exchange 2010 - Set Out of Office Script using a text file
# Version 1.0
# Author: Andy Grogan
# http://www.telnetport25.com

Param(
    [Parameter(Mandatory=$true)]
    [System.Management.Automation.ValidateNotNullOrEmptyAttribute()]
    [string] $mbxID,[Parameter(Mandatory=$false)]
    [System.Management.Automation.ValidateNotNullOrEmptyAttribute()]
    [string] $SourceFile,[System.DateTime] $startDate,[Parameter(Mandatory=$false)]
    [System.DateTime] $EndDate
)

$Message = Get-Content $SourceFile

if($startDate -eq $null -or $EndDate -eq $null){
    Set-MailboxAutoReplyConfiguration -Id $mbxID -AutoReplyState Enabled -InternalMessage "$Message" -ExternalMessage "$Message"
}else{
    Set-MailboxAutoReplyConfiguration -Id $mbxID -AutoReplyState Scheduled -InternalMessage "$Message" -ExternalMessage "$Message" -StartTime "$startDate" -EndTime "$endDate"
}

The OOF message is contained within the path that is passed within the “$SourceFile” parameter – therefore in my example the text file contains:

This user has left
Thank you for your e-mail, this user has now left our organisation, please contact McLovin' on xxx22-555.
Regards,
HR - My Organisation

The following screen shots shows the script in action when setting the OOF for the user without a schedule:

.\SetOOFExchange2010.ps1 –mbxID <samAccountName> –SourceFile <path to source file>

The Out of Office for the user will then look like the following:

You can also add the –StartTime and –EndTime parameters to the script to schedule to OOF.

Some further fun can be had by adding in a few HTML tags to the source text file – for example if you change the source file to look like the following:

<Font color="red"><h1>This user has left</h1></font>
Thank you for your e-mail, <b>this user has now left our organisation</b>, please contact McLovin' on xxx22-555.
Regards,
HR - My Organisation

The OOF Messages will look like the following:

Get-MailboxAutoReplyConfiguration

As you might expect, as well as giving you the ability to Set the OOF state in Exchange 2010 you can also get the Out of Office information for a given mailbox using the Get-MailboxAutoReplyConfiguration cmdlet.

The syntax for this command (in its most basic form) is:

Get-MailboxAutoReplyConfiguration –id <samAccountName>

The sample script below gives you a very simple overview of how you can report on the settings of each mailbox in your organisation where the Out of Office status is either “Enabled” or “Scheduled” to a text file:

# Exchange 2010 - Get Out of Office Report to a text file
# Version 1.0
# Author: Andy Grogan
# http://www.telnetport25.com

Param(
    [Parameter(Mandatory=$true)]
    [System.Management.Automation.ValidateNotNullOrEmptyAttribute()]
    [string] $reportFile
)

New-Item -ItemType file $reportFile -Force
$date = Get-Date
Add-Content $reportFile "Out of office report file: $Date"

$repMBXData = Get-Mailbox | Get-MailboxAutoReplyConfiguration | where {$_.AutoReplyState -eq 'Enabled' -or $_.AutoReplyState -eq 'Scheduled'}

foreach($oofEntry in $repMBXData){

        Add-Content $reportFile "---------------------------------------------"
        Add-Content $reportFile "Mailbox ID:"
        Add-Content $reportFile $oofEntry.Identity
        Add-Content $reportFile "Out of Office Status:"
        Add-Content $reportFile $oofEntry.AutoReplyState
        Add-Content $reportFile "Internal Message:"
        Add-Content $reportFile $oofEntry.InternalMessage
        Add-Content $reportFile "External Message:"
        Add-Content $reportFile $oofEntry.ExternalMessage
        Add-Content $reportFile "Start Time:"
        Add-Content $reportFile $oofEntry.StartTime
        Add-Content $reportFile "End Time:"
        Add-Content $reportFile $oofEntry.EndTime
        Add-Content $reportFile "---------------------------------------------"
        Add-Content $reportFile "`n"
}
Invoke-Item $reportFile

The script syntax looks like the following:

.\GetOOFExchange2010.ps1 –reportFile <path to report file>

The output of the script looks like the following:

Out of office report file: 01/29/2012 15:39:24
---------------------------------------------
Mailbox ID:
prepAD.local/ExchangeUsers/Alan.Reid
Out of Office Status:
Enabled
Internal Message:
<html>
<body>
<font color="red">
<h1>This user has left</h1>
</font>Thank you for your e-mail, <b>this user has now left our organisation</b>, please contact McLovin' on xxx22-555. Regards, HR - My Organisation
</body>
</html>

External Message:
<html>
<body>
<font color="red">
<h1>This user has left</h1>
</font>Thank you for your e-mail, <b>this user has now left our organisation</b>, please contact McLovin' on xxx22-555. Regards, HR - My Organisation
</body>
</html>

Start Time:
29/01/2012 15:00:00
End Time:
30/01/2012 15:00:00
---------------------------------------------

Using Set-MailboxAutoReplyConfiguration to disable a user OOF

If you would like to disable to OOF for a given user in your environment you can use the following:

Set-MailboxAutoReplyConfiguration –id <mailbox name> –AutoReplyState Disabled

Script Downloads

If you would like to download the scripts (rather than copy and paste them) for this article, I have made them available here and here.

Script Description

Powershell based NSClient++ monitoring script for use with Nagios Core.
This script performs the following functions:

• Retrieves the Databases that are running on the monitored server
• Checks to see if they are mounted
• If no databases are resident on the server (in DAG configurations) the script returns the following information string to the Nagios interface:

  ”OK: No databases are active on this host”

If any database is dismounted the script will return the following exit code:

2: CRITICAL

If all Databases are mounted the script will return an exit code of:

0: OK

Download

[ GetExchangeLocalDBs.ps1 – 1 KB ]

Usage

Please refer to the following article(s):

• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 1–Configuring Ubuntu for the Installation of Nagios Core…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 2–Setting up basic Windows Server Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 3–Setting up basic Exchange 2010 Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 4–Custom Exchange Monitoring Scripts…

Script Description

Powershell based NSClient++ monitoring script for use with Nagios Core.
This script is designed to Monitor the Replication Status of each database within a DAG Configuration. The script can return one of 2 error codes which are as follow:

0: OK
2: CRITICAL

Download

[ GetDAGReplicationStatus.ps1 – 1 KB ]

Usage

Please refer to the following article(s):

• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 1–Configuring Ubuntu for the Installation of Nagios Core…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 2–Setting up basic Windows Server Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 3–Setting up basic Exchange 2010 Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 4–Custom Exchange Monitoring Scripts…

Script Description

Powershell based NSClient++ monitoring script for use with Nagios Core.

This script is designed to return the name of the DAG which the host server is a member of. The script only returns the following status code:

0: OK

However the return description into the Nagios Interface will either be:

• Name of the DAG
• This Server is not part of a DAG

Download

[ GetDAGnfo.ps1 – 1 KB ]

Usage

Please refer to the following article(s):

• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 1–Configuring Ubuntu for the Installation of Nagios Core…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 2–Setting up basic Windows Server Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 3–Setting up basic Exchange 2010 Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 4–Custom Exchange Monitoring Scripts…

Script Description

Powershell based NSClient++ monitoring script for use with Nagios Core.
This script is designed to monitor the status of the Content Index for each mailbox DAG database within your environment – the script has two exit statuses:

0: OK
2: Critical

Critical is flagged when one or more Content Indexes are in a failed state within your DAG environment.

Download

[ Exchange2010ContentIndexMonitor.ps1 – 1 KB ]

Usage

Please refer to the following article(s):

• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 1–Configuring Ubuntu for the Installation of Nagios Core…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 2–Setting up basic Windows Server Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 3–Setting up basic Exchange 2010 Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 4–Custom Exchange Monitoring Scripts…

Script Description

Powershell based NSClient++ monitoring script for use with Nagios Core.
This script is designed to monitor the “LastFullBackup” attribute of the host Mailbox Server – the script has two exit statuses:

0: OK
2: CRITICAL

Critical (2) is flagged when one or more databases hosted on the monitored server has a “lastFullBackup” of 2 days or more.

Download

[ Exchange2010BackupMonitoring.ps1 – 1.3 KB ]

Usage

Please refer to the following article(s):

• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 1–Configuring Ubuntu for the Installation of Nagios Core…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 2–Setting up basic Windows Server Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 3–Setting up basic Exchange 2010 Monitoring…
• Installing Nagios on Ubuntu Server 11.10 then Monitoring Windows and Exchange Servers–Part 4–Custom Exchange Monitoring Scripts…

Ok, I have to admit that this series has been a lot of fun (well for me anyway ~ I have had a blast) – but this part is perhaps by far and away the most fun that I have personally had – as it means that I have needed to develop some sample Powershell scripts for monitoring Exchange 2010 using Powershell with Nagios!

This is one of the real boons for Nagios – as by developing your own Powershell monitoring scripts which return values to the Nagios Core interface means that you are in essence using Nagios as a monitoring “wrapper” providing your with the flexibility to pretty much monitor any facet of your Exchange Systems.

Just as a quick overview to the series for those of you whom are just joining us:

• In Part 1
  I covered how you can install Nagios Core 3.3.1 onto  an existing Ubuntu 11.10 server within your environment
• In Part 2
  I covered how you can setup basic monitoring on your first Windows Server – making use of the NSClient++, I also covered how you could setup a basic “check_nt” monitoring service
• In Part 3
  I covered how you can install the NRPE daemon onto your Nagios Server – and then use the NSClient to execute a basic Powershell script and report the output back into the Nagios interface

Custom Powershell for Exchange 2010 for use with Nagios

There are a couple key things to remember when developing custom Powershell scripts for use with Nagios:

• You need to structure your scripts so that they always return an exit code which is proceeded by a Write-Host which adds a description to the last values returned (more on this later)
• If you operate an environment that has a mix of DAG and Basic Servers (DAG and non-DAG) or for that matter – servers which operate multiple roles (MBX,CAS,HT) code your scripts so they can handle the absence of any specific features for example; if you develop a script that is designed to operate on DAG based servers, you should code in logic that can handle DAG features nothing being available – as a sample see the “GetDagnfo.ps1” script which is available for download below

Powershell exit codes for Nagios

As mentioned above – it is important that any Powershell that your write for use with Nagios returns and exit code.
Powershell has the ability to terminate execution with an exit code – this is demonstrated here – you can within your own scripts return any numeric decimal code that you want by using the “exit” statement.

However that being said, Nagios supports four exit status codes – which your scripts should conform to, these are as follows:

Exit codes 0 and 2 are reflected within the Nagios core interface like so:

Exit code 0:

Exit code 2:

Ok so what is the Powershell script behind the Backup Monitoring?

The script itself is pretty straight forward, and currently only checks for the lastFullBackup value on the Databases are resident on the Monitored Exchange Server.
Within the script there is a variable called $ThreshHold which reflects the number of days that can lapse without a full backup before the script will return an error to the Nagios Interface.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
$localServerName = Get-WmiObject -Class Win32_ComputerSystem | Select Name
$ThreshHold = 2
$Results = Get-MailboxDatabase -Server $localServerName.Name -Status | Select Identity,Server,LastFullBackup | where {$_.Server -eq $localServerName.Name}

foreach($itm in $Results){

        if($itm -eq $null){
            $Output = "OK: No Databases are active on this host"
            $NagiosResult = 0
        }else{
            if($itm.LastFullBackup -eq $null){
                $lastBackupSeed = 9999

            }else{
                $lastBackupSeed = New-TimeSpan $($itm.LastFullBackup) $(Get-Date)
            }
            if($lastBackupSeed.days -gt $ThreshHold -or $lastBackupSeed -eq 9999){
                $Res = "CRITICAL: Database Backup out of Schedule: " + $itm.Identity
                $Output += $Res + " "
                $statFlag = 1
            }else{
                $Output += "OK: Database: " + $itm.identity + " has a recent backup" + " "
            }
        }
}
Write-Host $Output
if($statFlag -eq 1){
    exit 2
}else{
    exit 0
}

Setting your scripts up

As detailed in part 3 – there are 5 steps that you need to follow in order to get your Exchange Monitoring Scripts reporting into the Nagios interface – these are as follows:

1. On your Exchange Server where you have installed the NSClient++, Copy (or save) the scripts into the NSClient “Scripts” folder (this should be in “C:\Program Files\NSClient++\Scripts”).
2. Perform the following within the NSC.ini file (this should be located in “C:\Program Files\NSClient++\”)

   For this example we will be using the “Exchange2010BackupMonitoring.ps1” script.
   Within the NSC.ini find the section entitled [ NRPE Handlers ] then add the following command:

check_exBackup=cmd /c echo scripts\Exchange2010BackupMonitoring.ps1; exit($lastexitcode) | powershell.exe -command -

Save the file, and then restart the “NSClient++” service from within the Windows Services Manager

1. From your Nagios Server using Filezilla – download a copy of the commands.cfg (located in /usr/local/nagios/etc/objects)
   Open it within Notepad++ and add in the following command definition

define command{
    command_name    check_exbackup
    command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -t 120 -c check_exBackup
    }

Save the file, and then upload it back to your Nagios Server.

1. From your Nagios Server using Filezilla – download a copy of the windows.cfg (located in /usr/local/nagios/etc/objects)
   Open it within Notepad++ and add in the following Service Definition for your Exchange Host:

define service{
use generic-service
host_name prod-ex2010-01.prepad.local
service_description Exchange DBs on Host
check_command check_exdb
}

1. Logon to your Nagios Server using PuTTY and from the command line enter in the following command:

sudo /etc/init.d/nagios restart

Sample Monitoring Script Downloads

Below I have provided 5 sample Powershell scripts which your are free to use / modify as you see fit. These should be downloaded to your Exchange Server into the NSCilent++ Scripts Directory “C:\program files\NSClient++\Scripts”
Before you use them, you will need to ensure that you have created the relevant service and command definitions (described above).

[ Exchange2010BackupMonitoring.ps1 – 1.3 KB ]
[ Exchange2010ContentIndexMonitor.ps1 – 1 KB ]
[ GetDAGnfo.ps1 – 1 KB ]
[ GetDAGReplicationStatus.ps1 – 1 KB ]
[ GetExchangeLocalDBs.ps1 – 1 KB ]

Sample Output within Nagios

The following is a sample output from the above monitoring scripts within my environment, naturally the ideal situation is to have all your statuses reporting “OK” as you can see I have a problem with Backups!

In part 5

In part 5 I will be covering the following:

• Grouping Servers and Services into Categories
• Troubleshooting Tips
• Sample Exchange Service Files
• Reporting

Welcome to part 3 of my series which is based around how you can use Nagios to monitor both Windows and Exchange Servers. In the previous two posts (Part 1 is located here and Part 2 is located here) – I covered the following:

Part 1

• Setting up Nagios on Ubuntu

Part 2

• Setting up basic monitoring for a Windows Server

In this part I would like to cover setting up some basic Exchange monitoring for Exchange 2010 DAG based servers using a script which is freely available in the Nagios community.
However before we get started there are a number of things that we need to configure on both the Exchange Server and the Nagios Server before we can effectively monitor our Exchange servers.

Installing NRPE on your Ubuntu Server

The definition of the NRPE Add-In for Nagios is as follows (taken from the Nagios Website):

NRPE allows you to remotely execute Nagios plugins on other Linux/Unix machines. This allows you to monitor remote machine metrics (disk usage, CPU load, etc.). NRPE can also communicate with some of the Windows agent add-ons, so you can execute scripts and check metrics on remote Windows machines as well.

In order to remotely execute Exchange specific monitoring commands from your Nagios server (which will be via Powershell) you will need to install the relevant components of the Nagios Remote Plugin Executor (NRPE) environment within your Nagios Environment.

NOTE: It is very important that you follow these steps as closely as possible as I personally found getting NRPE to work a bit of a hassle.

Using PuTTY (see part 1) logon to the Terminal of your Ubuntu server and type in the following commands:

sudo –s

cd /downloads

wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.13.tar.gz

tar –zxvf nrpe-2.13.tar.gz

./configure -–enable-command-args -–disable-ssl

make all

make install-plugin

make install-daemon

make install-daemon-config

apt-get install xinetd

make install-xinetd

You will then need to add the nrpe protocol to the Ubuntu Servers Services file.

From the Terminal Window type in the following command:

nano /etc/services

From the text editor window that appears you will need to add the following line:

nrpe 5666/tcp

When you have made the changes (as per the example above) press CTRL-O (to save the file) and CTRL-X (to exit).

You should now restart the the xinetd server using the following command:

/etc/init.d/xinetd restart

You should now check to ensure that the xinetd services (which encapsulates the NRPE service) is listening on your Ubuntu host – in order to do this you should type the following command into the Terminal window:

netstat –at | grep nrpe

You should be presented with the following output:

Configuring your Exchange Server for Monitoring

In part 2 I explained how you can install the NSClient++ monitoring agent on a Windows server in order to perform some basic monitoring. The example made use of the 32bit NSClient++, in order to Monitor Exchange 2010 you will need to download the x64 client to your Exchange servers and using the same procedure which is contained in part 2 install on your Exchange Server.

You should ensure that you also follow the process of defining the Exchange Server as a Windows Host within the windows.cfg file as you did in part 2.

Downloading Nagios compatible Exchange 2010 Monitoring Scripts

There are a number of Exchange 2010 Monitoring Scripts out in the Nagios community and by the end of this series I would like to put you in the position where I have provided you with some of my own, and hopefully enabled you to write your own (if you like writing stuff in Powershell).

However to get us started I have been using a script which was originally written by “The Angry Admin”, I have modified it slightly (to automatically detect the Host Exchange Server) – but aside from that it remains largely unchanged therefore the intellectual rights belong to “The Angry Admin”.

You should download the script to the “C:\program files\NSClient++\Scripts” folder on the Exchange 2010 server that you wish to monitor.

[ Exchange 2010 DAG Replication Status Script for Nagios – 1KB ]

When you have downloaded the script you will need to perform the following steps on the Exchange Server:

• Set the Powershell Execution Policy to “Remote Signed” – this is done by opening an Powershell command prompt and typing the following command:

  Set-ExecutionPolicy “RemoteSigned”

Configuring the NSClient++ ini File

• On the Exchange Server locate the “NSC.ini” (NSClient configuration file) which should be located in “C:\Program Files\NSClient++\” and perform the following:
  • Within the file locate the [NRPE] section and ensure that the following entries are either present or uncommented (e.g. the “;” is removed)

  # NRPE PORT NUMBER
  port=5666
  
  # USE SSL SOCKET
  use_ssl=0
  
  # ALLOWED HOST ADDRESSES
  allowed_hosts=<Nagios Server Address> # e.g. in my configuration it’s allowed_hosts=172.31.253.159

  • Within the “NSC.ini” you will find a section called [NRPE Client Handlers] – rename this to [NRPE Handlers] and then add:

  check_exrep=cmd /c echo scripts\exrep.ps1 | powershell.exe -command -

  • When you have made the above changes, save the file and then restart the NSClient++ Service from the Windows Services manager

Configuring the Exchange Service Monitoring within Nagios

We are now done with the configuration on our Exchange Server, and now need to turn our attentions back to the Ubuntu Nagios Server. In part 2 of this series I explained how you can add Service Monitoring to a Windows Service – this made use of two files:

• Windows.cfg
• Commands.cfg

Each of which you can download via Filezilla to your local machine (into the Nagios_Configuration_Files directory which we setup in part 2).

To execute the Powershell script file which we placed on our Exchange server we need to modify the above files (using Notepad++ as described in the previous part).

In the windows.cfg file add the following Service definition:

define service{
    use            generic-service
    host_name        prod-ex2010-01.prepad.local ;This should be changed to the host definition of your Exchange Server
    service_description   Exchange Database Status
    check_command    check_exrep
    }

When you have made the above modifications save them in Notepad++ (but don’t upload the file to the Nagios server just yet!)

Open the “Commands.cfg” file in Notepad++ and ensure that the following lines are present within the file – if they are not you should add them:

# 'check_nrpe' command definition
define command {
    command_name check_nrpe
    command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 180 -c $ARG1$
}

Then add the following command definition:

define command{
    command_name    check_exrep
    command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -t 120 -c check_exrep
    }

When you have added the above, you should save the file, and then using Filezilla upload the files to your Ubuntu Server to the “/usr/local/nagios/etc/objects directory”.

When you have done the above, restart the Nagios Server on the Ubuntu host from your PuTTY session via the following command for the changes to take effect:

/etc/init.d/nagios restart

When the above changes have been made you should see the following within the Nagios Web interface:

A clearer view looks like the following:

In the next part

In the next part of the series I would like to cover some custom Exchange 2010 monitoring scripts that make use of the NRPE interface which will give you some ideas on how you can develop an enriching monitoring environment.

Fellow Blogger and Exchange expert Paul Cunningham is currently canvassing for attendees for a FREE online Exchange 2010 boot camp. Having attended one of Paul’s sessions online I can highly recommend people sign up and attend – as Paul’s efforts are exceptionally well structured and informative. Any readers of my blog whom would like to have a highly informative experience from an exceptionally gifted Exchange professional – please sign up!

In the first part of this series I covered how you can get a working instance of Nagios Core on a Ubuntu VMWare server within your environment. What I would like to cover in this part is how you can begin to perform some basic monitoring on a Windows Server within your infrastructure using the Nagios Core Server that you configured in Part 1.

Installing the Monitoring Client on Windows Server that you wish to manage

Log onto the Windows Server that you wish to manage. You will need to download the NSClient++ from the following location: http://nsclient.org/nscp/downloads – you will need to select the correct architecture which fits your client system (Win32 or x64) – and I recommend that you download the MSI file rather than the zip (mainly for simplicity and it is easier to build an automated deployment around).

When you have the MSI file on your server you will need to perform the following steps:

Double click on the “NSClient++-0.3.9-Win32.msi” file which will then present you with the installer welcome screen (below) – click on the “Next” button

On the EULA screen, tick the “I accept the terms of the license Agreement” option and then click on the “Next” button – see below:

Next you will be asked to choose the components that you would like to install – these include the actual program binaries, configuring a Windows Firewall exception should you wish, registering the program to run as a service (recommended) and a number of functional plugins (which enable a number of checks on your system and the ability to communicate with a number of monitoring systems which support various listeners include Nagios).

For the purposes of this article I have chosen to install all components (as per the screenshot below) – when you are happy with your own choices click on the “Next” button:

As this is a new install the next screen is not really that relevant, however suffice to say that if you have a pre-existing configuration file in the installation location (for example during a client upgrade) – you will be prompted if you would like to use the existing file or create a new one. In our case we can just click on the “Next” button:

The next screen asks you to complete some information about you Nagios server (e.g under the “Allowed Hosts” section – within the IP address text box – you can provide a number of hosts that the agent can report to – in our case this will be the IP address of your Nagios Server).

In the NSClient Password section you should provide a password to secure (remember not encrypt) communications  between the client server and the Nagios server. This is used by the “check_nt()” function (more on this later) for Service Calls. In the “Modules to load” section I have ticked all options – however you should ensure that the “Enable nsclient server (check_nt)” is enabled and then click on the “Next” button – see below:

You will now be ready to install the NSClient on the server that you wish to monitor – click on the “Install” button – see below:

When setup has completed you will be asked if you wish to Start the NSClient Service (ensure that the Start Service is ticked) – you are of course welcome and encouraged to donate to the project as it does provide a unique service to folks like us – however when happy click on the “Finish” button:

Configuring Nagios to Monitor your Windows Server

Now this is where things get a more little involved as in order to setup the Windows monitoring configuration we need to make a few changes to some of the Nagios configurations files which are located on the Ubuntu server that we created in part 1.

Firstly I recommend that you setup sFTP to connect to the Linux file system on your Nagios Server (remember the OpenSSH server that we installed in part 1?). In order to do this, you need an FTP client that supports sFTP connections – you may already have a weapon of choice in this area – but if you don’t, I personally recommend Filezilla (as it is free and also what I have been using for a number of years – therefore this article will focus on using Filezilla from this point onwards – so you might need to substitute some steps to reflect your own client).

Secondly, as we will be editing the Nagios Configuration files within a Windows environment (don’t laugh Linux peeps)– you will need a text editor that supports both the Unix and ANSI formats – one suggestion that I have is Notepad++ which, again I have been using for a number of years and is pretty cool.

Setting up Filezilla to connect to your Nagios Server

Firstly you will need to download and install Filezilla onto your local machine. When you have installed the FTP client – launch it and then from the “File” menu select “Site Manager” – see below:

Within the Site Manager click on the “New Site” button and then on the “General” tab complete the required information as per your configuration – you should ensure that the “Protocol” option is set to “SFTP – SSH File Transfer Protocol”.

You should also ensure that the “Logon Type” is set to “Normal” and that you provide the username and password for your Ubuntu administrative user – see below:

Before you connect to your Ubuntu server I recommend that on your local Windows machine you create a folder called “Nagios_Configuration_Files” – this will naturally be used to store local copies of the Nagios configuration settings – which you can edit locally using Notepad++ and then upload them back to your server.

Key Nagios Configuration Files

In order to setup basic Windows monitoring from your Nagios server there are three principle configuration files that you will be working with – these are defined with the changes that you need to make below:

• nagios.cfg – located in /usr/local/nagios/etc
  This is the main configuration file for the Nagios server – there is only one change that needs to be made within this file, and once that has been made it is recommended that you make no further modifications (unless of course you have been doing some reading up on the product and want to do something fancy).

  Using Filezilla (sic. to connect to your server) – navigate to the path that is shown in bold above and download the nagios.cfg file to the local “Nagios_Configuration_Files” location that you created above – see below

When you have downloaded the file – open it using Notepad++ and then uncomment (e.g. remove the #) the following entry in the file:

cfg_file=/usr/local/nagios/etc/objects/windows.cfg

This tells Nagios that we will be monitoring Windows hosts, and therefore the “windows.cfg” and services files should be queried.

When you have done the above, save the file in Notepad++ and then via Filezilla upload the file back to the /usr/local/nagios/etc directory.

• commands.cfg – located in /usr/local/nagios/etc/objects

  This configuration file tells Nagios what monitoring commands it should expect to have executed against it.
  Again this file should only be edited when required and there is only one change required within the file for the initial setup.

  As before with the Nagios.cfg file, download the commands.cfg to your local “Nagios_Configuration_Files” directory and then open it within Notepad++

  Look for the following line:

# 'check_nt' command definition

You will see the following entry within the ‘check_nt’ define command block:

command_line    $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$

You need to add the –s switch with the password that you configured for the NSClient (in the first bit of this article) on your Windows Server – therefore the entry within the commands.cfg file should look like the following:

command_line    $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -s password -v $ARG1$ $ARG2$

When you have made the changes to the file, save them in Notepad++ and then using Filezilla upload them back to the /usr/local/nagios/etc/objects to your Nagios Server.

• windows.cfg – located in /usr/local/nagios/etc/objects

  It is within this configuration file that you will define all of your Windows hosts and the Services that you wish to monitor. As before download this file to your local “Nagios_Configuration_Files” directory.

  When you open the file in Notepad++ you will be presented with a number of entries which represent a sample configuration – you can remove everything below the HOST GROUP DEFINITIONS (NOT NOT REMOVE THE HOST GROUP DEFINITIONS SECTION!!!!) and replace them with the following configuration (I have included some comments inline below which describe what each configuration entry does):

# HOST DEFINITIONS

define host{
    use            windows-server    ; Inherit default values from a template
    host_name    prod-dc-01.prepad.local ; This should be the FQDN of the server that you wish to monitor
    alias        Prep AD Domain Controller Number 1    ; This should be a descriptive name for the monitored server
    address        172.31.253.138    ; IP address of the monitored host
}

# SERVICE DEFINITIONS

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local ; Replace this entry to reflect the host name in the define host section
    service_description    NSClient++ Version
    check_command        check_nt!CLIENTVERSION
    }

# Create a service for monitoring the uptime of the server
# Change the host_name to match the name of the host you defined above

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local
    service_description    Uptime
    check_command        check_nt!UPTIME
    }

# Create a service for monitoring CPU load
# Change the host_name to match the name of the host you defined above

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local
    service_description    CPU Load
    check_command        check_nt!CPULOAD!-l 5,80,90
    }

# Create a service for monitoring memory usage
# Change the host_name to match the name of the host you defined above

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local
    service_description    Memory Usage
    check_command        check_nt!MEMUSE!-w 80 -c 90
    }

# Create a service for monitoring C:\ disk usage
# Change the host_name to match the name of the host you defined above

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local
    service_description    C:\ Drive Space
    check_command        check_nt!USEDDISKSPACE!-l c -w 80 -c 90
    }

# Create a service for monitoring the Netlogon service
# Change the host_name to match the name of the host you defined above

define service{
    use            generic-service
    host_name        prod-dc-01.prepad.local
    service_description    Netlogon Service
    check_command        check_nt!PROCSTATE!-d SHOWALL -l lsass.exe
    }

When you are happy with the file, save it within Notepad++ and then upload it to your Nagios Server (ensure that the directory is /usr/local/nagios/etc/objects).

Committing the Configuration to your Nagios Server

Each time you modify any Nagios configuration file you need to “commit” the settings to the server so that they will take effect. In order to do this open up a PuTTY session to your server, logon and then type in the following command:

sudo /etc/init.d/nagios restart

This is demonstrated below:

After about 90 seconds you should see the following within the Nagios web console:

If you drill down into your new host – you should see the following:

Sample Configuration Files

To accompany this series I have provided my own Nagios configuration files direct from my lab environment for download below.
Please remember that these are specific to my own installation and should only be used for reference (should you get stuck) – these are also based upon the default file set that is provided by Nagios – and therefore the intellectual rights belong to the developers of Nagios.

[ Nagios Sample Windows Monitoring Files – 15KB ]

In the next part

In the next part of this series I will show you how you can use Nagios to monitor your Exchange Servers.
If you should have any questions about this article please post them in the comments section and I will get back to you.

Very off topic here but it is something that I think might be of interest to some folks.

There is a informational commercial on TV in the U.K at the moment for the British Heart Foundation which although quite amusing, delivers a very important message.

In essence, the advert stars former Wimbledon Football club “Hard Man” turned actor – Vinnie Jones (for my American and other readers he has been in films such as “Gone in Sixty Seconds” and “X-MEN The Last Stand”) – performing CPR (Cardiopulmonary Resuscitation) on someone to the tune of the Bee-Gees hit “Stayin Alive”.

Having been a First Aider, I know the importance of knowing CPR – and the value of educating as many people as possible in how to perform it ~ as it really does save lives.

The advert itself is really well put together, and I have enclosed a link to it below.

Every now and then I like to ramble off and do something with a technology that I would not normally blog about, which also I am by no means an expert in – as it is a learning experience and can be fun!.

Recently I have been looking at monitoring solutions mainly in the context of a new role that I have been appointed to, but also because I have not focussed on any real form of monitoring throughout the history of this site and I thought that it would be good to share some of my experiences.

I have been looking at SCOM (and I will get around to posting a little tip that I discovered recently during the installation of Operations Manager) as well as a few other products (some good, some bad). However what I would like to focus my next few posts upon is Nagios Core.

For those whom don’t know; Nagios Core is a popular monitoring system based around Linux and PHP which in its “Core Edition” is available for free. With Nagios you can monitor a large number of facets of your network (including but not limited to Servers, Switches, Routers, Firewalls) and their respective services. You can also do some basic (in the Core release) business intelligence and performance / capacity management functions.

There is a huge community of plug-ins, skins and alternative interfaces for Nagios which allow for some pretty impressive expansion of the product and pretty much has everything for your monitoring needs.

Before I get into the meat of the article I should point out that I am not a Linux or Nagios expert (more a dabbler to be honest) – but over the years I have played with Ubuntu in the context of a reverse proxy for OWA and looked at Nagios as a monitoring tool a few times ~ but never really have used them in anger, therefore with that considered there are probably some processes that I will describe in this series that could be done better or more efficiently.

It is probably also worth pointing out, that there are a number of articles on the Internet which explain how to install Nagios core, but there are not many (or none that I could find) that give you an end-to-end scenario of Server installation to Server client and Exchange monitoring – so I thought that I would put one together.

As mentioned I have decided to use Nagios on Ubuntu (as it is the Linux Distro that I am the most familiar with), but I will not be explaining the actual Ubuntu install. What I will say is that I have installed Ubuntu Server into my VMWare workstation environment using the “Easy Setup” function – which automated the entire process, and all I really needed to do was create a new Virtual Machine and point the Ubuntu ISO at it.

Prerequisite Steps

Updating you Ubuntu Installation to the latest version

NOTE: The following steps all assume that you have a working, vanilla version of Ubuntu Server in your environment, if you would like to know how you can set install Ubuntu 11.10 within VMWare Workstation 8 – please see my video overview located here

From the Ubuntu Console type in the following commands (every command should then be followed by pressing <Enter>):

sudo apt-get update

Which will give you some output similar to the following (only there will be much more of it):

Ign http://security.ubuntu.com oneiric-security InRelease
Ign http://us.archive.ubuntu.com oneiric InRelease
Ign http://us.archive.ubuntu.com oneiric-updates InRelease
Ign http://us.archive.ubuntu.com oneiric-backports InRelease
Hit http://security.ubuntu.com oneiric-security Release.gpg
Hit http://security.ubuntu.com oneiric-security Release

Then type the following command;

sudo apt-get dist-upgrade

This will then begin the process of updating your Ubuntu Server components to the latest versions.

Installing OpenSSH and an FTP Server

Whereas you do not need to install either OpenSSH or an FTP Server on your Ubuntu server, they are very useful tools to have in place later on when you are administering the system and making modifications to various configuration files.

OpenSSH provides an encrypted remote administration environment for telnet and FTP applications (like PuTTY and Filezilla ~ more on these later).

Whereas you can administer your server from the console (or if like me you are working in a virtual environment the VMWare tools) it is far easier to install OpenSSH and FTP so you can perform tasks on your local Windows machine (I can already hear many Linux aficionados scoffing at the prospect ).

In order to install OpenSSH and a FTP onto your Ubuntu box use following command on the console:

sudo apt-get install openssh-server vsftpd

Configuring your Ubuntu Server with a Static IP address and configuring DNS

Naturally your Nagios monitoring server will need a static IP address, rather than one that is assigned from DHCP – therefore the following steps can be used to assign a static IP.

From the Ubuntu console type in the following command:

sudo nano /etc/network/interfaces

This will open up a console based text editor with the interfaces IP configuration (some people may prefer to use VI – but I have to admit I am a wimp and cannot get on with it!).

You will initially be presented something that looks like the following configuration:

auto eth0
iface eth0 inet dhcp

You will need to change the above to reflect the settings within your environment – for example mine looks like this:

auto eth0
iface eth0 inet static
        address 172.31.253.159
        netmask 255.255.255.0
        network 172.31.253.0
        broadcast 172.31.253.255
        gateway 172.31.253.129

When you have finished editing the file in Nano press the CTRL-O key and then <Enter> to save the file, and then press CTRL-X to exit and return to the console.

You should then configure the DNS Servers for your environment – from the console type in the following command:

sudo nano /etc/resolv.conf

This command will present you with a file that looks like the following:

domain telnetport25.com
search telnetport25.com
nameserver 172.31.253.138

You should change all of the values within the configuration file to reflect those within your own environment, when done you will need to press CTRL-O and then <ENTER> and then CTRL-X to exit.

Now that you have configured both a static IP address and your nameserver configurations you will need to restart the networking Daemons for the settings to take effect. This is done by entering in the following command to the console:

sudo /etc/init.d/networking restart

Setting up PuTTy to administer your server

You are now in a position to administer the Ubuntu server with a remote tool such as PuTTy. I say PuTTy as it is still one of the most versatile Terminal tools on the market that is also free.

You can download PuTTy from the following location: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

PuTTY is very easy to use – after you have downloaded it – double click on the executable and from the Session screen provide the IP address of your server and ensure that the SSH radio button is selected – see below:

When you are done click on the “Open” button – you might be presented with a Certificate Error screen. This is generated because the OpenSSH server will have generated a self signed SSL certificate which naturally will not be trusted by the local PuTTY client. You will need to accept and trust the certificate.

When you have done that you will be presented with a Terminal window that looks like the following:

You can now remotely administer your server from PuTTY.

Installing a Compiler on your Server

Nagios and its associated components is supplied in a pre-compiled form which is compressed and tar-balled (tag.gz) therefore before you can install it you will need to compile it using a compiler. Ubuntu server does not come with a built in compiler, but there are a number in the Linux community which are free to download and use.

For the purposes of this article we will be using “Build-Essential” which can be installed onto your server using the following command line from your PuTTY session:

sudo apt-get install build-essential

Upon executing this command you will be asked to confirm the installation – ensure that you select “Y”

Installing the GD Libraries

The Ubuntu (or Debian) GD libraries are in essence binaries that allow for applications to dynamically draw images. These are most likely used by Nagios’ reporting tools.

To install the GD libraries type in the following command:

sudo apt-get install libgd2-xpm-dev

Installing Apache and PHP 5

Apache should really need no introduction with it still being one of the most popular web server platforms on the planet. Apache is naturally required to support the web interface of Nagios, and PHP5 is the platform language which does all of the cool stuff in the user front end.

To install Apache enter in the following command into the PuTTY terminal window:

sudo apt-get install apache2

When Apache has installed enter in the following commands to install PHP5:

sudo apt-get install php5-common php5 libapache2-mod-php5

Installing Nagios Core

Creating the Nagios service user and group for commands

Nagios needs a service user and a group which has the relevant permissions to run commands within the monitoring system. The need to be created before you being the fill Nagios install.

In order to create them type in the following commands into your Terminal window:

sudo useradd -m nagios

sudo passwd nagios – you will be prompted for a password for the Nagios Service user here

sudo groupadd nagcmd

sudo usermod -a -G nagcmd nagios

sudo usermod -a -G nagcmd www-data

Download the Nagios Core and Plug in files

We are now at the stage where we can download the Nagios Core and Plugins source to your Server.

Within the Terminal window type in the following commands:

sudo –s

mkdir downloads

cd downloads

wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.3.1.tar.gz (this is the latest stable release)

wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz

tar –zxvf nagios-3.3.1.tar.gz

tar –zxvf nagios-plugins-1.4.15.tar.gz

Installing Nagios Core

Now that you have downloaded the relevant files to your server we can now begin the installation process, from the Terminal Windows type in the following commands (please ensure that you are in the “downloads” folder that you created in the previous step):

cd nagios

./configure --with-command-group=nagcmd

make all

make install

make install-init

make install-config

make install-commandmode

make install-webconf

We will now create the administration user for the Nagios Core System (this is the account that will be used to log into the web interface)

mkdir /usr/local/nagios/etc

htpasswd –c /usr/local/nagios/etc/htpasswd.users nagiosadmin

You will then be prompted for a password for the admin user.

Installing the Nagios plugins

The Nagios plugins provide around 50 pre-configured monitoring functions and services, without them your Nagios installation is not going to do very much so it is important that they are compiled and integrated into the environment.

In order to install them from the terminal window, type in the following commands:

Navigate to the downloads folder (if you have been following the sequence this could be cd .. and then cd nagios-plugins-1.4.15).

./configure --with-nagios-user=nagios --with-nagios-group=nagios

make

make all

make install

Creating a Symbolic Link for the Nagios Service

We now have an almost functional Nagios system, however before we can start the system up, we need to create a symbolic link to the Nagios service so that it can be started with the O/S automatically.

In order to do this type the following command into the Terminal window:

ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Verify permissions and file system

During the configuration of the Nagios environments for this article I have encountered some small problems with file system permissions and a folder not being created by the installation process. Therefore I have added in this step which cleans up the permissions on the Nagios folders and ensures the correct directories are in place.

From the terminal window type in the following commands

chown -R nagios:nagios /usr/local/nagios

mkdir /usr/local/nagios/var/spool/checkresults

chmod 744 /usr/local/nagios/var/spool/checkresults

chown -R nagios:nagios /usr/local/nagios

Verifying the installation

Just before we start the Nagios server up, as a penultimate step we should now verify the configuration – this is done by executing the following command from the Terminal window:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Which should result in the following output:

Nagios Core 3.3.1
Copyright (c) 2009-2011 Nagios Core Development Team and Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 07-25-2011
License: GPL

Website: http://www.nagios.org
Reading configuration data...
   Read main config file okay...
Processing object config file '/usr/local/nagios/etc/objects/commands.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/contacts.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/timeperiods.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/templates.cfg'...
Processing object config file '/usr/local/nagios/etc/objects/localhost.cfg'...
   Read object config files okay...

Running pre-flight check on configuration data...

Checking services...
    Checked 8 services.
Checking hosts...
    Checked 1 hosts.
Checking host groups...
    Checked 1 host groups.
Checking service groups...
    Checked 0 service groups.
Checking contacts...
    Checked 1 contacts.
Checking contact groups...
    Checked 1 contact groups.
Checking service escalations...
    Checked 0 service escalations.
Checking service dependencies...
    Checked 0 service dependencies.
Checking host escalations...
    Checked 0 host escalations.
Checking host dependencies...
    Checked 0 host dependencies.
Checking commands...
    Checked 24 commands.
Checking time periods...
    Checked 5 time periods.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

Starting up Nagios and Accessing the Management Site

We can now start Nagios Core – therefore from the Terminal Window type in the following command:

/etc/init.d/nagios start

When the service has completed starting up – you can open a Web Browser to you the Nagios Core installation via:

http://<addressOFyourServer>/nagios

In the next part

In the next part of this series I will go through how you can configure some basic monitoring of some Windows Servers within your infrastructure.

Some of you may have read my recent article about my new test lab (which I had to hastily assemble after my old one went to the great testing god in the sky). I finished the article by explaining that if there one thing that I would change about the setup, it would be the (crappy) stock cooler that ships with the Intel i7 2600K.

Well over the weekend I was working on some video rendering for the telnetport25.com You Tube channel, which was taking a tad too long on my home desktop PC.

I thought ~ “Heck, I have a brand new i7 rig here, I could install my video software on to it and render via that Machine – surely it will be quicker”.

I was right, technically it would be quicker – what I did not count on was that the rendering process would max out all four cores in the i7 and send their temperatures soring to over 98 degrees Celsius – the long and short of which was my server locked up on me!

I starting thinking that I must be crazy (which most people knew already), I have this great machine and cannot use it to anyway near it true potential as I was too tight to go out and buy a new Heat Sink for the CPU.

So, I started having a look around on the web for a suitable Cooler from my usual suspects (Dabs, Scan etc).

In the end I could not find anything that I was really interested in, so I popped a mail off to my local PC store (a place called Planet-UK ~ special mention chaps! whom were really good at recommending the following bad boy to me:

http://www.scythe-usa.com/product/cpu/053/scnj3000-detail.html which they just so happened to have one left in stock.

So today I merrily popped off down Planet to purchase the Scythe Ninja 3 (I mean how the heck could I not buy a cooler that was called “Ninja” – it would be against the law!).

This evening I got the heat assassin home and set about removing the scummy Intel Stock cooler from my server and installing the new device and thought that I would write about my experience.

Installation

I have a Antec 85 Dark Fleet full tower case, which is designed to allow for the installation of Heat Sinks such as the Ninja 3 without having to remove the mother board. However, as I quickly found out this is a cruel marketing ploy – there is no sensible way to install the Ninja 3 in the Dark Fleet case without taking the motherboard out (don’t try it, honestly I did and I wasted a load to time coming to the conclusion that I had wasted … well a load of time – just take the motherboard out).

In fact, adding into the mix that I have an Asus P8 z68 pro mainboard, I also had to remove the chipset heat sinks before I could even contemplate installing this beast of a cooler onto my i7! (this added on more time and sobbing).

Given the above – I have to report that the actual installation process for the Ninja 3 was a real pain in the arse (well for me it was) taking about 2 hours in total (mind you 1 hour and 45 minutes of it was trying to retrieve the Ninja 3 screws from various places either in the case, or that had lodged themselves into various positions on the Motherboard after I had dropped the little buggers).

But when finally done, the finished article is very sturdy and looks amazing – see below:

Performance

Ok, so it looks sexy and would probably withstand a thermo-nuclear attack – but how well does it perform?

Well, idle CPU temperatures on the server would be around 32 – 35 degrees per core with the standard Intel Stock cooler installed; however with the Ninja 3 these dropped to around 22 – 25.

But idle temperatures are of course not what I was interested in, I wanted to know how the CPU would cope under load.

I decided to run the same Video rendering process that I had attempted at the weekend – and I was really very pleased with the results.

Each core during the rendering process topped out at about 53 degrees (bearing in mind that each core hit over the Tj Max value of 98 degrees with the Stock Cooler), but what excited me most was that each core never went above 40% utilisation – whereas previously each core was maxed out at 100% ~ really cool!

It is important to note that I have not overclocked this rig – all of the performance management is taken care of by the Asus BIOS.

Summary

I love this cooler.

Its called “Ninja”, its big and shiny, it comes with a large knob which allows you to control the fan speed and above all else – for a Air Flow based Heat Sink it really does its job well.

It’s the largest cooler that I have seen outside a proper server so you should really pay attention to the dimensions of both your case and the cooler itself – otherwise you might not be able to get the doors back on (luckily this did not happen to me).

It is true that it is a pain in the backside to install – but, that pales into insignificance when you see the benefits it brings to your system – so if you are in the market for a new CPU cooler, and don’t fancy that jump to water cooling just yet – give it a look! I cannot wait to point some Exchange Server madness at it

The December 2011 and January 2012 www.telnetport25.com newsletters are available for download from the following location:

[ December 2011 & January 2012 Newsletters ]

The November 2011 www.telnetport25.com newsletter is available for download from the following location:

[ November 2011 Newsletter ]

I have to confess that it has been a long time since I wrote something that has been so popular both with readers of my site, and indeed myself. For those of you whom have not been following the the life of the “RUPS”, in November 2011 I released the RUPS tool, which was designed to make the process of applying Exchange 2010 SP 1 Roll-Ups to DAG based Mailbox servers a little more straight forward.

A few days later I released version 1.1 – as I had received some really good feedback on the original version which I really wanted to see implemented into the tool.

On the 5th December 2011 Microsoft released Exchange 2010 SP2 – therefore I decided to expand the functionality of the Tool (version 1.2) to work with Service Packs as well as Roll-Ups. I also added some functionality that allowed for you to execute custom Powershell commands from within the environment (as Service Pack 2 for Exchange 2010 had a new pre-requisite – and the ability to install this from within a single Management interface made sense).

On December 9th 2011 I had some feedback which notified me of some bug fixes (therefore needed to be done straight away) and a couple of feature enhancements therefore I released version 1.3.

Finally, on the 13th December 2011 I received another bug report which I fixed for version 1.3a.

Summarising the above – in a short space of time the change log for the RUPS tool looked like the following:

• 1.0
  • Initial Release
• 1.1
  • Ability to disable Forefront Services
  • Disable Specific Services from within the tool
• 1.2
  • Ability to execute custom Powershell Commands
  • Ability to use the tool with Exchange Service Packs
• 1.3
  • BUG FIX: Fixed Forefront Services Disable Command
  • Added to the ForeFront Services Command – Stops the MSExchangeIS and MSExchangeTransport Services
  • Added to the Apply Command – Starts the MSExchangeIS and MSExchangeTransport Services
  • Added Command Logging Window with Export Command
  • Added hints window
  • Added dedicated About Box
  • Better error handling
  • Other minor bug fixes
• 1.3a
  • Minor bug fix to support expected services not being present on the execution server

Anyhow, over Christmas and New Year I have been getting a little bored (and drunk which is always dangerous coding territory for me), so I decided to have a close look at the tool again – the outcome of this “look” was that it occurred to me that I was not completely happy with all of what it did – or perhaps more to the point, what it didn’t do!

There were a number of features that I would personally like to see implemented which would “round” the utility into something that I think would be really useful for Exchange admins – for example;

• I wanted to add a splash screen (this was a drunk feature)– mainly because I had not ever written one in C# (however, this idea would later become quite useful as it serves as a placeholder which a number of Powershell Commands are executed by the tool as it starts up)
• I was VERY unhappy with the way I had implemented ForeFront Server Protection detection – basically it didn’t work (bearing in mind that I had tried to fix this twice now!) – I wanted it to be simple and to work!
• I had been trying to add in functionality to STOP ForeFront Services – but none to START it again afterwards (daft)
• I wanted a visual reference of the Roles that were installed on the Exchange Server that I was working on (I don’t know why, it was just something that I though would be good)
• I wanted the tool to be useful for managing the update process on Servers which run all Exchange 2010 Server roles – not just DAG members or Mailbox Servers
• I wanted to add a reference to the “Best Practice” order for upgrade an Exchange 2010 server which was visually prevalent within the tool’s interface
• I wanted to re-brand the tool as it was not just about Roll-ups, but more a update management system

So considering the above, I broke out my copy of Visual Studio, a few cans of Carling, and some Alanis Morrissette to implement the above features (cause that’s how I role beeaaaaatches!) – all of which are now present in the new version – 1.5 (which, henceforth shall be known as the UMS (Update Management System)).

Download

Version 1.5 is available for download from the link below. Like all previous updates this version supersede all previous releases – therefore if you are running a version of the UMS (or RUPS tool) – please remove it before installing this release.

Version 1.5 is now installed using the Windows Installer Service via a MSI package – therefore any future releases will “self-upgrade” (yaaa – finally).

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

Video Overviews and Tutorials

I thought that, rather than go through screen dumping everything that is new, it might an idea to produce a set of videos to accompany the new release of the tool.

Therefore I have put together 3 videos (below) which take you through the installation of the UMS, how the functionality works on DAG servers, and how the tool functions on roles that are non-DAG / non-Mailbox based. Much of the functionality is the same as was detailed in the articles that I put together when the tool was known as the “RUPS” tool (see the beginning of the article).

Installation

Using the Tool on DAG Members

Functionality of the Tool on non-DAG Servers

Anyhow, I hope (as always) that this helps someone along the way – and I would also like to wish all my readers (or any visitor to the site) a very Happy New year.

I thought that it would be good to take a break from the development stuff that I have been doing on the site for the last few months and focus on something a little more technical. I hope that the following will help aid some people in their own Exchange HA deployments.

Historically I have always had an attraction to Exchange clustering (whether it was SCC, CCR and now DAG) therefore in this post I would like to take the opportunity to discuss the concept of “Majorities” and “Quorum” in the context of Database Availability Groups.

There are of course a number of articles out and about on the web which deal with this subject at some level, but I thought that I would chuck in my own simplistic take on these critical concepts.

Firstly, how does Exchange 2010 DAG use Windows Failover Clustering?

Well, technically it does and it doesn’t (now there’s a great answer for you). Exchange 2010 has its own HA model of clustering and data replication (which is an enhanced version of the model introduced in Exchange 2007 with CCR)  – however there are some small elements of the Windows Failover Clustering service which DAG makes use of:

• Cluster Heartbeat
• Cluster Networks
• Cluster Configuration Database

When you open the Failover Cluster Manager on a DAG node within your environment you can see how the above components actually look in practice:

One of the key things to note is that in Exchange 2010 DAG you should not need nor, should be using the Windows Failover Clustering Manager to configure any aspect of the DAG – all functionality is presented either via the Exchange Management Console or the Exchange Management Shell.

You don’t even need to install and pre-configure the Windows Failover Clustering service, as it is installed during the execution of the New-DatabaseAvailabilityGroup cmdlet, or when you use the Wizard from within the Exchange Management Console.

Ok, but what about all this Quorum and Majority Node thingies and stuff?

This is where this post might seem to get a little complicated, but I am hoping to explain the ideas in a pretty straight forward way.

Each Mailbox Server which plays a part in a DAG is also considered a “voter” (a voter, like in political elections determines the right candidate to transfer services to in the event of a failure).

In many political situations (and if you have ever served on a committee you may have encountered this) there is a concept called “Quorum” – which means the minimum number of people with voting rights to carry a motion or decision must be present at a meeting.

This always needs to be a majority (as if you have two people whom vote you can get a 50 / 50 split therefore no majority – or you can get a 100% vote but as there were two people involved who is to say they are right?) – therefore you will find many official meetings will have a quorum set at a minimum of 3 (or more, but it will normally be an odd number above 3).

The principles of DAG and Majority Node Set follow pretty much the same rules that we would find in our (my) real world example.

Therefore if you have a EVEN number of DAG enabled mailbox servers in your configuration you will require 50% of your DAG voters plus a Witness Server to be available to provide an arbitration vote in the event of a failure within the system – mathematically this can be represented as:

Where represents 50% of the number of DAG Mailbox Servers and the is the arbitration vote of the File Share Witness server.

A File Share Witness Server does not hold a copy of the Quorum but can devolve a vote (arbitrate) to a server which is online within the DAG configuration (so that DAG server has two votes) – the FSW sever keeps track of which of the DAG nodes has the most up to date copy of the Quorum database and will pass its vote to that server.

Therefore to try and make the above clearer – if you have a 4 node DAG infrastructure you will need a minimum of two DAG Mailbox Servers plus the File Share Witness Server online in order to maintain Quorum (This is called Node and File Share Majority) – this is depicted in the example below:

In the above scenario – if you lose three of the DAG Servers or two plus the File Share Witness then a “Split Brain” scenario will occur – where the cluster cannot not identify the most up to date copy of the cluster configuration or indeed which server was running the relevant resources . This results in the whole DAG infrastructure going offline until an administrator can intervene to rectify the situation – see below:

If you have an un-even (Odd) amount of nodes in your DAG infrastructure (for example 3, 7,9 etc) Exchange 2010 will automatically set the Majority model to “Node Majority” (where the File Share witness is not used as there will be a majority number of voters based upon the DAG membership model).

This is where things might seem even more confusing, but when you do the maths – it makes sense.

If you have a DAG with 3 DAG nodes and one fails then you still have 66.6% of your voters online, if you lose two nodes from a 3 node DAG then you have lost 66.6% of the installation and therefore it would fail based on the total amount of nodes. Even in the above scenario, if the File share witness participated – remember the equation (where n is 50%) you would not achieve Quorum as you would have lost too many of the actual DAG members (as the FSW does not hold a copy of the Quorum).

Scaling Node Majority up to say 5 nodes you could lose two nodes and maintain Quorum without a FSW.

I hope that I have provided some insight into what is a concept in Exchange 2010 which can be very confusing. I will admit that I have not added in additional concepts such as Alternate Witness Servers and their role in the whole concept of DAG (perhaps a later post). But I hope that it helps someone.

In around April 2011 I put together an article which made some recommendations for a successful installation of Exchange 2010 SP1 onto Windows Server 2008 R2. Since then as you might expect a number of things have moved on in the world of both Windows and Exchange – therefore I have decided it is probably appropriate to publish a short post that details some relevant changes to the requirements process for Exchange 2010 on Windows Server 2008 R2.

Thankfully much of the original article is still pretty current, however it is worth updating as since April there have been a number of updates for Windows 2008 R2 and of course Exchange 2010 SP 2 has been released, therefore for your viewing pleasure I would like to present to you the following updates:

Windows 2008 R2 Hotfixes Required to install certain Exchange Roles

All of the hot fixes detailed in this section of the original article are now part of the Windows Update Step – therefore you do not need to download and install them separately (this was also very kindly pointed out by Brad Saide).

Get your permissions in order

All of recommendations that I made in the original post still remain the same -  however – I would like to add that if you are using an account that is not the original Domain Administrator for your Domain / Forest (e.g. one that you have created specifically for administrative purposes) – when running the Exchange “Setup.exe” binary, or a command prompt to execute the “Setup.com” binary you should ensure that these are run “As Administrator”.

For example; in the case of Setup.exe from the Exchange 2010 binary – right click on the file and from the context menu that appears choose the “Run as administrator” option – see below:

If you are running Exchange setup via the Command Prompt make sure that you start the Command Prompt as an administrative user – see below:

Some additional Tips

The following are some additional tips that I would like to add to the original article that I have thought of since

Domain Controller Goodness

• Before you install any new Exchange 2010 Server (does not matter if it is the first of one of many) you should ensure that all Domain Controllers are online and are working correctly in both Parent and Child Domains (should you have a multi-domain setup). If you have a DC that is offline, or is not functioning correctly in the replication topology, Exchange setup is likely to fail as the objects that need to be created cannot be replicated.

  Given the above – a good tool to use BEFORE You install Exchange is DCDIAG (which can be used from a Windows 2008 R2 command prompt or directly on a domain controller).
  Open a command prompt (as an Administrator) and type in the following command:

dcdiag /s:<home domain controller name> /a >c:\DomainReport.txt

This will pipe all relevant output to a text file called “DomainReport.txt” located in the root of C:\ on your server. The command will test each domain controller detected within your infrastructure for issues. When completed you should inspect this report (sic. the text file that has been produced) to ensure that there are no unexpected issues before you install Exchange.

Install PowerGUI

It is important to note that Exchange will work perfectly well without PowerGUI, but it comes with perhaps the best Powershell scripting Editor around – and as you all know, Exchange is a beast for Powershell.
Normally I would never recommend placing 3rd party software on an Exchange Server (aside from Anti-Viral, Backup, Monitoring Agents, Statistics Tools) – but PowerGui IMHO is an exception to this rule.

You can download PowerGui from: http://powergui.org/index.jspa

Previous Reboots

If you are installing Exchange for the first time on a new Windows 2008 R2 Server, you should ensure that there are no previous reboots pending (e.g. from Windows Updates and the like). If there are, Exchange Setup will fail and require you to reboot the machine.

Not an Exchange post, but a Windows one for those of you whom use VMWARE.

Today I was building a new SQL server within my VMWARE Workstation 8 environment. Everything was going swimmingly right up until I had just finished Windows 2008 R2 setup. I was in the process of applying Windows Updates when I lost Internet connectivity.

It was very odd, as I still had IPv4 connectivity (I would ping devices on my network with no issues), and I could use NSLOOKUP and Trace Route to both resolve DNS names and track packets – but every time that I tried to connect to the Internet (either via a sites IP address, or via the DNS name) I would get an error message.

The network icon in the bottom left of the Screen turned to the familiar yellow exclamation mark – see below

And opening up the Network Connection and Sharing Centre revealed the following:

I tried a number of things:

• Uninstalled the NIC from the within the Virtual Machine and then re-installing it
• Removing and installing VMWARE tools
• Switching the IPv4 Configuration between static and DHCP addressing
• Numerous Reboots of the VM

All of which were to no avail – as the problem still persisted.

After several hours of Googling, swearing, teeth Gnashing – I decided that I was going to physically remove the NIC from he Virtual machine, reboot, and the add it in again from within the Workstation console.

Just as I was about to do so, I remembered a setting which VMWare gives you on the NIC for a Virtual machine which allows for you to change the MAC address – I thought that I would give this a try before removed the adapter completely (my logic being that perhaps a rouge ARP entry or something else odd had happened at the network layer in my environment).

So from within the VMWARE management console I selected the properties of the Network Adapter, and then clicked on the “Advanced” button – see below

From the dialog that appeared I clicked on the “Generate” button located in the MAC Address section – see below

I then rebooted the Virtual machine, and low and behold – this solved the problem (lucky guess huh?). Although I have not checked this in any real detail – I am wondering if I had two VM’s active with the same MAC address, but heh – ho, problem solved and only 4 hours of my life lost on the problem – so, if you end up at your wits end and have tried all of the obvious stuff and you are using VMWARE – give this a go.

Note: The download version of this tool has been updated to reflect the lastest version.

Just a very quick update to the RUPS tool, taking it to version 1.3a – nothing too major, just a small bug fix to the logic which detects and then manipulates the MSExchangeIS and MSExchangeTransport services – basically if you executed the tool on a server which did not have either one of the services installed you would be presented with a .NET exception.

I have added in some Exception handling code that allows for the tool to continue processing should this circumstance arise. My thanks go out to Tunde TMoney for pointing this out to me.

I won’t go into great detail on how to upgrade the installation as this has been covered here.

Download

As before this version of the tool supersedes all previous releases and I recommend that you replace any current version that you are using with the one below.

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

Before I get into this it is VERY important to point out that this article is NOT supported by Microsoft in any way shape of form.

If you have run the Exchange 2010 Service Pack 2 Hybrid Configuration Wizard and therefore setup a configuration – you are NOT supposed to remove it.

If you have created a Hybrid Configuration, but not made use of its features – this will not affect the functionality of Exchange 2010 SP2 at all.

I have performed this process in a LAB – not in production, and I have posted it purely as a proof of concept as it came up on the MVP mailing list, and I was curious if it could be done, and therefore thought that I would share my findings, but it has not been tested for wider ramifications ~ you have been warned.

Background

OK, like me, some of you just out of curiosity might have executed the “Hybrid Configuration” wizard just to see what happens – just to let you in on the secret – what you will end up with by using the single step Configuration Wizard is a Hybrid Configuration entry within Exchange, a federation trust and a Self Signed SSL certificate for Federation on your Exchange servers (of course there is a lot more to it if you choose to actually use a Hybrid configuration) – see below;

Hybrid Configuration:

Federation Trust:

Federation Self Signed SSL:

The next thing that you will notice is that you cannot via either the Exchange Management Console, or Exchange Management Shell remove the Hybrid Configuration (mumble, mumble).

Therefore I have come up with the following process (again to reiterate that is NOT supported by Microsoft) that will remove the configuration and associated elements.

Step 1:

From within the Exchange Management Console – navigate to the “Organization Configuration” node and from the Organization configuration details window select the “Federation Trust” tab. Using the right hand mouse button – select the “Microsoft Federation Gateway” entry and from the context menu that appears choose “Remove Federation Trust” – see below

Step 2:

Navigate to the “Server Configuration” Node within the Exchange Management Console and select each server within your environment. You will see a list of certificates within the “Exchange Certificates” window – select the entry for “Exchange Delegation Federation” with the right hand mouse button and from the context menu that appears choose “Remove” – see below:

Step 3:

Open ADSI edit on your server (typically located within [ Start –> Programs –> Administrative Tools –> ADSI Edit ]) and make a connection to the “Configuration” Partition. You will need to navigate to [ Configuration –>Services->Microsoft Exchange –><Organisation Name>->Hybrid Configuration] – see below

The details pane will change to show you a “Hybrid Configuration” entry – using the Right hand mouse button – select this entry and from the context menu that appears choose “Delete” – see below

Step 4:

You will need to restart the Microsoft Exchange Service Host (MSExchangeServiceHost) service from the Services Manager on each of your Exchange Servers, and wait for AD replication to take place (if you have more than 1 domain controller) after which when you navigate back to the “Organization Configuration –> Hybrid Configuration” you will now see that the entry has gone.

Recently I have been doing a quite a bit in relation to Database Availability Groups, Service Packs, Roll-Ups in my lab. In order to test my applications (honestly, I do some testing before I release them) – there is quite a lot of shutting down, restarting and generally messing around with my DAG based Exchange Servers.

In order to facilitate all of the above and of course keep my servers in good shape, it has been a requirement to place certain servers within my infrastructure into various forms of DAG maintenance, restore normal operation, and finally redistribute the databases post DAG server maintenance.

Now as many of your will be aware – within Exchange 2010 from SP1 there are a number of built in scripts which administrators can use to configure a number of maintenance tasks on DAG members these typically are:

• StartDagServerMaintenance.ps1
• StopDagServerMaintenance.ps1
• RedistributeActiveDatabases.ps1

Normally the above are found in the C:\Program Files\Microsoft\Exchange Server\v14\Scripts folder

All these scripts are excellent accompaniments to your Exchange infrastructure – but as I have been using all three on a regular basis I decided for convenience to amalgamate them into a single script and add a new “Query” feature.

In essence the script that I have written is an encapsulation layer for all of the above Microsoft supplied ps1 scripts – encapsulating the following features:

• Accepts a single command line parameter via the –opMode switch:
  • Start – Executes the StartDagServerMaintenance.ps1 script but automatically detects the serverName parameter
  • Stop – Executes the StopDagServerMaintenance.ps1 script but automatically detects the serverName parameter
  • Query – New feature, detects the status of the DAG node that the script is executed on and reports the following information:

• Redist – Executes the RedistributeActiveDatabases.ps1 script but automatically detects the DAGName and sets the –BalanceDBSByActivationPreference parameter

DAG Server Maintenance Script

The following is an overview of the encapsulation script for you to review prior to download.

# Dag-Server-Maintenance Automation Script
# Author: Andy Grogan
# Version 1.0
# www.telnetport25.com

# Command Line Parameters

Param(
    [Parameter(Mandatory=$true)]
    [System.Management.Automation.ValidateNotNullOrEmptyAttribute()]
    [string] $opMode
)

# Query the Registry for the Exchange Install Location

$HKLM = 2147483650
$WMIReg = [wmiclass]'\\.\root\default:StdRegProv'
$specKey = "Software\Microsoft\ExchangeServer\v14\Setup"
$keyVal = "MsiInstallPath"
$retVals = $WMIReg.GetStringValue($HKLM,$specKey,$keyVal)
$exPath = $retVals.sValue

$localServerName = Get-WmiObject -Class Win32_ComputerSystem | select Name

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction SilentlyContinue

function do_functionalTask{

    if($opMode.ToLower() -eq "start"){
        Powershell.exe -File $exPath"Scripts\StartDagServerMaintenance.ps1" -serverName $localServerName.Name
    }elseif($opMode.ToLower() -eq "stop"){
        Powershell.exe -File $exPath"Scripts\StopDagServerMaintenance.ps1" -serverName $localServerName.Name
    }elseif($opMode.ToLower() -eq "query"){

        $AP = Get-MailboxServer -Identity $localServerName.Name | Select DataBaseCopyAutoActivationPolicy
        $CS = Get-MailboxDatabaseCopyStatus -Server $localServerName.Name | Select Name,ActivationSuspended
        Write-Host "------------------------------------------------"
        Write-Host "Activation Policy: " $AP.DataBaseCopyAutoActivationPolicy -ForegroundColor Cyan
        Write-Host "Copy Status for Server: " $localServerName.Name -ForegroundColor Yellow
        Write-Host "------------------------------------------------"
        foreach($val in $CS){
            Write-Host "Database Name: " ($val).Name "`nIs Activation Suspended?: " ($val).ActivationSuspended -ForegroundColor Green
        }
        Write-Host "------------------------------------------------"
        Write-Host "Cluster Node Status: "
        Cluster.exe node $localServerName.Name
        Write-Host "------------------------------------------------"
    }elseif($opMode.ToLower() -eq "redist"){

        $DAGName = Get-DatabaseAvailabilityGroup | Where {$_.Servers -eq $localServerName.Name} | Select Name
        Powershell.exe -File $exPath"Scripts\redistributeActiveDatabases.ps1" -DagName $DAGName.Name -BalanceDBSByActivationPreference -ShowFinalDatabaseDistribution

    }else{
        Write-Host "Error: Sorry the script does not support the command line argument you supplied." -ForegroundColor Red
        Write-Host "Valid Command Line Parameters are:" -ForegroundColor Cyan
        Write-Host " -opMode Start" -ForegroundColor Green
        Write-Host " -opMode Query" -ForegroundColor Green
        Write-Host " -opMode Stop" -ForegroundColor Green
        Write-Host " -opMode Redist" -ForegroundColor Green
    }
}
do_Functionaltask $opMode

    

Script Requirements

In order to use the script within your environment you will need to ensure that it (sic. the environment) conforms to the following requirements:

NOTE: As the script is designed for Mailbox Servers which are part of a DAG topology the chances are that you will automatically comply with the requirements below.

• Powershell version 2.0
• Exchange Server 2010 SP1 or above
• Exchange Server Management Tools installed
• Must be executed on the DAG Server that you wish to place into / take out of maintenance mode

Download

You can download the above script from the download link below – you should place the script in a convenient location on your DAG servers.

[ DagServerMaintenance.ps1 – 2KB ]

Script Usage

The script is executed from the Powershell Command Prompt (you do not need to have to use the Exchange Management Console). The script accepts a single parameter called “-opMode” which accepts one of four parameters (these are described above – and illustrated below):

-opMode Start

Example of output from using the –opMode Start Command;

-opMode Stop

Example of output from using the –opMode Stop Command;

-opMode Query

Example of output from using the –opMode Query Command;

-opMode Redist

Example of output from using the –opMode Redist Command;

I hope that someone will find this useful.

Note: The download version of this tool has been updated to reflect the latest version.

Ok, I admit that this is turning into a little bit of a saga – for those of you whom have been following the site recently will know that on the 26th November I released my Roll-Up Encapsulation tool (version 1.0), on the 27th I released an update (version 1.1) which included two new features in the form of Forefront Service maintenance and allowing the administrator to disable bespoke services from within the tool’s interface.

On the 5th of December – to coincide with the release of Exchange 2010 Service Pack 2 I released version 1.2 which allowed for both Service Packs and Roll-Ups to be installed via the interface, as well as allowing for custom Powershell commands to be executed.

I thought at that point my work was done and that I could return to the tool at a later point in time, however I was contacted by a chap called Charles Ojserkis (thanks buddy!) who pointed out a rather embarrassing bug (which I had missed) and also made a couple of really cool suggestions to improve its functionality.

What Charles basically said was;

• The Forefront command is FSCUTILITY not FSUTILITY (as was in my code) – oops – I forgot a “C”
• That the MSExchangeIS and MSExchangeTransport Services should be stopped before the above utility should be run (as I am not personally running ForeFront in the Lab I completely missed this ~ testing Grogan, testing…)

Charles then went onto explain that it would also be useful if folks could see the output of the Powershell scripts that are executed by the tool, just to check for errors (I had not included this in the original version probably because I am lazy), but it seemed like a good idea to me.

So, out came my copy of Visual Studio – and set about correcting the errors and adding a couple of new features.

Now that I have completed the development – one of the first things that you will notice about the new version (version 1.3) is that the interface has been slightly redesigned to encompass both a “Command Output”  and a “Hints” window – see below;

When you “hover” over an active area within the interface you will be presented with a hint in the “Hints” window, and when you execute a shell command via the interface, the results will be populated into the “Command Output Window”. You have the option of both clearing the Command Output (via the “Clear” button) as well as exporting the log to a file (by clicking on the “Export” button).

I have also made some “behind the scenes” changes which include better exception handling and stopping certain services when commands such as the FSCUTILITY are executed – and then starting those same services again before the patch is applied.

I have also renamed the tool to “Apply Exchange Updates” – which seemed to make more sense, given that it now supports both Roll-Ups and Service Packs.

Download

As before this version of the tool supersedes all previous releases and I recommend that you replace any current version that you are using with the one below. Installation and functionality are the same as described here, here and here.

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

Note: The download version of this tool has been updated to the latest released of the tool – this article is still relevant however.

Today Microsoft released Service Pack 2 for Exchange 2010 – and I thought that I would take this as an opportunity to update (again) my Roll-Up tool to support Service Packs as well as patches within DAG environments (or jump on the bandwagon )

Now sometimes service packs need new Windows features to be installed – for example in the case of Service Pack 2 for Exchange your Client Access Servers need to have the IIS 6 Web-WMI tools installed as has been documented here – therefore before you being the upgrade process, if the Exchange Server that you are working on has the CAS role installed you need to open a Powershell window and execute the following commands:

Import-Module ServerManager
Add-WindowsFeature Web-WMI

Therefore I have added a new feature to the tool that allows for you to execute custom Powershell commands within the application, which I hope should cater for most situations like the above when installing a Service Pack as well as a Roll-Up – remember in the case of SP2 the above only applies to Server running the CAS role.

Using the new features

The process for installing a Service Pack on a Server which contains both the CAS role and Mailbox role where the mailbox server is a member of a DAG is the same as detailed in my original article located here, however you now also have the following option if it applies to you:

From within the “Advanced Menu” (which was added in the last update) – you will see a new menu entitled “Custom Powershell – for Service Packs” – see below

In the command box you can enter in the Powershell commands that you wish to execute and then click on the “Add” button – see below

Each command will be added to the script window (you can enter commands directly into the script window should you wish – remember each command needs to be on its own line), when you have finished entering in commands click on the “Execute” button, the results of the script will be displayed in the “Output” window – see below

You can then return to the main application window and proceed with the installation of the Service pack in the same way that you would for a Roll-Up.

Download

As before the new version of my tool supersedes all previous versions and is available below.

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

Someone asked me a little while back why I love Exchange so much.

This was an interesting question, as even though I have worked with Exchange for many years – I had not really considered why I like it so much as a product until that point in time – or indeed that I really “loved it” more than any other software or hardware that I have worked with (Microsoft or otherwise) – in my own minds eye I had merely considered it to be “just something that worked” – or “something that made sense”.

I have been reflecting on the question for quite sometime now (honestly I do have some form of life – but my boss has been encouraging me to be more spiritually reflective on questions which resonate with me), therefore I decided to try to answer the question as a blog post.

I will warn you all in advance that this post will be a ramble, and go on a bit – as a trip down memory lane (well for me anyhow) – so really this is an “interest” piece for folks – rather than something that is going to help you fix a technical problem or revolutionise your career.

For me it all started back to about 1997 when my career really started moving (I can hear some of you snoring already!) – I was not (at the time) the biggest fan of e-Mail – in fact I hated it! My main experiences had been based around POP3, IMAP, and SMTP based on Apple Mac clients with no formal mail server or distribution point on site.

The entire setup was based around local storage of mail items and given that the primary technology was Apple based – the client was not even as advanced as Schedule + was at the time.

I messed around with e-mail (and the legacy protocols) in that job for two years – and unsurprisingly the uptake of e-mail as an effective communications mechanism within the company was very low (there were only about 10 mailboxes for a staff ratio of about 100) – and those 10 mailboxes caused me no end of grief.

The mail accounts were hosted by BT Campus World (wow ~ anyone in the UK remember them?) and the client was something to do with Mozilla and Netscape navigator (it’s all very hazy now – I drank a lot of beer – and went to some wild parties so remembering the actual e-mail client was not high on my list of memorable moments), however despite my lack of enthusiasm – I would admit that it gave me a good understanding of the principles of e-mail and the protocols that were used to send and receive.

Anyhow, after two years I moved jobs to a much bigger organisation (around 1999). The team that I joined was to say the least in a state of flux and the mail administrator had shall we say “left under a cloud”  – I remember being asked “Have you done anything with e-Mail?”

Foolishly I said – “yeah, sure” (eager to impress) – to which the reply was – “oh good, over in that dark corner is the ‘mail system’ and your the new admin”. So I bumbled over to the ‘Dark Corner’ and was presented with MSMail!!.

The setup was a core MSMail post office supporting around 360 users – where the “data store” (using the term very loosely) was located on a Old Mitsubishi Shogun server running Novell Netware 3.12 – below, purely for nostalgia is a photo of myself and a very good mate of mine “administering” the “Shogun” [ notice the ruler being used on the keyboard ]-

Anyhow – connecting into this primary MSMail post office were a number of MSMail gateways (15 if I recall correctly) which via Modem links (a full 56K!) would accept connections from a further 15 MSMail post offices which were spread around the geographic area.

It was at this point that I learned that if I thought that my experiences of e-mail administration had been painful up until that point – they were about to get worse. I spent the better part of a further two years supporting that MSMail infrastructure (along with Novell in general) travelling the area (around 30 square miles via bus) kicking the system into life as failures were common – very common.

It was inevitable that the decision was taken that Novell and MSMail were not really the way forward and after some very short deliberation we decided that Exchange 5.5 was the way to go (we were already using Schedule + and some Outlook across the estate and we were moving from Novell to Windows NT 4).

This I suppose was really the first time where you could say that “Andy met Sally – erm Exchange”.

I was assigned to a two person team (myself and a fabulous chap called Mahmoud Abu-Wardeh – pictured above) where we were tasked with migrating the 360 users from MSMail (yes those pesky fecking post offices were going to die) to Exchange 5.5.

At this time, it would be fair to say that Mahmoud was the “brains” behind the migration – or these days I prefer to think of him as more of a technical mentor. However through this process I found a bit of a niche in developing OWA for Exchange 5.5 beyond that of its original capabilities (I wrote a neat little set of ASP pages that replicated the Outlook Global Address List picker as well as customising the whole “look and feel” to suite the organisations branding).

As the project took shape I aided Mahmoud with the migration, but took lead on the development of a number of tools (using Borland Delphi and Object Pascal) which facilitated the mass creation of Windows NT accounts (Shares, NTFS permissions, Logon Scripts, Profiles etc.), as well as the aforementioned customisation of OWA for Exchange 5.5.

I obviously paid a bit of attention to the architectural side of Exchange, as after Mahmoud left (he was a contractor at the time) – I had to DR the Exchange installation a few times onto new hardware, as well as perform the usual housekeeping stuff such as Exchange and NT Service Packs.

As the years went on, an interesting offshoot to this project that came up – as mentioned, Mahmoud and I worked for one department within a company of over 4000 users (at the time). Each department had its own IT team, and IT systems (including mail) – the repercussions of which were that one person could not e-mail another person internally between departments.

There was no real company “Global Address List” or SMTP internet connectivity  – as other departments were using technologies like Beyond Mail (Banyan Vines), Office Power, Exchange 5.5 or MS Mail!

To cut a long story short story (which involved more drink, women and mad nipple tweaking South Africans whom piss on their own washing long story – see below)

In 2001 the company had decided that it wanted to centralise its IT function from 5 separate IT departments and systems – into one.

This meant that I had to apply for a new role, and I came out the other side as the Infrastructure Manager (pseudo CTO) – and was immediately handed the job of centralising the disparate mail systems and authentication domains into one unified platform.

Having come from a Microsoft background via the migrations from Novell to NT4, and indeed seeing what to me looked like the decline of other vendors (such as Bayan Vines and Novell) products – the natural way forward was to build a centralised infrastructure based upon Active Directory and Exchange Server 2000.

I thought about this proposition for quite a while reading numerous whitepapers and bought a suit (well a shirt and tie) – see below (god I had black hair!!!!)

The task of unifying the company systems presented me with a unique set of challenges, the desperate infrastructures were not necessarily orientated for co-existence – but part of the remit that I had been given was to maintain services throughout the migration process.

As mentioned in the mix I had Banyan Vines (running Beyond Mail), AIX (running Office Power), two lots of NT4 (running two separate Exchange 5.5 installations) – so as you can imagine the logistics of getting all of those platforms (including users, shared files, mail items, printers, permissions etc) onto a central, unified directory and mail infrastructure and keep it seamless was going to be difficult.

Again cutting a very long story short (as the actual details of what I did in the end to get these systems all into one place, would take forever to explain) needless to say, 6 months later the project was completed (on time and to budget) – the key thing that I had discovered during the migrations was how versatile and configurable both Exchange (2000) and Active Directory were even at that stage of their development.

When I say configurable, I mean it was amazing what you could accomplish by understanding the schema and associated ADSI properties of objects in AD and then apply a little scripting knowledge.

I was also in complete awe of how powerful both products were, in particular Exchange 2000 as through its feature set I was able to bring to the business not only a state of the art and resilient mail infrastructure, but added benefits such as really usable web client (in comparison to OWA in 5.5).

The whole product just oozed scalability and at the time it seemed that I would learn something new and cool every day; as I lavished loads of attention on the entire environment.

As the years passed, Exchange upgrades came into the mix, I took the environment from 2000 (both AD and Exchange to 2003) and eventually, just before I left the company in 2010 Exchange 2007 (based on a full CCR implementation).

What continued to strike me as the versions developed was how well the product evolved to provide more “killer” features to the business and to the admins – for example;

Between Exchange 2000 – 2003

• Improved and usable clustering capability (without requiring a PhD in particle physics)
• Workable and integrated implementation of Active Sync
• Much improved OWA experience
• Better Management Tools
• Larger Database sizes for the Standard edition

The whole product set was growing up.  It was around 2005 that I decided that I wanted to begin to write about my experiences with Exchange as well as participate more in the online forums; passing on what knowledge that I had – it was at this point where I completely fell for Exchange Server.

The Exchange community is one of the most vibrant a giving on the web, and for want of a better term an entire online nation of people whom I could learn from, share tips with and get a better understanding of the entire product. Sites like MSExchange.org and the Microsoft Exchange product team blog were (and still are) required reading.

It also amazed me that via the Exchange Team’s blog, you could actually enter into dialog with the development team on a 1-1 basis. It did not matter if you were an MVP, MCM, MCP, MCSE etc. they would speak with you directly to get your feedback.

In around 2005 I started telnetport25.blogspot.com (now defunct) which was my first foray into blogging about anything, but I saw it as a natural extension to my participation in the technical community – and it gave me a voice where I could share my own thoughts, experiences in my own words. The idea of blogspot evolved through to telnetport25.wordpress.com (also now defunct) to what it is today www.telnetport25.com .

In 2009 the community bestowed the distinct honour of becoming an Exchange MVP, where I was re-awarded for the 2010 and 2011 cycles.

In the 14 years that I have been working with E-mail it has become an absolutely essential part of almost all organisations and is a very long way from the 10 accounts that I was in charge of in 1997.

I have now worked on Exchange and Directory implementations of between 5000 – 15,000 seats as well as advised on the architectural side of implementations totalling hundreds of thousands of users, and what never ceases to amaze me is the amount that I still learn every day – not just from the product, but from other people whom are as enthusiastic as I am.

So, to finish – why do I love Exchange Server?

I guess it is because I will never be a master of it, I will always be learning something new – and the way that I do something today, will be different to how I do the same task in 4 months time!. I get to learn from others, and get a grasp of new technologies as they come along.

For example; these days if you are an Exchange admin at any level – you don’t just need to understand Exchange itself – you need to know about Active Directory, Powershell, DNS, IP, SMTP, POP3, IMAP, Telephony, Routing, SAN’s, RAID, Legal Compliance, Effective Systems monitoring – I could go on.

The key point is, that Exchange makes you learn and evolve in your career and by definition does not allow you as a technical professional to become ‘pigeon holed’ in one technology.

I have been making some modifications to my home lab over the last few days, one key change has been to add in a child domain so that I can test Exchange related scenarios in a multi-domain environment.

Naturally, once I had created the child domain, I wanted to populate it with some users – so out came my Powershell Lab users script – with a new CSV file with over 500 unique names within it for the domain.

I executed the script against my new child domain, and it was at this point where I discovered a flaw in the original code logic.

The original script detected the Active Directory domain using the following lines of code:

$domain = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$DomainDN = (([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).Domains | ? {$_.Name -eq $domain}).GetDirectoryEntry().distinguishedName

Which is OK if you are using a single domain and forest, however – if you have a multiple Parent / Child domain configuration and execute the script in the child domain – all the accounts are created in the Parent as the lines above will only detect Parent Domain in the Forest.

Therefore I changed the above lines to the following;

$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain()
$DomainDN = (([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).Domains | ? {$_.Name -eq $domain}).GetDirectoryEntry().distinguishedName

The changes above change the scope of the of the Active Directory lookup to the Active Directory domain which the local computer is a member of.

The script can now be executed from within any domain (either parent or child), and will create accounts correctly.

Usage

Please refer to the original article here for instructions: http://www.telnetport25.com/2009/12/quick-post-%e2%80%93-script-to-create-lab-users-%e2%80%93-powershell-version%e2%80%a6/

Download

You can download the script from the following location – the Self-Extracting file contains the updated Powershell Script file and two sample CSV files which have over 800 user names. I have separated the user accounts into two files in case you have a number of domains (and you obviously would not want the same user accounts in each domain!)

Create-Users.exe [ 150KB ]

Note: The download for this article has been updated with version 1.5 of the tool. 

Yesterday I published version 1 of my Exchange 2010 Roll-Up encapsulation tool – and today I am releasing version 1.1.

The good news is that there is nothing wrong with the original version (i.e. for once I have not had a bug reported to me which means that I have to re-code the entire app!) – but I am providing this update as I have had some pretty immediate feedback from readers of the site where two of the suggestions were far too good not to break out my trusty copy of Visual Studio again!

I would like to pass on my sincere thanks to iLantz for taking the time to feedback to me.

Updated Features

There are two main changes to this release which are as follows:

• The facility to disable Forefront protection services (fscutility /disable)
• Disable specific services from within the tool that could also disrupt the Roll-Up process

Download

The new version of the tool supersedes the old, all you need to do is download the installer from the following location:

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

The installation process is exactly the same as what was covered in the original release – however if you have already downloaded the first version of the tool you can choose to continue using it – or – delete it and install this version (recommended).

New Features in Action

When you load the new version of the tool up the first thing that you should see is a new “Advanced” menu entry at the top of the screen – see below

Selecting the “Custom Services Selector” will open a new Window that lists all of the Services that have been found on the local machine – see below

Selecting a Service will enable the “Stop” button – choose the services that you wish to stop and then click on the “Close” button.

The other new feature is the “Stop Forefront Services” open (from the Advanced Menu above) – select this option if you have Forefront installed on your Exchange Server and it will automatically execute the “fsutility” on your behalf.

Note: There is an update to this post located here: http://www.telnetport25.com/2011/11/update-to-the-rups-tool-apply-roll-ups-to-exchange-2010/

Additionally the original installation files for download have been replaced with the 1.5 versions of the tool.

There are a number of very good articles around on the web which focus on what the appropriate or best practice method is to apply Roll-ups to Exchange 2010 servers which are members of a dag configuration. There are a number of ways to skin this particular cat – which are detailed here, here and my personal favourite here by Paul Cunningham.

What has struck me about the process is that if you are new to Exchange it can be a little bit daunting to execute Powershell scripts, apply the update and then execute more Powershell scripts just to get your node ready for a Roll-up.

Even if you are an experienced Exchange Server admin, jumping in and out of PS console windows can be a little bit of a pain – so I decided to write a tool that centralises the process of applying Roll-ups to Exchange 2010 SP1 (and above) Mailbox Servers which participate in a DAG configuration.

This article will show you how you can obtain and use my tool to apply Exchange 2010 RUPS to DAG members.

Requirements

Before we begin it is important to have a quick look at the tools prerequisites:

• This software must be executed on the DAG node that you wish to install the Roll-up update on
• This software is only compatible with Exchange 2010 Service Pack 1 and above and should be used to apply Roll-up updates to Exchange Servers which are hosting the mailbox server role which is part of a DAG. Other Exchange 2010 roles can be present on the server – but the Mailbox Server role is mandatory.
• .NET Framework 3.5 SP1 and above

Download

You can obtain the tool from the following location:

[ Exchange 2010 Update Management System – v1.5 – 1.3MB ]

Installation

Download the setup binary file from the downloads section of this article to the DAG Member that you wish to update.

Double click on the “Exchange2010_ApplyRUPSSetup.exe” icon on the server which will present you with the following screen:

Once you have clicked on the “OK” button on the Welcome screen you will be presented with the default file extraction location options – choose a location which best suites your needs and then click on the “Unzip” button

All the required file will unzip to the location that you have chosen in the previous step and the application will then automatically launch:

Using the tool

Before you begin to use the tool you should ensure that you have also downloaded the required Exchange 2010 Roll-up to the server which you intend to update.

Once you have done this, navigate to the location where you downloaded the “Apply Exchange Roll Ups” tool and double click on the programs main executable. Doing so will present you with the following screen:

In the “Path to Rollup” section of the tool – click on the “Browse” button and locate the Rollup that you have downloaded and wish to apply.

When you have done the above – the “Exchange DAG Operations” window will change to show the DAG which the local server is a member of, you will also notice that the “Prepare”, “Resume” and “Redistribute” buttons are now enabled– see below:

In the “Exchange DAG Operations” window – expand the DAG that has been detected and select the Server name (this should be the same as the local server that you are running the tool on). Click on the “Prepare” button – see below

The tool will then execute the “StartDagServerMaintenance.ps1” script which performs the following actions:

• All resident database copies are moved to another server within the DAG
• Any core cluster resources owned by that server are moved to another node
• The DatabaseCopyAutoActivationPolicy property is set to Blocked
• Database copies are activation suspended
• The node is paused within the cluster service

See below:

When the script has been completed, from the “Apply Patch” area of the tool – click on the “Apply” button – the tool will then exit, and the patch will then deploy – see below:

When the Roll-up has completed, you may be prompted to reboot – please do so, and when the server has become available, execute the tool again.

From the “Exchange DAG Operations” area – click on the “Override” button, this will enable the “Resume” button.

Click on the “Resume” button – this will execute the “StopDagServerMaintenance.ps1” script which will switch the DAG node back into normal operation – see below:

When the above script has completed – you have the option of clicking on the “Redistribute” button – this will redistribute the Databases within the DAG according to the activation preference.

I hope that you find the tool useful.

Just thought that I would share with you all some of the articles and tips that I have recently had published on MSExchange.org.

Exchange Articles

Using Powershell to Simplify Mailbox Auditing (Part 1)

CSV DAG Creation in Powershell for Exchange 2010

Exchange Tips

Mount all Mailbox Databases on an Exchange Server

Remove Tools from the Toolbox in Exchange Management Console

Get all users who have a forwarding address set

Simple Script to apply Exchange Product Keys

Apply full access permissions to multiple mailboxes for a single user

Quickly set an offline address book for all Mailbox Databases

Colour coding the mount status of an Exchange Database

Quickly view all Arbitration mailboxes in your environment

Please feel free to have a mosey on over and see if there is anything that you find useful

Ok, so last weekend I was happily messing around in my Exchange test lab, then as Elzar from Futurama would say “Bam” the Exchange 2010 virtual server that I am working on dumps me out of RDP and will not let me back in.

I tried to ping the said Exchange Server – no reply, in fact I could not ping anything that was previously running in my lab. At this point I suspected that something screwy had perhaps happened to my home server – darn it, I was in the middle of something!

I popped upstairs to where my trusty friend resided, and noticed immediately that the machine was not powered on.

There was also a strange smell of burning in the air ~ you know the type, like burned out Electronics and melting plastic with a distinct sensation that this was not going to work out well.

I knew that this was a screwdriver job, so I opened up the case which revealed the power supply which can only be described as not looking as good as it used to – with some pretty hefty scorch marks emanating from its air flow vents.

This wasn’t good, in fact I suspected a total disaster.

Fitting a spare power supply that I had stashed away (like many I suspect, over the years I have built up a large range of spare parts for situations just like this one) pretty much confirmed my diagnosis.

Whereas I could get the machine to Power on (well I say “power on” – it beeped at me a whole hell of a lot), the brown out in the PSU had destroyed the motherboard, and after some further (more time consuming) troubleshooting  – the CPU and the RAM.

It was at this point, I probably started crying a little bit as to be without the test lab was one thing, but to know that it was pretty much fried really rounded off what had been a pretty crappy week for me, and at this stage I had no idea if the data on the Hard Drives was safe (about 1.7 TB of Exchange labs for various projects that I had been an was working on).

Also, part of my sobbing was due to the fact that I knew that I had to now go “cap in hand” to the financial controller of the house (sic. the wife) to ask if I could replace my old friend with a new partner in crime, one that didn’t smell of burned rats and would do more than just beep at me.

Now don’t get me wrong, I love my wife; and she does deserve a medal for putting up with both me and my expensive hobby / job, but I knew that on this occasion; asking for the release of capital funds from the household account to fund a new server was going to be the equivalent of Dragons Den. So I got ready for some serious begging.

As it happened, I was due a small windfall due from some technical writing that I had done, so – armed with the knowledge that I could offset the cost of the new lab against the credit card hounds of hell – I set off for my begging session!

An hour later, after explaining the whole scenario and also agreeing to do above and beyond my usual level of household domestication I finally had capital expenditure dispensation from the wife – so off to the Internet I trundled with credit card in hand!

The new specification

I thought that I would put the boat about a little bit and spend some serious cash on my new lab server, after all I was already dog house, so how much worse could it get? (actually don’t answer that!).

As many of you know I am serious about my blogging, and even more serious about working with Exchange Server so I decided that it was about time that I stopped messing around with kit at home that was in constant need of tweaking in order to get 7 Virtual Machines running with a reduced specification – I needed a home rig that can run up to 10 VM’s at a specification which is as close to production as I can realistically get.

So, the following was what I came up with:

What I liked about the above specification is that it gave me a good price point, which weighed up favourably with performance out of the box, and scalability for the future (although I have promised the wife that I will not upgrade it for at least a year ~ well, it might have been two years, but time erodes people’s memory of conversations!)

Putting it all together

This is perhaps my favourite part of getting any new computer – physically putting it together (I am the type that has always had custom machines made up from separate parts . I find that consumer models that you can get in the shop just don’t have the right specifications for the task that I will use the boxes for).

Of course there are a few of the downsides to building you own rigs, is that they can be fiddly to get to work first time, and indeed in the past I have been known for, how shall we say, making the odd fatal mistake (like putting in too many AIX mounting pins ~ bang!).

However I made sure that this time around, that I double, and triple checked each and every part’s placement within the case – avoiding that crispy “hair do” and a dead mother board moment (and more sobbing).

Below are a few snaps from the build process (I have a habit of documenting every machine that I build like this) for those whom are interested;

[Show as slideshow]

12►

Performance

Now that the machine is up and running, I can tell you that the performance is incredible.

The i7 processor just does not break into a sweat, and with the intelligent overclocking features of the Asus Mainboard mean that power is delivered to the Virtual machines “on demand”.

I can get about 11 machines running concurrently in the lab (if using Exchange 2010 with a reasonable spec about 6) all without noticeable slow down on the host or within the VM.

The only thing that I would probably change is replacing the Stock Cooler that comes with the i7 for a commercial alternative. From monitoring the machine the idle temperature is around 30 – 35 degrees Celsius  per core – which is ok, however I have seen it spike to about 60 – 72 when under load.

Whereas none of the above will cause the i7 major problems (the Tj.Max is around 98 ~ for those whom don’t know Tj.Max stands for Temperature Junction max and it is the threshold that needs to be reached before the CPU will be throttled down to a slower speed – this is different to the Thermal Cut-Out – which is where the CPU kills the system and shuts down before it is damaged).

By changing the stock cooler can probably overclock the entire rig safely to about 3.8 (although Overclockers.com managed to get one to 4.3 running at around 73 degrees – but I am not interested in that!) with a different heat sink.

Did I get all my old VM’s back?

The good news was, that although the internal hard disk drives from the old server were, like the rest of the old kit – “dead” – I stored all of my VM’s on USB3 external Hard Drives (long story) – all of them worked perfectly when connected to the new rig, so I was able to copy the content to the new 2 TB disks with no issues.

The Case (Enclosure)

I know, there are other cool parts in this rig that perhaps deserve a mention, but the case is – to say the least very cool (both from a looks and, well, cooling perspective).

Normally I would always buy ThemalTake cases and Power Supplies – but the vendor whom I went to did not seem to have any in stock, so I opted for the Antec Dark Fleet 85 ~ All I can say is wow and I was not disappointed!

7 fans, all adjustable, cleanable fan filters, provision for hot swap SATA, 2.5 inch SSD hot plug bay at the top and really easy to work with.

Really amazing bit of kit, and it runs the with the associated parts so well – I can really recommend it.

As you can imagine – I am really pleased with the whole setup – and the best bit of all is that I can continue to write articles for all of you – perhaps just slightly faster!

Client Access Arrays were introduced in Exchange 2010 as a means to provide High Availability scenarios for RPC clients (MAPI).
In previous versions of Exchange RPC / MAPI access was handled by the Mailbox Server role, where OWA and HTTP access were handled by the Client Access Server role.

In Exchange 2010 – the Client Access Server Role services all methods of connecting to your Exchange mailboxes.

Now, whilst this is a good thing as you can separate you CAS Servers from your Mailbox Servers therefore ensuring that the overhead of all Client Connectivity is taken away from the Mailbox Role, which is very useful in large / high demand environments – there is one small problem.

Once your Outlook client has made a connection to a Client Access Server in your Exchange 2010 environment, the routed connection stays with that CAS.

Therefore if the CAS Server goes down for any reason, you lose the connection to the Mailbox Server, and will not failover to any other CAS in your site.

This is where Client Access Arrays come into play.

The idea behind a Client Access Array is to group together all the CAS Servers within your AD site (remember that CAS Arrays are AD Site Based), and then using a load balancing solution provide a single connection point for RPC clients which is made up of a number of CAS endpoints.

This can be accomplished using Windows Network Load Balancing – however the best practice recommendations from Microsoft state that you should use a Hardware load balancer solution, this is the point where you might be asking the question why?

Well…

• Windows NLB is not supported on the same server as Failover Clustering – therefore, if you are running Exchange 2010 servers that combine the CAS and Mailbox Server role and you wish to use DAG – the you are out of luck
• Windows NBL Does not provide the ability to monitor dependency services – for example; if a request to port 443 is being routed via a NLB and IIS is down on the CAS, NLB is completely in the dark – most hardware Load Balancers provide “Service Awareness” and can monitor for you
• NLB does not scale well in large client basis – a standard Outlook client will initialise 6 sessions to NLB (4 MAPI + 2 HTTP) – so if you have 5000 clients that’s 30000 sessions that the CAS and NLB have to deal with – and NLB is not really recommended beyond 8 target nodes, so you are limited in what you can do

Therefore given given the above – a simple, visual overview of the above might look like the following in a production environment;

The CCAA Tool

Now that we have covered (very quickly and not in a great deal of detail) – the premise behind Client Access Arrays – we now move into how you can create them. Now, I will not go into huge amounts of detail here – as there are a number of good articles out on the web which take you through the process for example; here and here – however suffice to say the following are the basic steps:

• Create a DNS [A] Record pointing to the Published Address of you LB solution
• Drop into Powershell and Execute the “New-ClientAccessArray” cmdlet
• Add Mailbox Databases to the Array using the “Set-MailboxDatabase –RpcClientAccessServer”

Now the above process is simple enough, however being the type of guy whom really like simplicity – I started to think – surely I could write a little bit of software that provides a GUI overlay to the above which automates the process by performing the following tasks:

• Creating the DNS [A] Record
• Creating the Client Access Array
• Adding Databases to the Client Access Array

Requirements

In order to get the best from this tool your host system should meet the following requirements:

• This application will only run on x64 Systems
• .NET 3.5 or above installed
• Exchange 2010 Management Tools

Download

The tool can be downloaded from the following location:

[Exchange2010CCAA-Inst.exe – 612 KB ]

Install

In order to install the CCAA tool, double click on the “Exchange2010CCAA-Inst.exe” file when you have downloaded it to your Exchange Server:

You will be presented with a welcome message – click on “OK” to continue – see below

Chose an installation location on your Server – or – accept the defaults, when ready click on the “Unzip” button – see below

When the installer has finished extracting files you will be presented with the following message – click on the “OK” button – see below

Using the CCAA Tool

When the installer has finished the tool will automatically load – see below

• In the section entitled “DNS Server Name” – provide the FQDN or the IP address of the DNS Server where you would like to create the [A] Record for your Client Access Array, when you have done so – click on the “Get DNS” button.
• The section below the “Please select the DNS Zone that you wish to create the A record in:” will populate – select a DNS zone.
• In the section entitled “A Record Name” type in the name that you would like the CAS-Array to be known by
• In the section entitled “A Record IP” provide an IP address for the [A] record – this should be the published connection address of your Load Balancer solution.

- See below -

• The “Save” button will now be enabled – click on it – and the “Save Status” will change to show that the record has been save to the DNS Server.
• You might want to double check this by pinging the DNS record.

When you have clicked on the DNS Save button, the area at the top right of the application window entitled “Client Access Array Name” will change to reflect the name of the CAS array – click on the “Create” button – see below

When you have clicked on the “Create” button – the “Client Access Array Configuration” window  (located at the bottom of the application window) will change to reflect your settings so far – see below

In the “Exchange Databases” section (below the “Client Access Array Name” area) – click on the “Refresh” button to retrieve a list of all your Mailbox Databases. Select the Databases that you wish to be within the Client Access Array – and then click on the “Add” button – see below

When you have added your Databases, you will see that the “Client Access Array Configuration” window changes to show you what you have added so far. When you are happy with your selections – click on the “Commit” button.

It is at this point where the Client Access Array configuration is saved by the tool and made active within your environment – see below

You can check to see if the configuration tool has completed successfully by opening an Exchange Management Shell command prompt and typing “Get-ClientAccessArray” – see below

I hope that you enjoy the tool, and indeed that someone finds it useful. As always let me know of any features, changes, problems that you may encounter – and above all else – remember, test the tool in a lab before you use it in production!

A little while ago I ran into a neat little freeware tool for Powershell called the Inactive Users Tracker PowerShell Cmdlet by a company called Netwrix.
This cmdlet in essence provided a nice, simple to use wrapper for consolidated last logon information for accounts in Active Directory (as you may be aware the lastlogon attribute is not replicated in 2003 environments, and can be a little difficult to average out using a script).

I initially started using the Netwrix module for reporting on inactive account information within my directory environments, however, the potential for it to be used as part of a much wider tool to weed out, and close down unused accounts and mailboxes was clear – so in this article I have come up with a sample script to give you some ideas on how you can automate the following processes using it:

• Finding accounts that have not been logged into for a defined period of time
• Export the mailboxes attached to those account to PST
• Remove the mailboxes
• Disable the Active Directory Account
• Move the AD Account to a specific OU

Unfortunately, Netwrix has now discontinued this tool in favour of a GUI version which I believe can be scheduled from the command line – however you can still download the version that I am using from here which I advise that you do as the functionality is really cool.

The script itself is loosely based upon an article that I published here in August of this year (2011) – but expands upon its functionality.

One thing that I must point out is that this script is a sample only and should not be used in production without modification.
If you intend to use this script in a production environment – you should look at implementing exclusions from the export and disable process – as typically there are a number of mailboxes in production that on face value are not logged into, but are serving a purpose.

Additionally, you should also consider excluding accounts where the owner is on long term absence.

What I am saying is – use at your own risk!

Requirements

In order to make use of this script you will need to have the following pre-requisites installed on your Exchange (or Management Server):

• Exchange 2007 Management Tools
• Microsoft Outlook 2003 or 2007
• Quest Active Directory Cmdlets library
• Netwrix Powershell Library (requires a very quick installation)

Download

The script is available for download below – or you can copy it from the this page to a PS1 file on your Management / Exchange Server:

[ ExportMailboxesToPst-BasedonLogon.ps1 – 3KB ]

# Export Mailbox to PST, Disable Mailbox, Active Directory Account and Move to OU
# Version 1.0
# Author: Andy Grogan
# NOTE: This script REMOVES the mailbox from the account from the store
#
#
Add-PSSnapin Quest.ActiveRoles.ADManagement
Add-PSSnapin NETWRIXIUTPSSnapIn
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

$ErrorActionPreference = "SilentlyContinue"

# Change the following to fit your requirements

$gblInactiveDays = 50
$DestinationPSTPath = "X:\Psts"
$ServiceAccount = "Administrator@ethan.local"

function get-DNC{

     Param (
           $RDSE
       )

       $DomainDNC = $RDSE.defaultNamingContext
       Return $DomainDNC

}

$NC = (Get-DNC([adsi]("LDAP://RootDSE")))
$DisabledAccountOU = "OU=DisabledUsers,"+$NC

function apply_Permissions($strMailbox){

    Remove-MailboxPermission -Identity $strMailbox -User $ServiceAccount -Deny -InheritanceType 'All' -AccessRights 'FullAccess' -Confirm:$false
    Add-MailboxPermission -Identity $strMailbox -User $ServiceAccount -AccessRights 'FullAccess' -Confirm:$false
}
function remove_permissions($strMailbox){
    Remove-MailboxPermission -Identity $strMailbox -User $ServiceAccount -InheritanceType 'All' -AccessRights 'FullAccess' -Confirm:$false
    Add-MailboxPermission -Identity $strMailbox -User $ServiceAccount -Deny -AccessRights 'FullAccess' -Confirm:$false
}

function get_ADDomain(){

    $strDomain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name
    return $strDomain
}

function disable_mailbox($strMailbox){

    Disable-Mailbox $strMailbox -Confirm:$false

}

function get-dn ($SAMName)
{
    $root = [ADSI]''
    $searcher = new-object System.DirectoryServices.DirectorySearcher($root)
    $searcher.filter = "(&(objectClass=user)(sAMAccountName= $SAMName))"
    $user = $searcher.findall()

    if ($user.count -gt 1)
      {
            $count = 0
            foreach($i in $user)
            {
            write-host $count ": " $i.path
                  $count = $count + 1
            }

            $selection = Read-Host "Please select item: "
            return $user[$selection].path

      }
      else
      {
          return $user[0].path
      }
}

function moveToDisabledOU($strDN){

    move-QADObject -Identity $strDN -NewParentContainer $DisabledAccountOU
}

function get_InactiveAccounts(){

    $Domain = get_ADDomain
    $Accounts = Get-NCInactiveUsers -domain $Domain -days $gblInactiveDays

    foreach($Usr in $Accounts){

        $User = Get-User $Usr.AccountName

        if($User.RecipientType -eq 'UserMailbox'){
            $path = Get-DN $User.samAccountName "'" + $path + "'"
            apply_Permissions $User.Identity
            Export_ToPST $User.Identity
            remove_Permissions $User.Identity
            disable_mailbox $User.Identity
            $QADPath = Get-QADUser -Identity $User.samAccountName
            $account=[ADSI]$path
            $account.psbase.invokeset("AccountDisabled", "True")
            $account.setinfo()

            Set-QADUser -Identity $user.samAccountName -Description "Account Disabled by PST Export Script"

            moveToDisabledOU $QADPath.DN
        }
    }
}

function export_ToPST($strMailID){

        Export-Mailbox -Identity $strMailID -PSTFolderPath $DestinationPSTPath -Confirm:$false
}

get_InactiveAccounts

Using the script

Before the script can be scheduled for use, you will need to ensure that you have performed the following actions:

• Create an OU within your Active Directory infrastructure called “DisabledUsers” – see below

• Create a user account with the correct Exchange Permissions within your Exchange environment – the account needs to have a mailbox and have the following Exchange permissions:
  • Exchange Server Administrator
  • Local Administrator on the Management / Exchange Server
     
• You should then create a directory on your Management Server that will contain the exported PST files – in my example I have created a folder called “X:\Psts” – see below

• You should edit the script file and change the following values (located at the top of the script; to match the settings of your own environment)

$gblInactiveDays = 50
$DestinationPSTPath = "X:\Psts"
$ServiceAccount = "Administrator@ethan.local"

The value of $gblInactiveDays is the seed value for how long an account has not been logged into – in my example the script will seek out Active Directory accounts that have not been logged into in 50 days.

The value of $DestinationPSTPath is the location on the local management server where the PST files will be stored.

The value of the $ServiceAccount should be the SMTP address of the user account that you have created to export the mail items from the Mailboxes.

• Once you have edited the script file to suite your needs, you should create a batch file that executes the script and can be scheduled via the Windows task manager.

In order to do this you should create a .cmd file with the following commands contained within it:

@Echo off
@Powershell -command "& {x:\<PathToScript>\ExportMailboxesToPst-BasedonLogon.ps1 }"

See below:

When you have done the above, you should then schedule it via the Windows Task manager to execute (using the service account that you have stipulated) at a time which is most appropriate to your environment.

Script Operation

It should be noted that depending on the size of the mailboxes concerned – the time it takes for this script to execute could vary from a few minutes to a few hours or even days) – you should take note of this when scheduling the task in the Windows scheduler.

When the script is executed it will perform the following actions:

• Seek out Active Directory Accounts with Mailboxes that have not been accessed in the $gblInactiveDays
• Apply full mailbox access permissions to the service account on each Mailbox
• Export the e-Mail items to a PST file located in the PST path location
• Disable the Exchange Mailbox
• Disable the AD account
• Move the AD account to the DisabledUsers OU
• Stamp the Description of the Account with the moniker that it was placed there by the script

Therefore after execution in the PST folder you should see PST’s for the accounts that complied with the filter – see below

In the DisabledUsers OU in Active Directory Users and Computers you should see a list of accounts that have been processed – see below

Within the Exchange Management Console you should see that the relevant account have been removed – see below

Before:

After:

I hope that this example provides a little inspiration for some folks and gives you some pointers on how you can automate the processes of removing old accounts within your Infrastructure.

Linked to my previous post here after I had solved one issue I was immediately faced with another.

Even though I was now past the “Approving Object” error – I now had a “Moving Messages” error as per the log file below:

[10/11/2011 14:22:54] [0] Executing Command: 'Export-Mailbox ana.hayes -PSTFolderPath X:\psts -ReportFile x:\test.txt'
[10/11/2011 14:22:54] [0] Trying to open registry key 'Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\OUTLOOK.EXE'.
[10/11/2011 14:22:54] [0] The default value of the registry key is 'C:\PROGRA~1\Microsoft Office\Office12\OUTLOOK.EXE'.
[10/11/2011 14:22:54] [0] The version of Outlook.exe is '12.0.4518.1014'.
[10/11/2011 14:22:54] [0] Searching objects "ana.hayes" of type "ADUser" under the root "$null".
[10/11/2011 14:22:54] [0] Previous operation run on global catalog server 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:22:54] [0] Processing object "ethan.local/ExchangeUsers/Ana.Hayes".
[10/11/2011 14:22:55] [0] Searching objects "prod-ex27dc-01" of type "Server" under the root "$null".
[10/11/2011 14:22:55] [0] Previous operation run on domain controller 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:22:55] [0] Searching objects "PROD-EX27DC-01\First Storage Group\Mailbox Database" of type "MailboxDatabase" under the root "$null".
[10/11/2011 14:22:55] [0] Previous operation run on domain controller 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:22:56] [0] Ending processing.
[10/11/2011 14:22:56] [0] [Ana.Hayes] The operation has started.
[10/11/2011 14:22:56] [0] [Ana.Hayes] Initializing MAPI, loading library.
[10/11/2011 14:22:56] [0] [Ana.Hayes] Approving object.
[10/11/2011 14:22:56] [0] [Ana.Hayes] Logging on to the MAPI profile.
[10/11/2011 14:22:56] [0] [Ana.Hayes] Opening Exchange mailbox.
[10/11/2011 14:22:57] [0] [Ana.Hayes] The operation has finished.
[10/11/2011 14:22:57] [0] [Ana.Hayes] The operation has started.
[10/11/2011 14:22:57] [0] [Ana.Hayes] Initializing MAPI, loading library.
[10/11/2011 14:22:57] [0] [Ana.Hayes] Approving object.
[10/11/2011 14:22:58] [0] [Ana.Hayes] Logging on to the MAPI profile.
[10/11/2011 14:22:58] [0] [Ana.Hayes] Opening Exchange mailbox.
[10/11/2011 14:22:58] [0] [Ana.Hayes] Opening PST file.
[10/11/2011 14:22:59] [0] [Ana.Hayes] Moving messages.
[10/11/2011 14:22:59] [0] [Ana.Hayes] Merging messages.
[10/11/2011 14:22:59] [0] [ERROR] Error was found for Ana Hayes (Ana.Hayes@ethan.local) because: Error occurred in the step: Moving messages. Failed to copy messages to the destination mailbox store with error:
MAPI or an unspecified service provider.
ID no: 00000000-0000-00000000, error code: -1056749164
[10/11/2011 14:22:59] [0] [Ana.Hayes] The operation has finished.

Luckily this problem was easier to fix as it turned out to be as simple as the account with which I was executing the cmdlet (Export-Mailbox) did not have the correct permissions on the source mailbox.

Therefore the solution was to assign the execution account Full Mailbox Access Permissions to the Source Mailbox.

Assigning these permissions can be done via the Exchange Management Console – or via the Exchange Management shell using the Add-MailboxPermission cmdlet;

Add-MailboxPermission –Id <UserMailbox> –User <Account to have permissions> –AccessRights ‘Full Access’ –Confirm:$false

Whilst writing a script for a larger post today I came across the above error.
In essence, every time that I tried to use the Export-Mailbox cmdlet it would terminate and not finish the export operation.

Reviewing the log file (which is located in <Exchange Binary Root>\Logging\MigrationLogs) I would see the following information:

[10/11/2011 14:18:33] [0] Executing Command: 'Export-Mailbox ana.hayes -PSTFolderPath X:\psts -ReportFile x:\test.txt'
[10/11/2011 14:18:33] [0] Trying to open registry key 'Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\OUTLOOK.EXE'.
[10/11/2011 14:18:33] [0] The default value of the registry key is 'C:\PROGRA~1\Microsoft Office\Office12\OUTLOOK.EXE'.
[10/11/2011 14:18:33] [0] The version of Outlook.exe is '12.0.4518.1014'.
[10/11/2011 14:18:33] [0] Searching objects "ana.hayes" of type "ADUser" under the root "$null".
[10/11/2011 14:18:33] [0] Previous operation run on global catalog server 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:18:33] [0] Processing object "ethan.local/ExchangeUsers/Ana.Hayes".
[10/11/2011 14:18:33] [0] Searching objects "prod-ex27dc-01" of type "Server" under the root "$null".
[10/11/2011 14:18:33] [0] Previous operation run on domain controller 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:18:33] [0] Searching objects "PROD-EX27DC-01\First Storage Group\Mailbox Database" of type "MailboxDatabase" under the root "$null".
[10/11/2011 14:18:33] [0] Previous operation run on domain controller 'prod-ex27dc-01.ethan.local'.
[10/11/2011 14:18:34] [0] Ending processing.
[10/11/2011 14:18:34] [0] [Ana.Hayes] The operation has started.
[10/11/2011 14:18:34] [0] [Ana.Hayes] Initializing MAPI, loading library.
[10/11/2011 14:18:35] [0] [Ana.Hayes] Approving object.
[10/11/2011 14:18:35] [0] [Ana.Hayes] Logging on to the MAPI profile.
[10/11/2011 14:18:35] [0] [Ana.Hayes] Opening Exchange mailbox.
[10/11/2011 14:18:35] [0] [ERROR] Error was found for Ana Hayes (Ana.Hayes@ethan.local) because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221219
[10/11/2011 14:18:35] [0] [Ana.Hayes] The operation has finished.

Investigating the cause of the error using Google revealed nothing of any real value.

I pondered for a while about this and surmised that this error was perhaps down to the fact that the source mailbox that I was trying to export to PST had no items within it  – as I was working in my lab.

I sent a single item to the mailbox and attempted to try the export again – and this time it worked.

So, the moral of the story is that one cause of the “Unknown Error” (which I am assuming is a generic “don’t know what the heck happened” error code) is that the mailbox that you are trying to export is empty or has not been logged into before.

Came across this little issue today and thought that I would share the troubleshooting method and end solution, just in case someone else comes across the same scenario.

I had a number of reports from customers throughout the business which claimed that when trying to send photos to work e-mail addresses (in some sections of the business this is common place) via a mobile smart device – the messages would not send.

Sending an e-mail from the same phone without an attachment appeared to work just fine.

I did a little bit of troubleshooting from my trusty iPhone and found that I could send e-mails from my device, with attachments – however, only if I reduced the overall message size to around 1MB.

Now, I knew that the global message size limit for our environment was far higher, set at around 15MB – this was indeed proven by the fact that people using Outlook could send e-mails with attachments of sizes above 1MB to 15MB with no problems.

I also considered that perhaps there was some form of “Carrier” restriction that had been implemented on some tariffs – e.g. our mobile carrier for the business restricting the size of e-mail messages (the company uses T-Mobile whereas my personal handset is with Vodafone) – however I quickly discounted this as the same behaviour was exhibited using a company device over Wi-Fi.

This issue seemed to affect most users, and pretty much all devices that we have in production (iPhones, HTC based Android, Windows Mobile 6 devices etc.) – so a device specific issue was also very unlikely.

I also considered other factors such as server centric attachment filtering, but this was also discounted as in our environment there are no restrictions on the type of the attachments which the customers were trying to send.

Deciding that this was more than likely to be some kind of server issue a cursory investigation of the Exchange 2003 Mailbox revealed no issues which would prevent attachment sending from a mobile device.

Now unsurprisingly and as you might expect, our business has Exchange 2003 deployed (still) using a Front End / Backend scenario so I decided that the next most logical place to look for an issue would be on the FES.

It didn’t take long for me to hit “pay dirt” as the first thing that I noticed upon logging onto the Server was that the C:\ drive was almost out of disk space (about 2MB free).

This was interesting, as the attachment sizes that failed to send seemed to correlate with the amount of free space on the drive.

So, I managed to clear around 6GB (deleting old IIS log files) – and this solved the problem.

Now there are questions that I will need to continue to ask of my main ICT supplier as to why the low disk space threshold was not picked up – but in terms of the solution to the overall issue, if you are in a situation similar to that as I have described – have a look at your FES to ensure that it is a happy bunny!

I am probably the only person in the world whom finds the process of exporting Exchange Certificates to a file within Exchange 2010 a little bit fiddly – in fact – whilst I think about it, I found it fiddly in Exchange 2007.

Now that does not mean that I don’t know how to export Certificates from either version of Exchange (honest!!!) – just that I have never found it to be very intuitive, or in parts – consistent.

As many of you will be aware in Exchange 2010 you can export an existing Exchange enabled certificate from either the Exchange Management Console or the Exchange Management Shell.

You can also export these certificates from the IIS Server Manager – however it is important to note that this is not the preferred method, and Microsoft recommends that you use the Exchange supplied tools for managing any certificate which is used in connection with Exchange Server 2010 (this was also to the recommendation for Exchange 2007).

To give you some background – exporting from within the Exchange 2010 Management Console is accomplished via navigating to the [ Server Configuration ] node – see below;

Selecting an Exchange Server which contains the SSL certificate that you are interested in, and then on the “Exchange Certificates” tab (located in the bottom middle of the window) a list of the available certificates will be displayed – see below;

Once you have selected your Certificate the “Actions” area (to the right hand side of the screen) will change – towards the bottom you will see an option to “Export Exchange Certificate” – see below

You are then presented with a two step wizard that will ask you for a path for the export PFX file, and the private key that you wish to assigned to the PFX file (this is used later on when you need to import the file) – see below

Clicking on the “Export” button completes the process and outputs the PFX file to your desired location with the Private key assigned – see below

Of course the Exchange Management Shell provides another means to export Exchange based certificates to PFX files – an example which uses the “Subject Name” of the Cert is provided below – there are other ways that this can be achieved, for example here.

$sub='CN=owa.prepAD.local, OU=IT, O=Telnetport25.com, L=London, S=Middx, C=GB'
$pwrdNS=ConvertTo-SecureString "password" -asPlainText -Force
$cCert = Get-ExchangeCertificate | where {$_.Subject -eq $sub}
$file = Export-ExchangeCertificate -Thumbprint $cCert.Thumbprint -BinaryEncoded:$true -Password $pwrdNS
Set-Content -Path "X:\Test.pfx" -Value $file.FileData -Encoding Byte

Now, as I said in the introduction to this article that I have personally found the above processes to be a bit fiddly in practice and being the type of person whom backs everything up – I wanted a tool that could be fired up quickly and used to export Certs to a given location as a backup. In the absence of such a tool – I decided to write one – therefore I am pleased to present the Exchange 2010 Certificate Export tool.

Download

[ Exchange Certificate Export Tool – 500K ]

Requirements

In order to get the best from this tool your target system should be running:

• Windows 2003 SP1 and above x64, Windows 2003 R2 and above x64, Windows 2008 Server SP1 x64, Windows 2008 R2 x64
• .NET Framework 3.5
• Exchange 2010 Management Tools

You should install the tool on the Exchange Server where the certificates that you wish to export / backup reside.

Install

Once you have downloaded the above setup file to the server of your choice, double click on the “ExchangeCertSetup.msi” file to launch the program installer. Follow the installation wizard through to competition, an icon for the product will be placed within your start menu and on the desktop.

Usage

Launch the program from the start menu [ Start –> Programs –> Exchange 2010 Certificate Export Tool –> Export Exchange 2010 Certificates ] or from the desktop icon – see below

You will be presented with the main screen – from the “Certificate Information” area select the Service of the certificate that you wish to export (bear in mind the software will only detect certificates which are enabled for that service), the “Find” button will then enable – click on “Find” to retrieve the certificate list – see below

The window below the “Find” button with then populate, select the the certificate that you wish to export / backup – you must also provide a Private Key value (password) in the “Private Export Key” box – this is mandatory – if you do not provide a value the program will prompt you – see below

Click on the button to the right of the “Export Path” path field, this will open a save file dialog box – navigate to the path where you wish to save the export file and then provide a filename and click on the “Save” button – see below

The export path field will then populate – click on the “Export” button to begin the process of exporting the certificate. When the program is done, the PFX file will be in the location that you stipulated as well as a log file of the entire process – see below

It’s a simple tool – and I admit that some of you may have no use for it – but, I hope that some folks get some value as I now use it all the time to export and backup my clients Exchange certs. As always – let me know of comments and suggestions.

The Out of Office Configuration Tool Assistant (OOOCTA) was released over 6 months ago and is one of my most favourite tools that I have written, however I accept that it can be a little difficult to setup and get working particularly as there are so many diverse environments out there.

Given the above I have decided to write a quick post that goes through some of the more common problems that I have been made aware of.

Make sure that you are running the latest version

It is very important to make sure that you are running the latest version of the OOOCTA – there have been a number of patches since the RTP version – this can be found in the Downloads section of the site.

Please note that the patches are NOT cumulative (not yet) you must install them in order (e.g. RTP Release, Patch 1, Patch 2 – etc).

Running the correct EWS Version Mode

The EWS is the heart of the OOOCTA and it is key to ensure that you have selected the correct version of Exchange to execute the EWS against.

• If you are running OOOCTA on an Exchange 2010 Server or on a Management Server with the Exchange 2010 Management tools installed you should ensure that the Exchange Version is set to “Exchange2010” in the [ System Admin ] menu – see below

• If you are running OOOCTA in an “Interop” environment (e.g. with Exchange 2010 and Exchange 2007) – install OOOCTA on the Exchange 2007 Server – or on a management server with the Exchange 2007 Management tools installed and then ensure that the EWS version is set to “Exchange2007_SP1” – see below

The OOOCTA will still function against Exchange 2010 based mailboxes in this configuration.

• If you are running OOOCTA against Exchange 2007 – ensure that you have set the EWS functional level to “Exchange2007_SP1”

Ensure that the svcOOOCTA_DOM Service account has the proper permissions when using Exchange 2010

The OOOCTA Setup manual explains how to configure the svcOOOCTA_DOM service account for Exchange 2007 – but does not explain in great detail how to do the same in the context of Exchange 2010.

In order to ensure that the service account has the correct permissions you will (after you have created the service account mailbox) to assign the Organization Management role via the ECP.

Before you can configure the Organization Management role, you will need to be logged onto your Exchange 2010 server with the correct permissions (an account that has Organization Management rights already for example). You will them need to Open Internet Explorer and navigate to https://<YouCASServer>/ecp

Once you have logged into the ECP you will need to click on the “Roles & Auditing” option on the right – see below

Then double click on the “Organization Management” option – see below

Then add the svcOOOCTA_DOM account into the members list – see below

Then click on the “Save” button.

Make sure that SQL is configured to allow mixed authentication

Some people have reported to me that after installing the OOOCTA, the “OOOCTA Command Processor” service hangs on start-up.

When trying to manually start the service they are presented with the following error message:

In the event log, the following entry can then be found:

Faulting application name: outofofficeservice.exe, version: 3.5.0.1, time stamp: 0x4dfda869
Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e21213c
Exception code: 0xe053534f
Fault offset: 0x000000000000cacd
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13

Furthermore, when trying to view the [ System Log ] in the management interface they are presented with the following error:

These issues are almost always caused by:

1. The OOOCTA Command Processor and Management Interface not being able to connect to the Database
2. The SQL Server does not allow for Mixed Authentication (NTML and SQL passwords)

In the case of the latter – you must enable mixed mode authentication on your SQL server.

Make sure that SQL Server Network configuration is setup to allow connections to the Database

The most common problem however is the OOOCTA not being able to connect to the SQL database.

How you choose to configure this will be very much down to your own environment, but by default OOOCTA will attempt to connect to the SQL Database server stipulated in its configuration files using:

• Localhost\<InstanceName>
• <InstanceName>

If the SQL Database is installed on the same server as the OOOCTA you will need to have configured SQL to accept connections to 127.0.0.1 – this is accomplished using the [ SQL Server Configuration Manager –> SQL Server Network Configuration –> Protocols for SQLExpress ] – see below

Double click on the TCP/IP entry (make sure that it is enabled) – and from the dialog box that appears click on the IP Addresses tab and locate the 127.0.0.1 address – make sure that it is also enabled – see below

For reference the configuration files for OOOCTA which govern the SQL Server properties are located in:

<Install Path>\Interface\Web.config

<Install Path>\Service\OutOfOfficeService.exe.config

I hope that the above helps some people out, and encourages more folks to download the software. I do try my very best to offer as much support as I can for the tool and apologise to those whom I have not had the chance to contact back – I am hoping that this post will assist you.

I like to write about my technical screw-ups – especially when I am sober enough to remember them (perhaps I have just found the root cause…) as they can serve either as warning not to try something, or as an indicator to my overall competence – I will let you all be judge of which category this rambling fits into.

Anyhow I tried this (sic. the title of this post) the other day with little success.

Normally I would not install any other product on an Exchange Server other than Anti-Virus or Backup software (even in a Lab) – however the situation demanded that I install Visual Studio and Exchange 2010 on the same box.

NOTE: It is important to understand that the work that I was doing was purely in a LAB – I would personally never consider doing this in a production environment.

To give you all a very simple idea of the setup that I am using, I have a 3 Server DAG configuration running on Windows 2008 R2 with Exchange 2010 SP1 RU5 – where on the first Node of the DAG I needed to install VS2010 for some development work.

This did not work out well. In fact it was a complete disaster!

Now I will admit that I had a few problems with the VS installer, as firstly I installed the wrong version of Visual Studio (2008 ~ don’t ask why I did this, I still cannot understand why I made such a basic error, might have something to do with Beer and the amount that I had consumed before I began).

I removed VS 2008, rebooted, and then attempted to install Visual Studio 2010 – which failed to complete several times – as each initial attempt terminated with a more perplexing error message than the last.

Finally (after a lot of perseverance) I managed to get Visual Studio 2010 onto the Server – however it was at this point where my problems really started!

Initially I discovered issues when running Powershell (either running the Exchange Management Shell or just normal PowerShell) – for example; attempting to execute commands such as “Get-MailboxDatabase” or “Get-EventLog”.

Each command would exit throwing an exception, then every subsequent command (any command) would throw an error message about not being able to initialise the thread.

Furthermore when trying to start the EMC, I received an error message about MMC Snap-in registration, after clearing the error dialog box the EMC would then crash out.

Whereas I cannot pin-point the actual cause of the errors (either through losing interest, needing more beer, or running out of time to do some development) – I suspect that by using my “no smoke without fire” troubleshooting principle I concluded that Visual Studio 2010 installs various .NET 4 runtime environments which caused a number of major issues with Exchange 2010 as its preferred run time is 3.5 SP1.

I cannot find anything on the web which provides a direct support stance on Exchange with Visual Studio 2010, however I have found some references to some issues with Exchange servers running .NET 4 in conjunction with Exchange 2010 SP1  here (in the comment section), and here.

Interestingly enough the following article (and table) here suggest that .NET 4 is supported if it is upgraded from 3.5 or 3.5 SP1 – however in my case one would expect that by virtue of the fact of installing VS 2010 with .NET 4 would upgrade the 3.5 runtime – for my situation it appeared not!

However all of the above being said, it does seem that if you (I) install(ed) Visual Studio BEFORE Exchange then VS and .NET 4.0 can run side-by-side with no issues.

Therefore given the above my recommendations on this scenario are:

1. As a first option – don’t do it – best practices for Exchange is that no other software should be on the same machine as Exchange (unless it is backup, monitoring or AV related) – my findings would also suggest that .NET 4 should be installed with extreme care on an Exchange 2010 server
2. In practice – If you do need to use Visual Studio with Exchange – install it on a dedicated Management Machine with the Exchange Management Tools installed
3. If you do need VS on the Exchange Server – do not install it after you have installed Exchange – it seems that you will be asking for trouble
4. If you are using VMWARE or any other Virtualisation product and decide that you need Visual Studio / .NET 4 on your Exchange Server – snapshot the machine before you install it (if you are using DAG you might wish to disable replication as restoring a snapshot within a DAG can get messy)

Visually the installation method that I used that did not kill either Exchange or Visual Studio 2010 – looks like the following:

To sign off – It does occur to me that perhaps there are some folks out there that have managed to install Visual Studio 2010 on the same machine as Exchange Server 2010 SP 1 without any issues – which is great – however from my own personal experience it seems like a good idea to either avoid it, or take extra care when doing so, and I hope that above helps.

NOTE: this post has been re-published due to issues found with the original binary installer for patch 2. This version has been tested with Exchange 2010 and uses a modified setup.

This patch release is designed to fix an issued that has been identified in OOOCTA 3.5 (both the RTM and Patch 1) in regard to Exchange 2010 compatibility.

In essence when using OOOCTA on a management server or Exchange server which has Exchange 2010 SP1 installed the correct PowerShell command libraries are not loaded – users will see the following error message in the OOOCTA system log:

Microsoft.Exchange.Management.PowerShell.Admin is not installed on this computer

I would like thank Mark Hermann for bringing this to my attention.

Patch Download

Please note – this is a patch release, not the full version of the product – you will need to have the RTP (Release to Public) version of OOOCTA and Patch 1 installed before applying Patch 2.

This is a non-cumulative Patch – therefore you should installed the fixes contained in Patch 1 before applying Patch 2.

NOTE: Before you update the OOOCTA with Patch 1 you MUST stop the OOOCTA Command Processor Service from within the Windows Service manager – if you do not do this, the service binary will not be updated to the latest version.

[OOOCTA 3.5.2 – Patch 2 for OOOCTA RTP – 155KB ]

Patch Installation

Download the above patch to your Exchange or Management Server.

Double click on the “ooocta352-Patch2.exe” and following the installation wizard. When asked for an install location – make sure that you have selected the Service directory – if you have selected the default install location for the RTP build of the software this should be “c:\program files\OOOCTA35\Service”.

When the installer has completed you can restart the OOOCTA Command Processor Service from the Windows Services Manager.

A few months back I wrote an off topic article which depicted my own personal thoughts about Steve Jobs, and him standing down as CEO of Apple. Yesterday (Wednesday 5th October 2011) Mr Job’s died peacefully at home – with his family around him.

Naturally, and like many, many people around the world his passing has deeply saddened me – and my thoughts are with his family, friends and people whom worked closely with him.

One thing that has struck me throughout today is how my mind keeps returning to the image of a man whom I never met, didn’t know and had only ever seen through a TV screen or YouTube.

As mentioned in my previous article about Mr Jobs I cannot claim to be a massive Apple fan as I have always had some reservations about the firm (which mainly stem from an early part of my career when I was looking after a large network of Mac’s with a number of Apple Share file servers – I had some bad experiences with their pricing model and their overall clandestine support stances).

So, why has Steve resonated with me throughout my career, and why has his passing moved me so much?

I guess it is because I admire people with drive, passion, intelligence, vision and whom go and get what they want and achieve their goals. I respect people whom have the bravery to do things that I have not done – and may not ever do, as you can learn from them.

It might also be because Jobs was a consummate family man – protective of his personal life, and that he battled valiantly against a form of Cancer which ultimately took the life of my father – another very special man.

It’s true that there were what people consider to be “darker” traits to Steve Jobs – in the press we have been reminded that he was allegedly a control freak whom was an autocrat as a CEO – ensuring that everything down to the littlest detail was “just so” according to his own “exacting standards". We have also read that he had an attitude that was “his way or the high way”.

What I find interesting about these views are that they beg the question – “were they (are they) so bad?”

“I’m convinced that abo