Archive

Archive for the ‘Windows 2003’ Category

SYSVOL holder list wrong on multi-site AD config

September 10, 2010 Leave a comment

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.

Advertisements

LogonHours

July 22, 2009 Leave a comment

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………

December 17, 2008 Leave a comment

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;

200812171530.jpg

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

October 6, 2008 Leave a comment

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";

VBScript0.jpeg

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;

VBScript1.jpeg

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;

VBScript2.jpeg

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)

September 18, 2008 Leave a comment

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.

September 17, 2008 Leave a comment

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.