SYSVOL holder list wrong on multi-site AD config

After authentication to a Windows 2003 Domain Controller, the DC will then list the possible SYSVOL servers for the client to use for GPO related files/folders. By default the order is as follows;

· List all Site-local holders to the client

· Randomly list the remaining SYSVOL holders, not based on Site Costing.

Consider a three-site AD structure, with a single DC at each site;

A user authenticated against the DC in SITEA would get the following SYSVOL servers presented to it;

1 entries… Entry: domainnamesysvol ShortEntry: domainnamesysvol Expires in 0 seconds UseCount: 0 Type:0x1 ( DFS ) 0:[DC1.domainnamesysvol] State:0x21 ( ACTIVE ) 1:[ DC2.domainnamesysvol l] State:0x21 ( ) 2:[ DC3.domainnamesysvol] State:0x21 ( )

N.B. entry 1 and 2 are randomly generated, and could as easily be reversed

In this scenario, no further configuration or design thoughts are required and SYSVOL will always be presented from a local-to-site server.

However, consider a more complicated design that contains multiple sites without local Domain Controllers. This is fine for authentication, as site-based costing is utilised to decide the nearest DC to each site – this is stored within DNS so that clients can always see their nearest authentication server (GC).

As the default behaviour for SYSVOL location is Local Site, then Random (with no Site Costing based calculations done), this consider the following;

A User authenticates from SITEC. There are no local Domain Controllers (with the GC role) available; however it is able to locate DC2 as the nearest authentication point using DNS. DC2 is then asked for a list of available SYSVOL points, and calculates using the formula below;

· List all Site-local holders to the client

· Randomly list the remaining SYSVOL holders, not based on Site Costing.

As there are no site-local holders of the SYSVOL share, it skips the first point and lists the remaining SYSVOL holders randomly, giving a result similar to;

1 entries… Entry: domainnamesysvol ShortEntry: domainnamesysvol Expires in 0 seconds UseCount: 0 Type:0x1 ( DFS ) 0:[DC1.domainnamesysvol] State:0x21 ( ACTIVE ) 1:[ DC2.domainnamesysvol l] State:0x21 ( )

N.B. Again this can be random, and DC2 could just as likely be first priority.

This works fine if DC1 is over a fast WAN link, and therefore responsive enough for the end user to not notice. However, if DC1 is placed on the end of a 2mbit site-to-site link and DC2 is on a 100Mbit LES/MPLS, the difference is then astounding – especially in environments with multiple Group Policies.

LogonHours

Below is a script to find any users who have logon hours restricted (i.e. not set to “Allow Any Time”)

 

Don’t forget to generate an objects.txt by doing a “dsquery –user –l 0 > objects.txt” as per any of my other scripts.

 

strtextfile = "objects.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") Set objTextFile = objFSO.OpenTextFile(strtextfile, 1, False, 0) On Error Resume Next Do strobject = objTextFile.ReadLine strobject = Mid(strobject,2,Len(strobject)-2) Set objObject = GetObject("LDAP://" & strObject) arrLogonHours = objObject.Get("logonHours") strName = objObject.Get("CN") If arrLogonHours <> "" Then ‘wscript.echo (strName & " has had Logon Hours defined – checking to see if they have any set currently") For i = 1 To LenB(arrLogonHours)     strLogonArray = AscB(MidB(arrLogonHours, i, 1)) arrLogonArray = arrLogonArray & strLogonArray strMidB = MidB(arrLogonHours, i, 1) Next if arrLogonArray <> "255255255255255255255255255255255255255255255255255255255255255" then WScript.Echo (strName & " has Logon Hours defined – please investigate.") end if arrLogonArray = "" End If arrLogonHours = "" Loop Until objtextfile.AtEndOfStream = True

What to do when your SYSVOL stops replicating………

Just a reminder for myself how to do it really.

Got a customer who was getting several error messages.

I’ll deal with the SYSVOL replication issues first, then move onto the DCOM issues.

They were getting;

I checked the usual, and both DC01 and DC02 could talk ok, so I figured “Let’s just Resync the bugger”.

http://support.microsoft.com/kb/290762

The above MS KB will tell you in detail, however here is a overlay for replacing DC02 with DC01’s copy (making DC01 Authoritative)

Stop the File Replication Service on both DC01 and DC02

Edit the registry on both;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

On DC01 I set it to D4 –> AKA Authoritative. On DC02 I set it to D2 –> AKA non-authoritative.

Start the FRS on DC01 and let it clear through the normal event log messages (right up to where it proclaims it is OK to be a DC again! Thank god!), then start up DC02. Monitor, and voila it all synced!

Jobs a goodun’ guvnor 😉

Finding users who are not Inheriting Rights

Got a request from a support company, they have found multiple users who are not inheriting rights from above. These users are random, and he wanted a quick way to find (and therefore fix) the users effected. Screenshot below of the checkbox the users have mysteriously "unchecked";

So I created a little script that will check users to see if they are set to inherit or not.

First, create a new folder. Get a list of all users in your AD (or a specific OU) by doing the following;

Now, create a VBScript file with the following content;

‘ This code will output all users who are currently NOT inhereting ‘ Security from above. ‘ Writted by Stephen Croft and Chris Stos-Gale from ANS ‘ strtextfile = "objects.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") Set objTextFile = objFSO.OpenTextFile(strtextfile, 1, False, 0) Const SE_DACL_PROTECTED = 0 ‘ set to 0 to enable inheritance Do strobject = objTextFile.ReadLine strobject = Mid(strobject,2,Len(strobject)-2) Set objObject = GetObject("LDAP://" & strObject) Set objntSD = objObject.Get("nTSecurityDescriptor") intNTSDControl = objNtSD.Control If objntSD.Control = 39940 Then WScript.Echo strobject & " Needs Changing" End if Loop Until objtextfile.AtEndOfStream = True

And save in the same folder as your objects.txt file that the first part created.

Now, back to command prompt for the following;

Where test.vbs is your vbs file you created (obviously).

This will create a output txt file (test.txt in this matter) that is Tab Seperated (for Excel import) of all users who are NOT inheriting rights from above.

To change them to be inheriting, either pick through the list manually, or edit the VBS script slightly as per below;

‘ This code will output all users who are currently NOT inhereting ‘ Security from above. ‘ Writted by Stephen Croft ‘ strtextfile = "objects.txt" Set objFSO = CreateObject("Scripting.FileSystemObject") Set objTextFile = objFSO.OpenTextFile(strtextfile, 1, False, 0) Const SE_DACL_PROTECTED = 0 ‘ set to 0 to enable inheritance Do strobject = objTextFile.ReadLine strobject = Mid(strobject,2,Len(strobject)-2) Set objObject = GetObject("LDAP://" & strObject) Set objntSD = objObject.Get("nTSecurityDescriptor") intNTSDControl = objNtSD.Control If objntSD.Control = 39940 Then intNTSDControl = intNTSDControl And SE_DACL_PROTECTED objntSD.Control = intNTSDControl objObject.Put "nTSecurityDescriptor", objntSD objObject.SetInfo End if Loop Until objtextfile.AtEndOfStream = True

Obviously be careful with this, and don’t hold me responsible if it breaks anything!!!

Windows XP sp2 / Folder Redirection Policies and Internet Explorer Maintenance Policies (phew)

Found an interesting bug regarding XP2 and Group Policies.

When you apply a Internet Explorer policy to a XP SP2 machine, it only works first time. Any subsequent updates to the policy forces it to actually receive “nothing” via GPO.

http://support.microsoft.com/kb/888254 has the fix, but you have to request it.

Also believe that after applying the fix (and the registry fix also) you need to clear out any local profiles stored on the machines.

Fun fun fun 🙂

2003 SBS, New Users, and Recovery Storage Groups.

Come across a semi-interesting “bug” / “feature” this morning in Server 2003 SBS. Old product, I know, but meh who cares.

If you create a new user with the SBS Wizard, whilst you have a Recovery Storage Group configured (even if it is offline), it will default to creating (or attempting to as you will see) the users Exchange box on that SG.

As you try to login as the new user, you will obviously get “unable to access mail folder”, as the SG is (or should) be offline. Viewing the User properties will also show that they are in fact stored in the RSG rather than your First Storage Group.

Fix is easy enough, and comes in two flavours. Hardcore or Wussy.

Wussy Fix

Remove the user you just created. Remove the RSG. Re-create the user. Check s/he is on the FSG. Voila.

Hardcore Fix

Open up ADSI Edit.
Locate the user object, then locate the homeMDB string. Edit, and replace;

Recovery Storage Group

with

First Storage Group

Save, exit, and re-login as user. (Then go delete your RSG).

Personally I prefer the latter, as I always like to ADSI M$’s “features”

Later all.