SysAdmin Talk

One of the biggest challenges facing Exchange administrators is the management of SSL certificates. Exchange uses SSL certificates to secure communications between clients and servers for services such as Outlook Web App, Exchange ActiveSync, Outlook Anywhere, and more. There are several details that need to be taken into consideration when troubleshooting problems with Exchange certificates.

Imagine you are building a new forest including a new Exchange 2010 environment. The old Exchange 2003 environment contains a Public Folder infrastructure and you would like to move the content to the new Exchange 2010 environment. No problem you may think, but what are the steps that need to be taken to migrate the Public Folder to the new environment?

Here in the Information Systems team at Red Gate Software we wanted to do two things in one go:

1. Find out how big (or hopefuly small!) our own PST problem is, and
2. Test our new PST Importer tool

To accomplish both objectives we used Microsoft System Center Configuration Manager 2007 R2 to deploy the PST Importer Agent to all corporate desktops.

We use Standby Continuous Replication as part of our disaster recovery strategy.  Our environment consists of an Exchange 2007 clustered mailbox server using CCR which also replicates to an SCR server.  All our servers run Exchange 2007 SP2.

This week we did a test activation of the SCR replica in our test environment, but ran into an issue that we could not find a documented solution for.  In the hope that it saves someone else some time and anguish I’ve written about it here.

The procedure for activating an SCR copy is pretty well documented on Microsoft TechNet.

Step four in the activation procedure is to run the Exchange 2007 command line setup program, setup.com, to configure the clustered mailbox server on the SCR server.  The command line looks like this:

Setup.com /RecoverCMS /CMSName:<CMS Name> /CMSIPAddress:<IPAddress>

When we ran the command on our SCR server we received this error output:

Clustered Mailbox Server         ……………………. FAILED

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

The Exchange Server Setup operation did not complete. For more information, visit http://support.microsoft.com and enter the Error ID.

Exchange Server setup encountered an error.

An event 1002 error was also logged in the Application event log:

Exchange Server component Clustered Mailbox Server failed.

Error: Error:

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

WMI exception occured on server ‘exchangecms.example.com’: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Error:

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There is a similar issue described in this Microsoft Knowledge Base article: http://support.microsoft.com/kb/971713, but that did not help us as the conditions of our situation were different – both our SCR and CCR test servers are in the same AD site.  Nevertheless we checked our DCs and replication and found no problems.

After first checking the obvious things – domain controller replication, DNS and WINS name registrations and resolution, and re-running the command several times, we realised that the SCR server had managed to partially bring up the clustered mailbox server.  The Exchange services had been added to the cluster group, including the cluster name and IP address.  This meant that the server which setup was trying to modify must have been the SCR server itself.  We started IIS manager on the SCR server, and sure enough, the ‘Exchange’ virtual directory did indeed exist under the ‘Default Web Site’.

We removed the three Exchange virtual directories, Exadmin, Exchange, and Public, and re-ran the setup.com command and the process went through without any further errors.

So, if you are trying to activate an SCR replica, and you get an error telling you that the Exchange virtual directories already exist, try removing them on the SCR server.