A myth – Removing GC/DC and Exchange CRY

In the weekend I was working with my friend and helping him to remove his existing GC/DC and seen some interesting behavior about exchange which I thought to admit here which may be benefit to people those stuck into such Environment.

Current Setup

The environment has only one windows 2008 Server with all FSMO role installed and on top of that Exchange 2010 CAS,MBX,HUB role also installed (I know it’s not recommended 🙂 )

Requirement

They had installed one Exchange 2010 SP2 on Windows 2008 R2 server and configure all the roles and migrated all Mailbox, public folder etc. to new server successfully.

Installed one new DC (Windows 2008) and configured this DC as GC replicated DNS. All seems working fine on new DC as expected.

Now real fun is going to start. If you see various blog post and TechNet forum discussion, lots of MVP and expert advice to use CMDLET “Set-ExchangeServer” and point new DC/GC as static. I agree its good cmdlet and help Exchange Administrator to avoid any down time while you ask exchange to talk with new DC/GC

BUT, What about if someone change DC/GC for whatever reason – it becomes unavailable for an extended period of time (or worse: someone decided to decommission the server without telling you (happens all the time!). This would cause the Exchange Server to try binding to a non-existing DC/GC. Again if you want to remove static entry you can’t do as EMS is not getting started.

To avoid such issue and let exchange connect itself new DC/GC you need to allowing exchange minimum 30-45 minutes time. In this duration lots of event will generated as below.

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1111).
Exchange Active Directory Provider will discover the new DC’s and will show in in event log (Event id : 2080) . Let concentrate the event now.

(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
DC-OLD.ABC.local CDG 1 7 7 1 0 1 1 7 1
DC01.ABC.local CDG 1 7 7 1 0 1 1 7 1

If you see above the SACL value of both DC is ‘1’ which indicates that both DC’s are working as GC’s now. Now it’s time to shutdown/Disconnect old DC from network. Wait for 30 minutes and observe event logs. Go exchange server and try to restart Exchange AD topology server which would stop all services one by one and then start it again. Once all service are started , now you can confirm that new exchange is talking with new DC.

Now wait for couple of days and proceed with exchange & DC/GC removal.

Note : in some cases it has been observers that SACL value is  not showing 1 for new DC which cause exchnage to down. To resolve this. In the Default Domain Controller policy AND the Default Domain Policy under Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment, the policy “Manage auditing and security log” must have the Exchange Servers group added. This was not added in this environment. Once this was added the SACL as above changed to “1″ and the Exchange services started correctly

So, Why Set-exchangeServer cmdlet 🙂