Active Directory Cookbook for windows server 2003- P40 ppt

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