mcse exam 70-29 planning implementing and maintaining a windows server 2003 active directory infrastruct phần 5 ppsx

Rename Procedure
STEP Task

4

5
6

7
8
9
10

11
12

Enterprise
Administrator

X
(or Backup Operator)
X

X
X
X

X

X
X

X

X

X

X
X
X

X

X

X

X

Page 321

3

Back up all DCs

Domain
Domain Administrator
Administrator
on a Different Domain
on the Local Domain

4:29 PM

2

Backup, or thirdparty application
Set up the control Copy, and Windows
station
Server 2003 Support
tools setup
Generate the current Copy, and rendom
forest description
/list
Specify the new
rendom /showforest,
forest description
and Notepad or
other plain-text
editor
Generate domain
rendom /upload
rename instructions
Push domain rename dsquery, repadmin
instructions to All
DCs and verify DNS
readiness
Verify readiness
rendom /prepare
of DCs
Execute domain

rendom /execute
rename instructions
Unfreeze the forest rendom /end
configuration
Re-establish external Active Directory
trusts
Domains and Trusts,
or netdom
Fix Distributed File DFS (MMC snap-in),
System (DFS) topology or dfsutil
Fix GPOs and links gpfixup, and
repadmin

Local Administrator
on the Control
Machine

9/4/03

1

Tool(s)

256_70-294_04.qxd

Table 4.6 Required Authorization Levels for Each Step of the Domain


256_70-294_04.qxd

322

9/4/03

4:29 PM

Page 322

Chapter 4 • Working with Forests and Domains

Domain Rename Conditions and Effects
The domain rename procedure is complex, requires a great deal of care in planning and
execution, and should always be tested in a lab environment before performing it on an
operational forest.The time required to go through a complete domain rename operation
varies; the number of domains, DCs, and member computers is directly proportional to the
level of effort required.

NOTE
There is a good reason for caution. Read this entire procedure before attempting
any part of it, including the pre- and post-procedure steps. You might find limitations that preclude the procedure altogether on your network. Consult Microsoft
documentation, read Technet articles, and search for patches, hotfixes, and service
packs that can affect domain renaming and forest restructuring. Every attempt is
made in this chapter to address all pertinent topics and concerns, but issues and
conflicts continue to be exposed over time. Search Microsoft.com for new “Q” articles detailing conditions that might have an affect on this procedure. Most importantly, consider hiring a consultant who has recently and successfully performed a
domain renaming operation.

Before undertaking a domain rename operation, you must fully understand the following conditions and effects.They are inherent in the process and must be dealt with or
accommodated.
I

Each DC requires individual attention. Some changes are not replicated throughout
the Active Directory.This does not mean that every DC requires a physical visit.
Headless management can greatly reduce the level of effort required, depending on
the size and structure of the domain and the number of sites it contains.

I

The entire forest will be out of service for a short period. Close coordination is
required with remote sites, especially those in other time zones. During this time,
DCs will perform directory database updates and reboot. As with other portions
of the procedure, the time involved is proportional to the number of DCs
affected.

I

Any DC that is unreachable or fails to complete the rename process must be
eliminated from the forest for you to declare the procedure complete.

I

Each client workstation requires individual attention. After all DCs have updated
and rebooted, each client running Windows 2000 or Windows XP must be
rebooted two times to fully adapt to the renamed domain.Windows NT workstations must disjoin from the old domain name and rejoin the new domain name, a
manual process that requires a reboot of its own.

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 323

Working with Forests and Domains • Chapter 4
I

The DNS host names of your DCs are not changed automatically by the domain
rename process.To make them reflect the new domain name, you must perform
the domain controller rename procedure on each DC. Having the host name of a DC
decoupled from its domain name does not affect forest service, but the discrepancy will be confusing until you change the names.

I

The DNS suffix of client workstations and member servers will automatically
update through the domain renaming process, but not all computers will match
the DNS name of the domain immediately. As with most portions of this process,
the period of time required is proportional to the number of hosts in the domain.

Domain Rename Preliminary Steps
Prerequisites for the domain rename operation are not trivial.The preparation phase will
ensure that these are in place. Complete all of the preliminary steps in this section before
beginning the rename procedure. If these prerequisites are not taken care of, the domain
rename cannot be successfully performed.

Setting Windows Server 2003 Forest Functionality
The first step in preparing for a domain rename is to ensure that all DCs are running some
edition of Windows Server 2003.This is a prerequisite to raising the forest to the Windows

Server 2003 functional level, which is another preparatory step. See the section Raising the
Functional Level of a Domain and Forest for additional information on functional levels.

Creating Shortcut Trust Relationships
Interaction between domains in your forest is based on the establishment of trusts among
the domains.The Active Directory Installation Wizard creates most of these trusts automatically during the domain creation process.Through the manual creation of shortcut trusts,
you can maintain that interaction after the domains are renamed. It is only necessary if the
forest structure will change as result of the manipulation of the namespace. If you are
renaming a domain in place without changing its relationship with other domains in the
forest, then this step is not needed. Refer to Chapter 5 for the trust-creation procedures.

Pre-Creating a Parent-Child Trust Relationship
While repositioning domains, the necessary shortcut trust relationships must be created
between the domain you want to reposition and its new parent domain.These pre-created
trust relationships substitute for the required parent-child trust relationships that will be
missing in the restructured forest.
For example, suppose you want to restructure the Zoo.net forest, shown in Figure 4.46,
so that the Cat.fish.zoo.net domain becomes a child of the Zoo.net domain.You must
create two one-way, transitive shortcut trust relationships between Cat.fish.zoo.net and
Zoo.net before you can rename the child domain Cat.fish.zoo.net to the child domain

www.syngress.com

323


256_70-294_04.qxd

324

9/4/03

4:29 PM

Page 324

Chapter 4 • Working with Forests and Domains

Catfish.zoo.net.This trust relationship pre-creates the two-way parent-child trust relationship required for the parent and child domains after the rename. Figure 4.46 shows the
before structure, and Figure 4.47 shows the after structure, illustrating the needed shortcut
trust relationships for the new structure.

Figure 4.46 Pre-Creating a Parent-Child Trust Relationship Before the Forest
Restructure

Two
one-way
Shortcut
trusts

Root zoo.net
Domain

Child fish.zoo.net
Domain

Child
Domain
Cat.fish
.zoo.net

Child
Domain
Guppy.fish
.zoo.net

Child
Domain
Angel.fish
.zoo.net

Figure 4.47 Parent and Child Trust After the Forest Restructure

Parent-Child
Trust

Child
Domain
Catfish.zoo.net

Root zoo.net
Domain

Child
Domain

Child
Domain
Guppy.fish
.zoo.net

www.syngress.com

fish.zoo.net

Child
Domain
Angel.fish
.zoo.net


256_70-294_04.qxd

9/4/03

4:29 PM

Page 325

Working with Forests and Domains • Chapter 4

Pre-Creating Multiple Parent-Child Trust Relationships
If you need to restructure a domain that is both a child domain and a parent domain, you
will need to create shortcut trust relationships in two places. For example, suppose you
want to restructure the Zoo.net forest, shown in Figure 4.48, so that the
Striped.angel.fish.zoo.net domain becomes a direct child of Fish.zoo.net, and the
Angel.fish.zoo.net domain becomes a child of Catfish.net.This restructure operation calls
for four shortcut trusts that will become the two parent-child trust relationships for the
new forest. Figure 4.48 shows the before structure, and Figure 4.49 shows the after structure,
illustrating the needed shortcut trust relationships.

Figure 4.48 Pre-Creating Multiple Parent-Child Trust Relationships Before the
Forest Restructure
Tree Root
Trust

Root
Domain

zoo.net

fish.zoo.net
Domain
Catfish.net

Child
Domain
Angel.fish
.zoo.net
Child
Domain

Striped.Angel
.fish.zoo.net

Child
Domain

Pre-Creating a Tree-Root Trust
Relationship with the Forest Root Domain

When you restructure a domain to become a new tree root, you must pre-create two oneway, transitive trust relationships with the forest root domain. For example, suppose you
have a three-level deep tree and you want to shorten it by creating a new tree.This will
move the lowest domain to become a new tree-root domain. Figure 4.50 shows the two
one-way shortcut trusts you create, and Figure 4.51 shows the tree-root trust relationship
after the restructuring. Stripedangel.fish.zoo.net becomes the tree-root domain
Angelfish.net.
www.syngress.com

325


256_70-294_04.qxd

326

9/4/03

4:29 PM

Page 326

Chapter 4 • Working with Forests and Domains

Figure 4.49 Multiple Parent and Child Trusts After the Forest Restructure
Tree Root
Trust

Root
zoo.net
Domain

Catfish.net

Child
Domain

Domain

Fish
.zoo.net

Parent-Child
Trusts
Child
Domain
Striped
.catfish.net

Renamed
Domains

Child
Domain
StripedAngel
.fish.zoo.net

Figure 4.50 Pre-Creating a Tree-Root Trust Relationship Before the Forest
Restructure
Zoo.net
Tree Root

Trust

Shortcut
Trusts

Root
Domain

Fish
.zoo.net
Domain
Catfish.net

Child
Domain

Child
Domain
StripedAngel
.fish.zoo.net

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 327

Working with Forests and Domains • Chapter 4

Figure 4.51 Tree-Root Trust Relationship After the Forest Restructure
Zoo.net
Tree Root
Trust

Root
Domain

Tree Root
Trust

Parent- Child
Tru st
Domain
Angelfish.net

Domain
Catfish.net
Child
Domain
Fish .zoo.net

Preparing DNS
Any time a client requires access to Active Directory, it activates an internal mechanism
called the DC locator for locating DCs through DNS. It uses SRV records for this. If no
SRV records are found in DNS, the access fails.To prevent this failure, before renaming an

Active Directory domain you need to be sure that the appropriate zones exist for the forest
and for each domain.
After you create the DNS zones for the new domain name, your DCs will populate
each zone through dynamic update.This is one of the reasons for the reboot after the execution of the renaming script. Configure the zones to allow secure dynamic updates as a
good security practice. Repeat the zone creation for each domain you plan to rename.
Everything needed to support your existing Active Directory domain must be recreated
to support the domain after renaming. Usually, this is accomplished by mirroring your current DNS infrastructure. As an example, say you want to rename an existing domain called
Labs.dog.com to Retrievers.dog.com. If the zone containing your current SRV resource
records is called Labs.dog.com, you will need to create a new DNS zone called
Retrievers.dog.com.
To analyze and prepare DNS zones for domain rename, first compile a list of DNS
zones that you need to create. Second, create the forward lookup zones using the DNS tool
and configure them to allow dynamic updates.The section Configuring DNS Servers for Use
with Active Directory gives more detailed information.

www.syngress.com

327


256_70-294_04.qxd

4:29 PM

Page 328

Chapter 4 • Working with Forests and Domains

Head of the Class…

328

9/4/03

What Happens to My Distributed
File System When I Rename My Domain?
First, those of you who are not using DFS should think seriously about it. DFS allows
you to redirect specific folders like My Documents out to a high-availability network
location where each user’s files can be backed up and protected. Folder redirection
is a Group Policy extension that allows you to identify a connection between network servers or DFS roots and the local folders that you want to redirect.
What happens to DFS when you rename a domain all depends on how you
have it configured. Think about it. If you use a domain-based DFS path like
\\domainName\DFSRoot, then when the domainName goes away, what happens to
the path?
It goes dead, and everyone’s documents disappear, or become inaccessible. As
far as the users know, all of their data is gone. Your telephone will ring by 5 a.m.
the next day—guaranteed. What does it depend on, and how can you keep your
telephone from ringing? If your Folder Redirection policy specifies the NetBIOS
name of the domain in your domain-based DFS path, and you keep the NetBIOS
name of your domain the same instead of changing it along with the DNS name,
then you’re okay.
What if you want to change your NetBIOS name along with your DNS name?
You could push out a new group policy and move the files to another location.
Temporarily, you could point your folder redirection to a stand-alone DFS path, or
even to a simple server-based share. You should do that a couple of days before the
rename just to be sure it works before shaking things up again—you’ll be too busy
renaming to worry about DFS at that point. Since \\hostName\DFSRoot stays rock
solid through a domain rename, your documents should still be available the next
morning. When things settle down, restore the user files back to your domainbased DFS root and push out the old DFS policy again. That isn’t without risk, but
it keeps things working.

What about home directories and roaming profiles? Same thing. Look at the
pathname you specify in your policy to determine whether they’ll break when you
rename the domain. Make sure to fix those beforehand.

Configuring Member Computers for Host Name Changes
Because Active Directory is tightly integrated with DNS, member computers are designed
to automatically change their primary DNS suffixes when the domain membership of the
computer changes. If you rename the domain, this is treated like a membership change and
the fully qualified DNS host name changes automatically to match.This is the default
behavior, and you can check for it by following the steps in Exercise 4.18.
As an example, if you want to rename an existing domain called Labs.dog.com to
Retrievers.dog.com, the full DNS host name of the member computers of this domain will
also change from host.Labs.dog.com to host.Retrievers.dog.com if the default behavior is
in effect.
www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 329

Working with Forests and Domains • Chapter 4

NOTE
You should check to see if this default behavior has been changed in your domain,
because your rename will fail if you are not using the default setting.

The full DNS name and therefore the primary DNS suffix of a member computer
changes when the domain is renamed if both of the following conditions are true:
I

The primary DNS suffix of the computer is configured to update when domain
membership changes. See Exercise 4.18 for instructions on how to check this setting.

I

The member computer has no group policy applied that specifies a primary DNS
suffix. See Exercise 4.19 for instructions on how to check this setting.

EXERCISE 4.18
USING THE CONTROL PANEL TO
CHECK FOR PRIMARY DNS SUFFIX CONFIGURATION
1. On a member computer, open the System Control Panel.
2. Click Computer Name | Change.
3. Click More, and verify if Change primary domain suffix when
domain membership changes is selected (as shown in Figure 4.52). If
it is, then the computer will automatically adjust to the new primary
DNS suffix.
4. Click OK until all dialog boxes are closed.

Figure 4.52 The System Control Panel, General Tab, More Button

www.syngress.com

329

256_70-294_04.qxd

330

9/4/03

4:29 PM

Page 330

Chapter 4 • Working with Forests and Domains

Determining Whether Group Policy
Controls the Primary DNS Suffix for the Computer
There are a few ways to determine whether Group Policy controls the primary DNS suffix
for the computer. Log on to a representative member computer and do one of the following:
I

Open a command prompt and type gpresult. Look in the output to see if
Primary DNS Suffix is listed under Applied Group Policy objects.

I

Open Active Directory Users and Computers, right-click the computer
object you want to check, and click All Tasks | Resultant Set of Policy
(Logging).

I

Perform the steps in Exercise 4.19. If a value is present in step 4, then the primary
DNS suffix group policy is applied to the computer.

EXERCISE 4.19
USING THE REGISTRY TO CHECK FOR PRIMARY DNS SUFFIX
DOMAIN RENAME COMPUTER READINESS
1. Click Start | Run.
2. Type regedit and click OK.
3. Navigate to HKEY_LOCAL_MACHINE\Software\Policies\
Microsoft\System\DNSclient.
4. If the Primary DNS Suffix key contains a value, then the computer will
not automatically adjust to the new primary DNS suffix.
5. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Tcpip\Parameters.
6. Verify whether the value of REG_RWORD SyncDomainWithMembership
is 0x1. This value indicates that the primary DNS suffix changes when
the domain membership changes. Any other value means that the computer will not automatically adjust to the new primary DNS suffix.

Because the replication effects of member computer names being updated is proportional to the number of computers within the renamed domain, large domains can generate
a large amount of traffic.This replication “storm” is a problem for only the largest deployments. If you think that the resulting replication traffic might pose a problem to your
infrastructure, then consult the section entitled Avoiding Replication Effects of Domain Rename
in Large Deployments later in this chapter.
www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 331

Working with Forests and Domains • Chapter 4

Preparing Certification Authorities
You can continue to support the management of enterprise certificates through a domain
rename when the following requirements have been met beforehand:
I

The Certificate Authority functionality (CA) is not installed on any DCs.

I

All CAs should include both LDAP and HTTP URLs in their Authority
Information Access (AIA) and Certificate Distribution Point (CDP) extensions.

NOTE
If the CA has issued any certificate with only one of these URL types, the certificate
might not work. The steps covered in this chapter might not be sufficient for full
management of your CAs after the domain is renamed, depending on the complexity of your domain configuration. Proceed with the domain renaming only if
you have substantial expertise in handing Microsoft CAs.

If any of the following situations exist, CA management is not supported through the
domain rename process:
I

The CDP or AIA configuration includes only LDAP URLs. Certificates issued by
the CA will no longer be valid because the old LDAP extensions will be wrong
after the domain rename process. As a workaround, you will have to renew the

existing CA hierarchy and all issued End Entity certificates.

I

If you have established any interdomain trust relationships authenticated with
cross-certificates, and they have name constraints, those names might not be valid
after the domain rename operation. As a workaround, you will have to reissue
cross-certificates containing the new name constraints.

I

If RFC 822-style e-mail names () are a property of the user
account, these e-mail names will be incorrect after the domain rename operation.
Additionally, if any certificate template is configured to include RFC 822-type email names within the certificate, those names will no longer be valid.Those
Active Directory accounts should be updated prior to issuing any new certificates.

Finally, check to see if your certificate revocation lists (CRLs) and CA certificates are
going to expire soon. If so, these should all be renewed, reissued, and replicated to all client
machines prior to the rename process.

Avoiding Replication Effects of Domain Rename in Large Deployments
Thousands of computer names being changed at about the same time can cause a replication “storm.” If you are concerned about this replication traffic, this section is for you. If
you can tolerate a significant period of network congestion or saturation, you can skip this
www.syngress.com

331


256_70-294_04.qxd

332

9/4/03

4:29 PM

Page 332

Chapter 4 • Working with Forests and Domains

preparatory step. Note that versions of Windows before Windows XP do not fully support
this approach.
The solution is to rename member computers in smaller batches to lessen the replication traffic problem.You must take steps to limit the number of computers that will be
renamed following domain rename by reversing one of the conditions in Configuring
Member Computers for Host Name Changes earlier in this chapter.
When a computer’s name is changed, an update of the dnsHostName and
servicePrincipalName attributes on its computer account in Active Directory is triggered.This
happens during the reboot after the domain rename. In addition, it triggers an update of the
host (A) and pointer (PTR) DNS resource records in the DNS database.The two events, if
triggered by a large number of computers within a short period of time, might provoke
replication activity that saturates the network. Using Group Policy, you should reconfigure
the default behavior that changes the primary DNS suffix on member computers when a
domain is renamed.
Group Policy triggers the same replication traffic as the domain rename procedure. For
that reason, you must manage the Group Policy application in stages.This is accomplished
by dividing computer objects among several OUs or sites in Active Directory.To temporarily separate some of the computers, you might want to create additional interim OUs.
Generally speaking, only do this for workstations. Allow member servers to change automatically during the reboot, making them the last to change; otherwise, some services
might be affected until the domain rename is complete. If you have a large number of
servers, apply the DNS Suffix Search List policy to workstations first, and then to servers.

Before Applying Group Policy
The purpose of applying this group policy is to avoid replication and DNS update traffic
caused by the automatic update of the primary DNS suffix on all member computers following a domain rename. Use Group Policy to revise the primary DNS suffix of all computers in stages to the new domain name before the procedure.That way, domain
computers are manually updated and already have the correct primary DNS suffix at the
time you perform the domain rename. After you apply the group policy, the DNS suffix of
member computers will not match the DNS name of the domain for some period.To
handle this problem, the first step is to configure the domain to accept the possible names
that the DNS suffix can have. Make sure you do this before applying the policy.
The default primary DNS suffix is the name of the domain itself.To make a new one
available to member computers, you must first make the DNS suffixes known at the
domain level.You accomplish this by editing the msDS-AllowedDNSSuffixes attribute on the
domain object to contain these additional DNS domain names.This multivalued attribute
contains a list of valid DNS suffixes for member computers of the Active Directory
domain.The msDS-AllowedDNSSuffixes attribute should not contain the same values in
more than one domain.
At the same time, configure the DNS Suffix Search List group policy on all systems to
contain the old primary DNS suffix, new primary DNS suffix, and any parent suffixes of
www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 333

Working with Forests and Domains • Chapter 4

the old and new primary DNS suffixes. For example, if the old DNS suffix of a domain was
Cat.fish.zoo.com and the new name will be Catfish.naturepreserve.com, the DNS Suffix
Search List should contain the following suffixes:
I

Cat.fish.zoo.com

I

Catfish.naturepreserve.com

I

Fish.zoo.com

I

Naturepreserve.com

Note that the versions of Windows before Windows XP do not support the Group
Policy setting for the DNS Suffix Search List.To perform this procedure, all DCs in the
domain must be running Windows Server 2003, and a subdomain must exist in DNS for
each new DNS suffix that you add. Use ADSI Edit, one of the Windows Server 2003
Support Tools, to modify the msDS-AllowedDNSSuffixes attribute value on the domain object
in Active Directory as shown in Exercise 4.20. Do this for each domain whose name is
going to change.

EXERCISE 4.20
USING ADSI EDIT TO ADD DNS
SUFFIXES TO MSDS-ALLOWEDDNSSUFFIXES

1. Click Start | Programs | Windows Server 2003 Support Tools | Tools
| ADSI Edit.
2. In the scope pane, right-click ADSI Edit and select Connect to.
3. Under Computer, click Select or type a domain or server name, and
then click OK.
4. Double-click the domain directory partition for the domain you want to
modify.
5. Right-click the domain container object, and select Properties.
6. In the Attributes box, on the Attribute Editor tab, double-click the
msDS-AllowedDNSSuffixes attribute.
7. In the Multi-valued String Editor dialog box, in the Value to add
field, type a DNS suffix and then click Add.
8. Repeat this process for all the DNS suffixes that you need for the
domain, and click OK.
9. Click OK to close the Properties dialog box.
10. Repeat steps 2 through 9 for any additional domains that are being
renamed.

www.syngress.com

333


256_70-294_04.qxd

334

9/4/03

4:29 PM

Page 334

Chapter 4 • Working with Forests and Domains

Using Group Policy to Predefine the
Primary DNS Suffix Prior to Domain Rename
To prepare for the application of Group Policy, you need to create groupings of member
computers for incremental rollout. Perform the following steps for each domain to be
renamed.
1. Estimate the largest number of computers that can be renamed in your environment without adverse affects. Microsoft’s recommendation is to define groups of
1000 or less for a normal healthy LAN environment. Adjust this number for local
conditions.
2. Define rollout groups of the chosen size.
3. Create a schedule, leaving sufficient time between applications of Group Policy to
allow replication to occur. Make sure the updated dnsHostName and
servicePrincipalName attributes on computer accounts and replication of the DNS
records of the renamed computers are completed during each period before the
next group begins.
4. Apply Group Policy to the rollout groups according to the schedule. Make sure all
groups receive the policy before renaming the domain. Note that computers must
be rebooted for the host name change to take effect.

NOTE
Do not apply this policy to DCs. They will be renamed later in a separate procedure.

5. After the domain rename procedure is complete, and after all computers have
rebooted, disable the temporary DNS Suffix group policy.

Performing the Rename Procedure

This section presents step-by-step procedures for executing the domain rename operation in
your forest. Be sure to review and complete the preliminary procedures before performing
any steps in this section.There will be a short period of service interruption in your Active
Directory forest during this procedure. For the most part, this occurs while all the DCs in the
forest are automatically rebooting.The applicable section of the procedure tells you when to
expect it. Except for this short interruption, the Active Directory service should continue to
be available and function normally throughout the rest of the procedure.
A certain level of proficiency is expected from those performing this procedure. Do not
attempt it unless you have considerable experience with Active Directory, CAs, domain and
forest maintenance procedures and troubleshooting, and are comfortable with the administrative tools involved. Although not all steps require the same level of authority, you should

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 335

Working with Forests and Domains • Chapter 4

have access to the group memberships listed in Table 4.6 to perform the procedure as a
whole.These include:
I

Enterprise Admins group in the forest

I

Domain Admins group in trusted domains

I

Domain Admins group in trusting domains

I

Local Administrators group on the control station

Each step should be completed before going on to the next. Many steps will fail or have
unpredictable results if performed out of order.This especially applies to the freezing and
unfreezing of the forest configuration. During this time, the forest must be quiescent.You must
not make any changes to the Active Directory such as adding or removing domains, DCs,
directory partitions, or trust relationships other than those called for in the procedure itself.
When the rename process is complete, you can press forward with those types of activities.

STEP 1: Back Up All DCs
Simply put; make sure you accomplish a full backup of the system state of every DC in the
entire forest. Get complete backups of CAs, DFS roots, FSMO masters, and other commonuse and infrastructure items. Check the logs of every backup for any errors that might have
occurred, and perform one or more restores on test systems to ensure your backup processes
are sound.

STEP 2: Prepare the Control Station
Pick a conveniently located server that meets the following requirements:
I

Must be a member of one of the domains that will be renamed.

I

Must be a member server, not a DC, running Windows Server 2003 Standard
Edition,Windows Server 2003 Enterprise Edition, or Windows Server 2003
Datacenter Edition.

I

Must have available the installation CD for the version of Windows installed on
the control station.

This server will function as the administrative control station for the entire domain
rename operation.You will be running and controlling all rename procedures from this station. Special tools will need to be installed on the local disk, and scripts created and edited
here. Although you do have to contact each DC in the forest, you will reach them remotely
from this station.
Perform Exercise 4.21 to install Windows Server 2003 Support Tools from the OS CD.

www.syngress.com

335


256_70-294_04.qxd

336

9/4/03

4:29 PM

Page 336

Chapter 4 • Working with Forests and Domains

EXERCISE 4.21
SETTING UP THE CONTROL STATION WITH
THE REQUIRED TOOLS FOR THE DOMAIN RENAME OPERATION
1. Log on to the control station with at least local administrator rights.
2. Create a directory named X:\RenameTools on a local disk drive, where X
is a local drive letter.

NOTE
You will be executing all rename tools from within this directory. Give it a name
you will be comfortable with, but that will alert other administrators as to what it
is used for.

3. Insert the Windows Server 2003 Standard Edition, Windows Server
2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition
operating system CD into the CD-ROM drive.
4. Open a command prompt and copy the files from the valueadd directory, shown here with the CD-ROM in drive letter G. Use the command
copy G:\valueadd\msft\mgmt\DomainRename\*.* X:\ RenameTools.
5.

Verify that rendom.exe and gpfixup.exe are present in your working
directory on the control station.

6. Browse to the G:\Support\Tools directory, and double-click Setup to
install the Windows Server 2003 Support tools.
7. Verify that repadmin.exe and dfsutil.exe are installed on the

control station.

STEP 3: Document the Current Forest
In this step, you will use the rendom utility to generate a description of your current forest
structure as an XML-encoded file. It will contain a list of all the domain directory partitions as well as your application directory partitions within the forest.This is the baseline
that you start from, and you will modify this file later.
If you want to use authorization other than the account you are logged on as, use alternate credentials with the /user and /pwd command-line switches of rendom.exe. Perform
Exercise 4.22 to generate the baseline forest description.

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 337

Working with Forests and Domains • Chapter 4

EXERCISE 4.22
GENERATING THE CURRENT FOREST DESCRIPTION FILE
1. Log on to the control station with Enterprise Administrator rights.
2. Open a Command Prompt, change to the RenameTools directory, and
type rendom /list.
3. Type the following command to save a copy of the forest description
file for future reference: copy domainlist.xml domainlist-save.xml

The /list option of the rendom.exe creates an XML-encoded file named domainlist.xml
in the current directory. It contains a textual description of your current forest structure,
including a list of all the application directory partitions and domain directory partitions
within your forest.You will find an entry for each of these domain and application directory
partitions bounded by the <Domain></Domain> XML tags, as shown in Figure 4.53. Each
entry contains naming data that includes the object GUID of the partition root object, the
DNS name of the domain or application directory partition, and the NetBIOS name of the
domain. An application directory partition does not have a NetBIOS name.
In the example, the domainlist.xml file shows the structure of a forest containing two
domains called Zoo.net and Fish.zoo.net with NetBIOS names of ZOO and FISH, respectively.Three other entries appear, corresponding to the application directory partitions used
by the Active Directory integrated DNS service.These application directory partitions must
also be renamed:
I

DomainDnsZones.fish.zoo.net

I

DomainDnsZones.zoo.net

I

ForestDnsZones.zoo.net

The entry for an application directory partition is annotated with an XML comment in
the form:
<!— PartitionType:Application —>
The entry for the root domain of the forest is also annotated with an XML comment
in the form:
<! — ForestRoot —>

For this procedure, the critical fields are those bounded by the
<DNSname></DNSname> and <NetBiosName></NetBiosName> tags.

www.syngress.com

337


256_70-294_04.qxd

338

9/4/03

4:29 PM

Page 338

Chapter 4 • Working with Forests and Domains

Figure 4.53 Forest Description File, domainlist.xml, Generated by Rendom.exe
<?xml version = "1.0"?>
<Forest>
<Domain>
<!— PartitionType:Application —>
<Guid>3dacd6ab-d4e8-b94e-63b9-8bacc5d5e10b</Guid>
<DNSname>DomainDnsZones.fish.zoo.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>

<Domain>
<Guid>73cfaaec-faa6-4732-a851-c8050763fab0</Guid>
<DNSname>fish.zoo.net</DNSname>
<NetBiosName>FISH</NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<!— PartitionType:Application —>
<Guid>4d1c9e17-18bb-c642-1f4c-acc1be13d117</Guid>
<DNSname>ForestDnsZones.zoo.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<!— PartitionType:Application —>
<Guid>4d1c9e17-18bb-c642-1f4c-acc1be13d117</Guid>
<DNSname>DomainDnsZones.zoo.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<! — - ForestRoot —>
<Guid>73cfaaec-faa6-4732-a851-c8050763fab0</Guid>
<DNSname> zoo.net</DNSname>
<NetBiosName>ZOO</NetBiosName>
<DcName></DcName>
</Domain>
</Forest>

www.syngress.com

256_70-294_04.qxd

9/4/03

4:29 PM

Page 339

Working with Forests and Domains • Chapter 4

STEP 4: Design the New Forest
From the preliminary procedures, your new forest structure should be well documented. In
this step, you will overlay the new structure over the old one as described by the domainlist.xml file generated in step 3.You will use a text editor to edit the domainlist.xml file and
replace your old domain names with new ones.You must also edit the names of application
directory partitions in the same way.When you rename an Active Directory domain, the
corresponding DNS-specific application directory partition must also be renamed, if you are
using Active Directory-integrated DNS. If it is not, new DNS servers added to the network will
not automatically load the DNS zones stored in the DNS-specific application directory
partition and will not function properly.
Use a simple text editor such as Notepad to make the changes. Remember that at this
time you can change the NetBIOS name of any domain, the DNS name of any domain, or
both. In addition, take care to change the names of any child domains affected by a
renamed parent. Review all name changes for well-formed characteristics as described in the
Domain Rename Limitations in a Windows 2003 Forest section in this chapter.

WARNING
Double-check this step, preferably with more than one person to ensure that the
changes are complete and correct. These are the actual names that will be implemented, and any typographical or hierarchical error could translate into a nonfunctional forest or domain. If your target structure is not what you intended, you

must perform the entire domain rename procedure again.

Here are some guidelines for name changes:
I

Change the DNS name from old to new, which is the field bounded by the tags
<DNSname></DNSname>.

I

Change the NetBIOS name from old to new, which is the field bounded by the
tags <NetBiosName></NetBiosName>.

I

Change the domain-level DNS Application Partition name from old to new,
which is the DomainDnsZones.<domain DNS name> field bounded by the tags
<DNSname></DNSname>.

I

Change the forest-level DNS Application Partition name from old to new, which
is the ForestDnsZones.<forest DNS name> field bounded by the tags
<DNSname></DNSname>.

I

Do not change the GUID represented in the field bounded by the
<Guid></Guid> tags.

www.syngress.com

339


256_70-294_04.qxd

340

9/4/03

4:29 PM

Page 340

Chapter 4 • Working with Forests and Domains

Review Figure 4.54 for a sample of what the domainlist.xml file would look like after
the following restructuring design overlay. In this case, both DNS and NetBIOS names
were changed:
I

The top-level DNS name of Zoo.net has been changed to the more politically
correct name of Naturepreserve.net, while its child domain of fish.zoo.net has
been changed to Aquatics.naturepreserve.net.

I

The NetBIOS name of ZOO has been changed to PRESERVE, while the
NetBIOS name of its child domain has been changed from FISH to AQUATICS.

I

The domain-level DNS application partition name has been changed from
DomainDnsZones.fish.zoo.net to DomainDnsZones.aquatics.naturepreserve.net.

I

The domain-level DNS application partition name has been changed from
DomainDnsZones.zoo.net to DomainDnsZones.naturepreserve.net.

I

The forest-level DNS Application Partition name has been changed from
ForestDnsZones.zoo.net to ForestDnsZones.naturepreserve.net.

I

The GUID fields have not been modified.

I

No NetBIOS names have been assigned to any PartitionType:Application.

NOTE
If you have a Microsoft TAPI dynamic directory for an Active Directory domain, you
might have application partitions for the TAPI application data. There is normally
one TAPI-specific application directory partition for each domain. When you
rename an Active Directory domain, the corresponding TAPI-specific application
directory partition is not renamed automatically. If they exist, you should change

those as well.

Figure 4.54 Forest Description File, domainlist.xml, Customized for the New
Forest Design
<?xml version = "1.0"?>
<Forest>
<Domain>
<!— PartitionType:Application —>
<Guid>3dacd6ab-d4e8-b94e-63b9-8bacc5d5e10b</Guid>
<DNSname>DomainDnsZones.aquatics.naturepreserve.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>

Continued

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 341

Working with Forests and Domains • Chapter 4

Figure 4.54 Forest Description File, domainlist.xml, Customized for the New
Forest Design

</Domain>
<Domain>
<Guid>73cfaaec-faa6-4732-a851-c8050763fab0</Guid>
<DNSname>aquatics.naturepreserve.net</DNSname>
<NetBiosName>AQUATICS</NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<!— PartitionType:Application —>
<Guid>4d1c9e17-18bb-c642-1f4c-acc1be13d117</Guid>
<DNSname>ForestDnsZones.naturepreserve.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<!— PartitionType:Application —>
<Guid>4d1c9e17-18bb-c642-1f4c-acc1be13d117</Guid>
<DNSname>DomainDnsZones.naturepreserve.net</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<! — - ForestRoot —>
<Guid>73cfaaec-faa6-4732-a851-c8050763fab0</Guid>
<DNSname> naturepreserve.net</DNSname>
<NetBiosName>PRESERVE</NetBiosName>
<DcName></DcName>
</Domain>
</Forest>

Rendom.exe will display the new forest structure in the domainlist.xml file in a userfriendly format using text indentation to reflect the domain hierarchy using the /showforest
option. Type the command rendom /showforest from a command prompt in the
Renametools directory after each change to the domainlist.xml file to verify the forest
structure. Recheck the contents of this file after every edit until you are sure it is correct.

www.syngress.com

341


256_70-294_04.qxd

342

9/4/03

4:29 PM

Page 342

Chapter 4 • Working with Forests and Domains

STEP 5: Draft Domain Rename Instructions
Now that you have built a definition of your new forest structure, it is time to generate the
domain rename instructions that will implement the change.These instructions will execute
individually and remotely on each DC in the forest. Not surprisingly, the Domain Naming
Master plays a central role in the renaming process.The rendom.exe utility creates the specially formatted scripts, containing a sequence of directory updates, and writes them to the
msDS-UpdateScript attribute on the Partitions container object in the configuration directory partition on the Domain Naming Master for the forest.
The new forest description must be available as the XML-encoded file domainlist.xml,
which you created by editing the original forest description file in the previous step. Follow

these steps to create the domain rename instructions.
1. Open a command prompt, and change to the RenameTools directory.
2. Enter the command rendom /upload.
3. Verify the existence of the state file dclist.xml in the RenameTools directory and
that it contains an entry for every DC in your forest.
In addition to generating the domain rename instructions and uploading them into the
Active Directory, the rendom /upload command also generates a state file called dclist.xml and
writes it to the current directory of RenameTools. Rendom uses this state file to track the
progress and state of each DC in the forest.This tracking continues throughout the
remaining steps of the domain rename procedure. Refer to Figure 4.55 for an example of
the dclist.xml file. It contains the states for two DCs in the Zoo.net domain called DC1
and DC2, and two DCs in the Fish.zoo.net domain called DC3 and DC4.

Figure 4.55 Examining the dclist.xml State File Used for Tracking the Progress of
Domain Rename
<?xml version = "1.0"?>
<DcList>
<Hash>zzzzzzzz</Hash>
<Signature>zzzzzzzz</Signature>

<DC>
<Name>DC1.zoo.net</Name>
<State>Initial</State>
<LastError>0</LastError>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>

Continued

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 343

Working with Forests and Domains • Chapter 4

Figure 4.55 Examining the dclist.xml State File Used for Tracking the Progress of
Domain Rename
</DC>
<DC>
<Name>DC2.zoo.net</Name>
<State>Initial</State>
<LastError>0</LastError>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
<DC>
<Name>DC3.fish.zoo.net</Name>
<State>Initial</State>
<LastError>0</LastError>

<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
<DC>
<Name>DC4.fish.zoo.net</Name>
<State>Initial</State>
<LastError>0</LastError>
<Password />
<LastErrorMsg />
<FatalErrorMsg />
<Retry></Retry>
</DC>
</DcList>

Every DC in the forest must have an entry in the dclist.xml state file.The state of each
DC is delineated by the tags <State></State>. At this point in the rename process, all DCs
are initialized to the Initial state. As the procedure progresses, these states will change.

www.syngress.com

343


256_70-294_04.qxd

344

9/4/03

4:29 PM

Page 344

Chapter 4 • Working with Forests and Domains

STEP 6: Push Instructions to DCs
In Exercise 4.23, you will trigger a forced Active Directory replication.This pushes out the
domain rename instructions that you previously uploaded to the Domain Naming Master
to all DCs in the forest.Then, you should verify that the DC Locator SRV records registered in DNS by each DC for the new domain names have replicated to all DNS servers
that are authoritative for those records.

NOTE
You do not have to force replication, but it will accelerate the replication of the
changes to the Partitions container in the configuration directory partition to all
DCs in the forest. Alternately, you can wait for replication to complete according to
the delay characteristics and replication intervals of your forest.

EXERCISE 4.23
FORCING THE SYNCHRONIZATION OF CHANGES
MADE TO THE DOMAIN NAMING MASTER
1. Open a command prompt, and change to the RenameTools directory.
2. Type the command repadmin /syncall /d /e /P /q
DomainNamingMaster. Note that DomainNamingMaster is the DNS
host name of the current Domain Naming Master for the forest.

NOTE
Use the dsquery utility to determine which host is the Domain Naming Master, or
perform Exercise 4.12. In addition, be aware that the repadmin command-line

options are case sensitive.

It is critical that all DCs successfully replicate before continuing. If repadmin completes
successfully, the Domain Naming Master DC will have replicated to every other DC in the
forest. If you get an error for some of the DCs in the forest, you must try again until all
DCs in the forest have successfully received the changes from the Domain Naming Master.

www.syngress.com


256_70-294_04.qxd

9/4/03

4:29 PM

Page 345

Working with Forests and Domains • Chapter 4

STEP 7:Verify DNS Readiness
During domain rename, the Net Logon service of each DC pre-publishes the SRV resource
records to the authoritative DNS servers associated with their new domain name.The DC
Locator will malfunction if these are not successfully published. Other records must also be
in place for authentication and replication to take place. Refer to Exercise 4.24 to verify
that the various DNS records for the new domain names were successfully created.

NOTE
Do not, under any circumstances, proceed with domain rename if any of the DNS
records listed in Table 4.7 are missing. They are all required for normal operation of

the forest.

EXERCISE 4.24
VERIFYING THE DNS SERVICE LOCATOR RECORDS
1. Click Start | Programs | Administrative Tools | DNS to start the DNS
administrator console.
2. Expand the server name.
3. Expand the Forward Lookup Zones.
4. Expand the domain you want to verify.
5. Verify that the DNS records listed in Table 4.7 are present for all your
DCs within each domain. These records are crucial to the operation of
the domain.

Table 4.7 Required SRV Resource Records
Location of DNS Record

Type
of Record

DsaGuid._msdcs.DnsForestName

CNAME

Purpose
There must be one CNAME record
pertaining to every DC in all
authoritative DNS servers. Without it,
replication will not take place from
that DC.

Continued

www.syngress.com

345