A Small Concern When Virtualizing Domain Controllers - Time Sync

jdphilli — Fri, 13 Feb 2009 20:48:00 GMT

I'm sure this might open a can of worms, but it's a discussion that needs to happen. As virtualization technologies come into maturity, customers are more and more leaning towards virtualizing all of their infrastructure services. This includes Active Directory. Virtualizing Domain Controllers has been going on for some time now and was at first completely unsupported and even recommended against. That stance is changing considerably now, and we're beginning to see some official recommendations addressing this issue.

Let me first emphasize following the guidance set forth in this article: http://technet.microsoft.com/en-us/library/dd363553.aspx which contains official recommendations when virtualizing domain controllers in Hyper-V. The big 3 “don’t dos” are: never user differencing disks, don’t clone the guest without SYSPREPing it first, and don’t copy a VHD of a previously installed DC as the base for a new one. Those are all pretty straight forward to keep you from having SID conflicts or USN rollback issues which will totally mess up your AD installation.

Now, the next big issue is Time Sync. Microsoft recommends disabling host to guest time synchronization so that all DCs will use the default Windows Time service hierarchy just like a physical server. That’s not so hard, right? Just go into Hyper-V and disable that feature from the Integration Services settings. Easy. Done.

But: what about DCs running virtualized on VMWare [for the sake of discussion, let’s assume the SVVP supported version]? What does VMWare recommend? According to their KB article http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=1318, they say to turn of Windows Time service and use their host-to-guess time sync, except for the PDC Emulator of course, but then they want you to leave that on with “NoSync” turned on.

So: what is one to do?

First, I’d suggest a compromise – one that may avoid some of the issues. Don’t virtualize all your DCs. In fact, this is outlined in the Microsoft article above. You should really keep at least one hardware-based copy of your domain, and it should be the PDC emulator of the root domain of the forest. Preferably, in multi-domain forests, you’d want to keep a physical server for the PDC emulator of each child domain as well. This doesn’t have to be a very large machine, unless you’re a very large organization.

Now, if you virtualize all other DCs on Hyper-V (which I’d recommend not just because it’s Microsoft’s solution and I’m an employee, but because I’ve used both and Hyper-V is SO much easier to manage and configure), then the answer is clear: for DCs, leave the Windows Time service running on the guest DCs, with the root PDC Emulator’s time service configured to point to a highly-accurate external clock and disable Time Synchronization in the Integration settings. The Hyper-V hosts should then be joined to the domain. This will keep all hosts and guests synched to the proper time.

For guest running on VMWare, this is a tough decision since there are competing recommendations. Anecdotally, I have heard of no particular issues with disabling time sync in the VMWare tools and leaving Windows Time to synch the DC time clocks, but I have heard of issues the other way around: letting VMWare tools manage the time sync. In my opinion, such a custom solution as VMWare recommends should only be used if you’ve experience problems with the regular way of doing things. That’s why it’s the default: it generally works well when left that way. You should also configure the hosts to retrieve their time from the physical PDC Emulator in the root domain.

So, in summary, use a physical DC for at least one of your DCs per domain, and when you have to use VMWare, I’d recommend disabling the time sync from host to guest on domain controllers, and setting the hosts to obtain their time information from the root PDC Emulator. All other guests can be configured to obtain time from the host. But, as always, carefully monitor all your event logs for your servers and make sure you don’t have any issues.

Some Easy Active Directory Scripting

jdphilli — Tue, 26 Aug 2008 21:28:00 GMT

I solved a little problem for a customer the other day and I thought I'd share a little about it with you. It involves some VBScript user manipulation in Active Directory, and yes: there will be a code sample.

Let's start with the problem. For whatever reason, some users were missing some home drive information and more than half of users were not configured for roaming profiles. It was determined that this should be corrected. An easy way, of course, would be to push a group policy out which would configure something like: \\servername\home\%username% for home directory paths and \\servername\profile\%username% for profile paths. Well, that would have been easy if that's what the customer wanted to do, but it wasn't. Instead, they have set up a rather nice DFS root share for home drives and profile paths broken down by, lets say, users' last names. Sample paths for this would be \\dfsroot.com\home\%x\%username% where %x is the user's first initial of the last name. This wouldn't be so easy with a group policy. So for this, I wrote some code.

What I did was obtain a list of users who needed these properties set in display name format. This was done by extracting user information with CSVDE. The result would look something like this:

Smith, Bob
Johnson, William K.

Once I had this file (named users.txt), I could run my script

If you'll notice, in this particular instance, the display name is Last, First. Many corporations configure their GAL this way, and I can understand why, although at Microsoft we use the reverse order of First Last.

What the script does is open a log file for writing, open the users.txt file for reading

Const ForWriting = 2
Const ForReading = 1

'Path for log
logfilepath = "C:\TEMP\log.txt"

'Path for user list
userfilepath = "C:\TEMP\users.txt"

'Base Paths
baseHomePath = \\dfsroot.com\home\baseProfilePath = \\dfsroot.com\profile\

'Setup input file
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objInputFile = objFSO.OpenTextFile(userfilepath, ForReading, True)

'Setup log file
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objAdLogTextFile = objFSO.OpenTextFile(logfilepath, ForWriting, True)

'Create Objects for LDAP Queries
Set rootDSE = GetObject("LDAP://RootDSE")
DomainContainer = rootDSE.Get("defaultNamingContext")

Set conn = CreateObject("ADODB.Connection")
conn.Provider = "ADSDSOObject"
conn.Open "ADs Provider"

'Read in username from input file
Do Until objInputFile.AtEndOfStream

  strDisplayName = objInputFile.Readline

  'Find all users in AD using an LDAP query
  strLDAP = "<LDAP://" & DomainContainer & ">;(&(objectCategory=person)(objectClass=user)_
      (anr=" & strDisplayName & "*));adspath;subtree"

  'Get query results and output to file
  Set oComm = CreateObject("ADODB.Command")
  oComm.ActiveConnection = conn
  oComm.CommandText = strLDAP
  oComm.Properties("Sort on") = "displayName" 
  oComm.Properties("Page size") = 15000

  set rs = oComm.Execute
 
  If rs.recordcount = 0 then 
        QueryResult = "User not found" 
        objAdLogTextFile.WriteLine(FoundObject.Displayname & " | " & QueryResult)  
  End If 

  If rs.recordcount > 1 then 
        QueryResult = "Resolved to more than one name" 
        objAdLogTextFile.WriteLine(FoundObject.Displayname & " | " & QueryResult) 
  End If 

  If rs.recordcount = 1 then 
    While Not rs.EOF
      Set FoundObject = GetObject (rs.Fields(0).Value)
      fullProfilePath = baseProfilePath & left(FoundObject.displayName,1) & "\" &_
          FoundObject.sAMAccountName
      fullHomePath = baseHomePath & left(FoundObject.displayName,1) & "\" &_
          FoundObject.sAMAccountName
      objAdLogTextFile.WriteLine(FoundObject.Displayname & " | " & fullHomePath &_
          " | " & fullProfilePath)
      FoundObject.profilePath = fullProfilePath
      FoundObject.homeDirectory = fullHomePath
      FoundObject.homeDrive = "H:"
      FoundObject.SetInfo
      rs.MoveNext
    Wend
  End if
Loop
 
MsgBox "Processing complete!"

This code helped me to set the baseline for existing users. New would then need to be created with the proper home drive and profile path. A good way to automate this is with something like ILM to provision user accounts. ILM is good for quite a lot of things and maybe one day, I'll have some tidbits to post about it.

Until next time, I hope this sample will help you get started on your own scripts for your directory.

Notes From The Field : Active Directory

A Small Concern When Virtualizing Domain Controllers - Time Sync

Some Easy Active Directory Scripting