Active Directory Cookbook for windows server 2003- P9 pps

91
clients finding domain controllers. If you know the site a client is in, you can make a few DNS
queries to determine which domain controller they should be authenticating with.
The resource records a domain controller registers in DNS can be restricted, so querying DNS
may return only a subset of the actual domain controllers. See Recipe 13.14
and Recipe 13.15 for
more information.
3.21.4 See Also
Recipe 3.28 for finding the PDC Emulator via DNS and MS KB 267855 (Problems with Many
Domain Controllers with Active Directory Integrated DNS Zones)
Recipe 3.22 Changing the Preference for a Domain
Controller
3.22.1 Problem
You want a particular domain controller to be used less frequently for client requests or not at all.
This may be necessary if a particular domain controller is overloaded, perhaps due to application
requests.
3.22.2 Solution
You can modify the Priority or Weight fields in SRV resource records by modifying the registry
on the domain controller. Open regedit or regedt32 on the domain controller and browse to
the following key: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. To
configure the Priority, add a REG_DWORD with the name LdapSrvPriority. To configure the
weight, add a REG_DWORD with the name LdapSrvWeight.
After you make the change, the %SystemRoot%\System32\Config\netlogon.dns file should be
updated and the DDNS updates sent to the DNS server within an hour. You can also restart the
NetLogon service to expedite the process.
3.22.3 Discussion
Each domain controller registers several SRV records that clients use as part of the DC locator
process to find the closest domain controller. Two fields of the SRV record let clients determine
which server to use when multiple possibilities are returned. The Priority field is used to dictate
if a specific server or set of servers should always be contacted over others unless otherwise

unavailable. A server with a higher priority (i.e., lower priority field value) will always be
contacted before a server with a lower priority. For example, if DC1 has a SRV priority of 5 and
DC2 has a SRV priority of 10, DC1 will always be used unless it is unavailable.
The Weight field, on the other hand, determines the percentage of time clients should use a
particular server. You can easily calculate the percentage by dividing the weight by the sum of

92
all Weights for servers with the same Priority. If server's DC1, DC2, and DC3 have Weights of 1,
2, and 3, respectively, then DC1 will be contacted one out of six times (1 / (3 + 2 + 1) ), DC2
will be contacted two out of every six times or 1/3 (2 / (3 + 2 + 1) ), and DC3 will be contacted
three out of every six times or 1/2( 3 / (3 + 2 + 1 ) ). Here is an example of how the SRV records
look with these weights:
C:\>nslookup -type=SRV _ldap._tcp.dc._msdcs.rallencorp.com
Server: dns01.rallencorp.com
Address: 171.70.168.183

_ldap._tcp.dc._msdcs.rallencorp.com SRV service location:
priority = 0
weight = 1
port = 389
svr hostname = dc1.rallencorp.com
_ldap._tcp.dc._msdcs.rallencorp.com SRV service location:
priority = 0
weight = 2
port = 389
svr hostname = dc2.rallencorp.com
_ldap._tcp.dc._msdcs.rallencorp.com SRV service location:
priority = 0
weight = 3
port = 389

svr hostname = dc3.rallencorp.com
In certain situations, having this capability can come in handy. For example, the server acting as
the PDC FSMO role owner typically receives more traffic from clients simply because of the
nature of tasks that the PDC FSMO has to handle. If you find a certain server like the PDC
FSMO has considerably higher load than the rest of the servers, you could change the priority or
weight of the SRV records so that it is used less often during the DC locator process. You can
increase the Priority to eliminate its use unless all other domain controllers fail. Modify the
Weight to reduce how often it will be used.
Recipe 3.23 Disabling the Global Catalog Requirement
During a Windows 2000 Domain Login
3.23.1 Problem
You want to disable the requirement for a global catalog server to be reachable when a user logs
into a Windows 2000 domain.
3.23.2 Solution
3.23.2.1 Using a graphical user interface
1. Open the Registry Editor (regedit).
2. In the left pane, expand HKEY_LOCAL_MACHINE
System CurrentControlSet
Control.

93
3. Right-click on LSA and select New Key.
4. Enter IgnoreGCFailures for the key name and hit enter.
5. Restart the server.
3.23.2.2 Using a command-line interface
> reg add HKLM\SYSTEM\CurrentControlSet\Control\LSA\IgnoreGCFailures /ve
> shutdown /r
3.23.2.3 Using VBScript
' This code enables the IgnoreGCFailres registry setting and reboots
strLSA = "HKLM\SYSTEM\CurrentControlSet\Control\LSA\IgnoreGCFailures\"

Set objWSHShell = WScript.CreateObject("WScript.Shell")
objWSHShell.RegWrite strLSA, ""
WScript.Echo "Successfully created key"
WScript.Echo "Rebooting server . . . "
objWSHShell.Run "rundll32 shell32.dll,SHExitWindowsEx 2"
3.23.3 Discussion
With Windows 2000, a global catalog server must be contacted for every login attempt;
otherwise, the login will fail (unless there is no network connectivity, which would result in a
cached login). This is necessary to process all universal groups a user may be a member of.
When a client attempts to authenticate with a domain controller, that domain controller contacts
a global catalog server behind the scenes to enumerate the user's universal groups. See Recipe
7.9 for more details. If you have domain controllers in remote sites and they are not enabled as
global catalog servers, you may run into a situation where users cannot login if the network
connection to the network with the closest global catalog server fails.
Although there is a plausible workaround in Windows Server 2003 Active Directory (see Recipe
3.24), the only option you have available with Windows 2000 is to have the domain controllers
ignore GC lookup failures. You can do this by adding an IgnoreGCFailures registry key under
HKLM\SYSTEM\CurrentControlSet\Control\LSA on the domain controller(s) you want this to
apply to. If you use universal groups in any capacity, having the domain controllers ignore GC
failures can be very problematic because a user's token may not get updated with his universal
group memberships. It may be useful, though, if you have branch-office sites where you cannot
deploy domain controllers.
3.23.4 See Also
Recipe 3.24 for disabling the global catalog requirement for Windows Server 2003, Recipe 7.9
for enabling universal group caching, MS KB 216970 (Global Catalog Server Requirement for
User and Computer Logon), and MS KB 241789 (How to Disable the Requirement that a Global
Catalog Server Be Available to Validate User Logons)

94
Recipe 3.24 Disabling the Global Catalog Requirement

During a Windows 2003 Domain Login

This recipe requires the Windows Server 2003 forest functional level.

3.24.1 Problem
You want to disable the requirement for a global catalog server to be reachable when a user logs
into a Windows 2003 domain.
3.24.2 Solution
See Recipe 7.9 for information on enabling universal group caching, which effectively eliminates
the need to contact a global catalog server during logon.
Recipe 3.25 Finding the FSMO Role Holders
3.25.1 Problem
You want to find the domain controllers that are acting as one of the FSMO roles.
3.25.2 Solution
3.25.2.1 Using a graphical user interface
For the Schema Master:
1. Open the Active Directory Schema snap-in.
2. Right-click on Active Directory Schema in the left pane and select Operations Master.
For the Domain Naming Master:
1. Open the Active Directory Domains and Trusts snap-in.
2. Right-click on Active Directory Domains and Trusts in the left pane and select
Operations Master.
For the PDC Emulator, RID Master, and Infrastructure Master:
1. Open the Active Directory Users and Computers snap-in.
2. Make sure you've targeted the correct domain.
3. Right-click on Active Directory Users and Computers in the left pane and select
Operations Master.
4. There are individual tabs for the PDC, RID, and Infrastructure roles.

95

3.25.2.2 Using a command-line interface
In the following command, you can leave out the /Domain <DomainDNSName> option to query the
domain you are currently logged on.
> netdom query fsmo /Domain:<DomainDNSName>
For some reason, this command returns a "The parameter is incorrect" error on Windows Server
2003. Until that is resolved, you can use the dsquery server command shown here, where
<Role> can be schema, name, infr, pdc, or rid:
> dsquery server -hasfsmo <Role>
3.25.2.3 Using VBScript
' This code prints the FSMO role owners for the specified domain.
' SCRIPT CONFIGURATION
strDomain = "<DomainDNSName>" ' e.g. emea.rallencorp.com
' END CONFIGURATION

set objRootDSE = GetObject("LDAP://" & strDomain & "/RootDSE")
strDomainDN = objRootDSE.Get("defaultNamingContext")
strSchemaDN = objRootDSE.Get("schemaNamingContext")
strConfigDN = objRootDSE.Get("configurationNamingContext")

' PDC Emulator
set objPDCFsmo = GetObject("LDAP://" & strDomainDN)
Wscript.Echo "PDC Emulator: " & objPDCFsmo.fsmoroleowner

' RID Master
set objRIDFsmo = GetObject("LDAP://cn=RID Manager$,cn=system," & strDomainDN)
Wscript.Echo "RID Master: " & objRIDFsmo.fsmoroleowner

' Schema Master
set objSchemaFsmo = GetObject("LDAP://" & strSchemaDN)
Wscript.Echo "Schema Master: " & objSchemaFsmo.fsmoroleowner

' Infrastructure Master
set objInfraFsmo = GetObject("LDAP://cn=Infrastructure," & strDomainDN)
Wscript.Echo "Infrastructure Master: " & objInfraFsmo.fsmoroleowner

' Domain Naming Master
set objDNFsmo = GetObject("LDAP://cn=Partitions," & strConfigDN)
Wscript.Echo "Domain Naming Master: " & objDNFsmo.fsmoroleowner
3.25.3 Discussion
Several Active Directory operations are sensitive, such as updating the schema, and therefore,
need to be done on a single domain controller. Active Directory cannot guarantee the proper
evaluation of these functions in a situation where they may be invoked from more than one DC.
The FSMO mechanism is used to limit these functions to a single DC.

96
There are five designated FSMO roles that correspond to these sensitive functions. A FSMO role
can apply either to an entire forest or to a specific domain. Each role is stored in the
fSMORoleOwner attribute on various objects in Active Directory depending on the role. Table 3-4
contains a list of FSMO roles.
Table 3-4. FSMO roles
Role Description fSMORoleOwner Location
Domain
or
Forest-
wide?
Schema
Processes schema
updates
CN=Schema,CN=Configuration,<ForestDN>
Forest

Domain
Naming
Processes the
addition, removal,
and renaming of
domains
CN=Partitions,CN=Configuration,<ForestDN>
Forest
Infrastructure
Maintains
references to objects
in other domains
CN=Infrastructure,<ForestDN>
Domain
RID
Handles RID pool
allocation for the
domain controllers
in a domain
CN=RidManager$,CN=System,<DomainDN>
Domain
PDC
Emulator
Acts as the
Windows NT master
browser and also as
the PDC for
downlevel clients
and Backup Domain
Controllers (BDCs)

<DomainDN>
Domain
3.25.3.1 Using VBScript
If you want to get the DNS name for each FSMO, you'll need to get the parent object of the
nTDSDSA object and use the dNSHostName attribute, similar to Recipe 3.8. The code for getting
the Schema Master could be changed to the following to retrieve the DNS name of the DC:
set objSchemaFsmo = GetObject("LDAP://cn=Schema,cn=Configuration," &
strForestDN)
set objSchemaFsmoNTDS = GetObject("LDAP://" & objSchemaFsmo.fsmoroleowner)
set objSchemaFsmoServer = GetObject(objSchemaFsmoNTDS.Parent)
Wscript.Echo "Schema Master: " & objSchemaFsmoServer.Get("dNSHostName")

97
3.25.4 See Also
MS KB 197132 (Windows 2000 Active Directory FSMO Roles), MS KB 223346 (FSMO
Placement and Optimization on Windows 2000 Domain Controllers), MS KB 234790 (HOW TO:
Find Servers That Hold Flexible Single Master Operations Roles), and MS KB 324801 (HOW
TO: View and Transfer FSMO Roles in Windows Server 2003)
Recipe 3.26 Transferring a FSMO Role
3.26.1 Problem
You want to transfer a FSMO role to a different domain controller. This may be necessary if you
need to take a current FSMO role holder down for maintenance.
3.26.2 Solution
3.26.2.1 Using a graphical user interface
1. Use the same directions as described in Recipe 3.25 for viewing a specific FSMO, except
target (i.e., right-click and select Connect to Domain Controller) the domain controller
you want to transfer the FSMO to before selecting Operations Master.
2. Click the Change button.
3. Click OK twice.
4. You should then see a message stating whether the transfer was successful.

3.26.2.2 Using a command-line interface
The following would transfer the PDC Emulator role to <NewRoleOwner>. See the discussion to
see about transferring the other roles.
> ntdsutil roles conn "co t s <NewRoleOwner>" q "transfer PDC" q q
3.26.2.3 Using VBScript
' This code transfers the PDC Emulator role to the specified owner.
' See the discussion to see about transferring the other roles.
' SCRIPT CONFIGURATION
strNewOwner = "<NewRoleOwner>" ' e.g. dc2.rallencorp.com
' END CONFIGURATION

Set objRootDSE = GetObject("LDAP://" & strNewOwner & "/RootDSE")
objRootDSE.Put "becomePDC", 1
objRootDSE.SetInfo
3.26.3 Discussion
The first domain controller in a new forest is assigned the two forest-wide FSMO roles (schema
and domain naming). The first domain controller in a new domain gets the other three domain-

98
wide roles. It is very likely you'll need to move the roles around to different domain controllers
at some point. Also, when you need to take down a domain controller that is currently a FSMO
role owner, you'll want to transfer the role beforehand. If you plan to install a hotfix or do some
other type of maintenance that only necessitates a quick reboot, you may not want to go to the
trouble of transferring the FSMO role.
Some FSMO roles are more time critical than others. For example, the PDC Emulator role is
used extensively, but the Schema Master is needed only when extending the schema. If a FSMO
role owner becomes unavailable before you can transfer it, you'll need to seize the role (see
Recipe 3.27).
3.26.3.1 Using a command-line interface
Any role can be transferred using ntdsutil by replacing "transfer PDC" in the solution with one

of the following:
• "transfer domain naming master"
• "transfer infrastructure master"
• "transfer RID master"
• "transfer schema master"
3.26.3.2 Using VBScript
FSMO roles can be transferred programmatically by setting the become<FSMORole> operational
attribute on the RootDSE of the domain controller to transfer the role to. The following are the
available attributes that can be set that correspond to each FSMO role:
• becomeDomainMaster
• becomeInfrastructureMaster
• becomePDC
• becomeRidMaster
• becomeSchemaMaster
3.26.4 See Also
Recipe 3.25 for finding FSMO role holders, Recipe 3.27 for seizing a FSMO role, MS KB
223787 (Flexible Single Master Operation Transfer and Seizure Process), MS KB 255504 (Using
Ntdsutil.exe to Seize or Transfer FSMO Roles to a Domain Controller), and MS KB 324801
(HOW TO: View and Transfer FSMO Roles in Windows Server 2003)
Recipe 3.27 Seizing a FSMO Role
3.27.1 Problem
You need to seize a FSMO role because the current role holder is down and will not be restored.

99
3.27.2 Solution
3.27.2.1 Using a command-line interface
The following would seize the PDC Emulator role to <NewRoleOwner>:
> ntdsutil roles conn "co t s <NewRoleOwner>" q "seize PDC" q q
Any of the other roles can be transferred as well using ntdsutil by replacing "transfer PDC" in
the previous solution with one of the following:

• "seize domain naming master"
• "seize infrastructure master"
• "seize RID master"
• "seize schema master"
3.27.2.2 Using VBScript
Seizing a FSMO role is typically not something you need to do programmatically, but you can
do it. All you need to do is set the fSMORoleOwner attribute for the object that represents the
FSMO role as described in Recipe 3.25 with the distinguished name of nTDSDSA object of the
new role owner.
3.27.3 Discussion
Seizing a FSMO role should not be done lightly. The general recommendation is to seize a
FSMO role only when you cannot possibly bring the previous role holder back online. One
reason that seizing a role is problematic is that you could possibly lose data. For example, lets
say that you extended the schema, and immediately after it was extended the Schema FSMO
went down. If you could not bring that server back online, those extensions may have not
replicated before the server went down. You would need to determine if the any of the schema
extensions replicated and, if not, re-extend the schema. A similar problem can result from losing
the RID FSMO, where duplicate RID pools may be allocated. See Recipe 2.24
for more
information.
3.27.4 See Also
Recipe 3.25 for finding FSMO role holders, Recipe 3.26 for transferring a FSMO role, MS KB
223787 (Flexible Single Master Operation Transfer and Seizure Process), and MS KB 255504
(Using Ntdsutil.exe to Seize or Transfer FSMO Roles to a Domain Controller)

100
Recipe 3.28 Finding the PDC Emulator FSMO Role
Owner via DNS
3.28.1 Problem
You want to find the PDC Emulator for a domain using DNS.

3.28.2 Solution
3.28.2.1 Using a command-line interface
> nslookup -type=SRV _ldap._tcp.pdc._msdcs.<DomainDNSName>
3.28.3 Discussion
The PDC Emulator FSMO role is the only FSMO role that is stored in DNS. Like many of the
other Active Directory-related DNS records, the PDC record is stored as an SRV record under
_ldap._tcp.pdc._msdcs.<DomainDNSName> where <DomainDNSName> is the domain the PDC is in.
3.28.4 See Also
Recipe 3.21 for finding domain controllers via DNS