Windows Insider

8 AD Mistakes You May Have Missed

Keep getting error messages? Check this list for something you might have overlooked.

• By Greg Shields
• 01/01/2007

Well, sometimes all you need is a fresh pair of eyes to double-check your work and find those little misconfigurations that some day could take down the entire network. Many are so small they can go undetected for years, but any one of them can have a negative effect on the overall health of your Windows domain. Let's take a closer look at what could be impacting your AD right now.

1. Stale AD Site Links
Microsoft's recommended practice for the Knowledge Consistency Checker (KCC) is to leave it alone. With the KCC updates available in Windows 2003, its algorithms have been enhanced to handle thousands more objects, as well as to decrease the amount of time it takes to complete a site link convergence.

Once a site link is manually created, it's no longer managed by the KCC and can either grow stale or become inappropriate as the network changes over time. Unless you have a specific network requirement for a manually created site, it's a good idea to remove any that have been created.

2. DNS Scavenging and Reverse Lookups Not Enabled
Microsoft's default behavior for DNS is meant to initially disable aging and scavenging. Aging adds a time-to-live (TTL) value to each record, which is reviewed by the scavenging process each time it runs. When the scavenging process sees a TTL greater than its configured refresh interval, it will delete the record.

This is important for zones that involve dynamic data, like those populated by DHCP clients. When DHCP clients change their IP address, they'll re-register any new IP addresses with the DNS. Without scavenging, this can create multiple FQDNs for each IP address while also creating multiple IP addresses for each FQDN.

Reverse lookup zones are also a must for domain functionality. Clients use reverse lookups to locate their assigned AD site and identify the closest DNS server. Lacking reverse lookup zones can also prevent clients from processing Group Policy and connecting to the correct Domain Controller (DC).

3. DSRM Passwords Unknown
Have you written down and properly secured your Directory Services Restore Mode (DSRM) passwords? Arguably the most forgotten password is the one for DSRM because it's created only when a DC is built, and used only during critical DC recovery operations. Not knowing this password can prevent a successful recovery.

If you don't know your DSRM passwords and haven't stored them in a safe place, use the following commands for each Domain Controller to reset it to a known value:

ntdsutil
set dsrm password
reset password on server {servername}

Once you do this, write down that password and lock it away.

4. GPOs Not Easily Restorable
If you're using standard backups to store each DC's system state to tape, you've got the bare minimum necessary to restore an AD in the case of a failure. But in the case of a simple object restore like a Group Policy, the process can be time-consuming. If you've ever accidentally deleted a Group Policy or cleared its settings, you now realize you have less than 90 minutes before your machines start reconfiguring.

There's a much easier way to back up these policies. The Group Policy Management Console includes handy scripts in the Program Files\GPMC\Scripts directory. One script in particular can save the day:

cscript BackupAllGpos.wsf {Backup Path}

On one Domain Controller, set this script as a scheduled task to back up your Group Policy configuration every day.

5. Broken GPT and GPC Linkages
Group Policy Objects have two parts consisting of the Group Policy Template (GPT) residing in the SYSVOL and the Group Policy Container (GPC) in Active Directory. When problems occur with SYSVOL replication or in the AD itself, the two halves can become unsynchronized. When this happens, Group Policy can cease to function or start behaving strangely.

To validate synchronization of GPTs and GPCs, use the Resource Kit tool gptool.exe. In a healthy domain all policies should return a "Policy OK" result. When a policy fails to do so, some troubleshooting of SYSVOL replication and GPO version numbers is in order.

6. Unnecessary Apps Installed
Many administrators like the added convenience of keeping commonly used applications installed on servers. For instance, having Adobe Acrobat installed means you can read documentation in the server room. But, having Acrobat or any other workstation application installed on a Domain Controller increases that server's attack surface. Remember, non-Microsoft applications have patching needs, too.

You should dump those unnecessary applications on both Domain Controllers and any other server in the data center.

7. Morphed SYSVOL Folders Present
Not at R2 yet? Morphed folders are created when issues occur in SYSVOL replication or restoration, or when administrators create similar folders in SYSVOL on different DCs simultaneously. When it does, the morphed folder is renamed to {foldername}_ntfrs_{random 8 digit hex value}. Although these folders are present and available in SYSVOL, they may not be linked to other AD components properly.

Fixing a morphed folder involves removing or renaming the folder and its morphed pair and waiting for replication to complete. Then the correct folder is identified and renamed to its correct name or copied to its correct location.

8. Orphaned Domains and Domain Controllers Resident
Orphaned domains and Domain Controllers can cause issues with replication, Global Catalog promotion, and Event Log errors as your AD attempts to communicate with the missing DC. The best way to remove a domain or DC from the forest is to dcpromo it before removing it from the network.

If the dcpromo fails or you forget to do it, you must remove the machine's metadata from the domain. Removal of both domain and DC information is done with the ntdsutil command using the metadata cleanup option. Additional DNS, sites, and trusts cleanup is necessary after ntdsutil completes.