Get-ExchangeServer | FL won’t return Static Domain Controllers

Sometimes you need to set a statically controlled Domain Controller or Global Catalog server so that Exchange will only use that particular DC or GC.  In Exchange 2003 this was fairly easy.  You would go into Exchange System Manager, right click the server object and choose properties.  One of the tabs was for DSAccess.  You would be able to uncheck the Automatically Detect AD servers.  This made it really easy to see if a previous Exchange Administrator (its always someone else’s fault, isn’t it?) had made this change.  Simply check the box and everything goes back to normal.

In Exchange 2007, we don’t expose this in the UI anymore.  In order to set this, we have to run Powershell commands.  Even for a Powershell newb like me, that is not difficult to do.  Microsoft even makes it easy for you to find out how to do this on Technet.   The command we run is Set-ExchangeServer –Identity (Your Server name goes here) –StaticDomainControllers (Your DC name goes here). In the picture below, you will see that I set my CAS/Hub server to use win-19ichdu0fvs as my only DC.

As you can also see I am going to run the Get-ExchangeServer | FL to make sure that it was set properly.  What I expect to see is that I now have a statically set Domain Controller.

But wait, where is it?  Did the command run successfully?  I didn’t get an error when I ran it, so it looks like I ran it properly.  Let me run that again.  Ok still no error let me run Get-ExchangeServer | FL again.  And it still doesn’t show.  I must be doing something wrong.  Don’t worry your not, your just missing a switch that needs to be run in order for that to be populated.

Before we get into that switch, let’s talk about where this gets set actually.  Setting a static Domain Controller is not done in AD.  It is actually done in the registry of the Exchange Server.  Below is a snapshot of the regisrty before and after statically setting the Domain Controller.

Before:

After:

As you can see we add the UserDC1 subfolder to Default after setting the static Domain Controller.  Because this is not an AD setting, we need to call in to the Active Directory Topology server to pull this information.  The Exchange product group determined that there was too much of performance hit when we called into the Active Directory Topology service, which calls into the Remote Registry Service to warrant populating this information.  To offset that, they added the –status switch.  When you run Get-ExchangeServer –Identity (Your server name goes here) –Status | FL you will be able to see the static Domain Controller.

Lately, Exchange Support has fielded some calls on the symptoms that are seen when you set the –StaticDomainControllers.  The call usually starts out as, all my Domain Controllers are not reporting their information to Exchange properly.  Only one seems to be able to communicate with Exchange.  What the callers are looking at is the MSExchangeADAccess 2080 event.  Below is how the 2080 event will look when you set a static Domain Controller (server names have been blacked out to protect the innocent)

Event Type:    Information
Event Source:    MSExchange ADAccess
Event Category:    Topology
Event ID:    2080
Date:        3/18/2010
Time:        12:51:32 PM
User:        N/A
Computer:   XXXXXXXXXXXXXX

Description:

Process IISIPM38882B6C-3365-4687-BC84-D5D0A52F5F59 -AP "MSEXCHANGEOWAAPPPOOL (PID=5704). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
StaticDC        CD- 1 6 6 0 0 1 1 6 1 
NotSet1    --- 1 0 0 0 0 0 0 0 0
NotSet2    --- 1 0 0 0 0 0 0 0 0
NotSet3    --- 1 0 0 0 0 0 0 0 0
NotSet4    --G 1 1 7 1 0 1 1 7 1 
NotSet5    --- 1 0 0 0 0 0 0 0 0

At first glance this looks pretty bad and the natural instinct is to call PSS.  There has to be something wrong with AD.  But if you begin to break this event down, we can see a whole different story.  In my troubleshooting, the first thing that struck me was how NotSet4 was reporting.  Why would it only show a G?  I know that G stands for Global Catalog server and in order for that to be a Global Catalog server, it would have to be a Domain Controller. Talking with the customer, I determined that the other servers were only Domain Controllers. So why doesn’t that show the D in the event?  At this point this would tell me this is a configuration setting and not something wrong with AD. 

The previous Engineers were running Get_ExchangeServer | FL and were getting thrown off the path of what the true issue was.  The customer was extremely confused because they thought it was a static Domain Controller as well, but the data we were getting back was not reflective of that.  Once we ran Get-ExchangeServer –Status | FL we could see that it indeed was a static Domain Controller.  To remove that we had to run Set-ExchangeServer –Identity (name of your Exchange Server goes here) –StaticDomainControllers $NULL.  After running that and waiting 15 minutes, we could see that all of our Domain Controllers were back to speaking to the Exchange server.