The other day whilst trying to send an e-mail to a new starter in my organisation I discovered that their name did not appear to be on the Global Address List within my Outlook client (Outlook 2010). Now I knew that the user had been created correctly (and had been several days ago), was also not hidden from the GAL, and others folks were quite happily sending her e-mails – so I suspected that as I was using Outlook Cached mode (which normally I don’t) there was a problem with the Offline Address Book.

This problem could of course be local, or on the Exchange Server  – but first I needed to confirm that this was indeed a OAB problem.

I did this by temporarily turning off cached mode and then checking the address book from within Outlook by using direct mode – and I found that the user was present, I further backed up my theory about the oddness with the OAB by checking to see if the user was present from within the OWA address list – she was as well.

To eliminate a local issue  – my first action was to exit Outlook and delete all of the local Offline Address Book cache files on my local machine ~ if you are using Windows 7 with Outlook 2010 these are located in: [ %UserProfile%\AppData\Local\Microsoft\Outlook\Offline Address Books\ ] and are listed as:

Source: Microsoft

Once I had deleted the files, I restarted Outlook and then from the “Send / Receive” ribbon select [ Send / Receive Groups –> Download Address Book ] – see below

I then un-ticked the “Download changes since last Send / Receive” (this will ensure that a full download is instigated) and then clicked on the “OK” button – see below

This did not work, as the user that I was trying to find did not appear in my local address list.

This indicated that the problem was not with the local copy of the Offline Address List – but was an issue with the generated OAB on the Exchange Servers within my organisation. So I opened up an Exchange Management Console Session and ran the following cmdlet:

Update-OfflineAddressBook –Identity “Address Book Name”

Executing the above command does pretty much what you would expect it to – e.g. it starts a refresh of the Offline Address Book which is outside its normal schedule on the designated OAB Generation Server. Generally this can take a little while to complete (depending on the size of the organisation and the number of recipients)

If you would like to get the details of your Offline Address Books and the Generation Servers you can use the following command:

Get-OfflineAddressBook | Select Name,Server

Which will produce output that looks like the following:

Anyhow – I gave it about 30 minutes and tried the OAB download again within Outlook, and unfortunately – no luck, my elusive user was still missing.

When this happens the root cause is * generally * something screwy within the bowels of Active Directory that will need intervention using something like ADSI edit.

Of course the question was what? – What is wrong in AD?

Now the only way that I was going to deduce this was to increase the logging levels on the [ MSExchangeSA\OAL Generator ] logging level on the OAB generation server.

This can be done in two ways:

• Via the Exchange Management Console

Open the Exchange Management Console navigate to [ Server Configuration ] from the right hand pane – right click on the OAB Generation Server and from the context menu that appears choose “Manage Diagnostic Logging Properties” – see below

From the dialog box that appears – select [ MSExchangeSA –> OAL Generator ] then select the relevant logging level (Lowest, Low, Medium, High, or Expert) and then click on the “Manage” button – see below

• Via the Exchange Management Shell directly on the Generation Server

You can also set the diagnostic logging level for the OAL Generator from the Exchange Management Shell directly on the Generation Server using the following command line:

Set-EventLogLevel -Identity "MSExchangeSA\OAL Generator" -Level Expert -Confirm:$False

You can also execute this command remotely by using a Powershell remote session (which is the direction that we are heading in for reasons that will become clear very soon) – see below

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionURI http://servername/powershell
Invoke-Command -Session $Session  {
    Set-EventLogLevel -Identity "MSExchangeSA\OAL Generator" -Level Expert -Confirm:$False
}
Exit-PSSession

Of course by setting the Logging level to “Expert” on the Generation Server – I was presented with a situation that I personally found a little long winded – as the process that I had to go through to both update the offline address book and gather the logging information involved:

• Raising the Event Logging of the “MSExchangeSA\OAL Generator” on the designated generation server to “Expert”
• Performing another “Update-OfflineAddressBook” command after I had raised the logging level on the Generation Server
• Logging onto the OAB Generation Server and review the Application Event Log and filter out all System Attendant Events which are part of the OAL Generator category
• Put the Event Logging Level back to “Lowest” on the OAB generation server

So I decided to write a Powershell script that would automate all of the above tasks for me that could also be executed from any Exchange Server / Computer that had the Exchange Management tools installed and then compile the results into a HTML based report file.

The Script

The script that I came up with is detailed below (with an associated download should a copy and past from the website not work as it should)

<#
.DESCRIPTION

   This script will perform an update of the Offline Address Book Service, but will configure logging levels
   to aid in troubleshooting. These logs will then be collated into a single log file for viewing.

.PARAMETER oAddressBook

   -oAddressBook "Address Book Name" -fHTML "Path and Filename for HTML Report"

.EXAMPLE

   .\updateOABandLog.ps1 -oAddressBook "<Name of Address Book>" -fHTML <Path to HTML file>

.Copyright_Author

    (c) 2012 www.telnetport25.com
    Author: Andy Grogan

.Version
    v1.0 - First Release

#>

param(
    [parameter(Mandatory=$true,ValueFromPipeline=$false,HelpMessage="Name of the Offline Address Book that you wish to update")]$oAddressBook,
    [parameter(Mandatory=$true,ValueFromPipeline=$false,HelpMessage="Path and Filename to report file")]$fHTML
)

function checkExchangeSN
{
    if (! (Get-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:SilentlyContinue) )
    {
        Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:Stop
    }
}

New-Item -ItemType file $fHTML -Force | Out-Null
$ComputerName = $env:COMPUTERNAME
Write-Host "Execution Computer Name is: " $ComputerName -ForegroundColor White

function writeHeader{
    param($fileName)
    Add-Content $fileName "<html>"
    Add-Content $fileName "<head>"
    Add-Content $fileName "<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1'>"
    Add-Content $fileName '<title>OAB Events Report</title>'
    Add-content $fileName '<STYLE TYPE="text/css">'
    Add-content $fileName  "<!--"
    Add-content $fileName  "td {"
    Add-content $fileName  "font-family: Tahoma;"
    Add-content $fileName  "font-size: 12px;"
    Add-content $fileName  "border-top: 1px solid #999999;"
    Add-content $fileName  "border-right: 1px solid #999999;"
    Add-content $fileName  "border-bottom: 1px solid #999999;"
    Add-content $fileName  "border-left: 1px solid #999999;"
    Add-content $fileName  "padding-top: 0px;"
    Add-content $fileName  "padding-right: 0px;"
    Add-content $fileName  "padding-bottom: 0px;"
    Add-content $fileName  "padding-left: 0px;"
    Add-content $fileName  "}"
    Add-content $fileName    ".Headings {"
    Add-content $fileName  "font-family: Tahoma;"
    Add-content $fileName  "font-size: 14px;"
    Add-content $fileName  "font-weight: bold;"
    Add-content $fileName "}"
    Add-content $fileName  "body {"
    Add-content $fileName  "margin-left: 5px;"
    Add-content $fileName  "margin-top: 5px;"
    Add-content $fileName  "margin-right: 0px;"
    Add-content $fileName  "margin-bottom: 10px;"
    Add-content $fileName  ""
    Add-content $fileName  "table {"
    Add-content $fileName  "border: thin solid #000000;"
    Add-content $fileName  "}"
    Add-content $fileName  "-->"
    Add-content $fileName  "</style>"
    Add-Content $fileName "</head>"
    Add-Content $fileName "<body>"
    Add-content $fileName  "<table width='100%'>"
    Add-content $fileName  "<tr bgcolor='#3366FF'>"
    Add-content $fileName  "<td colspan='7' height='25' align='left'>"
    Add-content $fileName  "<font face='tahoma' color='#FFFFFF' size='4'><strong>Offline Address Book Processing Log - Executed on: $ComputerName</strong></font>"
    Add-content $fileName  "</td>"
    Add-content $fileName  "</tr>"
    Add-content $fileName  "</table>"
}

function WriteFooter(){

    Param($fileName)
    Add-Content $fileName "</body>"
    Add-Content $fileName "</html>"

}

function script_Logging($logEntry,$Colour){
    Write-Host $logEntry -ForegroundColor $Colour
}

function get_OABServer{
    $oabGenSrv = Get-OfflineAddressBook $oAddressBook  | Select -ExpandProperty Server
    return $oabGenSrv
}

function set_Logging($switch){
    script_Logging "Getting OAB Generation Server" "Green"
    $GenerationServer = get_OABServer
    script_Logging "OAB Generation Server is: $GenerationServer" "Yellow"
    $URIString = "http://" +  $GenerationServer + "/Powershell"
    script_Logging $URIString "Green"
    script_Logging "Setting up new PS Session to remote host" "Green"
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionURI $URIString
    script_Logging "Getting Mode" "Green"

    if($switch.ToLower() -eq 'enable'){
        script_Logging "Mode Set to Enable" "Green"
        Invoke-Command -Session $Session  {

            Set-EventLogLevel -Identity "MSExchangeSA\OAL Generator" -Level Expert -Confirm:$False
        }
        script_Logging "Exiting Remote PS Session" "Cyan"
        Exit-PSSession
    }else{
        script_Logging "Mode Set to Disable" "Green"
        Invoke-Command -Session $Session {

            Set-EventLogLevel -Identity "MSExchangeSA\OAL Generator" -Level Lowest -Confirm:$False
        }
        script_Logging "Exiting Remote PS Session" "Cyan"
        Exit-PSSession
    }
}

function update_OAB{
    Param($fileName)
    $PerformUpdate = Update-OfflineAddressBook -Identity $oAddressBook

    script_Logging "Sleeping for 60 Seconds - ZZZZZZzzzzzzzzzz" "Green"
    Sleep 60
    $GenerationServer = get_OABServer
    script_Logging "Getting Event Logs from System Attendant on OAB Server" "Green"
    $oabEVENTS = Get-EventLog -ComputerName $GenerationServer -LogName "Application" -Source "MSExchangeSA" | where {$_.Category -eq 'OAL Generator'}

    Add-Content $fileName "<p class=headings>OAB Generation Event Logs from OAB Generation Server: $GenerationServer</p>"
    Add-Content $fileName "<table>"
    Add-Content $fileName "<tr>"
    Add-Content $fileName "<td><strong>Event ID</strong></td>"
    Add-Content $fileName "<td><strong>Time Generated</strong></td>"
    Add-Content $fileName "<td><strong>Machine Name</strong></td>"
    Add-Content $fileName "<td><strong>Category</strong></td>"
    Add-Content $fileName "<td><strong>Entry Type</strong></td>"
    Add-Content $fileName "<td><strong>Message</strong></td>"
    Add-Content $fileName "</tr>"

    foreach($evt in $oabEVENTS){

        $evtID = $evt.EventID
        $evtTime = $evt.TimeGenerated
        $evtMachine = $evt.MachineName
        $evtCat = $evt.Category
        $evtType = $evt.EntryType
        $evtMessage = $evt.Message

        if($evtType -eq 'Error'){
            Add-Content $fileName "<tr bgcolor=""#FF0000"">"
            Add-Content $fileName "<td>$evtID</td>"
            Add-Content $fileName "<td>$evtTime</td>"
            Add-Content $fileName "<td>$evtMachine</td>"
            Add-Content $fileName "<td>$evtCat</td>"
            Add-Content $fileName "<td>$evtType</td>"
            Add-Content $fileName "<td>$evtMessage</td>"
            Add-Content $fileName "</tr>"
        }elseif($evtType -eq 'Warning'){
            Add-Content $fileName "<tr bgcolor=""FBDA05"">"
            Add-Content $fileName "<td>$evtID</td>"
            Add-Content $fileName "<td>$evtTime</td>"
            Add-Content $fileName "<td>$evtMachine</td>"
            Add-Content $fileName "<td>$evtCat</td>"
            Add-Content $fileName "<td>$evtType</td>"
            Add-Content $fileName "<td>$evtMessage</td>"
            Add-Content $fileName "</tr>"
        }else{

            Add-Content $fileName "<tr>"
            Add-Content $fileName "<td>$evtID</td>"
            Add-Content $fileName "<td>$evtTime</td>"
            Add-Content $fileName "<td>$evtMachine</td>"
            Add-Content $fileName "<td>$evtCat</td>"
            Add-Content $fileName "<td>$evtType</td>"
            Add-Content $fileName "<td>$evtMessage</td>"
            Add-Content $fileName "</tr>"
        }
    }
    Add-Content $fileName "</table>"
}
    writeHeader $fHTML
    checkExchangeSN
    set_logging "enable" "Green"
    update_OAB $fHTML
    set_logging "disable" "Green"
    writeFooter $fHTML
    script_Logging "Script Completed" "Yellow"
    Invoke-Item $fHTML

Download

[ UpdateOABandLog.ps1 – 8KB ]

Script Usage

Should you wish to use the script download it to a location on one of your Exchange Servers (or a computer with the Exchange 2010 management tools installed), open a Powershell session and type in the following command:

.\UpdateOABandLog.ps1 -oAddressBook "PrepAD Offline Address List" -fHTML x:\scripts\OAB-Report.html

If execution fails you might need to follow some of the steps that are detailed in the article that I detailed here.

Sample Script Output

When the script is executed you will see output similar to the following screenshot

When the script has finished you should be presented with report within your default web browser that details all events that occurred during the execution of the “Update-OfflineAddressBook” cmdlet. The script is designed to highlight Warnings in Yellow and Errors in Red – see below

So what was my problem?

I suppose that the above is a bit of a leading question really – those who know me will say that I have loads of problems, but in the context of this post the reason why my user was not appearing in the Offline Address List was down to a previously deleted OAB entry which was still the default OAB within Active Directory (don’t know who did this as I inherited this Exchange installation) – after a bit of reconfiguration using ADSI edit all was back to normal – but using this script helped me identify the problem from a single workstation, and I hope that it will be of some use to someone out there.

I probably should have started to look at Lync Server a long time ago, but I never quite got around to it for one reason or another (I was going to say that I was just being lazy, but in truth I have really not had the time with all the other stuff that I work on). Recently however I have been asked to start looking at an “in house” Lync deployment for the company that I am currently working for. Whereas I have been sent a deluge of Lync related material by my boss, with me being me – and the way I like to learn I have decided to deploy it into my test lab without first RTFM’ing as I kind of like to suffer the consequences!

Initially I have found that if you are used to purely setting up Exchange server (2007 or 2010), the Lync Deployment Wizard and topology builder will seem very alien and convoluted whilst at the same time making no sense whatsoever.

However, that being said, I found – that you should preserve with the setup process – as after your sixth attempt (it was around attempt 6 for me) at the point when your configuration starts to work – it begins to become clear to you why the setup process structured in the way it is.

I would also go as far to say, that when it “clicks” in your head – you can see a number of similarities between Lync deployment and Exchange – although I need to stress that that Lync is a IMHO more complex beast, but it is obvious that a lot of thought has gone into the setup experience (Elan, if you are reading this – kudos to you for working with Lync for so long and producing the content that you do )

I won’t get into too much detail about the method that I used to get my environment up and running (just yet), mainly because it is a test lab (where I want to test a few features whilst getting a feel for the kind of resourcing that a real deployment will require), and is not intended for production scenarios and I admit that at the moment I do not know enough about Lync HA deployments – there are plenty of people around who know more than me about it at this point in time .

However if you really need a good reference to get your started – I can HIGHLY recommend John Policelli's Blog where he has published an excellent 100 page guide which focuses on deploying an Enterprise configuration of Lync 2010 in a lab environment.

Ok, so what was I trying to achieve with my lab?

The requirements of my lab at this stage were (are):

• Provide IM and Presence abilities / Information for Lync enabled accounts
• Provide Audio and Video conferencing

I have provided a very simple “high level” overview of the setup below:

What issues have a encountered so far?

SQL 2012

I like all shiny new things, especially when its either Exchange or SQL server – but, whatever you do don’t try and use Microsoft SQL Server 2012 as the backend database for Lync (or any other Database which Lync uses for that matter). I tried for days to get them to talk to one another – and had some successes, but ultimately – it does not work in the end and let’s not forget – its not supported.

Honestly, I know that when we read about “not supported” we think, “probably will work” – but in this case it just doesn’t – so don’t try it – I did and wasted a load of time – if you need the official support stance and reasons why have a look here

Local RTCLOCAL Database configuration failed on the Enterprise FE Server (for the XDS DB)

This first issue which I encountered was admittedly down to my own stupidity, in essence my first few attempts at installing Lync resulted in a lot of aborted effort (think of these failed attempts as Neanderthal man trying to make fire – there was a lot of keyboard banging and the words “ugg, ugg” then poo being thrown around).

In essence I had ended up in a situation where I could publish the Lync Topology, but when using the [ Lync Deployment Wizard – > Install or Update Lync Server System –> Install Local Configuration Store ] on the Enterprise Front End Server – I was presented with a number of SQL database creation errors which related to the local “RTCLOCAL” instance (this is the replica instance of the Central Configuration Store which is on each Enterprise FE server).

This was caused by a failed installation where I had then tried to remove Lync and all its components from the FE server – this had only partially completed leaving both the MSSQL Express Instance (RTCLOCAL) and the “Lync Server Replica Replicator Agent” Services installed.

In the end I installed SQL 2008 R2 Express Edition Management Studio, and physically deleted the XDS database (which was the only DB that had been created). Of course this now left me without a means to begin the Database recreation process (as I could not remove Lync fully) – or progress my installation ~ bugger!.

Now I did not wish to blow away my lab at this point (as I had foolishly activated the Windows 2008 R2 Server instances with MS) and not taken a checkpoint of the VM’s so my only way forward was to try and rescue the Lync instances.

As luck would have it I found this wonderful article by Terence Luk which whilst it did not solve my problem – did give me a major clue about how I could correct the issue. Essentially within Terence’s post he explained that during a successful install of Lync server a file called LCSSetup_Commands.txt is created within C:\Users\install account\AppData\Local\Temp  created which contains all of the relevant PS and CSCRIPT commands which build your installation are stored.

It occurred to me at some point during my faffing about, the XDS Database must have been at the very least created correctly (before I then blew it up) – so if I could trace back through the “LCSSetup_Commands.txt” file I might be able to find the command line that creates the XDS replica database. I was then thinking that if I could get the XDS database working correctly, I might be able to run the Local Configuration Store process again.

Whilst looking inside the file I found the following command entry:

CScript.exe //U //Nologo DBSetup.wsf /sqlserver:localhost\rtclocal /serveracct:"PROD-LYNC-01\RTC Server Local Group;PROD-LYNC-01\RTC Component Local Group" /adminacct:"PROD-LYNC-01\RTC Local Administrators" /roacct:"PROD-LYNC-01\RTC Local Read-only Administrators" /role:se /verbose

Given that the whole process of setting up setting up the local replica instances had gone to “hell in a hand basket” seemed logical to execute again. So I opened up a Windows CMD prompt, navigated to the “C:\Program Files\Common Files\Microsoft Lync Server 2010\DBSetup” and executed the above command again (this is probably not supported by MS BTW) – but – it worked! and I was able to complete the process of installing the Local Configuration Store.

Install Roles – Prerequisite WMF2008R2 Fails to install

After I got past my (self inflicted) issues with the Lync Replica database I then encountered the following failure when attempting to run the Lync Server Components wizard:

In essence “WMF2008R2” is part of the media components for Lync server – and thankfully getting around error is very well documented on the web (for example here: http://www.howexchangeworks.com/2011/05/lync-2010-server-components-setup.html) – I won’t reproduce Rajith Jose Enchiparambil article in full here as I don’t have permission, but suffice to say there is a command that you can run that corrects the issue (in essence it adds the correct version of the pre-req to the Windows database).

Lync Address Book Updates

After over coming the issues that I experienced above, the rest of the installation went very smoothly and before long I had a functional Lync system (well at least from a server perspective). The next thing was to provision a couple of users within the environment to give it a little test run. The provisioning process went smoothly (I used the web based control panel as at this stage I am a bit of a wimp) – see below

I provisioned two users (with a view to setup a bit of IM traffic and have a online conference meeting via the Lync client) – this is where I hit a problem – When looking for my “partner” to add to my contact list I would receive the following message:

“Address book is synchronizing. Results might not be current” – see below

In essence the above should really be down to being willing to wait for Lync’s internal processes to complete – but you can force an Address Book Update by using the following command from the Lync Management Shell:

Update-CsAddressBook

In the example below I have added the –Verbose switch so you can see messages that are returned from the command:

You should then see the following event within the servers event logs (below 21010 means that the process has completed) – see below

And Event 21056 gives you an overview of the entire process – see below

However, even if you do see the above events; you still might not see the relevant contacts (or updates) appear within the Lync client as the it does not bring down the latest version of the address book immediately (this is performed at a random interval of between 1 and 60 minutes).

You can force this process by following the excellent guidance which Lync MVP Jeff Schertz has provided here.

So, that is it for now – I will be posting more over the next few weeks!

The March and April 2012 www.telnetport25.com newsletter(s) are available for download from the following location:

[ March / April 2012 Newsletter – 800KB ]

A looooong time ago (in about 2010 I think) I wrote an ASP.NET web enabled application that allowed for a defined group Service Desk users to be delegated password reset access for users within a given organisation. I had initially wrote the code for use within a company that I was working for at the time as we were not keen on deploying ADUC to the service desk for a number of reasons.

I did make the tool available for download on Telnetport25.com, but somewhere during the migration from Joomla to WordPress I lost the source code, didn’t bring across the previous versions download location and could not find the original Word source of the Installation and Users manual (doh!)

However the other day (during my migration from VMWARE to Hyper-V) I found a load of old LAB machines hiding on an external hard drive – which I decided to “power on” to see what they used to do (just in case there was something useful on them).

To my delight I found the full source code for Service Desk.NET, as well as a load of the supporting documentation that I had written at the time – so I decided to give the tool a little bit of a face lift (not by much) – and add some new features to it – as well as tidy up the installation process (which for the original tool was pretty intense).

I have made ServiceDesk.NET available for download from the following location: http://www.telnetport25.com/2012/04/servicedesk-net-version-3-5-1/ so if you are looking for a pretty simple tool where you can simply delegate password resets to a group of users – check it out

Information

The telnetport25.com Service Desk.NET Password Reset tool is designed for small to medium sized organisations which have Service Desk operators whom it is not appropriate to provide access to the MMC of ADUC (Active Directory Users and Computers) – but require a secure means to reset customer passwords.

Normally Service Desk Operators whom reset domain passwords at the front line have their rights delegated to them via the Active Directory administrators for the organisation.

This method can be fiddly and indeed requires the Windows ADMIN PAK to be installed on each service desk operator’s machines or indeed another 3^rd party tool which can be expensive.

The telnetport25.com Service Desk.NET tool is simple to install, web based and allows for Service Desk Operative to reset customer’s passwords under their own basic set of security principles (there is no delegation required by the Active Directory Admin).

The tool allows for Active Directory Administrators to configure restricted groups – whereby if the target account is a member of a group which is “Disavowed” the password cannot be reset and an event is logged in a secure database.

System Requirements

• Windows 2003 x32 Standard or Enterprise Edition (R2) – RTM Edition is fully supported, however SP2 is recommended.
• Windows 2003 x64 Standard or Enterprise Edition (R2)
• Windows 2008 x32 Standard or Enterprise Edition (R2) – RTM is supported (Windows 2008 is the recommended configuration)
• IIS 6.0 / 7.0
• NET Framework 3.5 (minimum)
• Microsoft SQL Server 2008 (Standard, Enterprise or Express Edition) – The software will function with SQL 2000 / 2005 but no configuration instructions are provided for these versions

Download

[ Service Desk.NET 3.5.1 – Password Reset Tool – 800KB ]

[ Installation and Users Guide – 5MB ]

This is not an Exchange focussed post – but it is something that has driven me nuts for the last few days on one server within my Exchange 2007 lab running on Windows 2003 Server which I ported from VMWARE to Hyper-V.

The situation was that on this specific LAB server – I found an instance of “hiberfil.sys” weighing in at 3GB located in the root of the C: drive that I could not get rid of!

Now, I know that you can drop to a command line and use “powercfg –h off” or turn the hibernation features off from the Power Options applet within the control panel – but I found that the command line would return the following error when trying to execute the command:

and the Hibernation tab (in the GUI) was missing – see below:

To compound matters – when trying to delete the “hiberfil.sys” file (from the root of C:\) I received “This file is in use by another process” or “Access is Denied”.

The solution

After a lot of messing around with the server in question, I arrived at the following solution (detailed in the following steps):

Step1:

Add the following command to the “boot.ini” file (which is typically found in the root of c:\):

/MAXMEM=4096

An example of my “boot.ini” is  provided below:

DO NOT reboot your computer at this stage.

Step 2:

Open Computer Management MMC and expand “System Tools”  node and then right click on the “Device Manager” node. From the context menu that appears choose [ VIEW->Show hidden devices ] – see below

In the right hand pane that appears navigate to [ Non-Plug and Play Drivers –> VGA Display Controllers ] – see below

Right click on the entry for the “VGA Display Controller” – and from the context menu that appears choose “Uninstall” – see below:

Step 3:

When the “VGA Display Controller” has been removed from the system reboot your computer (you should be prompted for the reboot).

Step 4:

When the reboot has completed you will see that within the “Power Options” control panel the “Hibernate” tab will now be displayed – un-tick the “Enable hibernation” check box under the “Hibernate” option area and then click on “OK” – see below:

If you then run the “powercfg –h off” you will see that the values for system hibernation are now set to “Never” – see below:

and most importantly the “hiberfil.sys” has now been removed from your computer.

I am working on a new application at the moment which requires for all Distribution Groups within an Exchange 2010 environment to be populated into a Drop Down list on the default ASP.NET page, and then based upon the selected Distribution group place the SMTP addresses of each member of that group into a list box.

Having a hunt all over the web to see if this has been done before (well I say “all over the web”, maybe about 0.016% of it!) – I could not find a code example which quite met my needs.

Therefore I decided to have a crack at it myself – and to my surprise came up with the following code which works! (I am not saying that it is the most efficient way of doing it – just that it works).

If you are interested in using the code sample below, you will need to start a new C# project in Visual Studio, and ensure that the you have imported the “System.DirectoryServices” reference into your project – this is accomplished by adding the reference at the top of your main code file – see below

using System.DirectoryServices;

You will also need to add the following Controls for your Form:

• A drop down list control – called dd_Membership
• A List control – called lb_Members

The main part of the code uses LDAP filters within the DirectorySearcher object to perform the following actions:

• Locate all Groups in the Directory that are of the type “Distribution” – this uses the filter:

  (&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))
  

• Locate all members of the selected distribution group using the following filter:

  (&(objectCategory=person)(|(objectClass=contact)(objectClass=user))(memberOf=" + dd_Membership.Text + "))
  

The code looks which populates both the Distribution list and get the membership to the list box looks like the following:

public static DirectoryEntry GetDirectoryEntry()
       {
           try
           {
               DirectoryEntry entryRoot = new DirectoryEntry("LDAP://RootDSE");
               string Domain = (string)entryRoot.Properties["defaultNamingContext"][0];

               DirectoryEntry de = new DirectoryEntry();

               de.Path = "LDAP://" + Domain;
               de.AuthenticationType = AuthenticationTypes.Secure;

               return de;
           }
           catch
           {
               return null;
           }

       }

       protected void Page_Load(object sender, EventArgs e)
       {

           DirectoryEntry entry = GetDirectoryEntry();
           DirectorySearcher search = new DirectorySearcher(entry);
           search.Filter = "(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))";
           SearchResultCollection results;
           results = search.FindAll();

           foreach (SearchResult ent in results)
           {
               dd_Membership.Items.Add(ent.Properties["DistinguishedName"][0].ToString());
           }

           search.Filter = "(&(objectCategory=person)(|(objectClass=contact)(objectClass=user))(memberOf=" + dd_Membership.Text + "))";
           results = search.FindAll();

           lb_Members.Items.Clear();

           foreach (SearchResult ent in results)
           {

               lb_Members.Items.Add(ent.Properties["mail"][0].ToString());
           }
       }

Which produces results like the following within your application:

Of course there might be more efficient ways to accomplish the above (which if you have come across, please feel free to link them in the comments section) – but I thought that this might help someone out along the way.

I am (almost) speechless – I have just received a notification that I have been re-awarded the status of Exchange MVP for the 4th year running from Microsoft. I am really pleased – and again – humbled and honoured that people who read this site and my community peers still think that all this time later I am still worth the time to nominate and consider.

It has been an interesting couple of years, having moved out of the “hands on” technical role to a strategic endeavour and more recently (in the last month) back into a senior technical position – I will admit that it has been hard to keep my time up on the site and keeping pace with the ever changing world of Exchange Server .

One of the very best things about being an MVP is the people who you meet and converse with online – whether they are readers of a (this) site, members of forums, fellow MVP’s, Community Site owners or Microsoft employees – each and everyone of those individuals contribute to a single MVP’s status and for want of a better term ~ success.

I would not have managed to of been re-awarded this year if it were not for the continued advice of other MVP’s, the consideration of people like Barbara Matysik-Magro (of MSExchange.org) and – a very, very personal thanks to my MVP lead Claire Smyth who supported me with an issue with my submission when she did not really have to.

But most importantly – I thank you, the reader(s) of this – who (and to sound cliché) – it really would not be worth it, unless you viewed, commented upon and suggested things. Even if I were not an MVP I would still put my energies into www.telnetport25.com as even if my inane ramblings helps one person – then it is worth it!

Anyhow ~ I am hoping to produce a bumper year here on telnetport25.com (I have a load of ideas that I want to get published) – so all that I have left to say is ~ thank you once again – and of course have a great Easter!

I was asked the above question the other day – essentially, how do you have a group of people with delegated access to manage all aspects of Distribution Lists within Exchange 2010?

There was a desire to devolve the management of its Distribution Lists the HR section, therefore releasing a number of members from the 3rd tier support group.

Luckily there is a built-in RBAC role in Exchange 2012 called “Manage Distribution Groups” which is designed to allow for delegated control of distribution management and creation – which by default has no members (or groups) – therefore it is relatively straight forward to add in a custom Universal Security Group in AD to the RBAC role to allow for member of the security group to administer.

Create a Universal Security Group in Active Directory

In order to take advantage of the built in RBAC group you should create a universal security group within your active directory environment which will contain the user accounts that will have the permissions to create / modify Distribution lists.

You can of course assign members to the RBAC role on a per account basis, but this ultimately becomes difficult to manage – so the group based approach is highly recommended.

In order to setup the security group that will contain the user accounts that you wish to delegate administrative permissions to – open Active Directory Users and Computers and “right click” on the location where you would like to store the security group – then from the context menu that appears choose [ New –> Group ] – see below:

From the “New Object – Group” properties dialog box fill in the information (Group Name and Group Name (pre-Windows 2000) as you wish, ensure that the group scope is set to “Universal” and the “Group Type” is set to “Security” – see below

You can now add the members of the security group that you wish to manage all distribution groups within the directory and Exchange environment.

When you are done, click on the “OK” button and close ADUC.

Exchange Management Shell Command

Open the Exchange Management Shell and type in the following command:

Add-RoleGroupMember “Manage Distribution Groups” –Member “<name of the security group>”

Where the “<name of security group>” is the name of the group that you created in AD – see below

After these changes have been made, the members of the AD security group that you defined will be able to manage distribution lists either from Outlook, or within the Exchange Control Panel (ECP) – see below

Back in February I delivered a preview of a new tool that I had been working on called the “Nagios Discovery Tool for Windows” – or the NDT for short.
Since then I have been trying to get a manual for the tool together, but as is the way of my life it has been very hectic so I have made little progress on that front.

A number of readers have commented and mailed me asking to test the tool for which I am very grateful – but I did not want to put it out into the open until I had at least put some sort of very basic user guide together. Therefore I decided that I would do a few videos which take you through the installation and configuring a basic monitoring setup – these are now done ~ yaaaa! – and I am pleased to announce that I have made the program available for download.

Now there are a couple of things that I would like to point out to folks, just so there is a little bit of expectation management:

1. I consider the tool very much in the “Release Candidate” phase – therefore there are some elements of the tool that will be subject to change (or might not work as well as expected). If you should find something odd, let me know and I will fit it into a bug release ~ but my time at the moment is a little limited so bear with me on fixing stuff
2. Aside from the videos that I am putting on my You Tube channel – there is no official documentation as of yet – I am writing it, but naturally its fairly time consuming ~ so please bear with me
3. The tool is designed to be used in conjunction with my own Nagios series – therefore some of the more interesting service monitors (Exchange DAG and the AD replication Monitors for example) will need to be setup on your Nagios Core server as per the articles located here, here, here and here

Download Link

The download page for the Nagios Discovery Tool is located here: http://www.telnetport25.com/2012/03/nagios-discovery-tool-version-1-0/

On the download page you will find some useful release information, as well as some video overviews which cover installation and very basic usage.

Information

The Nagios Discovery tool is designed to make the process of discovering devices on your network and then configuring them for active monitoring with Nagios Core simpler. The Tool provides a GUI interface to scan for hosts and configure the relevant monitoring facets (services) that are associated with them.

The tool comes supplied with a number of XML files which define some common service elements to monitor (for example Basic Windows Services) – this is called the Nagios Discovery Tool XML Service Framework.

I have also supplied a number of XML files which allow for the configuration of the Scripts that I have supplied as part of my on-going series of Monitoring Exchange Server with Nagios Core (the series started here) and the scripts are located for download here.

The service monitoring capabilities of the Nagios Discovery tool are designed to be extended via this XML framework which removes the need for the actual executable file to be replaced and allows for users of the tool to customise the monitoring functionality that it provides (e.g. if you develop your own custom NRPE scripts).

Firewalls

The Nagios Discovery Tool needs to be able to connect to your local network and use ICMP to both resolve and confirm that hosts are online.
Given the above, if you are running a local Firewall you will need to configure an exception for the tool, otherwise it will not work properly.

It is important to note that you should not disable your local Firewall as this will leave your system unprotected.

Conversely if hosts which are to be monitored are running a local Firewall then there is a chance that the tool will not find them, therefore Firewall exceptions may need to be implemented to allow for the discovery process to succeed.

Scanning Network Ranges

This tool has the ability to scan network ranges. Whilst all it does is look for hosts, resolve their name and try to ping them, you should ensure that by using the NDT you are complying with your organisations acceptable use policies and are authorised to perform range scans. Furthermore, do not use the tool to scan hosts on the Internet.

System Requirements

• Windows Vista (x32 & x64), Windows 7 (x32 & x64), Windows Server 2003 (all editions + x32 & x64), Windows Server 2008 (all editions + x32 & x64), Windows Server 2008 R2
• .NET Framework version 4.0
• Nagios Core – version 3.3.1 (this is the version that the tool has been tested against – but it is likely to work with future releases of Nagios Core).

Download

[ Nagios Discovery Tool for Windows – Version 1.0 – 570KB ]

Installation

A video tutorial is available below:

Usage

A video tutorial is available below:

Nagios Discovery Tool XML Service Framework (NDT-X)

The Nagios Discovery Tool XML Services Framework is designed to allow for both customisation and servicing of the NDT.
Supplied with the tool are a number of XML files which allow for you as the user and me as the author to add to the service check command set for each host within your Nagios installation.

For example; if you have been following my series of how to create custom Powershell scripts for use with Nagios for monitoring Exchange server as an example, you can add in your service check commands into the supplied XML files – and have them available for new hosts as you bring them onto the network.

Below I have supplied an overview of the Framework (full documentation is still being complied) for reference, and perhaps to get some of you started with customisation.

[ NDT-X Framework Overview – 350KB ]

Credits

The Nagios Discovery Tool uses modified portions of code by Sharpoverride – I thank him for his efforts in developing a very basic IP range scanner.

Ok, whilst this is not a Exchange focussed post, I am hoping that it will help some folks out there. I have over the years been in charge of some quite large Active Directory environments, which naturally have a number of Administrators – some of which are based in many locations and sometimes in different physical groups within a given company.

Now, in such scenarios you tend to to end up with people whom are responsible for the administration having different levels of discipline in controlling access to sensitive, key groups within the directory or who make changes in a dis-jointed fashion without communicating the changes. I think that most of us have encountered that person who will add a user into the “Domain Admins” or “Enterprise Admins” group to solve an immediate permissions issue (and of course by doing so committing a cardinal sin of any form of AD management) – and then forget to remove them.

In some organisations (especially large ones with lots of admins) this is usually only picked upon when there is an audit (this has happened to me on a number of occasions) and as “sods law” dictates you will be left looking kind of silly in front of the auditor that you just told that you run a ship toighter than Goldmember’s tiger!

Now, unless you have some form of dedicated group monitoring product – which is keeping track of who has been placed within your critical security groups – effective governance can be a little difficult (mainly down to the fact that as administrators you probably have 101 other things to be worried about) – so, I have written a very simple script in Powershell that will scan the group membership of any number of groups that you stipulate and send an e-mail to you which tells you who the current members of each group are.

You can schedule this script to run periodically (or depending on your organisational inspection policy) and review the results for irregularities.

This script is designed to be executed against Domain Controllers which are running Active Directory Management Gateway Service – therefore your environment will require at least one domain controller that conforms to the following:

• Windows 2008 R2 (native support)
• Windows 2008 RTM (with the Active Directory Management Gateway Service Installed)
• Windows 2008 SP2 (with the Active Directory Management Gateway Service Installed)
• Windows 2003 R2 (with the Active Directory Management Gateway Service Installed)
• Windows 2003 SP2 (with the Active Directory Management Gateway Service Installed)

It is recommended that you execute this script on a DC which has the Management Gateway service installed, if you only have a single domain controller with this service you will need to ensure that the $ADWSDC value at the top of the script is populated with the name of that DC ~ I would personally recommend that all of your Domain Controllers have this service installed.

You should also populate the $SMTPServer value with that of an SMTP server which you can relay the notification messages off of, as well as the $MessageFrom and $MessageTo values set (as the sender and recipient respectively for the report).

If you would like to add additional groups which are to be inspected by the script – have a look at the $strCriticalGroups constant – you can add additional groups but typing in their name (separating them via a comma) and saving the script.

The Script

You can view the script below and copy and paste it into a new PS1 script file on your domain controller. If you would like to schedule the script via the task Scheduler – there are some instructions here which explain how you can use Powershell scripts from the command line or via batch files, which can then be used with the Task Scheduler to run at periodic intervals.

# Active Directory Group Notification Reporting Script
# Author: Andy Grogan
# www.telnetport25.com
# Credits: sendMail function based upon code from the
# Windows PowerShell Team:
# http://blogs.msdn.com/b/powershell/archive/2009/10/30/sending-automated-emails-with-send-mailmessage-convertto-html-and-the-powershellpack-s-taskscheduler-module.aspx

$ADWSDC = "prod-dc-01"
$SMTPServer = "172.31.253.140"
$MessageFrom = "infoSec@prepad.local"
$MessageTo = "administrator@prepad.local"

Import-Module ActiveDirectory
[Array]$strCriticalGroups = "Enterprise Admins","Domain Admins","Exchange Servers"

function sendMail($strBody){

    $ErrorActionPreference = "Stop"
        try {
            $messageParameters = @{
                Subject = "Domain Group Notification Report Update"
                Body = $strBody
                From = $MessageFrom
                To = $MessageTo
                SmtpServer = $SMTPServer
            }
            Send-MailMessage @messageParameters -BodyAsHtml
        } catch {
            $_ |
                Out-File x:\grpMonSMTPerr.txt -Append -Width 1000
        }
}

$messBody += "<p>Please find enclosed your Group Monitoring Report: </p>"

foreach($grp in $strCriticalGroups){

    $GroupMembers = Get-ADGroupMember $grp -Server $ADWSDC
    $messBody += "<h1>" + $grp + "</h1>" + "<br>"
    foreach($member in $GroupMembers){
        $messBody += $member.Name + "<br>"
    }

}
sendMail $messBody

The following is some sample output from the script:

Linked to my multi part series on using Nagios Core with Exchange server, I would like to explain how you can configure mail notifications to recipients when status changes occur within the Nagios monitoring environment.

If you are just joining us here, I recommend that you have a look at the series in its entirety before reading any further, as there are a few concepts used in this article which were covered in-depth within previous four parts. You can view them here:

• 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
• In Part 4
  I covered how you can build some custom PowerShell scripts to monitor you Exchange environment

Making Sure that you DNS Configuration is correct

Before you begin to setup the tools which will enable mail notifications to be sent from Nagios, you should ensure that you destination mail domain can be resolved from your Ubuntu server. I have assumed that you will be sending notifications to a mailbox within your Exchange infrastructure which naturally is separate to the Nagios implementation.

In my example, my destination domain is “prepad.com” – therefore in order to check if the Nagios server can lookup the MX record for that domain you can use the “dig” command like so:

dig prepad.com mx

If everything is ok, you should receive an output to the command similar to that below:

Installing POSTFIX

Postfix is a free MTA for Linux which is designed to be easier to setup and configure than the more traditional SendMail offering. Combined with Heirloom-MailX (see next section) Nagios can be configured to use the two products to send e-mail notifications to a designated set of contacts in the event of an alert being generated.

From the perspective of using Postfix to send e-mail from Nagios – the setup is very simple (e.g. I am not going to go into huge amounts of detail on how you can configure Postfix).

In order to install Postfix open an SSH session to your Nagios Ubuntu Server using PuTTY and type in the following command:

sudo apt-get install postfix

You will then be presented with a two step setup Wizard – the first page will ask you what type of POSTFIX SMTP Server you would like to use – ensure that you have selected the “Internet Site” option, when done navigate (using TAB) to the “OK” button – see below

You will then be asked to supply a Domain Name which the source e-mails will be sent from – in my example I have used “nagios.notify” – when you are done tab to the “OK” button – see below

This will then complete the configuration of Postfix.

Installing Heirloom-MailX

Heirloom-MailX is a small binary program that is used by Nagios to send mail to the Postfix mail server – it is very easy to install.
From the SSH console, type in the following command:

sudo apt-get install heirloom-mailx

Configuring Exchange to accept messages from your Nagios Server

There are better ways to do this, however if you want to ensure that your Exchange Hub transport servers are accepting mail from your Nagios server, you should ensure that the Default Receive Connector on your HT is configured to accept anonymous connections – you can do this by opening up the Exchange Management Console and navigating to [ Microsoft Exchange On-Premises –> Server Configuration –> Hub Transport ], then select your HT and then from the low pane (Receive Connectors) right click on the “Default <Your HT>” – from the context menu that appears choose “Properties” – see below

From the properties box that appears, click on the “Permission Groups” tab, and then tick the “Anonymous Users” tick box, and then click on the “OK” button – see below

In the real world, you should probably consider creating a dedicated Receive Connector for the Nagios instance.

Configuring Nagios to Send Mail Notifications

Now that you have installed the required components to enabled Nagios to send mail notifications, you will need to download two configurations files from your Nagios Server (using FileZilla and edit them using Notepad++ – if you need to understand how to do this, please review part 2 of my installing Nagios for Exchange series).

These files are:

1. commands.cfg
2. contacts.cfg

Which are located in:

/usr/local/nagios/etc/objects

Open the commands.cfg file in Notepad++ and modify the following two lines:

# 'notify-host-by-email' command definition
define command{
    command_name    notify-host-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /bin/mailx -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
    }

# 'notify-service-by-email' command definition
define command{
    command_name    notify-service-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mailx -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
    }

To look like the following:

# 'notify-host-by-email' command definition
define command{
    command_name    notify-host-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mailx -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
    }

# 'notify-service-by-email' command definition
define command{
    command_name    notify-service-by-email
    command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/mailx -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
    }

In essence you are changing the /bin/mail part of each command to /usr/bin/mailx

When you are done, save the file and then using FileZilla upload it back to your Nagios Server.

Next open the contacts.cfg file and change the “email” property to that of the account where you would like the notifications to be sent – see below

define contact{
        contact_name                    nagiosadmin        ; Short name of user
        use                                generic-contact        ; Inherit default values from generic-contact template (defined above)
        alias                           Nagios Admin        ; Full name of user
        email                           administrator@prepad.com    ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ******
        }

When you are done, save the file, and upload it back to your Nagios server.

To finish up the configuration, from a PuTTY session type in the following command:

sudo /etc/init.d/nagios restart

For the configuration changes to take effect.

When there is now a problem with either a service or a host, the chosen recipient should receive a mail notification like the following:

Recently I have been doing quite a bit of work with Nagios Core, which if you have not seen the article series you are most welcome to have a look at them below:

• 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
• In Part 4
  I covered how you can build some custom PowerShell scripts to monitor you Exchange environment

What I have found throughout my work with Nagios Core, is that whilst it is an excellent monitoring tool, there are some downsides to it. Perhaps the two biggest failings are:

1. There is no provision for auto discovering hosts on your network
2. As a result of above, each host has to be manually entered into the Nagios Configuration files, and the Administrator has to then add in each associated monitored service for each host. Then upload the configuration files back to the Nagios Server

This results in quite a lot of typing (if you have a large number of hosts to add to the system) – so I thought that I would break out my trusty copy of Visual Studio and see if I could come up with a tool that would make life a little easier for people.
The net result is the “Nagios Discovery Tool for Windows” – which I would like to provide you all with a Video preview of before I upload it to the site for download.

Of course to get around this people can opt to use Nagios XI which is the commercial offering of Nagios which has a number of rather sexy features, however that version is not free (well I say its not free ~ you can select a special license mode which will allow for up to 7 hosts to be monitored).

The Nagios Discovery tool has the following features:

• Network Scanning API which can resolve host names within certain IP Address Ranges
• The ability to check if resolved hosts are responding to pings
• A fully customisable XML based overlay which allows the user of the tool to build their own Nagios Monitoring Commands directly into the GUI without needing updates from me
• The ability to add hosts to the Nagios “windows.cfg” file, and configure services on the host to be monitored

I plan to release the tool for download in the next week or so (I am still working on the manual, and a few “how to” videos) – however, if anyone is interested in being an early tester – drop me a line and I will make the installer available to you, in the mean time – here is the preview video:

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

cd nrpe-2.13

./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.

[ NOTE: ] This part has been updated to reflect some suggestions from readers of the site. Sections that have changed are:
Installing Nagios Core – added the sed commands before the “Make” process, this fixes an issue with the Make file which prevents the Nagios home page from being displayed, as well as some issues with the RSS feed – many thanks to Michael for pointing this out, and Simon Krenger for the actual fix.

I have also changed the Verifying Nagios Permissions section to reflect Michael’s suggestions – this fixes an issue when trying to schedule a service recheck which is related to permissions on the “nagios.cmd” file.

I have also removed the suggestion for an FTP server within the configuration – in essence you should be using SSH transfers via FileZilla.

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

Whereas you do not need to install OpenSSH on your Ubuntu server, it is a very useful tool 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 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 onto your Ubuntu box use following command on the console:

sudo apt-get install openssh-server

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

sed -i 's:for file in includes/rss/\*;:for file in includes/rss/\*.\*;:g' ./html/Makefile

sed -i 's:for file in includes/rss/extlib/\*;:for file in includes/rss/extlib/\*.\*;:g' ./html/Makefile

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 nagios.nagcmd /usr/local/nagios/var/rw

 

chmod g+rwx /usr/local/nagios/var/rw

 

chmod g+s /usr/local/nagios/var/rw

 

/etc/init.d/nagios restart

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 ]