12.8.4 See Also Recipe 12.2 for viewing the replication status of several domain controllers Recipe 12.9 Enabling Enhanced Logging of Replication Events 12.9.1 Problem You want to ena
Trang 1objLink.Put "replInterval", intNewInterval
objLink.SetInfo
WScript.Echo "Set interval for link " & objLink.Get("cn") & _
" to " & intNewInterval
12.6.3 Discussion
To configure the inter-site replication interval between two sites, you need to set the
replInterval attribute on the site-link object that connects the two sites The value of the attribute should be the replication interval in minutes The default value is 180 minutes (3 hours) and the minimum is 15 minutes
Recipe 12.7 Disabling Inter-Site Compression of
Replication Traffic
12.7.1 Problem
You want to disable inter-site compression of replication traffic
12.7.2 Solution
You need to modify the options attribute of the site-link object that connects the sites you want
to disable compression for Site-link objects are stored in the following location:
cn=IP,cn=Inter-site Transports,cn=Sites,cn=Configuration,<ForestRootDN>
The options attribute is a bit flag In order to disable compression, you must set bit 4, or 0100 in binary If the attribute is currently unset, you can simply set it to 4 If it contains a value, you should see Recipe 4.12 for more information on properly setting bit flags
12.7.3 Discussion
By default, data replicated inter-site is compressed By contrast, intra-site replication traffic is not compressed It is useful to compress inter-site traffic if the traffic is going over a WAN on the assumption that the less traffic the better The trade-off to reduce WAN traffic is increased CPU utilization on the bridgehead servers replicating the data If CPU utilization is an issue on your bridgehead servers and you aren't as concerned about the amount of traffic being replicated, you should consider disabling inter-site compression
12.7.4 See Also
Recipe 4.12 for setting bit flag attributes
Trang 2Recipe 12.8 Checking for Potential Replication
Problems
12.8.1 Problem
You want to determine if replication is succeeding
12.8.2 Solution
The following two commands will help identify problems with replication on a source domain controller:
> dcdiag /test:replications
> repadmin /showrepl /errorsonly
12.8.3 Discussion
For a more detailed report, you can use the Replication Monitor (replmon.exe) The Generate Status Report option will produce a lengthy report of site topology, replication information, and provide details on any errors encountered The Directory Service event log can also be an
invaluable source of replication and KCC problems
12.8.4 See Also
Recipe 12.2 for viewing the replication status of several domain controllers
Recipe 12.9 Enabling Enhanced Logging of
Replication Events
12.9.1 Problem
You want to enable enhanced logging of replication events
12.9.2 Solution
Enable diagnostics logging for 5 Replication Events See Recipe 15.2 for more information
12.9.3 See Also
MS KB 220940 (How to Enable Diagnostic Event Logging for Active Directory Services)
Trang 3Recipe 12.10 Enabling Strict or Loose Replication
Consistency
12.10.1 Problem
You want to enable strict or loose replication consistency
12.10.2 Solution
12.10.2.1 Using a graphical user interface
1 Run regedit.exe from the command line or Start Run
2 Expand HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services
NTDS Parameters
3 If the Strict Replication Consistency value does not exist, right-click on Parameters and select New DWORD Value For the name, enter Strict Replication Consistency
4 In the right pane, double-click on the value and enter 1 to enable strict consistency or 0 to enable loose consistency
5 Click OK
12.10.2.2 Using a command-line interface
To enable strict consistency, run the following command:
> reg add HKLM\System\CurrentControlSet\Services\NTDS\Parameters /v
"Strict[RETURN]
Replication Consistency" /t REG_DWORD /d 1
To enable loose consistency, run the following command:
> reg add HKLM\System\CurrentControlSet\Services\NTDS\Parameters /v
"Strict[RETURN]
Replication Consistency" /t REG_DWORD /d 0
12.10.2.3 Using VBScript
' This code enables strict or loose consistency on the specified DC
' - SCRIPT CONFIGURATION -
intEnableStrict = 1 ' 1 = strict consistency, 0 = loose consistency
strDC = "<DomainControllerName>"
' - END CONFIGURATION -
const HKLM = &H80000002
strNTDSReg = "SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
set objReg = GetObject("winmgmts:\\" & strDC & _
"\root\default:StdRegProv")
objReg.SetDWORDValue HKLM, strNTDSReg, "Strict Replication Consistency", _
Trang 412.10.3 Discussion
Up until Windows 2000 Service Pack (SP) 3, domain controllers followed a loose replication consistency model whereby lingering objects could get reinjected into Active Directory and replicate among all the domain controllers A lingering object is one that was previously deleted, but got reintroduced because a domain controller did not successfully replicate for the duration
of the time defined by the tombStoneLifetime attribute or was restored using a backup that was older than the tombStoneLifetime See Introduction in Chapter 16 for more on the
tombStoneLifetime attribute
Windows 2000 SP2 and earlier domain controllers would replicate the lingering object
throughout the naming context Loose consistency has the potential to cause some security risks since an object you thought was deleted is now back in the forest again
Some post-SP2 hotfixes and SP3 introduced strict replication consistency Under strict
replication, a domain controller will stop replicating with a destination domain controller when it determines that the source is attempting to replicate a lingering object Event id 1084 will get logged in the Directory Service event log indicating that it couldn't replicate the lingering object Although strict replication can halt replication, it is the preferable method and is a good check to ensure lingering objects do not infiltrate your forest For this reason, you must monitor your domain controllers to ensure they are replicating on a regular basis and do not have any 1084 events
12.10.4 See Also
See the Introduction in Chapter 16 for more on the tombStoneLifetime attribute, MS KB
317097 (Lingering Objects Prevent Active Directory Replication from Occurring), and MS KB
314282 (Lingering Objects May Remain After You Bring an Out-of-Date Global Catalog Server Back Online)
Recipe 12.11 Finding Conflict Objects
12.11.1 Problem
You want to find conflict objects that are a result of replication collisions
12.11.2 Solution
12.11.2.1 Using a graphical user interface
1 Open LDP
2 From the menu, select Connection Connect
3 For Server, enter the name of a domain controller (or leave blank to do a serverless bind)
4 For Port, enter 389 or 3268 for the global catalog
5 Click OK
Trang 56 From the menu, select Connection Bind
7 Enter credentials (if necessary) of a user that can view the object
8 Click OK
9 From the menu, select Browse Search
10 For BaseDN, type the base DN from where you want to start the search
11 For Scope, select the appropriate scope
12 For Filter, enter (|(cn=*\0ACNF:*)(ou=*\0ACNF:*))
13 Click Run
12.11.2.2 Using a command-line interface
The following command finds all conflict objects within the whole forest:
> dsquery * forestroot gc attr distinguishedName scope subtree
-filter[RETURN]
"(|(cn=*\0ACNF:*)(ou=*\0ACNF:*))"
12.11.2.3 Using VBScript
' This code finds any conflict objects in a forest
' If the search times out, you may need to change strBase to
' a specific OU or container
' - SCRIPT CONFIGURATION -
strBase = "<GC://" & "<ForrestRootDN>" & ">;"
' - END CONFIGURATION -
strFilter = "(|(cn=*\0ACNF:*)(ou=*\0ACNF:*));"
strAttrs = "distinguishedName;"
strScope = "Subtree"
set objConn = CreateObject("ADODB.Connection")
objConn.Provider = "ADsDSOObject"
objConn.Open
Set objRS = objConn.Execute(strBase & strFilter & strAttrs & strScope)
WScript.Echo objRS.RecordCount & " conflict objects found"
while not objRS.EOF
Wscript.Echo objRS.Fields.Item("distinguishedName").Value
objRS.MoveNext
wend
12.11.3 Discussion
Any distributed multi-master system has to deal with replication collisions, and Active Directory
is no different A collision can occur if an object is created on one domain controller and before that object has time to replicate out, an object with at least the same name, if not identical, is created on a different domain controller So which object wins? With Active Directory, the last object created wins and gets to keep its name while the first object created has to be renamed The format of the renamed object is:
Trang 6where <ObjectName> is the original name of the object, followed by a null termination character, followed by CNF:, followed by the object's GUID
It is good to periodically scan your Active Directory tree to ensure you do not have a lot of conflict objects hanging around It is a bit problematic to find conflict objects in a single query because the filter to find them is not optimized In all three solutions, you have to perform a leading and trailing match pattern search (with *) and this can easily timeout if you have a lot of objects You may want to restrict your initial search to a few containers so the search is quicker Most notably, you'll want to search against your containers that have computer objects because they can frequently generate conflict objects This can occur when a computer account is created, joined to a domain, and then the computer reboots After the computer starts up, if it
authenticates against a domain controller that has not replicated the new computer object, the domain controller will add a new object, which eventually results in a conflict
See MS KB 297083 for more information on how to handle conflict objects after you've
identified them
12.11.4 See Also
MS KB 218614 (Replication Collisions in Windows 2000) and MS KB 297083 (How to Rename
an Object After a Replication Collision Has Occurred)
Recipe 12.12 Viewing Object Metadata
12.12.1 Problem
You want to view metadata for an object The object's replPropertyMetaData attribute stores metadata information about the most recent updates to every attribute that has been set on the object
12.12.2 Solution
12.12.2.1 Using a graphical user interface
1 Open LDP
2 From the menu, select Connection Connect
3 For Server, enter the name of a domain controller or domain that contains the object
4 For Port, enter 389
5 Click OK
6 From the menu, select Connection Bind
7 Enter credentials (if necessary) of a user that can view the object
8 Click OK
9 From the menu, select Browse Replication View Metadata
10 For Object DN, type the distinguished name of the object you want to view
11 Click OK
Trang 712.12.2.2 Using a command-line interface
In the following command, replace <ObjectDN> with the distinguished name of the object for which you want to view metadata:
> repadmin /showobjmeta <DomainControllerName> <ObjectDN>
This command was called /showmeta in the Windows 2000 version of repadmin Also, the parameters are switched in that version, where <ObjectDN> comes before
<DomainControllerName>
12.12.2.3 Using VBScript
' This code displays the meta data for the specified object
' - SCRIPT CONFIGURATION -
strObjectDN = "<ObjectDN>" ' e.g dc=rallencorp,dc=com
strDC = "<DomainControllerName>" ' e.g dc1
' - END CONFIGURATION -
set objIadsTools = CreateObject("IADsTools.DCFunctions")
intRes = objIadsTools.GetMetaData(Cstr(strDC),Cstr(strObjectDN),0)
if intRes = -1 then
Wscript.Echo objIadsTools.LastErrorText
WScript.Quit
end if
for count = 1 to intRes
WScript.Echo count & " " & objIadsTools.MetaDataName(count)
WScript.Echo vbTab & " Version: " & _
objIadsTools.MetaDataVersionNumber(count)
WScript.Echo vbTab & " Last Write: " & _
objIadsTools.MetaDataLastWriteTime(count)
WScript.Echo vbTab & " Local USN: " & _
objIadsTools.MetaDataLocalUSN(count)
WScript.Echo vbTab & " Source USN: " & _
objIadsTools.MetaDataSourceUSN(count)
WScript.Echo vbTab & " Server: " & _
objIadsTools.MetaDataServerName(count)
next
12.12.3 Discussion
Object metadata can be an invaluable source of information when you need to troubleshoot replication problems or find out the last time an attribute was set for a particular object In fact, a quick way to determine if two domain controllers have the same copy of an object is to look at the metadata on both servers for the object If they both have the same metadata, then they have the same version of the object
Unfortunately, the attribute is stored as an octet string, so you cannot
Trang 8method understands the format of the replPropertyMetaData attribute and can return it into a readable format The following data is stored for each attribute that has been set on the object:
Attribute ID
Attribute that was updated
Attribute version
Number of originating writes to the property
Local USN
USN of the property on the local DC This will be the same as the originating DC if the originating DC and local DC are the same
Originating USN
USN stored with the property when the update was made on the originating DC
Originating DC
DC that the originating write was made on
Time/Date
Time and date property was changed in UTC
12.12.4 See Also
See IadsTools.doc in the Support Tools for more information on the IADsTools interface
Trang 9Chapter 13 Domain Name System (DNS)
Introduction
Recipe 13.1 Creating a Forward Lookup Zone
Recipe 13.2 Creating a Reverse Lookup Zone
Recipe 13.3 Viewing a Server's Zones
Recipe 13.4 Converting a Zone to an AD-Integrated Zone
Recipe 13.5 Moving AD-Integrated Zones into an Application Partition
Recipe 13.6 Delegating Control of a Zone
Recipe 13.7 Creating and Deleting Resource Records
Recipe 13.8 Querying Resource Records
Recipe 13.9 Modifying the DNS Server Configuration
Recipe 13.10 Scavenging Old Resource Records
Recipe 13.11 Clearing the DNS Cache
Recipe 13.12 Verifying That a Domain Controller Can Register Its Resource Records Recipe 13.13 Registering a Domain Controller's Resource Records
Recipe 13.14 Preventing a Domain Controller from Dynamically Registering All
Resource Records
Recipe 13.15 Preventing a Domain Controller from Dynamically Registering Certain Resource Records
Recipe 13.16 Deregistering a Domain Controller's Resource Records
Recipe 13.17 Allowing Computers to Use a Different Domain Suffix from Their AD Domain
Trang 10Active Directory is tightly coupled with the Domain Name System (DNS) Both clients and domain controllers use DNS to locate domain controllers in a particular site or that serve a particular function Each domain controller requires numerous resource records to be present in DNS so it can advertise its services as a domain controller, global catalog server, PDC Emulator, etc For a detailed description of each of these records plus much more on DNS, see Chapter 6 in
Active Directory, Second Edition (O'Reilly)
One of the innovative uses of Active Directory is as a store of DNS data Instead of using the antiquated primary and secondary zone transfer method or even the more recent NOTIFY
method (RFC 1996) to replicate zone data between servers, AD-integrated zones store the zone data in Active Directory and use the same replication process used to replicate other data
between domain controllers The one catch with AD-integrated zones is that the DNS server must also be a domain controller Overloading DNS server responsibilities on your domain controllers may not be something you want to do if you plan on supporting a large volume of DNS requests
The Anatomy of a DNS Object
The only time DNS data is stored in Active Directory is if you have a zone that is AD-integrated When using standard primary and secondary zones that are not AD-integrated, the DNS data is stored locally in the file system of each DNS server in zone files If you have an AD-integrated zone under Windows 2000, a container is created in the following location:
cn= <ZoneName> ,cn=MicrosoftDNS,cn=System, <DomainDN>, where <ZoneName> is the name of
the zone For Windows Server 2003, you can use application partitions to store DNS data in an alternate location By default, there are three options:
• Store DNS data on all domain controllers in a domain (only option for Windows 2000)
• Store DNS data on all domain controllers that are DNS servers in the domain
• Store DNS data on all domain controllers that are DNS servers in the forest
The default location for the second option is dc=DomainDNSZones, <DomainDN> and for the
third option, it is dc=ForestDNSZones,<ForestDN> These two locations are actually application
partitions that are replicated only to the domain controllers that are DNS servers in the domain or forest, respectively
Inside the MicrosoftDNS container, is a dnsZone object for each AD-integrated zone Inside of the dnsZone container are dnsNode objects, which stores all resource records associated with a
particular node In the following textual representation of an A record, the dc1.rallencorp.com
name is considered a node (generally the left side of the resource record)
dc1.rallencorp.com 600 IN A 6.10.57.21
There could be multiple resource records associated with the dc1.rallencorp.com name, so
Microsoft decided to implement each distinct name as a dnsNode object The dnsNode object has