Microsoft Exchange 2010 – SSL Certificates

I recently installed my first third party certificate into an Microsoft Exchange 2010 environment. This process is almost identical to how it is performed in Exchange 2007, however the PowerShell commands differ very slightly. Microsoft Exchange 2010 does actually support certificate requests and installations directly through the Exchange Management Console, however I’m not much of a fan of this, it has a slightly clunky feeling to it much like the Small Business Server 2008 implementation of wizard driven certifcate requests and installations.

For this certificate installation I was using a Go Daddy UCC 5 Domain certificate, which is more than adequate for Exchange 2010. You may see Exchange certificates branded as UCC (Unified Communications) or SAN (Subject Alternative Name), these are essentially the same, just different vendors choose to brand them differently. As a rule of thumb, always go for at least a five domain Unified Communications certificate otherwise you will find yourself in a pickle when it comes to adding subject alternative names. The following section of this post details the steps required to generate your CSR and install your certificate into your Exchange 2010 environment.

1. The first step of this process is to generate the CSR that will be used to tell your SSL vendor all about your environment. To make life a little easier, DigiCert have created a web based tool that will compile the required CSR PowerShell command for you, which you can find here

Hopefully once you have filled out the required fields in the DigiCert tool, you should have something very similar to the below screenshot. Please pay attention to the Subject Alternative Names used and the order that they have been entered in.

DigiCert CSR 300x159 Microsoft Exchange 2010   SSL Certificates

Please note that where contoso.com is your public domain name, and where contoso.local is your local domain name. Mail.contoso.com would the public DNS A record that is pointed to your internet endpoint, for example the global IP address of your router or firewall.

2. Once you have filled out of the required fields, click the generate button and then copy the generated PowerShell command to your clipboard. Open the Exchange Management Shell (EMS) on your Exchange 2010 server and paste the copied PowerShell command into the EMS and press return. Once this has completed, navigate to the C:\ drive on your server and open the generated .csr file in notepad. The content of this notepad file is the information you need to submit to your SSL vendor when they request CSR information.

3. When your certificate has been generated, download it from your SSL vendors website onto the root of the Exchange 2010 servers C:\drive. Once this has been performed, we need to action a PowerShell command to both import the new certificate and append this certificate to all Exchange 2010 services.  The PowerShell command you need to run is the following:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\your_certificate.cer -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS,POP,IMAP,SMTP

In the above command, please edit the -Path attribute to read the file location of where you have stored your downloaded certificate.

4. To verify the certificate installation, browse to Outlook Web Access from an external source, so for example to https://mail.mydomain.com/owa and ensure that the correct certificate is being utilised by clicking the padlock icon in Internet Explorer or your preferred browser.

Microsoft Exchange 2010 – Public Folder Replicas

A major part of any Microsoft Exchange transition is the task of moving all public folder content. Sometimes Ive found this to be a migration sticking point, awaiting all of your public folder content to move from one Exchange Organisation to another. One thing I have found that speed’s up the process, are two PowerShell scripts that are supplied “out of the box”  with Microsoft  Exchange 2010. To benefit from these, perform the following actions:

1. Open the Exchange Management Shell (EMS) and change directory to:

“C:\Program Files\Microsoft\Exchange Server\V14\Scripts\”

2. The following PowerShell script will add your new Exchange 2010 server as replica on all public folders in your existing public folder database. In the same EMS window you opened in step one, run the following command. Please note, replace the “MyExchange2010Server” entry with the name of your own Exchange 2010 server.

AddReplicaToPFRecursive.ps1 -TopPublicFolder “\” -ServerToAdd “MyExchange2010Server”

3. Once this command has completed, we can then run a second PowerShell script to initiate the move of all public folder content. To perform this task, in the same EMS window run the following command. Please note, replace the “MyExchange200xServer” and “MyExchange2010Server” entries with the names of your own legacy and  Exchange 2010 servers.

MoveAllReplicas.ps1 -Server “MyExchange200xServer” -NewServer “MyExchange2010Server”

Once this command is complete, your public folder content will now start to replicate. You can monitor it’s progress by viewing the “Public Folder Instances” container in Exchange System Manager on Microsoft Exchange 2003 or through the Public Folder Management Console in Microsoft Exchange 2007.

As a note, if you are transitioning to a Microsoft Exchange 2007 organisation, these PowerShell scripts are also available and can be found in the following directory, C:\Program Files\Microsoft\Exchange Server\Scripts.

VMware Capacity Planner – Missing Data

A while ago I was performing a VMware Capacity Plan for a third party company. During the implementation of the planning software I experienced an issue collecting CPU, RAM and disk statistics for two particular servers. I noted that when running an inventory job in the capacity planning software, the following error was being produced:

RetrieveSystemUpTime: PdhVbGetDoubleCounterValue() has bad status. No uptime data 

After a prolonged investigation of the issue I contacted VMware to see if they had experienced this problem. To some surprise, there was no entry in their internal knowledge base for this issue and the problem was passed to their developers in the United States. A week later, and it turned out this error is actually produced if the capacity planning software receives “invalid” data from a server. In my case, rebuilding the Windows Performance Counter Library Values resolved the issue. We could only assume these had become corrupt and were therefore sending incorrect values to the capacity planner. To rebuild your performance counters, please follow the steps detailed in Microsoft KB Article 300956: http://support.microsoft.com/kb/300956