Windows Server 2008 R2 Unleashed (42 page)

ptg

Examining a Special-Purpose Domain Real-World Design Example

CompanyE is a computer consulting firm headquartered in Morioka, Japan. Most consult-

ing work is performed by full-time CompanyE employees; however, some outside contrac-

tors are brought in from time to time to help on projects. The company had already

deployed AD DS for the internal organization, but was concerned about opening access to

the forest for any nonemployees of the company. Consequently, a single domain AD DS

implementation was created for the nonemployees to use. A cross-forest transitive trust

was established between this domain and the internal forest, and access to resources such

as file and print services were delegated and controlled by the central IT organization.

Users in the contractor domain can access resources in the main companye.com domain,

but only those to which they are specifically granted access. In addition, the exposure that

the main companye.com domain receives from nonemployees is greatly reduced.

Renaming an AD DS Domain

AD DS in Windows Server 2008 R2 gives domain designers the flexibility to rename their

domain namespace and/or splice domains in a forest to different locations within a forest.

This capability gives AD DS great new functionality because design changes can be made

because of corporate mergers or organizational changes.

Domain rename supports renaming either the AD DS namespace (for example, compa-

nyabc.com) or the NetBIOS (legacy NT) domain name or both. The procedure is a rather

brute-force process, however, and should not be considered to be a routine operation.

The domain rename functionality in Windows Server 2008 R2 is mainly a psychological

factor because the prerequisites for deploying domain rename make it unlikely to be widely

Renaming an AD DS Domain

171

performed, at least in the initial stages of Windows Server 2008 R2 adoption. Domain

rename offers long-term answers to the previous barriers to AD DS adoption, which

revolved around the fact that organizations did not want to be locked in to any decisions

that could not be changed. Because a Windows 2000 AD DS namespace decision was irre-

versible, this effectively put many decision makers on edge, as they did not want to “paint

themselves into a corner,” so to speak. Domain rename removes this stipulation and makes

AD DS adoption much more palatable to decision makers within an organization.

Domain Rename Limitations

Domain rename has several limitations. It is important to understand the following

restrictions before considering a domain rename operation:

.
Cannot reduce the number of domains in a forest—
The domain rename tool

cannot be used to drop additional domains from a forest. For example, if a forest is

composed of four domains, there must be four domains remaining after the proce-

dure is complete. This type of domain consolidation role can be performed only

through the use of other tools, such as the Active Directory Migration Tool.

.
The current root domain cannot be demoted—
Although the domain rename

5

tool can splice and transplant domains from one portion of an AD DS namespace to

another, it cannot fundamentally change the root domain in a tree. A root domain

ptg

can be renamed, however.

.
Cannot transfer current domain names in one cycle—
A production domain

cannot be named the same as another production domain that exists in a forest. You

need to run the domain rename procedure twice to achieve this type of desired

functionality.

Outlining Domain Rename Prerequisites

In addition to the limitations of the domain rename tool, specific prerequisites for domain

rename must be met before a domain can be renamed. These prerequisites are as follows:

.
The entire forest must be at least Windows Server 2003 functional level—
All

domain controllers in the domain must be first upgraded or replaced with Windows

Server 2003, 2003 R2, 2008, or 2008 R2 and the forest functional level raised to at

least Windows Server 2003 functional level.

.
New DNS zones must be created—
The DNS server(s) for a domain must have a

zone added for the new domain namespace to which the domain will be renamed.

The exception is if the domain rename procedure will be renaming only the NetBIOS

domain name.

.
Domain rename must run from a console server—
A member Windows Server

2008 R2 computer (not a domain controller) must serve as the console server for the

domain rename procedure. All domain rename operations are run from this one box.

.
Shortcut trust relationships might need to be created—
Any domains that will

be “spliced” into a new location in the AD DS forest will need to have a shortcut

trust established between itself and the parent domain where it will be transplanted.

172

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

Renaming a Domain

The domain rename procedure, from the back end, is not extremely complex. Most of the

barriers to domain renaming, aside from the limitations and prerequisites listed in the

preceding section, come in the form of the disruption to the forest that is caused by the

reboots applied to all the computers in the forest.

After the prerequisites have been satisfied, the domain rename process can proceed. The

entire domain rename process is accomplished through six basic steps. As previously

mentioned, however, this routine is rather harsh on the network because it causes down-

time to a network infrastructure and should not be considered to be a common operation.

Step 1: List Current Forest Description

The tool used for domain rename is known as Rendom. Rendom has several flags that are

used in import and export operations. The first procedure run from the console server is

rendom /list, which locates the domain controllers for a domain and parses all domain-

naming information into an XML document named Domainlist.xml.

This XML document can easily be modified by any text editor such as Notepad and, as

will become evident, is central to the domain rename procedure.

Step 2: Modify Forest Description with New Domain Name(s)

ptg

The XML file generated by the /list flag must be modified with the new domain-naming

information. For example, if CompanyABC is changing its name to CompanyXYZ, all

references to companyabc in the XML list are changed to companyxyz. This includes the

NetBIOS and DNS names.

Step 3: Upload Rename Script to DCs

After the XML document is updated with the new domain information, it can be

uploaded to all domain controllers in a forest through the use of the rendom /upload

command. This procedure copies the instructions and new domain information up to all

domain controllers within a forest.

Step 4: Prepare DCs for Domain Rename

Domain rename is a thorough process because it is absolutely necessary that all domain

controllers in a forest receive the update information. It is, therefore, necessary to run

rendom /prepare to initiate a preparation process that checks to see if every single domain

controller listed in AD DS responds and signifies that it is ready for the migration. If every

single domain controller does not respond, the prepare function fails and must be

restarted. This precaution exists to keep domain controllers that are powered down, or not

accessible across the network, from coming up at a later time and attempting to service

clients on the old domain name.

Step 5: Execute Domain Rename Procedure

After all domain controllers respond positively to the prepare operation, you can initiate

the actual domain rename by running the rendom /execute command from the console

server. Before the execute command is run, there are actually no changes made to the

production environment. However, as the command is run, all domain controllers execute

Best Practices

173

the changes and automatically reboot. You then must establish a method of rebooting all

member servers, workstations, and other client machines and then reboot them all a

second time to ensure that all services receive the domain-naming change.

Step 6: Post-Rename Tasks

The final step in the Rendom task is to run the rendom /clean operation, which will

remove temporary files created on the domain controller and return the domain to a

normal operating state.

In addition to the cleanup tasks, you need to effectively rename each domain controller,

to change its primary DNS suffix. Each domain controller needs to go through this opera-

tion, which you run via the netdom command-line utility. The following steps outline the

renaming of a domain controller:

1. Open a Command Prompt window (choose Start, Run, and then type cmd.exe).

2. Type netdom computername OldServerName /add:NewServerName.

3. Type netdom computername OldServerName /makeprimary:NewServerName.

4. Restart the server.

5

5. Type netdom computername NewServerName /remove:OldServerName.

ptg

You run all the preceding commands from the command line. Replace the generic desig-

nators OldServerName and NewServerName with the entire DNS name of the old server

and the new server, such as server1.companyabc.com and server1.companyxyz.com.

Summary

With the advent of technologies such as domain rename, fine-grained password policies,

and cross-forest trusts, mistakes in AD DS design have become more forgiving than they

were in the past. However, it is still important to thoroughly examine the political and

technical aspects of any organization to design an infrastructure that aligns with its needs.

AD DS is very flexible in these regards and can be matched with the needs of almost any

organization.

Best Practices

The following are best practices from this chapter:

. Fully understand the structure of AD DS before designing.

. Implement fine-grained password policies and the Active Directory Recycle Bin to

reduce the need for additional domains.

. Secure any external namespace chosen by registering it so that it cannot be used

anywhere on the Internet.

174

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

. Start a domain design by considering the single domain model first.

. Consider using multiple domains for specific reasons only.

. Consider using the federated forest design model when uniting two disparate AD DS

structures.

. Control and optimize replication traffic by using sites.

. Upgrade any down-level clients to reduce administration and maintenance.

. Use domain rename sparingly, and only when faced with no other alternative.

ptg

CHAPTER 6

IN THIS CHAPTER

Designing
. Defining Organizational Units in

AD DS

Organizational Unit and
. Defining AD Groups

. Examining OU and Group Design

Group Structure
. Starting an OU Design

. Using OUs to Delegate

Administration

The organization of users, computers, and other objects

. Group Policies and OU Design

within the Windows Server 2008 R2 Active Directory

Domain Services (AD DS) structure gives administrators

. Understanding Group Design

great flexibility and control over their environments. Both

. Exploring Sample Design

organizational unit (OU) and group structure design can be

Models

tailored to fit virtually any business need. There is, however,

a great bit of confusion among administrators in the design

and use of OUs and groups. Often, OUs are indiscriminately

used without reason, and group structure is ineffectual and

ptg

confusing. With the proper preparation and advance knowl-

edge of their use, however, a functional OU and group

design can do wonders to simplify a Windows Server 2008

R2 AD DS environment.

In addition to the lessons learned from OU and group use

in Windows 2000 Server and Windows Server 2003,

Windows Server 2008 R2 introduced functionality such as

the Active Directory Recycle Bin, which reduces the risk of

OU deletion, and Active Directory Web Services and an

Active Directory Module for Windows PowerShell, which

makes it easier to administer OUs. In addition, AD DS builds

upon the improvements to OU structure and design intro-

duced with the release of Windows Server 2008, such as OU

Deletion Protection, universal group membership caching,

incremental group replication, and other enhancements

that have increased the flexibility of OU and group design

and have given administrators greater tools to work with.

This chapter defines organizational units and groups

within Windows Server 2008 R2’s AD DS and describes

methods of integrating them into various AD DS designs.

Specific step-by-step instructions and “best practice” design

176

CHAPTER 6

Designing Organizational Unit and Group Structure

advice are given as well. In addition, functional OU and group design models are detailed

and compared.