In January 2010 I wrote a blog post Where oh where, did my AD site go…[Alternate title: It’s the DNS, stupid.]. In that blog post I discussed a situation where an incorrect DC locator record could cause a server to report itself as a member of an improper Active Directory site. That can cause a number of issues with Exchange.
I am in the process of migrating that same customer to Exchange 2013 (the prior blog post was written when migrating a particular customer to Exchange 2010).
The first Exchange 2013 server was brought online after the OS was installed. I went through the normal process of installing Exchange 2013 role and feature pre-requisites, installed Ucma 4.0, etc. etc. When it came time to do the first actual step in installing Exchange 2013, PrepareSchema, setup.exe reported that the Schema Master FSMO was not in the same Active Directory site as the computer running setup.
Huh?
Of course it was. I know this requirement and made certain it was satisfied! The Schema Master FSMO was in the AD site named “10-129-59”. The new server was in the same subnet.
However, when executing “nltest /dsgetsite”, nltest reported that the AD site was “Default-First-Site-Name”. Uh, wow.
I immediately reviewed AD Sites and Services to ensure that AD Subnets and AD Sites were properly configured. Indeed, they were. Next, I reviewed the customer’s DNS, in detail, as described in the above blog post. The DNS was correct.
Finally, with little hope of success, I tried resetting the secure channel to the proper FSMO DC. That succeeded.
So, I rebooted. After the reboot, the secure channel was again reset to a DC in “Default-First-Site-Name”. OK, I tried the same thing again (resetting the secure channel and then rebooting) with no change in behavior.
No need to try a third time. That would meet a classical definition of insanity. 🙂
I spent a limited amount of time investigating the particular reasons for why this should occur. But when it comes down to it, as a consultant, my job is to accomplish this project. So, I went out to find ways to ensure that a particular computer is a member of a particular AD site.
It turns out to be pretty simple. You must set a registry value for this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
The value is called SiteName and is of type REG_SZ (the name is case sensitive).
In my case, I set SiteName to “10-129-59” and closed regedit.exe (of course you can set this value in many ways – you can use PowerShell, .NET, Win32, reg.exe – whatever you wish to use). Documentation says that restarting the NetLogon service should correct everything, but that is not my experience. After rebooting the server, the computer came up in the proper AD site and I was able to proceed with installing Exchange Server 2013.
Follow me on Twitter: @essentialexch