Performing an Active Directory Health Check Before Upgrading
(Post courtesy Bonoshri Sarkar)
Hi everyone, this is Bonoshri Sarkar here. I have worked for Microsoft as Partner Technical Consultant specializing in Directory Services for the past two years; providing end to end consulting to enable partners to design, position, sell and deploy Microsoft Platforms for their customers. In my earlier role, I worked for more than 4 years on the Microsoft Support team focusing on Microsoft Directory Services.
Since I have a great affinity for Directory Services, I thought it would be a great idea to pen down my thoughts and experience on ensuring a smooth Active Directory Upgrade.
For any kind of Upgrade/ Migration / Transition to go smooth, and later on to have an healthy environment, it is required to spend a fair amount of time in planning and making sure that the source or the present environment is in a healthy state. Two driving factors for any upgrade or transition include the need to utilize the new features that the new version of the product has to offer, and the other being to ease the complexities and the issues of the current environment. However, most IT Pros do not take adequate steps to check the health of their existing Active Directory environment. In this post, I would like to address some of the key steps that an AD Administrator must perform prior to an upgrade or transition.
In my experience of assisting customers and partners in different transitions, most of the issues pertain to the source domain or the source domain controllers, so I will discuss few important things which should be considered as mandatory before going for any kind of Upgrade / Migration / Transition.
Performing an Active Directory Health Check
The health check should be done in 2 phases.
1. Planning Phase
2. Deploy Phase (just before implementing the upgrade, transition or migration)
In the first phase we should identify what all services and roles are running on the machine that we are planning to upgrade, and rule out things that we do not want to move to our new box.
Putting emphasis on diagnosing AD issues, we can use dcdiag to ensure a healthier Active Directory, I know we have been using dcdiag for many years, and we look for failure messages in the output, but apart from the failure messages, we can also consider issues such as those highlighted in yellow below:
If you notice the first part of dcdiag says “failed test replication”, which implies that there are issues with Active Directory replication with this Domain Controller.
The second message tells us that there are issues with netlogon and sysvol which are default logon shares, both the errors can be interdependent or could be because of completely different reasons.
In this scenario we need to fix AD replication first or dig into it more to find what is causing these errors. Now you can use few more commands to check the AD replication like repadmin /syncall /eAP. In case of a huge enterprise, you can also use Replmon (2003).
The third message tells us that the important services are running. We need to be sure that the above services are started to ensure a smooth transition.
If we don’t get enough details from the dcdiag results, check the event viewer, and if you do not see anything restart the FRS service and then check the event viewer for Event ID 13516.
Apart from dcdiag you can also use Netdiag to check the network status and get detailed information.
In addition to this, make sure the NIC card drivers are updated on the old server.
Instead of disabling the hardware or software based firewall between on the servers (old &new), ensure that you make the appropriate exceptions and port configurations to ensure proper communication between the directory servers (see Active Directory and Active Directory Domain Services Port Requirements).
Any third party legacy application(s) should be tested in lab environment to make sure that they are compatible with new version of server OS and Active Directory.
We also have different versions of Exchange BPA (Best Practice Analyzer) tools depending on the version of Exchange to check Exchange integrity and Exchange specific permission (You can select Permission check to gather that information).
Last but not the least read the migration or transition documents (https://technet.microsoft.com/en-us/library/cc731188(WS.10).aspx) to make sure server has all the minimum requirements.
Once we are sure that the servers are in healthy state do not forget to take a full and a system state backup using a supported backup system as documented in the TechNet article below
https://technet.microsoft.com/en-us/library/cc731188(WS.10).aspx
All these stitches in time would definitely save you nine hours’ worth of troubleshooting. It’s up to you to decide, would you like to troubleshoot or enjoy your Fries with Coke?