Here is a few one-liner commands to help get info on your Active Directory environment. I don’t think there is any mind blowing commands here but they’ve helped me out. There are literally hundreds of these around the web as well as PowerShell ones but these are the ones that I’ve been using lately.
How to view the Domains you trust and see what those Domain SIDs are:
nltest /domain_trusts /v
A quick listing of your AD Sites:
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn description location -filter (objectClass=site)
A quick listing of your AD sites and their Site Links and Costs (sure would be nice if you could spit this out to Visio or something):
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn costdescription replInterval siteList -filter (objectClass=siteLink)
Compare time against your forest root PDCe:
w32tm /monitor /computers:ForestRootPDC
Find out which DC for a site is the ISTG:
dsquery * "CN=NTDS Site Settings,CN=siteName,CN=Sites,CN=Configuration,DC=forestRootDomain" -attr interSiteTopologyGenerator
I recently blogged about time and how critical it is in a domain environment. Just this morning I read a post from the Directory Services Team that shows how to configure WMI Filtering through Group Policy to ensure that the PDC Emulator always has the right time configuration. You need to read through this post really consider implementing a similar policy into your environment.
The only portion that is missing from that post is the location of the W32Time settings in Group Policy. The policy you will be configuring is located under the Computer ConfigurationAdministrative TemplatesSystemWindows Time ServiceTime ProvidersConfigure Windows NTP Client
After you enable it you will want to change the default setting from NT5DS (which means find and sync with the PDCe) to NTP. This is because we are configuring this for our PDCe which should be pointing to a reliable time source (internal or external). You will also configure the location to that reliable source in the NTPServer dialog box.
I haven’t seen a great tip like this in some time. This is one of those great little finds and I hope you enjoy it.
My daughter Alyssa and I play a game…well she might not consider it a game but she is constantly asking me “What time is it without looking”. I’ve actually gotten pretty good at it and can usually get within a few minutes. Not sure why she likes to play but perhaps time is something they recently talked about at school but she seems obsessed with it. I keep telling her that at 6 she really shouldn’t worry to much about time.
Although time may not be important for my daughter, it is immensely important for Active Directory. Most AD admins know that domain controllers and clients need to be within 5 mins of each other to work correctly. If your time was out by 5 or more minutes the client would not be able to authenticate. What most AD admins might not know is that time just doesn’t affect AD, it also can affect certain time sensitive applications. I don’t know of any out of the box ones from Microsoft but organizations have plenty of custom built apps that may use time syncs. I’ve seen custom applications that need to be accurate within less than a second.
Let’s take a look at how time synchronization works in an Active Directory forest. The magic all starts in the root domain (I always wanted to use that in my blog). The PDC Emulator (PDCe) is solely responsible for time synchronization and uses the Network Time Protocol (NTP) on port UDP 123. You will want to sync the PDCe with a reliable source, either internal (perhaps a router) or external. The problem with going external is that there is less security because of the lack of authentication and verifiable authenticity.
Clients and servers in your forest root domain will sync their time with any DC in the forest root. This is all configured in the registry at the following location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters. Domain members have Nt5DS set for the TYPE key which configures them to use the domain hierarchy for time. Some people change this to NTP which means it will go to a specific time source besides the PDCe but I prefer to keep the default here because it works! If you’re crazy enough you could configure it so that it relies on the CMOS clock…I just don’t have enough faith in the batteries for that.
If you have child domains or other tree roots in your forest realize that the forest root PDCe is STILL the authority for forest wide time synchronization. The PDCe for the child domains will sync their time with the forest root PDCe or any DC in the root (but those root DCs get their time from the PDCe). The clients and servers in the child domain will always go to a DC in their domain, so they should never go up to the forest root domain. Clients poll the time every 45 minutes by default. After three successful synchronizations it will increase that polling time to 8 hours. Below is a great illustration of how time works in a multi domain forest.
To configure your forest root PDCe with a valid time source you should use the w32tm command:
w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update
You can and I recommend adding multiple peers but simply putting a space between them. Please don’t forget to run this command on the DC that you have designated as the DC to fail the PDCe role over to during downtime (for example, patching).
To test how close your time is synced you can use the w32tm command again, except this time we can get a really cool command prompt chart…hey its the simple things in life that get me.
w32tm /stripchart /computer:target /samples:n
Replace target target with the name of the forest root PDCe. I prefer to get 10 samples but you can go for whatever amount you like. This will tell you the difference between the clocks. More info can be found on the w32tm here.
The Microsoft Directory Services team has a great blog that talks about high accuracy in w32tm and why they don’t support it. This is a must read for all AD admins. Don’t forget to set up an RSS feed to the Windows Time Service blog as well.
I would recommend baseline the time difference in your environment so that if an issue does occur you will know what the norm state is for your time differential. You may also want to include some monitoring that can alert you of time drift using the baseline numbers you’ve collected. I would also recommend talking to your developers and ensure they understand how time works in the environment.
Hopefully this sheds some light on how time works in an Active Directory forest but also how you can control and tweak it. Oh and if you’re bored try playing the time game…its a great exercise for your mind and internal clock! :,,)