The Life of Brian

Active Directory, Group Policies, Server Core and the Life of Brian

Email Notifications

Blog Search Form

Go

Recent Posts

Tags

Disclaimer

  • This blog is provided "AS IS" with no warranties, and confers no rights. This blog contains my own views and does not necessarily reflect the view of my employer.
    Locations of visitors to this page
    Add to Technorati Favorites

Sites I Visit

Archives

October 2008 - Posts

Hyper-V Delegation

I was playing around with Microsoft’s Hyper-V today and ran into some problems managing the service remotely.  I set my server up and wanted to connect via RSAT from my Vista box but was not able to connect to my server because of permissions.  No biggie there, actually I didn’t expect I would just be able to connect to the server and manage Hyper-V.  I did think that after installing Hyper-V that there would be some groups created to help manage Hyper-V…needless to say I was wrong.

Thankfully I found a great series of posts on delegating access to VM and Hyper-V and thought it would be great to share them here with you.

Delegation Model in Hyper-V – Part 1
Delegation Model in Hyper-V – Part 2
Delegation Model in Hyper-V – Part 3
Delegation Model in Hyper-V – Part 4
Delegation Model in Hyper-V – Part 5
Delegation Model in Hyper-V – Part 6

Basically Hyper-V uses Authorization Manager to delegate what you can do within it.  If you haven’t used AzMan don’t be scared, the posts walk you though several scenarios. 

And for those of you that are interested in the HW aspect of my project…This is simply a development server that I'm using to test some things.  It is an HP DL360 G5 with a single quad core XEON (only 2 Ghz) with 16 GB of RAM.  All my VMs will be hosted locally (not sure on the number yet).  I’m trying to set up an environment that people can use to practice Server 2008.  I don’t think the CPU is going to be that much of a limiter since there won’t be a ton of people on at the same time doing processor intensive operations. 

Restartable AD DS and DSRM Logon Behaviors

Ever since Windows 2000's implementation of Active Directory (AD) we have had a method to restore AD objects that were removed.  Although it hasn’t been as easy as hitting CTRL-Z to undo a mistakenly deleted object or to try to restore from the Recycle Bin, we have had a method to restore objects.  That method is to restart the Domain Controller (DC) in Directory Services Restore Mode (DSRM) and logon with the DSRM account and password that is generated using DCPROMO.  (how to reset a DSRM  account password)

Having to restart a DC to restore objects has always been a sore subject with me.  Thankfully in Windows Server 2008, Active Directory Domain Services (AD DS) now functions as a service.  This service may look the same from the outside but if you dig a little deeper you will see that it is a bit different.  For example, you cannot pause this service and the startup is hard coded to Automatic...thus the only way you can start a DC with AD off is via DSRM, but you can Stop it while the server is up in a norm state.

The advantage of this is that you no longer have to bring down a DC to do an offline defrag of your ntds.dit.  One thing you can't do by default is stop AD DS and then perform an authoritative restore.  I say by default because this can change in Server 2008.   This all changes with Server 2008 and you now have the ability to change the DSRM logon behavior.  By modifying the following registry key you can select when you want to allow the DRSM administrator to log on:
HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior

There are three values that can be selected:

Value Description
0 (default) DSRM Administrator can log on using DRSM boot option
1 DSRM Administrator can log on while AD DS is stopped
2 DSRM Administrator can log on at all times

I'm personally a fan of Value 1.  Value 0 has to big of an impact for restores and maintenance and Value 2 is a little too liberal for my likings.

Finally some commands that can be used for those Server Core Admins: 

  • net start ntds (starts AD DS service)
  • net stop ntds (stops AD DS service)
  • sc \\ <DC Name> query ntds (queries AD DS service)

Important Notes:
When you stop AD DS you are also stopping the following services on that DC:

  • File Replication
  • Kerberos Key Distribution Center
  • Intersite Messaging
  • DNS Server (hopefully your clients have multiple DNS sever entries)
  • DFS Replication

Be aware that when you change the value of DSRMAdminLogonBehavior the DRSM Administrator account is not checked by any password policy.

What W32tm is it anyway?

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_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.  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.

image

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! :)