401 objLink.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 402 Recipe 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) 403 Recipe 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", _ intEnableStrict WScript.Echo "Strict Replication Consistency value set to " & _ intEnableStrict 404 12.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. 405 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 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: <ObjectName>\0CNF:<ObjectGUID> 406 where <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. 407 12.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 replPropertyMetaData attribute is stored as an octet string, so you cannot simply read the attribute to view all of the metadata information. In the VBScript solution, the IADsTool GetMetaData method is a wrapper around the DsReplicaGetInfo method call. This 408 method 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 409 Chapter 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 410 Introduction Active 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 . 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) 403 Recipe. 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. (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