AD Health Checks, they’re not just for your on-premises infrastructure any more. These checks are becoming more and more important as companies are federating to various cloud vendors (Office 365, AWS, etc). These connections require what you might call ‘pre-flight’ and ‘post-flight’ checks. These checks are important because they usually provide a dual function for my clients.
One is that we generate documentation of the environment, which I have found to be lacking in about 50-75% of environments. The System Admins know their environment, but there is not formal documentation. An AD Health Check can lead to some useable documents for reference by the admins or their managers. Second, these checks also ensure that the migration or federation (for Hybrid) will go smoother. The hope is that we can identify any issues that could cause headaches down the road. Let’s take a look at what can be done during a health check.
Task List / What to Check
By no means can I provide a comprehensive
checklist for any and all migrations. Every environment is different and every company should have health checks customized to their environment. We cannot take the same approach to a small company with 3 servers as we would to an enterprise with 50+ sites (each with a DC) around the country. Take the list below with a grain of salt and try to stretch or shrink the list to meet your particular situations needs.
- AD Best Practices Analyzer
- Event Logs
- IDFix
- Microsoft Replication Status Tool
- Microsoft Baseline Security Analyzer
- Microsoft Topology Diagrammer
- Sites and Services Review
- Identify Non-Admin accounts without Inheritable Permissions set
- PowerShell Queries and Reporting
- Third Party Tools
AD Best Practices Analyzer
While this tool does not appear to be as comprehensive or as in-depth as other analyzers, it can provide useful information that will help provide a clean Active Directory infrastructure environment. 
One of the errors I look for, as it has caused me issues in the past, is strict replication. In particular what would happen is that, depending on how this was configured and how many sites your environment has, you may not notice anything wrong until the migration or transition to Office 365 is halfway done. This was my scenario where a client with a dozen plus sites had previously moved 6 sites and on the 7th site experienced issues.
In the end, 50-75% of the mailboxes would not move initially. Strict replication was causing all sorts of issues with replication of data to the cloud. Once this was resolved, all the mailboxes for the site moved without issue.
Run the analyzer and just consider it as one tool for analysis and not the only tool for analysis of your AD infrastructure.
Event Logs
Always review your logs. Always.
Examine them all – Application, System, Security, DNS, Directory Service, DFS Replication, File Replication Service, etc. If this can be done in some sort of automated fashion, then do so. Event Log analysis can be tedious, but it is necessary. If you don’t review these logs on a regular basis, then you are not using all the available tools to keep your environment healthy.
** Remediate issues found in the logs as well. Don’t just review them.
IDFix
The IDFix tool is one of the key tools that 
should be run prior to synchronizing Active Directory to Office 365. Why? Because IDFix looks for things like duplicate attributes that exist in your environment (UPNs, mail and proxy addresses) as well as incomplete attributes (UPNs and email addresses missing their domain). A complete list of what can be reported can be found on the Office Support Documentation. IDFix will also suggest what changes that should be made and you can use IDFix to make the suggested changed for you.
Changes that are made via IDFix can be rolled back because of its Transactional Logging Feature. Now, I have not used the roll-back feature because I try to make sure only to make necessary changes to AD using the IDFix tool. As with any other tools that can make changes on AD objects, make sure to test this out before rolling out any mass changed. Test the rollback feature as well to make sure any mistakes can be corrected.
Microsoft Replication Status Tool
The Replicaton Status Tool provides a quick graphical look at the status of Active Directory replication in your environment. Each AD partition for each Domain Controller is listed and checked to make sure that replication is working. If a Domain controller is a Global Catalog (GC), this is listed as well as if the server is an Read Only Domain Controller (RODC).
The on caveat I’ve learned from running it myself and from other consultants I work with is that sometimes anomalies crop up and the tool may need to be run again to verify if an error found is a truly a real error.
Microsoft Baseline Security Analyzer
An old tool, but still a useful free tool from Microsoft.
The newest version can be found here. The MBSA will help identity missing patches, vulnerabilities in SQL, local or domain account issues and so on. The idea here is to make sure that the Domain Controllers which are synching data to the cloud are secure and patched for production. This will help reduce potential issues down the road.
Microsoft Topology Diagrammer
Another good tool that has been around for awhile. This tool is most useful for making documentation and helping visualize an AD infrastructure. To run the tool you need to have Administrative rights on the
Results produced in Visio will look something like the below pictures. Note that the Sites one on the left is cleaned up a bit for display purposes:
I have had only one issue recently when trying to generate the files in Visio 2013 has cause an error to be generated. This has to do with the blocked file features of 2013. The below settings work fine for my documentation purposes:
(File –> Options –> Trust Center –> File Block Settings)
Sites and Services Review
For a long time AD Engineer, reviewing what
is present in AD Sites and Services is essential to reviewing the health of the AD infrastructure. From this console I can confirm DC and GC layout, Replication links, costs, empty sites and so on. This console may not seem important for an Office 365 project, however something is awry here, it could cause an issue with changes that need to be replicated to the cloud. Perhaps a DC’s connection is manual instead of automatic and replication is not occurring as expected. If a change to a user account is made (say a C-level executive) and this change is not replicated to a DC near your ADFS / DirSync servers, it may not make its way to the cloud.
We can also see objects that were manually create (site links) or deleted and sites left behind. Old servers than no longer have the DC/GC roles could be present.
Inheritable Permissions and Non-Admin Accounts
From my past experience in moving mailboxes from on-premises Exchange to Office 365, inheritable permissions has cause numerous issues. See my previous post – Inheritable Permissions – Failed Mailbox Migration – on how to deal with this issue.
PowerShell
PowerShell has proven to be a powerful
addition to the Microsoft product line. I won’t dig into that, but I will say that Powershell scripts can be written to help with validating information, creating documentation and more. For health checks I generally use it to make informational charts about the various domain controllers:
- Site the DC is in
- Status of open ports
- Admin shares
- Servers that are RODCs and GCs
- Disabled users and computers
- Empty OUs
- Unlinked GPOs
- etc.
Create what works for your environment. Be aware that scripts run in series, not parallel, so in a large environment, running multiple PowerShell windows will speed up the discovery process.
Sample PowerShell Script for DNS test
# Imports AD module if missing or not loaded
import-module activedirectory
function getinfo {
dcdiag /s:$dc /test:dns /v /i /x:"c:\test\"$dc"-test.xml"
$data += @($dc,$domain,$site)
$xml = "c:\test\"+$dc+"-test.xml"
[xml]$dcdiag = get-content $xml
$summary = $dcdiag.DCDIAGTestResults.DNSEnterpriseTestResults.Summary.Domain.DC.test
Foreach ($line2 in $summary) {
$data += @($line2.status)
}
$rowline = $data -join ","
add-content c:\test\dcdiagdns.csv $rowline
$rowline = $null
}
# Main Script Body
$data = @()
$rows = "DC," + "Domain," + "Site," + "Auth," + "Basc," + "Forw," + "Del," + "Dyn," + "Rreg," + "Ext"
$domaincontrollers = get-addomaincontroller -filter *
add-content c:\test\DCDiagDNS.csv $rows
foreach ($line in $domaincontrollers) {
$dc = $line.name
$domain = $line.domain
$site = $line.site
getinfo
}
# Define Style for HTML file
$a = "<style>"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 2px;border-style: solid;border-color: black;}"
$a = $a + "TD{border-width: 1px;padding: 2px;border-style: solid;border-color: black;}"
$a = $a + "</style>"
# Convert CSV to HTML
$output = import-csv c:\test\DCDiagDNS.csv
$output | convertto-html -head $a | set-content c:\test\DCDiag-DNS-Tests.html
Conclusion
The one thing I want you, the reader, to come out with from this article is that your on-premises infrastructure’s health can affect your move to the cloud. Check it out, clean it up and THEN migrate or connect your data to the cloud. Keep it clean and keep it running smooth.
Lastly, do not forget that a selective synchronization can also be configured to exclude OUs if there is indeed data that does not need to go to the cloud – disabled users would be a possible example of that may not be needed.
Further Reading
Install and Run the Office 365 IDFix Tool
Reference: IdFix excluded and supported objects and attributes
Microsoft Baseline Security Analyzer – more information
Exclude OU from DirSync
