Over the last 12 months, I have been undertaking a centralisation of AD project across over 100 Sites. If you read through some of my previous AD design and implementation articles, you will see that i push the single AD path quite heavily inline with both Microsoft reccomendations and real world experience
Unfortunately, there are one or two small bugs that still need to be addressed in a Single AD environment, with remote sites that do not host a Domain Controller. In reality, with sites that have 4 or 5 computers, there is not a justification of cost to implement a local DC at each site. Whilst this would be a Fantastic environment to work in, its simply not something that can always be justified.
The biggest problem that i have found so far, is that when a WAN link drops at a remote site, certain functions of everyday network no longer work, the biggest is local drive mappings. For example, say you have an XP machine that hosts a small POS application, and all other clients MAP to this machine. If the WAN link drops, the user can logon with Cached Credentials, but drive mappings to other machines fail, due to no local GC being contactable to provide authentication. This may be ok for an hour or so, but when you start talking of days without a Link being restored, this becomes a very serious matter
The ony work around to date that i have found is to emulate a workgroup environment temporarily. When i say emulate, i mean drop back to the Authentication of mapped drives occuring at a SAM level, rather than AD. This isnt as bad as it sounds, considering that cached computer security settings from a GPO still apply so your security isnt breached
Basically, i have created a small script that runs as a startup script within GPO whilst the link is up, that creates a local user account on each machine. When the Link drops and is not returned to an operation state (time period set by internal SLA's) we simply guide the local staff in logging in with the local account, and mapping drives to the appropriate machine - to enhance efficiency, you can even create a set of batch or vbs files to take care of this all for your users depending on your environment. a local logon script still runs and makes life much easier. This must be run as a startup script rather than a logon script as local users do not have permissions to create users
This runs on all local machines, uncluding terminal services, and includes the appropriate group membership for the loca user to allow both local, and TS access when no link is present.
2008 Server introduces RODC's, which will start taking care of a lot of these problems, especially for sites that may contain a local 2008 file and print server. 2008 Group Policy also allows for local user create via GPO, which will make this script redundant (yay!) and make life much easier
Here is the code that i am currently using - its simple and easy - feel free to use it as you see fit
James
DIM strUserName
DIM strFullName
DIM strDescr
DIM strPassword
DIM strComputer
Set WshNetwork = WScript.CreateObject("WScript.Network")
strUserName = "LanLogon"
strFullName = " WAN Down"
strDescr = "Local Logon Account WAN Link is Down"
strPassword = "PassWord0099"
strComputer = WshNetwork.ComputerName
Set colAccounts = GetObject("WinNT://" & strComputer & "")
colAccounts.Filter = Array("user")
result = false
For Each objAccount In colAccounts
if (objAccount.Name = strUserName) then
result = true
end if
Next
If result= false Then
set objSystem = GetObject("WinNT://" & strComputer)
set objUser = objSystem.Create("user", strUserName)
objUser.FullName = strFullName
objUser.Description = strDescr
objUser.SetPassword strPassword
objUser.SetInfo
Set objUserGroup = GetObject("WinNT://" & strComputer & "/Users")
Set objRemoteGroup = GetObject("WinNT://" & strComputer & "/Remote Desktop Users")
objUserGroup.Add(objUser.ADsPath)
objRemoteGroup.Add(objUser.ADsPath)
End If