Professional Documents
Culture Documents
Administeringad ch8
Administeringad ch8
Books
Contents
Chapter 8 Special Domain Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
FSMO Role Review and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Knowing Role Holders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Dumpfsmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Replmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Transferring Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Role Transfer Through the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Role Transfer Through the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Seizing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Cleaning Up the AD Metabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Metabase Clean-Up Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Renaming DCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
DC Rename Through the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
DE Rename Through the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Renaming Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Domain Rename — A History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Windows 2003 Domain Rename — An Alternative . . . . . . . . . . . . . . . . . . . . . . . . . 165
Windows 2003 Domain Rename — How To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Thank You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
147
Chapter 8:
In this final chapter, I discuss administrative tasks that involve operations I hope you seldom – if ever
– need to perform. These useful and occasionally necessary operations can be hazardous to the
overall health of Active Directory (AD) if they’re not handled perfectly. However, should you be
called upon, you’ll want to know how to perform these tasks. I recommend that you attempt these
operations first in a test lab – before you’re called to active (directory) duty.
Among the administrative tasks I cover are working with server roles, cleaning up the AD
metabase, renaming domain controllers (DCs), and renaming domains. Because the powerful
operations you’ll use for these tasks involve specific dangers, you need to know how to perform the
operations safely.
Figure 8.1
RID – the last part of the user’s SID
• Infrastructure Master – Each domain has one Infrastructure Master. The Infrastructure Master’s job
is to help translate group memberships. This function kicks into gear when accounts from one
domain are members of groups in another domain.
Each forest role also resides in a specific place and controls specific functions:
• Schema Master – Each forest has one Schema Master. The Schema Master, as I discussed in
Chapter 5, controls all access to the schema. If you extend the schema, the entire forest must
comply because the forest has only one schema.
• Domain Naming Master – Each forest has one Domain Naming Master. The Domain Naming
Master ensures that no two domains with the same name become members of the forest.
Dumpfsmos
One way to check role ownership is to use the Dumpfsmos command, which you can find in the
Microsoft Windows Server 2003 Resource Kit. Use the syntax
dumpfsmos <any Domain Controller>
and the results will reveal which roles reside on which DCs, as Figure 8.2 shows.
Figure 8.2
The Dumpfsmos command
Replmon
You can also discover which roles reside on which DCs through Active Directory Replication Monitor
(Replmon), which I discussed in Chapter 7. Simply add any DC to Replmon’s list of DCs, then
examine the DC’s Server Properties. On the FSMO Roles tab, you’ll get the rundown that Figure 8.3
shows.
Figure 8.3
Locating FSMO roles through Replmon
Transferring Roles
If you need to take a server that holds a role down for maintenance, you should be able to transfer
its role to another DC. If the DC’s role is a domain-specific role (e.g., RID Master, PDC Emulator,
Infrastructure Master), you can transfer the role to another DC in the domain. If the DC’s role is a
forest-specific role (e.g., Domain Naming Master, Schema Master), you can transfer the role to another
DC in any domain. You can perform role transfers two ways: through the GUI and through the
command line.
• To transfer the Infrastructure Master role, you use the Active Directory Users and Computer
console.
You can transfer the first three roles listed through the Active Directory Users and Computers console,
as Figure 8.4 shows.
Figure 8.4
Changing FSMO role owners through the Active Directory Users and Computers console
• To transfer the Schema Master role, you use the Microsoft Management Console (MMC) Active
Directory Schema snap-in.
• To transfer the Domain Naming Master role, you use the Active Directory Domains and Trusts
console.
You perform these steps through commands inside Ntdsutil. For example, if you need to transfer
the RID Master role from VMServer2 to VMServer5, you would type the following sequence of
commands:
ntdsutil
to go to fsmo maintenance
connections
You’ll be asked whether you’re sure you want to perform the transfer. After you answer affirmatively,
the RID Master should be transferred to the target server, as Figure 8.5 shows (highlighted in red).
Figure 8.5
Transferring a role
Seizing Roles
Should a server go down while it owns a role, you might have to seize the role. Seizing a role
basically draws a line in the sand that says, “I’ve tried multiple times and can’t get the server back
online. The server from which I’m seizing the role will never come back online again.”
d Caution
Seize a role only if you’re certain that you must.
The procedure for seizing a role involves Ntdsutil and resembles performing a transfer with that
utility. Again, I’ll begin with a brief overview of the sequence involved in the process. You would
1. run the Ntdsutil tool
2. use the Connect command to connect to the server on which you want the role or roles to
finally reside
3. seize the role or roles you need to relocate
4. confirm that you want to perform the seize
5. exit the tool
You perform this sequence through commands inside Ntdsutil. For example, if you must seize
the PDC Emulator role from VMServer5 and relocate the role on VMServer2, you would type the
following sequence of commands:
ntdsutil
to go to fsmo maintenance
connections
You’ll be asked to verify that you want to perform the seize operation. After you answer
affirmatively, the system first attempts a “safe transfer” (which I described in the Transferring Roles
section) before it performs the seize operation. If the transfer fails (presumably because the server is
dead), you must seize the role – in this case, the PDC Emulator role – and place it on the target
server, as Figure 8.6 shows (highlighted in red).
Figure 8.6
Seizing a role
Figure 8.7
A DC that needs to be removed
Once again, you perform this procedure through commands inside Ntdsutil. In this example, I’m
removing VMServerF. The commands you would type are
ntdsutil
to return to the metadata cleanup prompt (In the example that Figure 8.8 shows, I abbreviated the
command Quit to the letter “q.”)
select operation target
to display all the domains to which you have access and automatically assign each of them a number
select domain <number>
to display all the sites in the forest and assign each of them a number
select site <number>
to display all the DCs for the site and assign each of them a number
select server <number>
Figure 8.8 shows the complete series of commands for removing a server. The highlighted
section shows the final removal of VMServerF.
Figure 8.8
Removing VMServerF
you see the dialog box that Figure 8.9 displays. (Note that this dialog box appears before the final
lines of text in the screen shot that Figure 8.8 shows.)
Figure 8.9
Server Remove Confirmation dialog box
The DC should be successfully removed. You need to return to the Active Directory Sites and
Services console and delete the object. You also need to load the Active Directory Users and
Computers console and delete the object.
j Tip
According to Microsoft, after you delete a DC, you can add a DC that has the same name as
the DC you’ve deleted. However, I recommend that you not do so. I’ve seen directory
corruption occur when names are reintroduced.
Renaming DCs
Renaming a server or DC should be easy. However, to rename a server in Windows NT, you must
remove the server’s computer account from the domain, which adds the server to a workgroup, then
reboot. You then rename the server and reboot again. You then rejoin the server to the domain, and
– oh, yes – reboot again!
With NT DCs, the process is worse. Basically, you can’t rename an NT DC without reformatting
the disk and starting over.
Win2K lets you rename a server from the Computer Name tab in System Properties. As long as
the server is online, the corresponding computer account in AD is changed to reflect the name
change.
To rename a Win2K DC, you run Dcpromo to demote the DC to a garden variety server, reboot,
then rename the server and reboot. You run Dcpromo again to promote the server to DC and – you
guessed it – reboot again.
Windows 2003 changes things a bit. To rename a DC, you no longer begin by undoing its DC
status. That is, you don’t need to run Dcpromo and first demote the DC to server. You can rename a
DC two ways: through the GUI or through the command-line.
Figure 8.10
Renaming a DC through the GUI
j Tip
Figure 8.10 displays a warning you see when you use the GUI to rename a DC.
After you’ve read the warning and are ready to proceed, click OK to continue. You’ll be
prompted to change the name, enter administrative credentials, and restart the DC. After the records
change in DNS, the DC will be fully renamed and available to service requests.
In the example that Figure 8.11 shows, I’m adding an alternate name (rename5) for the DC
VMServer5.
Figure 8.11
Deploying Netdom to rename a DC
After you reboot the computer, you should start to see new DNS (A) records populate for the new
name in DNS, as Figure 8.12 shows.
Figure 8.12
DNS (A) records for both server names
DNS should now have (A) records for both server names. You should also be able to ping and
perform Nslookups for the computer by either name, as Figure 8.13 shows.
Figure 8.13
Finding both names with Ping and Nslookup
When you’re ready to expunge the old name, you can use the syntax
netdom computername <newname> /remove:<oldname>
Renaming Domains
In the domain arena, Windows 2003 brings a totally radical concept to the table. That is, you can
rename domains as well as perform rudimentary pruning and grafting within AD. However, before I
discuss the new domain rename option, let me set the context by taking you back in time.
you’ll find the steps to do so. However, when you rename NT domains, some serious cautions apply,
and, to some degree, Microsoft has never truly support the renaming.
Win2K offers no real way to rename domains. If you want to rename a domain, you have to
demote every DC in the domain to server, then promote your first server back to DC – and introduce
a new name. In addition, you can rename a server only if the server is at the end of a domain tree –
not if it’s anywhere in the middle. Also, when you rename the domain, you lose all your user
accounts in that domain, and you have to recreate them from scratch.
Figure 8.14 shows an example of a Win2K domain in which – through the process described
above – you can rename some domains but not others. You can’t rename domains at the top of the
tree (or forest) or in the middle. Only the domains on the end are valid candidates for renaming, and
even then, the thought of losing all accounts isn’t appealing.
Figure 8.14
Valid and invalid domains for renaming
corp.com
✓
west.corp.com east.corp.com
✓ ✓
divisiona.corp.com divisionb.corp.com
Windows 2003 offers a new approach to renaming domains. However, don’t jump headlong into a
Windows 2003 domain rename, which is still complex and fraught with peril.
Figure 8.15
Adding valid UPN names to the forest
After you add an alternate UPN suffix to the forest, you’ll be able to specify user account suffixes
with the new name, as Figure 8.16 shows.
Figure 8.16
Modifying a user account to use a UPN name
You can have users log on with the new name by explicitly spelling out their full UPN name every
time they log on, as Figure 8.17 shows.
Figure 8.17
User logon with a UPN name
Of course, this change is only skin deep. Indeed, the new UPN name (Bigfish.com) doesn’t even
show up on the Log on to: line of the authentication dialog box. However, this adaptation might be
enough to satisfy those who requested the change.
j Tip
Creating a UPN name is much simpler than performing a domain rename – and it might
suffice.
d Caution
Although you’ll find domain rename tools on the Windows 2003 CD-ROM, the tools are old –
avoid them! Always download the latest Microsoft domain rename tools.
d Caution
Also, keep in mind that Microsoft doesn’t support the domain rename operation if the forest
contains Microsoft Exchange 2003 or Exchange 2000. Exchange simply can’t handle the
change.
Because of the several steps required, the potential bumps in the road on the way to the goal,
and the restriction that you can’t rename forests that contain Exchange 2003 or Exchange 2000 – the
domain rename operation might be out of reach for many organizations (although rumor has it that
Exchange 2003’s Service Pack 1 – SP1 – might let a domain rename succeed).
j Tip
To read Microsoft’s two white papers on the specific step-by-step procedure for performing
domain renames (one is 30 pages long and the other 80 pages long), go to
http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx, where you’ll
find links to the two documents with all the (gory) details.
d Caution
Be sure to perform the domain rename operation – in fact, all the operations I discuss in this
chapter – first in your test lab, not on your production servers. Also, after a domain rename
operation, as the Microsoft papers discuss, certain other elements of AD (e.g., certificates, Dfs)
might need adjusting before they work again.
Final Thoughts
I hope you won’t need to perform the operations I discuss in this chapter often. From the transfer
and seizing of FSMO roles to renaming DCs and domains, all the operations involve some perils.
However, none of them is impossible, and you should be aware of what’s required to perform them
as safely as possible.
Thank You
I would like to thank NetIQ and Windows and .Net Magazine for providing the opportunity to write
about a topic I love – Windows 2003 and AD.
Special thanks to Dave Bernard at Windows and .Net Magazine for seeing this project off to a
smooth start and landing. Additional thanks to Veronica Patterson, who edited this book and pro-
vided just the right amount of firmness in editing.
I thank Jan De Clercq (Hewlett-Packard – HP) and Dave Peterson (NetIQ) for providing technical
editing. However, if you find any technical errors, they’re mine, not theirs. Please feel free to contact
me to point out technical errors and necessary updates at http://www.moskowitz-inc.com.
I also thank Bill Boswell for additional bits and pieces of technical assistance throughout the
book and for being a solid sounding board for my questions.
Finally, thanks to all of you – the readers who have taken and will take time to download and
read the chapters of this eBook. I’m grateful to you for reading what I have to offer.
Dedication
I dedicate this book to the best friend a guy ever had: Jill Knapp. In a word, you rock. (Okay, that’s
two words.)
Contact Information
If you need AD training, deployment assistance, or a resource to validate your plans for AD deploy-
ment, growth, or renovation, please feel free to contact me at http://www.moskowitz-inc.com. I also
encourage you to visit my free community Group Policy forum at http://www.GPOanswers.com.