Migrating to Windows Server 2003, Active Directory, And Exchange 2003

Published on January 2017 | Categories: Documents | Downloads: 35 | Comments: 0 | Views: 614
of 232
Download PDF   Embed   Report

Comments

Content

i

Books
Contents
Chapter 1 The Windows Server System:
Featuring Windows Server 2003 and Exchange Server 2003 . . . . . . . . . . .
Introduction

1

....................................................

1

Introducing Windows Server System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

The Windows Server 2003 Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Edition: Not just the small kid on the block . . . . . . . . . . . . . . . . . . . . . . . .

3
3

Evaluating Windows Server 2003’s Directory Service Improvements . . . . . . . .

3

Upgrading to AD from NT 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading to Windows Server 2003 AD from Windows Server 2000
Technology and Functionality . . . . . . . . . . . . . . . . . . . . . . . .
Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AD administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Group Policy management . . . . . . . . . . . . . . . . . . . . . . . .
Command line tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

Overview of Windows Server 2003 Deployment and Migration
Hardware Requirements . . . . . . . . . . . . . .
System Compatibility . . . . . . . . . . . . . . . .
The Windows Catalog: HCL on steroids
Application compatibility . . . . . . . . . . .
Compatibility tools and resources . . . . .
Upgrade vs. Migration . . . . . . . . . . . . . . .
Upgrading . . . . . . . . . . . . . . . . . . . . . . . .
Migrating . . . . . . . . . . . . . . . . . . . . . . . .
Security IDs . . . . . . . . . . . . . . . . . . . .
Repermissioning resources . . . . . . . . . .
SID History . . . . . . . . . . . . . . . . . . . .
A common solution . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

6
6
6
8
8
9
9

. . . . . . . . . . . . 10
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

10
11
11
11
13
13
14
14
14
15
15
16

Evaluating Exchange Server 2003’s New Capabilities and Features . . . . . . . . . . 16
Exchange Server 2003 Editions . . . . . . . . . . . . .
Retired Features . . . . . . . . . . . . . . . . . . . . . . . .
Security Enhancements . . . . . . . . . . . . . . . . . . .
Manageability Improvements . . . . . . . . . . . . . . .
Antispam Features . . . . . . . . . . . . . . . . . . . . . .
Backup Features . . . . . . . . . . . . . . . . . . . . . . .
Mobile Access: OWA, OMA, and RPC Over HTTP
New Features for the Outlook Client . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

16
17
18
18
18
19
19
21

ii

An Overview of Exchange Server 2003 Deployment and Migration . . . . . . . . . 24
Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optimized for Windows Server 2003 . . . . . . . . . . . . . . . . . . . .
Interoperability with Exchange Server 2000 and Exchange Server 5.5
Mixed Mode vs. Native Mode . . . . . . . . . . . . . . . . . . . . . . . .
Coexistence and Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation and Deployment Improvements . . . . . . . . . . . . . . . . .
Upgrading from Exchange 2000 Server . . . . . . . . . . . . . . . . . . . . .
Migrating from Exchange Server 5.5 . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

24
24
25
25
25
26
26
28
29

iii

Books
Contents
Chapter 2 Active Directory Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A Brief Overview of Key Active Directory Elements . . . . . . . . . . . . . . . . . . . . . . 30
Forest Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Forest Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forest Design Tenets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A single forest is the most straightforward design . . . . . . . . . . . . . . .
A forest shares common security enforcement . . . . . . . . . . . . . . . . .
A forest indicates and requires ownership of forest data and service .
A forest implies strong levels of trust between administrators
of each domain within the forest . . . . . . . . . . . . . . . . . . . . . . . .
A forest implies high levels of collaboration between administrators
of each domain within the forest . . . . . . . . . . . . . . . . . . . . . . . .
A forest implies high levels of collaboration between users in various
domains in the forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating Forest Design Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forest service and data ownership . . . . . . . . . . . . . . . . . . . . . . . . .
Administrative complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross-forest trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metadirectory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

32
33
33
33
33

.........

33

.........

34

.
.
.
.
.
.

34
35
35
35
35
36

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

Domain Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Domain Characteristics . . . . . . . . . . . . . .
Administrative boundry . . . . . . . . . . .
Data boundary . . . . . . . . . . . . . . . . .
Authentication boundary . . . . . . . . . .
User account security policy boundary
Policy-based administration boundary .
Domain Models . . . . . . . . . . . . . . . . . . .
Single domain model . . . . . . . . . . . .
A dedicated forest root domain . . .
Single global child domain model . . .
Multiple domain models . . . . . . . . . .
Evaluating Domain Models . . . . . . . . . . .
Divergent security policies . . . . . . . . .
Minimizing replication traffic . . . . . . .
Data isolation requirements . . . . . . . .
Data autonomy requirements . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

36
36
37
37
38
38
38
38
39
39
40
41
41
41
42
42

iv

DNS Namespace Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Typical DNS Designs . . . . . . . . . . . . . . . . . . .
Subdomain . . . . . . . . . . . . . . . . . . . . . . .
A .local domain . . . . . . . . . . . . . . . . . . . .
Interoperating with Existing DNS Infrastructures
NetBIOS Names . . . . . . . . . . . . . . . . . . . . . . .
UPS Suffixes . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

43
43
43
43
44
44

OU Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Collect objects sharing common administration . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Collect objects sharing similar configuration, application, or security settings . . . . . .
3. Collect objects for visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45
45
46

Site Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
The Functions of Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

Server Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Domain Controllers . . . . . . . . . . . .
Operations Masters . . . . . . . . . . . .
Forest-wide operations . . . . . . .
Domain naming . . . . . . . . . .
Schema maintenance . . . . . .
Domain operations . . . . . . . . . .
Relative Identifier assignment .
Infrastructure master . . . . . . .
PDC Emulator . . . . . . . . . . .
Placement of Operations Masters
Forest operations . . . . . . . . .
Domain operations . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

47
47
48
48
48
48
48
48
49
50
50
50

Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

v

Books
Contents
Chapter 3 Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Assembling the Planning and Migration Team . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Identifying the Big Picture Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Training IT Staff and End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing the Existing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing the Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . .
Auditing the Directory Services Infrastructure . . . . . . . . . . . . . . . . . .
Auditing Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Applications and Services . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Clients and the User Environments . . . . . . . . . . . . . . . . . .
Getting Help in the Auditing Phase . . . . . . . . . . . . . . . . . . . . . . . .
Planning Active Directory Design . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating Upgraded vs. Restructure Migration . . . . . . . . . . . . . . . . . . .
Planning the Migration Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating DCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifying Opportunity for Server Consolidation and Reappropriation
Evaluating Server Migration Order . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

55
56
56
57
59
60
61
62
64
64
64
65
65
65
66

Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

vi

Books
Contents
Chapter 4 Migration Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Overview of Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Domain Upgrade . . . . . . . . . . . . . . . . . . . .
Domain Restructure . . . . . . . . . . . . . . . . . .
Resource Access During and After Migration .
A review of security fundamentals . . . . .
The effect of domain restructure . . . . . . .
Security translation . . . . . . . . . . . . . .
sIDHistory . . . . . . . . . . . . . . . . . . . .
Group membership . . . . . . . . . . . . .
Understanding ADMT . . . . . . . . . . . . . . . . .
Other Consideration in a Domain Restructure

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

68
68
69
69
70
70
70
71
71
73

Deploying the New Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Delegate the DNS Zone for the Forest Root Domain . . . . . . . .
Install the First DC in the Forest Root Domain . . . . . . . . . . . .
Install Windows Server 2003 . . . . . . . . . . . . . . . . . . . . . .
Install Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . .
Post-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Install Additional DCs in the Forest Root Domain . . . . . . . . . .
Configure Site Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Complete the Installation of the Forest Root Domain . . . . . . . .
Complete Additional Domains in the Forest . . . . . . . . . . . . . .
Preparing the Migrate with ADMT . . . . . . . . . . . . . . . . . . . . .
Establishing a two-way trust between the source and target
Establishing migration credentials . . . . . . . . . . . . . . . . . . .
Installing ADMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing the target domain . . . . . . . . . . . . . . . . . . . . . . .
Preparing the source domain . . . . . . . . . . . . . . . . . . . . . .
A nifty shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing to migrate passwords . . . . . . . . . . . . . . . . . . . .
Preparing the target domain . . . . . . . . . . . . . . . . . . . .
Generating the encryption key . . . . . . . . . . . . . . . . . . .
Configuring the PES . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

74
74
74
74
75
77
78
78
79
79
80
81
84
85
85
86
87
87
88
88

vii

Using ADMT to Migrate from Windows NT Server 4.0 to
Windows Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Migrating or Recreating Trust Relationships . .
Identifying Service Accounts . . . . . . . . . . . .
Migrating Global Groups . . . . . . . . . . . . . .
Remigrating groups . . . . . . . . . . . . . . . .
Creating a Group Mapping and Merging Plan
Builtin Groups . . . . . . . . . . . . . . . . . . . . . .
A Summary of Group Migration Tasks . . . . .
Migrating Users . . . . . . . . . . . . . . . . . . . . .
User account properties . . . . . . . . . . . . .
Migrating Computers . . . . . . . . . . . . . . . . .
Migrating servers and workstations . . . . .
Translating Security . . . . . . . . . . . . . . . . . .
Creating a SID mapping file . . . . . . . . . .
Translate Local User Profiles . . . . . . . . . . . .
Migrating Local Groups . . . . . . . . . . . . . . .
Establishing appropriate trust relationships
Migrating shared local groups . . . . . . . .
Processing group membership . . . . . .
When to migrate shared local groups . . .
Migrating service accounts . . . . . . . . . . .
Decommissioning DCs . . . . . . . . . . . . . . . .
Troubleshooting . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

90
91
92
92
94
94
95
95
97
97
98
98
101
102
103
104
105
105
105
106
108
109

Advanced Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Third-Party Migration Tools . . . . . . . . . . . . . . . . . .
High-level features to evaluate . . . . . . . . . . . . .
Support for complex environments . . . . . . .
Project-based migration . . . . . . . . . . . . . . . .
Monitoring and reporting . . . . . . . . . . . . . .
Roll-forward and rollback . . . . . . . . . . . . . .
Email migration . . . . . . . . . . . . . . . . . . . . .
Desktop migration features . . . . . . . . . . . . .
Desktop upgrade or deployment . . . . . . . . .
Terminal Server profile support . . . . . . . . . .
Security translation in complex environments
Migration cleanup . . . . . . . . . . . . . . . . . . .
Other features . . . . . . . . . . . . . . . . . . . . . . . .
Migration Services and Support . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

109
110
110
110
110
110
111
111
111
111
111
111
111
112

Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

viii

Books
Contents
Chapter 5 Maintaining Windows Server 2003
in a Post-Migration Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Preparing for the Administration of Windows Server 2003 . . . . . . . . . . . . . . . . 114
Native Administrative Tools . . . . . . . . . . . . . . . . . . . . . . . . .
Customize the Location of the Administrative Tools Folder
Install the Full Suite of Native Administrative Tools . . . . .
Introduction to the Microsoft Management Console . . . . . . . .
Familiar Snap-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools Relocated to the MMC Framework . . . . . . . . . . . . .
New Snap-ins and Consoles . . . . . . . . . . . . . . . . . . . . . .
Super Consoles with Multiple Snap-ins . . . . . . . . . . . . . .
Creating Simple Customized Consoles . . . . . . . . . . . . . . .
Create a Simple Customized MMC Snap-in . . . . . . . . .
Other Important Administrative Tools . . . . . . . . . . . . . . . . . .
Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Group Policy Management Console . . . . . . . . . . . . . . . .
Resource Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service-Specific Administrative Tools . . . . . . . . . . . . . . . .
Remote Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Remote Desktop for Administration . . . . .
Enable Remote Desktop for Administration . . . . . . . . .
The Client Side . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Install the Remote Desktop Client . . . . . . . . . . . . . . .
Managing RDCs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End a User’s RDC to a Server . . . . . . . . . . . . . . . . . .
Configure Remote Desktop Session Behavior . . . . . . .
Using Alternate Credentials (aka Secondary Logon or Runas) .
Run a Program with Administrative Credentials . . . . . . . .
Other Run As Options . . . . . . . . . . . . . . . . . . . . . . . . . .
Important Notes About the Runas Command . . . . . . . . . .
Models for Providing Administrative Tools . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

114
114
115
116
117
117
117
117
118
118
120
121
121
121
121
121
121
122
122
122
122
123
123
123
124
124
124
125

Active Directory Administration 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
User Accounts . . . . . . . . . . . . . . . . .
Create a User Account . . . . . . . . .
Manage a User Object or Account
Unlock a User Account . . . . . . . .

..................................
..................................
....................................
..................................

125
125
126
127

ix

Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create a Group . . . . . . . . . . . . . . . . . . .
Group Type . . . . . . . . . . . . . . . . . . . . . .
Distribution Groups . . . . . . . . . . . . . .
Security Groups . . . . . . . . . . . . . . . . .
Group Scopes . . . . . . . . . . . . . . . . . . . .
Domain Local Groups . . . . . . . . . . . . .
Global Groups . . . . . . . . . . . . . . . . . .
Universal Groups . . . . . . . . . . . . . . . .
Local Groups . . . . . . . . . . . . . . . . . . .
Nesting . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Users to Groups . . . . . . . . . . . . .
Computer Objects . . . . . . . . . . . . . . . . . . . .
Creating Computer Accounts . . . . . . . . . .
Create a Computer Object or Account .
Manage a Computer Object or Account
Joining to a Domain . . . . . . . . . . . . . . . .
Join a Computer to a Domain . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

127
127
127
127
127
128
128
128
128
129
129
130
130
130
131
131
131
131

Managing Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Installing the GPMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Group Policy Terminology and Concepts . . . . . . . . . . . . . . . . . . . .
Policy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPOs and the GPO Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPO Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WMI Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPO Precedence and Inheritance . . . . . . . . . . . . . . . . . . . . . . .
Resultant Set of Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and Linking GPOs . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Domain Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Domain Controller Policy . . . . . . . . . . . . . . . . . . . . . . . . .
Member Server and Workstation Policies . . . . . . . . . . . . . . . . . . . .
Managing File and Folder Access . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add a Security Principal to the ACL . . . . . . . . . . . . . . . . . . . . .
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Blocking Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Block Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reinstating Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reinstate Inheritance on an Object . . . . . . . . . . . . . . . . . . . .
Reset Permissions to Enforce Inheritance from a Parent Folder

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

133
134
135
135
137
137
138
138
140
141
141
141
142
142
142
143
143
143
144
144
145
146
146

x

Effective Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Permissions Override Folder Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Permission Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implicit No Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allow Permissions Are Cumulative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deny Overrides Allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Explicit Permissions Override Inherited Permissions . . . . . . . . . . . . . . . . . . . . . .
Evaluating Effective Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Best Practices for ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sharing a Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

146
147
147
147
147
147
147
148
148
148

Other Guidance on What Is New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Help and Support Center . . . . . . . . . . . . . .
Microsoft IE Enhanced Security Configuration
Shadow Copies . . . . . . . . . . . . . . . . . . . . .
Disaster Planning and Recovery . . . . . . . . . .
Monitoring DC Health . . . . . . . . . . . . . . . .
Third-Party Administrative Tools . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

149
149
149
150
151
151

Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

xi

Books
Contents
Chapter 6 Planning an Exchange Server 2003 Migration . . . . . . . . . . . . . . 152
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Intraorg or Interorg? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
In-Place Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Front-End Servers vs. Back-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Standard or Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Exchange and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
The Active Directory Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Global Catalog Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

The Exchange System Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Client Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

xii

Books
Contents
Chapter 7 Installing Exchange Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . 165
Pre-Installation Considerations for Exchange Server 2003 . . . . . . . . . . . . . . . . . 165
Performing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Post-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Exchange Server Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Migrating From Exchange 5.5 To Exchange 2003 . . . . . . . . . . . . . . . . . . . . . . . . 182
Phase One: Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase Two: Prepare Active Directory . . . . . . . . . . . . . . . . . . . . .
Phase Three: Installing Exchange Server 2003 on the Initial Server
The Easier Road: Exchange Server Migration Wizard . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

183
184
186
187

SP1 for Exchange Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
The Grand Finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

xiii

Books
Contents
Chapter 8 Managing Exchange Server 2003 . . . . . . . . . . . . . . . . . . . . . . . 195
Common Administrative Chores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Monitoring and Troubleshooting
Outook Web Access . . . . . . . .
Implementing Security . . . . . . .
Avoiding Spam . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

201
207
210
212

Migration, Administration, and Beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

1

Chapter 1

The Windows Server System:
Featuring Windows Server 2003 and
Exchange Server 2003
Introduction
Welcome to Migrating to Windows Server 2003, Active Directory, and Exchange Server 2003, an
eBook brought to you by NetIQ and Windows & .NET Magazine. This book answers the following
burning questions about Windows Server 2003 and Exchange Server 2003:
• Why should I migrate?
• How can I prepare to migrate?
• What are the best practices in performing a migration?
• What do I need to bear in mind after migrating?
Our goal is to provide you with a straightforward, practical guide to help answer migration
questions specific to your environment. We’ll try to cut through the marketing hype and spin so you
can identify what really matters. And we’ll bring with us the experience we’ve gleaned from migrating
organizations large and small to Active Directory (AD) and Exchange Server.
This book focuses solely on migrations from previous Windows OSs, such as Windows 2000
Server, Windows NT 4.0, Exchange Server 2000, or Exchange Server 5.5. We will not examine
migration from other directory services or messaging systems. Chapter 1 provides an overview of the
products and the broad topics related to migration. This chapter provides insights into the new 2003
platform features so you can determine whether Windows Server 2003 and Exchange Server 2003 are
right for you. We also introduce some key issues related to migration of the directory service and
messaging system. Chapters 2–5 provide details regarding migration to Windows Server 2003 and AD
and Chapters 6–8 highlight migration to Exchange Server 2003.
Throughout this book, we assume you have experience with Windows platforms—this book is
not for “Dummies.” We present straightforward concepts as succinctly as possible and touch lightly
on common and familiar concepts. When we reach core topics, we focus on them. These core topics
might be new to Windows Server 2003 and Exchange Server 2003 or might be complicated subjects
from earlier versions that our experience has shown are not well understood by IT professionals.
We will guide you to resources that provide additional details. Microsoft certainly provides some
of the most useful resources, specifically:
• the Windows Server 2003 home page at http://www.microsoft.com/windowsserver2003
• the Windows Server 2003 technology center of the TechNet site at
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/default.asp
• the Exchange Server 2003 home page at http://www.microsoft.com/exchange
Brought to you by NetIQ and Windows & .NET Magazine eBooks

2

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• the Exchange Server 2003 technology center of the TechNet site at
http://www.microsoft.com/technet/prodtechnol/exchange
In addition, we remind you of Windows & .NET Magazine’s superb resources, which have
the distinct advantage of being independent from Microsoft and are available at
http://www.winnetmag.com.
One advantage of an eBook is the dynamic nature of its time-release publishing. By the time
you receive the final chapter of this eBook, technology will have changed. The technology changes
as the market adopts and adjusts to Windows Server 2003 system, as Microsoft rolls its emphasis on
patch deployment and trustworthy computing into Windows Server 2003’s first service pack, and as
new technologies such as Microsoft Office System and Windows SharePoint Services enter the market.
To get the most benefit from this eBook, you need to regularly visit our eBook update Web site at
http://www.intelliem.com/migrationebook. On that Web site, we will post updates, host discussions,
and provide tools and solutions to support you in your migration efforts.
Finally, we discuss the strengths and weaknesses of the native tools: the commands and utilities
that are available in Windows Server 2003 and Exchange Server 2003, including resource kit tools and
Microsoft freebies. Where weaknesses exist, we point out third-party tools and their capabilities. If
your environment is large or complex, you will almost certainly require assistance from third-party
tools. Microsoft has tried several third-party tools and in the case of some tools, “they liked it so
much they bought the company.” In smaller environments you might need only native tools. But
you will need to evaluate the total cost of migration—including your time, the likelihood of error,
and the cost of error—against the cost of reliable, targeted, retail migration tools. We hope to provide
valuable insight into these migration considerations also. With these introductory notes out of the
way, let’s pull back the covers from Microsoft’s latest crown jewel, Windows Server System.

Introducing Windows Server System
Windows Server System is the brand identity for a large and diverse group of server products
including Microsoft Application Center, BizTalk Server, Commerce Server, Content Management
Server, Exchange Server, Host Integration Server (HIS), Identity Integration Server 2003 Enterprise
Edition (MIIS), Internet Security and Acceleration (ISA) Server, Microsoft Operations Manager (MOM),
Project Server, SharePoint Portal Server, Small Business Server (SBS), Speech Server, SQL Server,
Systems Management Server (SMS), Storage Server 2003, and yes—Windows Server 2003 and even
Windows 2000 Server. If the list includes servers you have not heard of before, don’t be surprised.
Microsoft has recently unveiled a number of servers specializing in granular enterprise services, and
in the coming months, Microsoft will undoubtedly announce more.
In the past few years, Microsoft had problems coming to terms with the identity of its server
lineup. Before its release, Windows Server 2003 was called Windows .NET and Windows .NET Server.
Microsoft also was preparing to brand other servers with the .NET identity. However, the market
didn’t understand “.NET” so Microsoft dropped the identity. But the .NET technologies are still in
the products. .NET encompasses a new architecture for applications and services that facilitate
information access by a comprehensive assortment of devices and tools—from native Windows
applications running on PCs to next generation phones and “smart” watches. Although Windows
Server 2003 encompasses many exciting and valuable components of the .NET vision, it will take
several years and more revisions of Windows Server 2003 before the entire OS will be truly “.NET.”
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

3

By then the initiative and its technologies will certainly be called something entirely different, but
we as customers will benefit from the inherent secure nature of .NET code. If for no other reason
than security, .NET can’t come soon enough.
Staying the course of .NET technology, Microsoft branded its server products with a more
market-friendly identity as Windows Server System with identifiable product names and year-based
version tags.

The Windows Server 2003 Family
Windows Server 2003 is an incremental, evolutionary revision of the architecture introduced in NT
and the significant technologies introduced in Windows 2000 Server. The internal version number of
Windows Server 2003 (i.e., 5.2) tells the tale: Windows 2000 Server is version 5.0 and Windows XP
is version 5.1. The Windows Server 2003 family consists of four editions:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition

Web Edition: Not just the small kid on the block
Each edition has the same core architecture and shares the vast majority of its code base.
However, Microsoft designed each edition to better meet the needs of customer segments with
specific requirements for scalability, service, and hardware platform support. By creating unique
bundles with various scalability and performance, Windows Server 2003 editions, which Table 1.1
lists, can meet the business needs of large datacenter customers as well as small businesses.
Every enterprise will want to examine Windows Server 2003, Web Edition as part of its
comprehensive migration plan. This platform delivers Web pages, Web sites, Web applications,
and Web services, plus it supports popular technologies such as Active Server Pages (ASP), ASP.NET,
and the Windows .NET Framework. Although designed to provide a Linux alternative for Web
hosting providers, its competitive pricing also lets organizations migrate existing internal or external
Web servers to a more cost-effective platform. In the past, organizations needed to buy the full
version of the server platform, even if they didn’t use many network services.
With the introduction of technologies such as Software Update Services and Windows SharePoint
Services, Web servers will likely play an increasingly important role inside enterprises. Given the
unique security needs of a Web server, we advise dedicating Web servers so you can update them
quickly and regularly; and in the event of a security breach, non-Web applications, services, and data
stores are not jeopardized. You need to consider cost, security, and manageability when you look at
server consolidation versus dedication.

Evaluating Windows Server 2003’s Directory Service Improvements
With each new release Microsoft says it provides, “Better performance, scalability, stability,
availability, security, manageability….” You’ve probably heard it enough times to use it as your
“om” in yoga class.
So what do these words really mean? As the consultant once said, “It depends.” Windows Server
2003 has many enhancements. The relative value of those enhancements to your enterprise depends
Brought to you by NetIQ and Windows & .NET Magazine eBooks

4

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Table 1.1: Windows Server 2003 Editions
Server Edition
Windows Server
2003, Standard
Edition

Windows Server
2003, Enterprise
Edition

Windows Server
2003, Datacenter
Edition

Server Role
Replaces Windows 2000 Server.
An all-purpose server platform
that performs diverse roles
including Web, application,
database, messaging, and
network service. Supports
AD and can act as a DC.

Business Target
Targeted for use in small
businesses and for
departmentaluse within
larger organizations.

Scalability and Availability
Provides SMP support for
up to 4 CPUs
Supports a maximum
of 4GB of RAM.
Offers no support for clustering
Supports only x86 processor
systems; provides no support for
64-bit platforms such as those
Intel Itanium-based systems.
Replaces Windows 2000
Targeted for businesses of
32-bit version
Advanced Server.
all sizes, particularly when Provides SMP support for up
An all-purpose server platform scalability and availability
to 8 CPUs.
that performs diverse roles
are a concern.
Supports a maximum of
including Web, application,
32GB of RAM.
database, messaging, and
Supports clustering up to 8
network service.
nodes.
Supports AD and can act
Supports x86 processor systems.
as a DC.
64-bit version
Provides SMP support for up to
8 CPUs.
Supports a maximum of 64GB of
RAM.
Supports Intel Itanium-based
systems.
Replaces Windows 2000
Targeted for data processing 32-bit version
Datacenter Server.
environments consisting
Provides SMP support for up to
A high-performance, highof business-critical and
32 CPUs with a minimum of
scalability, and high-availability mission-critical applications 8 CPUs.
server platform available only
that require superior levels
Supports a maximum of 64GB
on preinstalled on OEM
of reliability, availability,
of RAM.
systems.
and scalability.
Supports clustering up to 8
nodes.
64-bit version
Provides SMP support for up to
64 CPUs.
Supports a maximum of 512GB
of RAM.
Supports Intel Itanium-based
systems.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

5

Table 1.1: Windows 2003 Editions continued
Windows Server
2003, Web Edition

Is the new member of
Windows Server System.
Can belong to a domain or
workgroup but cannot act as
a DC.
Limited to 10 Server Message
Block (SMB) connections (not
designed for file and print
service). Optimized for Web
serving functions.

Targeted for Web and
hosting services and as a
Windows alternative to
Linux.

Provides SMP support for up to
2 CPUs.
Supports a maximum of 2GB of
RAM.
Provides no support for
clustering.
Supports only x86 processor
systems.

on your current environment and where you want to take that environment. Before we examine the
key new features, let us put in our 2-cents worth of advice: upgrade! We’ve seen three enormous
benefits from Windows Server 2003 that affect almost every organization, big and small.
Security. It’s true. Windows Server 2003 is significantly more secure, more likely to stay secure, and
will support important security update and patch management technologies that Microsoft will release
in late 2003 and in 2004. Out of the box, Windows Server 2003 is locked down, as you might have
heard. This security is true, important, and not a moment too soon.
Productivity. Windows Server 2003 addresses weaknesses in the Windows 2000 Server technologies
and tools, particularly in AD. We examine many of the productivity changes throughout this book.
Most of the enhancements are small, but they add up to significantly reduced pain and increased
productivity for administrators.
Support for new technologies. We believe that SharePoint Services, Microsoft Office Live
Communications Server (LC Server) 2003, Real Time Communications Server (RTC Server), and the
entire Office 2003 System will make a huge difference where it counts for organizations today—
in the productivity of every information worker.
Depending on how the market adopts these technologies, we might eat our words by
Chapter 8’s release, but we still assert that the first two reasons are enough to warrant an
upgrade as soon as your budget allows. These three benefits provide significant drive to migrate.
But you will find dozens more reasons to upgrade, depending on the type of organization you
have, your user population, your security concerns, your network topology, and your server roles.
An exhaustive exploration of all the new features is available in the white paper titled, “Why
Upgrade From Windows NT 4.0 to Windows Server 2003 Server 2003” at
http://www.microsoft.com/windowsserver2003/docs/NT4toWNET.doc. We found this document
to be informative and recommend that you look it over.
Because this book facilitates the migration of directory services, let’s tour the key new features
and technologies of AD. Take note as to how much return you would expect to get from the
improvements.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

6

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

AD serves as the enterprise directory service for a Windows network. AD centralizes the
management of identities (e.g., user accounts), the management of information about enterprise
resources, and the security of those resources.

Upgrading to AD from NT 4.0
The reasons to upgrade to AD from NT 4.0 domains and their rudimentary directory service, the SAM,
are well understood. Enterprises of any size have experienced the pain due to the SAM’s limitations,
including a limit to how many users and groups it can support, its lack of control over administrative
authority, the need for multiple domains, and the creation of trust relationships between those
domains.
A single enterprise AD, called a forest, can support an enterprise of any size. AD supports
millions of objects per domain and granular delegation of administrative authority within each
domain, thereby significantly reducing the need for multiple domains within the forest. Elegant and
simple designs consisting of one forest and one or two domains are not uncommon, even in
enormous globally dispersed enterprises. We haven’t heard anyone claim that AD increased his or
her total cost of ownership (TCO) over NT 4.0. In fact the enterprises we work with are huge fans
of the new directory service, particularly after we educate and train them how to design and
implement AD correctly. You are forewarned: AD is a significant change from NT 4.0, and although
this book will provide you with lots of great information to help you migrate, be sure to read,
discuss, and learn as much as you can before migrating. AD is not only a replacement for the SAM,
but it also acts as a central repository of information about the enterprise, such as information about
users, groups, computers, printers, servers, applications, and topology.

Upgrading to Windows Server 2003 AD from Windows 2000 Server
For organizations currently running Windows 2000 Server as their domain controllers (DCs),
Windows Server 2003’s revision of AD provides important and long-awaited enhancements to its
security, performance, and manageability.

Technology and functionality
Migration. You can use the AD Migration Tool (ADMT) to migrate users and groups to AD. ADMT
2.0 now supports migration to Windows Server 2003 domains, and importantly, lets you migrate user
passwords.
Coexistence. Windows Server 2003 AD DCs, domains, and forests can coexist with DCs running
Windows 2000 Server and NT 4.0 because of the domain and forest functionality levels that Windows
Server 2003 supports. Domain and forest functional levels disable or enable AD features on a
per-domain or forest-wide basis to account for earlier version DCs that do not support the extended
feature set of Windows Server 2003. These functionality levels are similar to the domain modes
(i.e., mixed mode, native mode) in Windows 2000 Server environments. Windows Server 2003 AD
supports four different domain functional levels and three different forest functional levels. Each level
lets you deploy certain new features, and different levels of interoperability with existing DCs running
Windows 2000 Server or NT 4.0. To use some of the new features listed in this chapter you must
configure a domain or forest to a specific functional level. We’ll highlight those situations and go into
more detail about forest and domain functional levels in Chapters 2–5.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

7

Trust relationships. Although most enterprises will need only one AD forest, on rare occasions an
enterprise will need a multi-forest model, particularly when two organizations merge and each has an
established forest. Creating and managing trust relationships between forests was difficult in Windows
2000 Server because you had to establish relationships between every individual domain in each
forest. Windows Server 2003 supports cross-forest, transitive-trust relationships so you can establish a
single trust relationship between the root domains of each forest. Cross-forest trusts require you to
configure the forests at the Windows Server 2003 forest functional levels.
Name changes. In Windows 2000 Server, you could not rename a domain or change the hierarchical
position of a domain without first removing AD entirely. Windows Server 2003 supports renaming
and repositioning domains after you configure the forest at the Windows Server 2003 forest functional
level. This enhancement will be particularly useful for enterprises adjusting their networks to
accommodate acquisitions, mergers, name changes, reorganizations, or modifications to their AD
design. Windows 2000 Server was also strict about DC names: you could not rename a DC without
demoting it, changing the name, and promoting it again. Windows Server 2003 domains configured at
the Windows Server 2003 domain functional level support renaming DCs without first demoting them.
Branch offices. When a user logs on to an AD domain, a global catalog server must supply
information about the user’s universal group membership. If a global catalog server is not available
and the user is not a member of the domain administrator group, then the user is denied logon.
Users at branch offices that have locations separated by WAN links are denied logon due to the
inaccessibility of a remote global catalog server when the link is down. So organizations with
Windows 2000 Server environments adopted a best practice of configuring a global catalog server on
a DC in each location separated by a WAN link. That practice addressed the risk of denied logon but
increased replication traffic across the WAN link. Windows Server 2003 introduces universal group
membership caching. This feature lets you specify a DC in a branch office that caches users’ universal
group membership and decreases the need for a local global catalog server. A global catalog server is
queried the first time a user logs on at that location, then the DC caches the user’s universal group
membership so subsequent logons do not require access to a global catalog server.
Domain controller installation. Windows Server 2003 lets you use a backup of the domain AD as
the initial data source to promote a DC. This enhancement lets you install a DC in a remote location
without eating up bandwidth as it replicates the entire directory over a WAN connection.
Enhanced partitioning. AD’s database is divided into partitions that contain information to support
specific functionality. For example, the schema partition defines the types of objects that AD can store
and thereby acts as the blueprint for the forest’s directory service. Every DC stores a copy of the
schema partition. The configuration partition, which every DC in a forest also stores, contains objects
related to sites and services. The domain partition stores objects for resources in that domain,
including users, groups, and computers. Only the DCs in that domain will store and replicate the
domain partition. If the forest contains multiple domains, each domain maintains and replicates its
own domain partitions. The problem is that some information is not necessary for every DC to
maintain and replicate. For example, you can maintain DNS zones in the AD database but unless
every DC will act as a DNS server for clients in the enterprise, there’s no need to replicate the DNS
Brought to you by NetIQ and Windows & .NET Magazine eBooks

8

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

data to every DC. Windows Server 2003 introduces application partitions. These AD partitions
maintain information for one or more specific applications. Administrators can designate which DCs
within a domain or forest will maintain each application partition. This enhancement lets administrators refine replication so that each DC contains only the information it requires to perform its duties.
Improved replication. The many changes to replication will make AD significantly more efficient.
Perhaps the most important change is that when you configure a forest at the Windows Server 2003
functional level, group membership changes replicate granularly instead of replicating an entire list of
members. This latter change is quite significant for performance, security, and manageability.
Schema functionality. AD now lets you redefine or deactivate schema attributes and object classes.
This provides organizations a way to correct for errors or retire unused schema objects. Schema
changes also no longer force a complete replication of the global catalog.
Active Directory Application Mode. AD’s robust, efficient LDAP-compatible directory service makes
it an attractive data store for many applications. However, for an application to use AD, it often must
make modifications to the directory’s schema so the directory can store new attributes or objects.
Schema modification, as we discuss in later chapters, is serious business. Many businesses shy away
from installing AD aware applications, which is unfortunate because integration with enterprise
applications is one of the best features of a real directory service. Microsoft listened and came up
with Active Directory Application Mode (ADAM), which installs AD as an application, rather than a
service. This means you can have one or more discrete instances of AD running on a server—and
that server doesn’t need to be a DC! For more information about ADAM, go to Microsoft’s Web page
at http://www.microsoft.com/windowsserver2003/adam.

Manageability
Microsoft provides enhanced tools and snap-ins with Windows Server 2003. The company hopes to
address some of its strongest criticisms of its version 1.0 administrative tools with these enhancements.
AD administration
AD Users and Computers now lets you:
• Select multiple objects simultaneously.
• Drag objects to a new location such as a different container, organizational unit (OU), or group.
• Modify common properties of multiple objects simultaneously. For example, you can now select
multiple user accounts and change the user profile location for all of them.
In addition, the Microsoft Management Console (MMC) snap-in now hosts a Saved Queries
folder. Unlike the Find command available in both Windows Server 2003 and Windows 2000 Server,
Saved Queries lets you define an AD query, save it, and run the query again at any time. For
example, you can create a saved query that displays all disabled user accounts in the domain. When
you need to monitor disabled accounts, simply run the saved query and the results will show you the
status of user accounts across every OU in the domain.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

9

Group Policy management
An entirely new and incredible MMC snap-in called Group Policy Management Console (GPMC)
centralizes and facilitates the creation, linking, application, and analysis of Group Policy Objects
(GPOs). In Windows 2000 Server, you can only administer GPOs from the Properties dialog box
of a site, domain, or OU, and the UI made it difficult to locate and understand options related to
the application and functioning of the GPO. GPMC, as Figure 1 shows, provides a single interface
with drag-and-drop functionality to let an administrator manage Group Policy settings across
multiple sites, domains, or even forests. Some of the capabilities of GPMC include the ability to
back up, restore, import, and copy GPOs, while providing an intuitive reporting interface that shows
GPO deployment. Using this tool an administrator can easily determine which GPOs apply to a
given domain, the configuration of inheritance settings, and which users or groups have the ability to
manage these objects. The GPMC snap-in is available for download from
http://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

Figure 1:
The Group Policy Management Console

The Resultant Set of Policy (RSoP) tool is also a long-awaited addition to the Group Policy
administrative toolset. Determining what settings will, in the end, drive the user or computer
environment can be extraordinarily complex because you can apply Group Policy to sites, domains,
and OUs; you can filter Group Policy by security group membership and WMI queries; you can
disable Group Policy in part or in whole; you can block or enforce Group Policy; and you can apply
Group Policy to users or computers. RSoP lets you determine settings, as well as troubleshoot GPO
application and plan “what-if” scenarios to evaluate the Group Policy impact of moving a user or
computer between AD containers.

Command line tools
Windows Server 2003 provides additional flexibility and opportunity for automation thanks to its
new arsenal of command line utilities. In the Group Policy arena, the gpresult command produces
an analysis of RSoP from the command prompt and the gpupdate command forces updates of

Brought to you by NetIQ and Windows & .NET Magazine eBooks

10

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

GPOs. These utilities replace and enhance the GPO functionality of Windows 2000 Server’s secedit
command. The secedit command still exists in Windows Server 2003, but its functionality focuses on
security templates.
Almost every service, including Microsoft Internet Information Server (IIS), Dfs, NTBackup, Task
Scheduler, Terminal Services, SharePoint Services, and AD, offers command-line management tools.
AD commands are particularly impressive, allowing administrators to query, add, modify, remove, and
move AD objects from the command line.

Overview of Windows Server 2003 Deployment and Migration
Perhaps after reading the above information, reviewing various resources available from Microsoft,
and evaluating the new features, technologies, and capabilities of Windows Server 2003, you have
determined it is time to move to Windows Server 2003. Chapters 2–5 provide significant detail
regarding migration to Windows Server 2003 (particularly to AD) from Windows 2000 Server and
NT 4.0. But a few topics warrant an introduction and others deserve detail at this early stage.

Hardware Requirements
Among your first tasks is evaluating your hardware and budget for appropriate upgrades and
replacements. Each time Microsoft releases a new version of the platform, it releases minimum system
requirements related to processor, memory, and disk space necessary for the OS to function. Table
1.2 summarizes the published minimum requirements for the Windows Server 2003 family.
Table 1.2: Minimum Windows Server 2003 Requirements
Minimum CPU speed

Standard Edition
133MHz

Recommended minimum
CPU Speed
Minimum RAM
Recommended minimum RAM
Maximum RAM

550MHz
128MB
256MB
4GB

SMP support

Up to 4

Disk space for setup

1.5GB

Enterprise Edition
133MHz (x86)
733MHz (Itanium)
733MHz

Datacenter Edition
400MHz (x86)
733MHz (Itanium)
733MHz

Web Edition
133MHz

128MB
256MB
32GB (x86)
64GB (Itanium)
Up to 8

512MB
1GB
64GB (x86)
512GB (Itanium)
Minimum 8
Maximum 64
1.5GB (x86)
2GB (Itanium)

128MB
256MB
2GB

1.5GB (x86)
2GB (Itanium)

550Mhz

Up to 2
1.5GB

Hardware minimums are an interesting beast because they represent more-or-less the bare bone
requirements for the OS to function. Testing has shown that the OS can install on somewhat less
capable platforms but it might not function well or function for any business purpose. Recommending
system hardware requirements without knowing how the system will be used (e.g., the services it will
run, the demand those services will be put under) is nearly impossible. You must evaluate your
current servers’ performance, then account for growth and scalability of both the services performed
by each system and the type and quantity of users and transactions of each system.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

11

System Compatibility
In addition to evaluating a system against published minimum requirements and current and future
needs, you must also ensure, before installing any edition of Windows Server 2003, that the server’s
hardware and the applications it will support are compatible with Windows Server 2003.

The Windows Catalog: HCL on steroids
To facilitate hardware compatibility evaluation, Microsoft publishes the Windows Catalog, formerly
called the Hardware Compatibility List (HCL). An online, searchable version of the Windows Catalog
is available at http://www.microsoft.com/windows/catalog/server/.
The catalog is a directory of Windows Server 2003 compatible hardware that Microsoft’s Windows
Hardware Quality Labs (WHQL) tested and approved. The Windows Catalog is dynamic and grows
regularly over the lifecycle of the OS as vendors develop new hardware and Microsoft tests and
certifies it for compatibility.
Devices that pass the hardware compatibility tests are given the following benefits:
• designation with the “Designed for Microsoft Windows Server 2003” logo
• listing in the Windows Catalog
• Microsoft signed drivers that can be installed without intervention
• driver updates distributed through Windows Update
Keep in mind that Microsoft performs the compatibility certification and its labs are not a charity.
Companies must pay for Microsoft’s compatibility testing, and some companies simply don’t. Thus a
device or application not listed in the Windows Catalog can, in fact, be compatible. You will often
need to rely on the vendor’s statements regarding compatibility and weigh those statements against
the risk that the device or application might not be quite as compatible as the vendor asserts.
Similarly, although a device listed in the Windows Catalog is likely to perform as desired, you must
nevertheless perform adequate testing to ensure that you won’t have surprises given the unique
combination of hardware and applications in your environment.

Application compatibility
Although most administrators are aware of the need to evaluate hardware compatibility, I have seen
far too many administrators underestimate the importance of verifying application compatibility. A
new resource exists to facilitate the evaluation of applications. Microsoft has partnered with VeriTest
to perform compatibility analyses of third-party applications. The result is the Catalog of Certified
Server Applications available at http://cert.veritest.com/CfWreports/server. In the near future, the
Windows Catalog will list certified applications along with the hardware devices.
VeriTest examines stability, manageability, and security. The applications that meet its demanding
standards earn the Certified for Microsoft Windows Server 2003 logo. VeriTest is the only lab
authorized to perform these analyses. Although Microsoft sometimes seems not to be listening to
customers (except the biggest ones), the high-level requirements for application compatibility
demonstrate that Microsoft understands the pain we face in the trenches.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

12

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Certification Standards for Standard Edition are
• Windows fundamentals
• no unplanned downtime
• driver verification
• correct installation
• no restarts
• support for smart card log on
• secure desktop
• secure network communication
• security templates
• graceful degradation that does not bring down services
• no user UI for services running as LocalSystem
Certification Standards for Enterprise Edition are all Standard Edition requirements, plus
• no cluster vulnerabilities
• compatibility with virus scanning
• test for crash recovery
• appropriate resource use
Certification Standards for Datacenter Edition are all Enterprise Edition requirements, plus
• ability to run on 8-processor or 32-processor systems
• stability testing under stress
• driver verification under stress and driver interface stress testing
• test for crash recovery under stress
• availability of debug symbols or tools
• round-the-clock support availability
Supplementary and Optional Certifications are
• optimized for use with AD services
• optimized for use with Terminal Services technologies
• optimized for manageability
Applications that meet these high-level requirements as well as significantly more detailed
specifications receive the Certified for Microsoft Windows Server logo, which indicates that an
application is likely to perform as desired. As with hardware, you must also perform testing to
evaluate an application’s compatibility with your environment. In many instances, third-party software
companies and in-house developers won’t have submitted their applications to VeriTest, so you must
rely on their assertions of compatibility and their support policies in the event something goes wrong.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

13

Compatibility tools and resources
Windows Server 2003 includes diagnostic and configuration utilities to help automate the evaluation
of compatibility. Before upgrading a server to Windows Server 2003, you need to run Windows
Upgrade Advisor, which using a wizard-driven interface analyzes the current hardware and software
environment of the server, compares the information it gleans to the Windows Catalog, and reports
any compatibility concerns it identifies.
After you insert a Windows Server 2003 CD-ROM and the graphical setup program loads, you
can select the Check System Compatibility link, and then select the Check My System Automatically
link to access the Upgrade Advisor tool. You can also launch Upgrade Advisor from the command
line by issuing the command
cd-rom:\i386\winnt32.exe /checkupgradeonly
As we previously mentioned, confirmation of compatibility by the Upgrade Advisor is a good
indicator but is not a substitute for your own testing. Similarly, a report of a compatibility problem
doesn’t mean a device or application won’t function perfectly well in your environment.

Upgrade vs. Migration
To move from a Windows 2000 Server or NT 4.0 domain, you need to update your current directory
service. Depending on your business needs, functional requirements, and environment, you can
choose from two upgrade paths: upgrading existing DCs and servers or performing clean installations
that involve migrating data, applications, and settings.
Windows Server 2003 supports upgrades from Windows 2000 Server and NT 4.0. Companies that
choose to upgrade believe upgrading is the simpler process because it lets the directory maintain
existing user accounts, settings, groups, rights, and permissions. Upgrading also can avoid the need to
reinstall applications. We provide details about upgrading later in the book and you will see that the
perception of simplicity is quite distant from the reality. To perform a complete and clean upgrade,
you need to perform many preparatory and follow-through steps that make it not so simple after all.
Our experience is that upgrading is effective—it works. However, upgrading is generally best
only in situations where the environment is very straightforward or migration needs to take place at
an extremely rapid pace. The most underestimated disadvantage of upgrading is that it does not
encourage a complete and thorough inventory and examination of the IT environment. Therefore
upgrading does not encourage rethinking the role and processes of IT to better leverage and reflect
new directory service driven enterprise technologies.
True migration requires you to introduce a new system (in this case a new server with a new
directory service) into the environment and move all relevant components to the new system. As
such, you can theoretically migrate from any other platform to Windows Server 2003 with the right
tools. Microsoft provides ADMT to facilitate migrations from Windows 2000 Server and NT 4.0.
Third-party companies produce applications to migrate from Netware, Bindview, and other directory
services.
Because migration provides a clean start, you receive a guarantee that misconfigurations, bugs,
and other problems won’t carry over from old system to the new system. Given Windows Server
2003’s impressive security, this guarantee is an important consideration; you don’t want to risk

Brought to you by NetIQ and Windows & .NET Magazine eBooks

14

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

increasing security vulnerability by carrying over pathetic configurations from NT 4.0 or even
Windows 2000 Server.

Upgrading
Table 1.3 describes the supported upgrade paths from Windows 2000 Server and NT 4.0 Server
editions to Windows Server 2003 editions. Note that you cannot upgrade to Windows Server 2003,
Web Edition from any earlier platform.
Table 1.3: Windows Server 2003 Supported Upgrade Paths
NT Server 4.0
NT 4.0, Terminal Server Edition
NT Server 4.0, Enterprise Edition
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter Server

Standard Edition
X
X
X

Enterprise Edition
X
X
X
X
X

Datacenter Edition

X

Be aware that to upgrade to Windows Server 2003 from any NT 4.0 edition, you must install
Service Pack 5 (SP5) or later. Also note that Windows Server 2003 doesn’t support direct upgrades
from NT versions earlier than NT 4.0. As such, an upgrade from NT 3.51 first requires you to upgrade
to Windows 2000 Server or NT 4.0, then upgrade again to Windows Server 2003. In such cases, a
clean installation is almost always the better choice.
The basic process of upgrading is to simply insert the installation CD-ROM and let the Setup
Wizard upgrade the system. In an NT 4.0 domain, you begin with the PDC, then upgrade the BDCs.
In a Windows 2000 Server domain, the order is not as important. To perform a clean and complete
Windows Server 2003 upgrade of a domain, the steps are somewhat more complex, and we explain
them later in this book.

Migrating
Migration is typically a more complex process but with significant return on effort. By carefully
evaluating, planning, testing, piloting, and implementing a migration, your organization will benefit
from a well-documented, well-thought-out enterprise network. Such a network will align with and
support business strategies and will adapt and flex with the business as its needs and functional
requirements change over time. These are significant strategic benefits to migrating, although difficult
to quantify.
The most important consideration in migration is the management of identities and security
permissions. Although we explore this topic in depth in coming chapters, you need to understand
the major thrust of the issue.

Security IDs
Windows directory services (in Windows Server 2003, Windows 2000 Server, or NT domains)
maintains identity information about security principals. Security principals are identities that you can
assign logon rights, system privileges, or permissions to resources such as files and printers. The most
common security principals are users, groups, and computers. Windows Server 2003 adds a new
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

15

security principal, inetOrgPerson, for compatibility with other directory services. A security principal’s
identity information refers to attributes in the directory that describe and enable it; you probably refer
to this as an account. For example, a user object in AD includes the properties, such as username
and password, which let the directory authorize a user. So while a user object in AD is an account, it
is also much more because it contains information including phone numbers, managers and direct
reports, organizational information, and email addresses.
What identifies a security principal is a unique number, the SID, assigned to a newly created
object. Each security principal (i.e., user, group, computer, and inetOrgPerson) has a SID unique in
the domain. That SID appears on ACLs that define resource access permissions for files, folders,
printers, registry keys, and much more.
When you migrate an account from an earlier version (i.e., Windows 2000 Server or NT 4.0)
domain to a Windows Server 2003 domain, you create a new security principal in the Windows
Server 2003 AD and populate that object’s attributes with the attributes (e.g., name, username,
password, home directory) from the account in the earlier version domain. All the important attributes
will copy except the SID, which the new directory service creates.
Therefore a user can log on to the new domain with the same username and password. But
after receiving authorization, that user receives a SID from the new domain, and that SID won’t allow
access to resources previously secured using the old account’s SID. The same thing happens for
groups. So you can end up with a situation where the new directory service looks like it maintains
the same user and group accounts as the old domain, but nobody can access resources that they
accessed in the old domain. You can choose from two methods to address what would otherwise
be a disastrous problem.

Repermissioning resources
The first method is to repermission resources, which replaces permissions that point to accounts in
the old domain with permissions that refer to the appropriate security principals in the new domain.
Although repermissioning resources results in a completely clean migration, with no vestiges of
accounts or SIDs from the old domain, it can be extremely complex, time consuming, and subject
to error.

SID History
The second method uses an attribute for security principals called sIDHistory. Windows Server 2003
AD supports this attribute, which stores SIDs from previous accounts. When you migrate a user
account from a Windows 2000 Server or NT 4.0 domain, you can elect to copy its SID into the
sIDHistory attribute of the security principal in the new domain. When the user logs on, their identity
then consists not only of SIDs from the new domain user account and the groups to which the user
belongs but also of the SIDs from the sIDHistory of the user and group objects. Then, when the user
attempts to access a resource that contains permissions on the ACL referring to the old domain SID,
the SIDs from the SID history allow access at the same level as before.
This method is a creative and effective solution to the challenge of migrating identities. The
disadvantage is that this method leaves behind engorged security tokens (the collection of SIDs and
sIDHistories) and with resources that are secured with old identities. In other words, you have a bit
of bloat remaining.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

16

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

A common solution
Many organizations use sIDHistory to provide the user with an uninterrupted experience and to
maintain security and resource access levels after migration. Over time they repermission resources to
refer only to the SIDs in the new domain, then after completing the repermissioning, remove the SID
histories of security principals.
These processes are intensive but luckily many tools, particularly from third-party vendors such
as NetIQ, Aelita, or Quest can help. We examine the factors that might lead you to use of one or
more of these tools in Chapters 2–5.

Evaluating Exchange Server 2003’s New Capabilities and Features
Exchange Server 2003 is the latest release of Microsoft’s widely adopted messaging and groupware
platform. In 1996 Microsoft introduced Exchange Server 4.0 to replace its aging Microsoft Mail (MS
Mail) product. The initial Exchange Server release ran on NT Server 3.51. Throughout the next
several years, Exchange Server became a popular messaging system for large, medium, and small
organizations worldwide. In February 1997, Microsoft released Exchange 5.0, which ran on NT 4.0
and 3.51. Then in November 1997, Exchange Server came of age as a mature, robust messaging and
groupware solution. Exchange Server 5.5 supports messaging databases over 16GBs and offers
support for 2-node active and passive clustering. Exchange Server 5.5 introduces other important
technology such as support for IMAP4, the Deleted Item Recovery server-side feature, the Outlook
Web Access (OWA) client, and server-side event scripting.
In October 2000, Exchange 2000 Server entered the market. This Exchange Server edition doesn’t
maintain its own directory. Instead, Exchange 2000 Server relies completely on Windows 2000 Server
AD for its directory service. Exchange 2000 Server runs only on Windows 2000 Server (i.e., not on NT
4.0 or Windows Server 2003). The only Microsoft-based messaging solution that runs on both
Windows Server 2003 and Windows 2000 Server is Exchange Server 2003.

Exchange Server 2003 Editions
Like the Windows Server 2003 editions, Exchange Server 2003 comes in two bundles to target specific
customer types. The Standard Edition is designed for small- and mid-size organizations, supporting
a messaging database store of up to a maximum of 16GBs. The Standard Edition also offers support
for the new Recovery Storage Group, which acts as a temporary database store for holding restored
mailboxes when restoring from backup. After you restore mailbox data to the Recovery Storage
Group, you can then merge the restored data with the original mailbox store. In this way, you have
the option of restoring the entire mailbox store or just selected, individual mailboxes.
In contrast to Exchange 2000 Server’s Standard Edition, you can configure Exchange Server 2003,
Standard Edition as a front-end protocol server. Exchange 2000 Server lets you use only the Enterprise
Edition as a front-end protocol server. A front-end server can service incoming requests from clients
to one or more back-end servers that store mailboxes and public folders. You can use several
different messaging protocols (e.g., POP3, SMTP, IMAP4, and HTTP) to configure front-end servers
to communicate with clients.
Both editions of Exchange Server 2003 also support query-based distribution lists (DLs). You
can use the Lightweight Directory Access Protocol (LDAP) to set up AD-based queries that dynamically update DLs. For example, you can create a query-based DL to include only the current sales

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

17

managers so that each time a user sends a message to that query-based DL, the LDAP query runs and
selects only current sales managers. Members who are no longer sales managers won’t be on the DL.
The Exchange Server 2003, Enterprise Edition, designed for medium to large organizations,
supports a virtually unlimited messaging store (i.e., up to 16TBs) and allows multiple messaging
databases per server. Whereas the Standard Edition allows only one storage group, which supports a
maximum of two messaging databases per server, the Enterprise Edition allows up to four storage
groups and each storage group can contain up to five messaging databases (thereby supporting up to
20 messaging databases when you use all four storage groups). The Enterprise Edition uses Windows
2000 Advanced Server to support clustering of up to two nodes, Windows 2000 Datacenter Server to
support clustering of up to four nodes, and both Windows Server 2003 Enterprise Edition and Datacenter Edition to support clustering of up to eight nodes. The Enterprise Edition includes support for
the X.400 connector to connect Exchange Server to other email systems; the Standard Edition does
not support the X.400 connector.

Retired Features
Although Microsoft added and enhanced many features in Exchange Server 2003, it also incorporated
features into other products and dropped them from the Exchange Server 2003 product line.
Exchange Server 2003 lacks the following major features:
• the Lotus cc:Mail Connector
• the MS Mail Connector
• the Instant Messaging (IM) Service
• an automatically mapped M drive
• Key Management Service (KMS)
• Mobile Information Server
• the Exchange Conferencing Server optional add-on product
You can only use the Exchange System Manager (ESM) for Exchange 2000 Server SP3 or later
systems to manage MS Mail or Lotus cc:Mail Connectors. ESM for Exchange Server 2003 does not
support the MS Mail or cc:Mail connectors. And neither Exchange Server 2003 edition includes these
connectors. When upgrading Exchange 2000 Server to Exchange Server 2003, you must uninstall any
instances of these two connectors before you perform the upgrade. To maintain these connectors, do
not upgrade to Exchange Server 2003 on any server with these components installed; install Exchange
Server 2003 on other servers in your network environment.
The Exchange Server data store uses the Universal Naming Convention (UNC) \\.
\BackOfficeStorage\mail.domain.name\mbx for the location of the mailbox store. Exchange 2000
Server automatically maps the drive letter M to this default location. Unfortunately, by mapping the
M drive to this location, the mailbox store can become corrupt due to file-level antivirus software
scans or due to other file system procedures such as backup operations. For these reasons, Microsoft
has removed the automatic drive mapping in Exchange Server 2003 and Microsoft recommends that
you disable the default M drive mapping for Exchange 2000 Server installations as well. You can
learn how to disable the M drive mapping under Exchange 2000 Server by reading the Microsoft

Brought to you by NetIQ and Windows & .NET Magazine eBooks

18

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Knowledge Base Article 305145, “HOW TO: Remove the IFS Mapping for Drive M in Exchange 2000
Server” at http://support.microsoft.com/?kbid=305145.
With Exchange Server 2003, KMS is no longer necessary for sending digitally signed and
encrypted messages. Exchange Server 2003 supports standard X.509v3 certificates and works with
applications that use public key infrastructure (PKI) services that also support the X.509v3 certificate
standard. Therefore, you can use the enhanced version of PKI that ships with Windows Server 2003
to enroll users in advanced security and to manage public or private key archival and recovery
operations. In Exchange 2000 Server, KMS performs these functions.
Exchange Server 2003 now offers Outlook Mobile Access (OMA) for mobility support, so it
doesn’t support Mobile Information Server. Before you upgrade an Exchange 2000 server to Exchange
Server 2003, you need to remove Mobile Information Server.
The Exchange 2000 Server Conferencing Server add-on (which is an optional component that
you can purchase separately and install) is not available for Exchange Server 2003. Under Exchange
2000 Server, the Conferencing Server software provides real-time collaboration features such as IM,
chat, conferencing, and multimedia (or unified) messaging. Before upgrading Exchange 2000 Server to
Exchange Server 2003, you must remove these Conferencing Server components. RTC Server 2003
and LC Server 2003 replace and improve on the capabilities of Exchange 2000 Server Conferencing
Server. LC Server 2003 does not require Exchange Server 2003. However, LC Server has hefty
requirements, including an Intel-compatible Pentium III 1.4GHz or faster processor, at least 2GBs of
RAM, Windows Server 2003, and AD hosted by either Windows Server 2003 or Windows 2000 Server.

Security Enhancements
Exchange Server 2003 and Outlook 2003 can now use the Kerberos authentication protocol to
validate users. AD under Windows Server 2003 permits user authentication from a different AD forest
(cross-forest authentication) to DCs in a trusted forest. This feature lets user accounts and Exchange
servers reside in different forests. Organizations no longer need to use IP Security (IPSec) to encrypt
user credentials for front-end and back-end server communication. Exchange Server 2003 now uses
Kerberos delegation when sending user credentials between Exchange front-end and back-end
servers. Earlier Exchange Server versions used Basic authentication to transmit user credentials
between Exchange front-end and back-end servers.

Manageability Improvements
You can now monitor performance statistics for Outlook 2003 users when you purchase and install
MOM. Although you must purchase the MOM software product separately, Microsoft includes the
MOM Management Pack at no extra charge in both Exchange Server 2003 editions. For more
information about MOM, go to the Microsoft Web site at http://www.microsoft.com/mom. You can
use MOM and the Exchange Server 2003 Management Pack with numerous Outlook 2003 client-side
performance counters such as client remote procedure calls (RPCs) attempted, client RPCs succeeded,
client RPCs failed, and client latency greater than two RPCs per second.

Antispam Features
To support the reduction or elimination of unsolicited commercial email (UCE), Exchange Server 2003
implements connection filtering based on Block lists. Connection filtering works in conjunction with

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

19

third-party solutions that provide lists of known sources responsible for UCE, lists of dial-up user
accounts, and lists of email servers configured for open relay that allow UCE. With connection
filtering, you can set up global accept and deny lists based on IP addresses. You can also configure
specific recipient addresses as exceptions to global filtering rules. You can set up global accept and
deny lists whether you use a block list service provider or not. When Exchange Server 2003 receives
an email message from a sender listed on a block list, it sends an SMTP 550 5.x.x error message as a
response to the sender of the message. You can configure multiple connection filters and you can
specify the priority that you want them applied.

Backup Features
Exchange Server 2003 fully supports the new Volume Shadow Copy Service (VSS) along with the
new VSS API calls for creating backups. With Windows Server 2003, backup software can use either
the Windows 2000 Server-based API or the VSS API to backup data. (Windows 2000 Server does not
support VSS.) At the start of the backup operation VSS creates a shadow copy (also called a
snapshot) of the drive volumes where data will be stored. At that point, Exchange Server 2003
redirects the backup program and uses the VSS API to copy the data from the shadow copy snapshot
(instead of copying the data directly from disk). As a result, normal Exchange Server operations can
continue unaffected by the backup procedure. And the backup software can copy all the data onto
the backup media even when the data is in use. In addition, VSS promises to make tape backups a
thing of the past because you can very quickly transfer a shadow copy to another disk or disk array
on another computer. Note two important points about shadow copy backups:
1. Exchange Server 2003 supports VSS only for normal and copy backup operations, not for
incremental or differential backups.
2. The Windows Server 2003 Backup utility that ships with the OS does not support VSS for
the Exchange Server 2003 message store. You must purchase and install a backup solution from a
third-party vendor that supports shadow copy backups for Exchange Server 2003. The Backup Utility
does support VSS for file-level backups.
Exchange Server 2003 also supports the Recovery Storage Group feature. The Recovery Storage
Group can coexist with normal storage groups, even when four storage groups already exist on a
server running the Enterprise Edition. When you restore a messaging database to the Recovery
Storage Group, you can use the Exchange Server Mailbox Merge (Exmerge) utility to move one or
more recovered mailboxes from the Recovery Storage Group to a database in one of the standard
storage groups. You can choose to recover a complete mailbox store including the Exchange log files
or you can select one or a few mailboxes to restore. The Recovery Storage Group feature supports
the recover of only mailbox stores; it does not support the recovery of public folder stores.

Mobile Access: OWA, OMA, and RPC Over HTTP
OWA for Exchange Server 2003 has significant improvements over OWA for Exchange 2000 Server.
OWA 2003 is a full-featured email client almost indistinguishable from Office Outlook 2003. OWA
now includes support for message rules, spell check, and digitally signed and encrypted email
messages. Microsoft redesigned the OWA UI to match Outlook 2003 as closely as possible to provide
the user the same experience as with Outlook 2003. OWA even includes the navigation pane and the

Brought to you by NetIQ and Windows & .NET Magazine eBooks

20

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

reading pane, as Figure 2 shows. Like Exchange 2000 Server, Exchange Server 2003 automatically
installs OWA.

Figure 2:
Viewing the OWA for Exchange Server 2003

Exchange Server 2003 offers two OWA versions: OWA Premium and OWA Basic. OWA Premium
requires Microsoft Internet Explorer (IE) 5.01 or later to take advantage of most of the new features.
OWA requires IE 6.0 or later for some new features, such as sending and receiving digitally signed
or encrypted email messages, and IE 6.0 SP1 or later to support data compression and to clear the
user credentials cache during logoff. OWA Basic supports earlier version Web browsers and Web
browsers not compatible with the IE 5.01 and later feature set. OWA Basic supports browsers
compatible with the HTML 3.2 and ECMA scripting standards. OWA Basic supports only a subset of
the OWA Premium features. For example, OWA Basic lacks support for the reading pane, the
two-line mail view, search folders, public folders, and spell check. OWA Premium supports all these
features.
Outlook Mobile Access (OMA) is a new remote mobility feature built into Exchange Server 2003
to replace Exchange 2000 Server’s Mobile Information Server. OMA lets users use mobile devices
with Web browsers installed (e.g., mobile phones and PDAs) to access their Mailbox, Contacts,
Calendar, and Tasks folders. OMA supports mobile devices that support one of the following
hypertext markup languages: HTML, Compact HTML (cHTML), or Extensible HTML (XHTML).
Exchange Server 2003 automatically installs and disables OMA. You must enable OMA for users to
connect to Exchange Server 2003 with their mobile devices. From the mobile device’s browser, type

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

21

https://ExchangeServerName/oma to connect to OMA (Replace ExchangeServerName with the name
of the Exchange server hosting OMA.)
Exchange Server 2003 also lets you use Pocket PC 2002 and other devices to synchronize
Exchange data with Exchange ActiveSync. When you install Exchange Server 2003, it automatically
enables synchronization. When users synchronize a mobile device to an Exchange Server 2003 server,
they can access their information without staying connected to a mobile network. In this way, users
can use their wireless Internet connections to synchronize their Exchange information to their Pocket
PC Phone Edition or smart phone devices, then work offline with this information.
With RPC over HTTP, mobile computer users can securely access their mailboxes on Exchange
Server 2003 over a standard Internet connection (without requiring a VPN). RPC over HTTP uses
HTTP packets to encapsulate RPC calls so that Outlook 2003 clients and Exchange Server 2003
servers behind firewalls on different networks can securely communicate. RPC over HTTP requires
Exchange Server 2003 and Windows Server 2003. DCs and global catalog servers accessed for RPC
over HTTP must also run Windows Server 2003. You must create at least one front-end server running Exchange Server 2003 to act as the RPC Proxy Server. All client computers using RPC over
HTTP to connect must run Outlook 2003 and Windows XP SP1 or later, plus you must install the
RPC patch for Windows XP as discussed in the Microsoft Knowledge Base article 331320 “Outlook
2003 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through
HTTP” at http://support.microsoft.com/?kbid=331320.

New Features for the Outlook Client
Microsoft designed Office Outlook 2003 to take full advantage of Exchange Server 2003’s new
features and enhancements. Using the new Cached Exchange Mode, Exchange Server 2003 and
Outlook 2003 need to communicate much less frequently because when possible Outlook 2003
stores each user’s mailbox data on the local workstation. This reduces RPCs and overall network
traffic between Outlook 2003 clients and Exchange Server 2003. Additionally, the data sent between
Outlook 2003 clients and Exchange Server 2003 servers is compressed. Therefore data synchronization
between clients and servers is faster and less frequent. On low-bandwidth, high-latency networks, this
greatly improves the user experience because the user primarily accesses their data from the locally
cached Exchange Server 2003 mailbox rather than the server. When the network connection goes
down, Outlook 2003 continues to function without throwing a tantrum. When using Cached
Exchange Mode, which Figure 3 shows, keep in mind that users with Offline Folder (.ost) files that
exceed 1.5GBs can slow down Outlook 2003’s performance. You can turn off the Cached Mode
Exchange feature for users with large .ost files, or better yet, have those users archive some email
messages!

Brought to you by NetIQ and Windows & .NET Magazine eBooks

22

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 3:
Configuring a new email account to use Cached Exchange Mode in Office Outlook 2003

Microsoft redesigned the Outlook 2003 interface, which Figure 4 shows, to make it easier and
faster to use. The navigation pane replaces the Outlook bar by integrating the basic navigation and
share features of Outlook into a central, easy-to-use location. When using the Inbox, now named
Mail, users see more mail folders than before, and they can move their favorite folders to the top of
the list. In Calendar, users can view other users’ shared calendars side-by-side along with their
Calendar. In Contacts, Microsoft improved the ways users can view their contacts. Now users can see
the list of all contacts folders they can open (whether stored on their local computer or on a network
location). Microsoft designed all the Outlook 2003 modules to help users quickly find what they need
and view it in the format they want.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

23

Figure 4:
Showing the redesigned Outlook 2003 interface

The redesigned reading pane displays email messages vertically. This layout is easier on the eyes
and with the new multiline message list, users can view nearly twice as much of an email message
on the same size monitor as compared to the preview pane in earlier Outlook versions. With the
reading pane users no longer need to open a separate window to read each email message. New
search folders contain constantly updated search results of all email messages matching specific
search criteria. Users can use the default search folder named Unread Mail to view all unread email
messages in every folder of their mailbox. To help reduce the size of users’ mailboxes, the Large Mail
search folder displays a user’s largest messages, regardless of which folder stores the message. To
create Search Folders users can also select from a list of predefined templates or create a custom
Search Folder.
Outlook 2003 now offers an integrated antispam feature called Junk E-mail filtering. An algorithm
in the product analyzes incoming messages for spam-like characteristics. Users can choose from four
settings:
1. The low setting moves obvious junk email messages to the Junk E-mail folder.
2. The high setting catches most junk email messages along with some regular email messages as
well. Users must check the Junk E-mail folder for messages that have incorrectly been identified as
junk email messages.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

24

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

3. The Safe Lists Only setting moves all email messages into the Junk E-mail folder except
messages from addresses listed on the Safe Senders list or the Safe Recipients list.
4. The No Automatic Filtering moves only email messages from addresses listed on the Blocked
Sender list into the Junk E-mail folder.
Outlook 2003 now supports two file formats for Personal Folder (.pst) files. For compatibility
with earlier Outlook versions, Outlook 2003 still supports the legacy .pst file format. In addition,
Outlook 2003 supports an enhanced .pst file format that allows .pst files to grow beyond the former
2GB limit to offer greater storage capacity. And this new format supports multilingual Unicode data.
Unfortunately, when you use the new Outlook 2003 Personal Folder file format to create .pst files,
those files are not compatible with earlier Outlook versions.

An Overview of Exchange Server 2003 Deployment and Migration
Much like Windows Server 2003, Exchange Server 2003 represents an evolutionary upgrade from its
previous release with significant improvements in security, manageability, scalability, stability, and
availability. Many organizations that delayed their Exchange migrations want to move directly to
Exchange Server 2003, and for good reason. In fact, Exchange server migrations are likely to drive
organizations to move from NT 4.0 directory services to AD.
If you have decided that Exchange Server 2003 is the right messaging platform for your
environment, you need to spend sufficient time evaluating hardware, deployment options, and
migration considerations.

Hardware Requirements
Microsoft’s published minimum requirements for Exchange Server 2003 are as follows:
• Intel-compatible Pentium processor running at 133MHz or faster
• 128MB of RAM (256MB of RAM recommended)
• 500MB of available disk space on the drive volume where you will install Exchange Server 2003
• 200MB of available disk space on the system drive volume
• CD-ROM drive
• VGA or better display adapter and monitor

OS Requirements
Exchange Server 2003 supports Windows Server 2003 and Windows 2000 Server SP3 or later.
Exchange Server 2003 requires the NTFS file system for the system drive volume and the Exchange
Server 2003 drive volumes. Exchange Server 2003 drive volumes include the volume that stores the
Exchange Server 2003 program files, volumes that store the transaction log files, volumes that store
the messaging database files, and any other volumes that hold Exchange-related files. During
Exchange Server 2003 Setup, the installation program needs to contact at least one AD DC running
Windows Server 2003 or Windows 2000 Server SP3 or later within the same AD site.
To install Exchange Server 2003 under Windows Server 2003 or Windows 2000 Server SP3 or
later, you must install and run the Network News Transfer Protocol (NNTP) service, the SMTP service,
and the World Wide Web (WWW) Publishing Service on the server to which you want to install

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

25

Exchange Server 2003. In addition, you must install the ASP.NET subcomponent of the Application
Server Windows component in the Add or Remove Programs dialog box.

Optimized for Windows Server 2003
Exchange Server 2003 takes advantage of many Windows Server 2003 improvements. Windows Server
2003 provides enhanced administration capabilities and increased performance features. AD benefits
from Windows Server 2003 DCs because of the reduced network traffic between replicas; the ability
to install an additional DC at a branch office using tape, CD, or DVD media; and the ability to roll
back changes made to the AD schema. If you plan to upgrade from Exchange 2000 Server to
Exchange Server 2003, you must first upgrade to Windows Server 2003. Windows Server 2003 does
not support Exchange 2000 Server.
Although Windows 2000 Server SP3 or later supports Exchange Server 2003, many Exchange
Server 2003 features are not available running under Windows 2000 Server. Features and technology
not supported include RPC over HTTP, four-way P4 Xeon processors, messaging store database
backups using VSS, and data compression with OWA.
Exchange Server 2003 also takes advantage of the improved memory management technology in
Windows Server 2003. Windows Server 2003’s improved memory allocator results in less virtual
machine (VM) memory fragmentation. For servers with more than 1GB of RAM installed, Windows
Server 2003 Datacenter, Enterprise, and Standard editions support the boot.ini file’s /3GB command
line switch, which allocates up to an extra 1GB of memory to applications. In Windows 2000 Server,
only Datacenter and Advanced Server editions support the /3GB switch. When using the /3GB
switch, we recommend that you also use the new /Userva=3030 parameter with it. For more
information about the /3GB and the /Userva=3030 switches, see Microsoft Knowledge Base article
810371 “XADM: Using the /Userva Switch on Windows Server 2003 Server-Based Exchange Servers”
at http://support.microsoft.com/?kbid=810371 and Microsoft Knowledge Base article 316739 “How to
Use the /USERVA Switch in the Boot.ini File to Tune /3GB Configurations” at
http://support.microsoft.com/?kbid=316739.

Interoperability with Exchange 2000 Server and Exchange Server 5.5
Microsoft includes backward compatibility options in Exchange Server 2003. Therefore, Exchange
Server 2003 can coexist with Exchange 2000 Server and Exchange Server 5.5.

Mixed Mode vs. Native Mode
Like Exchange 2000 Server, Exchange Server 2003 supports a default configuration called mixed
mode, which is backward compatible with Exchange Server 5.5 environments. However, in mixed
mode, you cannot realize the full capabilities of Exchange Server 2003. To take advantage of the new
features you must switch your Exchange Server 2003 environment to native mode. Keep in mind that
switching to native mode is a one-time option that you cannot reverse! Under native mode, Exchange
Server 2003 offers the following features:
• SMTP is the default routing protocol
• query-based distribution groups are available
• mailboxes can be moved between administrative groups
• servers can be moved between different routing groups
Brought to you by NetIQ and Windows & .NET Magazine eBooks

26

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• routing groups can reside on servers from different administrative groups
• routing bridgehead servers employ more efficient 8-bit MIME data transfers (instead of 7-bit data
transfers), which results in lower bandwidth requirements

Coexistence and Upgrades
In mixed mode, Exchange Server 2003 can coexist with Exchange Server 5.5 and Exchange 2000
Servers. In native mode, Exchange Server 2003 can only coexist with Exchange 2000 servers. For
Exchange Server 5.5 servers, you can only perform migration upgrades; you must first join an
Exchange Server 2003 to an Exchange Server 5.5 site, then you can move mailboxes, public folders,
and other resources to the new Exchange Server 2003 organization. Exchange Server 2003 does not
support in-place server upgrades from Exhange 5.5; you cannot directly upgrade a physical Exchange
Server 5.5 server to Exchange Server 2003. Microsoft also recommends against in-place server
upgrades from Exchange Server 5.5 to Exchange 2000 Server. A new and improved AD
Connector (ADC) ships with Exchange Server 2003 to synchronize objects between an Exchange
Server 5.5 directory and AD. When upgrading from Exchange 2000 Server, the Exchange Server 2003
Setup program supports both in-place upgrades on a single server and migration using a new
Exchange Server 2003 server.

Installation and Deployment Improvements
The improved and enhanced Exchange Server 2003 Setup program makes performing new
installations and upgrades easier. Setup no longer requires Exchange Server Full Administrator
permissions at the organization level for the user account that installs additional Exchange Server 2003
servers within an Exchange organization. However, Setup requires Full Administrator permissions for
the administrator who installs the first Exchange Server 2003 server within a domain. Also, the
Exchange Server 2003 Setup program no longer contacts the DC that has the Schema Master role. In
Exchange 2000 Server, Setup contacted the DC that held the Flexible Single-Master Operations
(FSMO) role for the AD schema each time it installed Exchange 2000 Server on a server.
When you install Exchange Server 2003 on multiple servers simultaneously, you can now use the
new /ChooseDC switch, which Figure 5 shows, on the setup.exe command line to specify the DC
that you want the setup program to read from and write to. If you make sure that each new
Exchange server accesses the same DC, then you won’t encounter replication problems between
different DCs, which can cause installations to fail. When you install or upgrade the first Exchange
server, this installation assigns the default permissions for the Exchange Organization. These
permissions, which are assigned only once, are assigned during that first installation or upgrade.
Subsequent installations or upgrades of Exchange servers within the same organization do not
reassign or overwrite permissions as Exchange 2000 Server did. In this way, any custom permissions
remain in place with additional Exchange Server installations.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

27

Figure 5:
Displaying the command line switches for the Exchange Server 2003 setup program

To install Exchange Server 2003 for the first time within an AD forest, you must run SETUP
/forestprep to prepare the forest and make the necessary schema additions, SETUP /domainprep to
prepare the domain for Exchange, then run SETUP without any switches to install the Exchange
Server application itself. Note that because of the increased network and replication traffic you need
to run both the ForestPrep process and the DomainPrep process during non-production hours. You
need to run the ForestPrep process only once in each forest and the DomainPrep process only once
in each domain. Before you can install Exchange Server 2003, you need to install the following
services and components on the server:
• ASP.NET
• .NET Framework
• IIS
• WWW Publishing Service
• SMTP
• NNTP
Fortunately, the Exchange Server 2003 Deployment Tools can guide you through the installation
process. The Exchange Server 2003 CD-ROM includes these tools and the Exchange Server 2003
Welcome screen (which appears after inserting the CD-ROM into the drive) encourages you to take
advantage of these useful tools.
Exchange Server 2003 automatically secures all messaging database stores. Therefore Exchange
administrators do not inherit permissions to read messages stored in other users’ mailboxes. Out of
the box Exchange Server 2003 supports remote mobile access features. The Exchange Server 2003

Brought to you by NetIQ and Windows & .NET Magazine eBooks

28

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Setup installs the new OMA and the Exchange Server ActiveSync services automatically. Exchange
Server 2003 doesn’t support the Exchange 2000 Server Mobile Information Server product. For OMA
to operate, you must install the .NET Framework component. When upgrading from Exchange 2000
Server running under Windows 2000 Server, the Exchange Server 2003 setup installs the .NET
Framework and the ASP.NET components automatically.
Just as with Exchange 2000 Server, Exchange Server 2003 relies heavily on IIS for features such
as SMTP, NNTP, ASP.NET, Web Distributed Authoring and Versioning (WebDAV), and OWA. Under
Windows Server 2003, Exchange Server 2003 setup automatically configures IIS 6.0 for the new
worker process isolation mode, which provides improved robustness and security for Web services.
The new setup program also turns on an assortment of required extensions for the Internet Server
API (ISAPI). These ISAPI extensions provide support for features such as OWA, WebDAV, and
Exchange Server 2003 Web forms. Windows Server 2003 prohibits ISAPI extensions from
automatically loading. However, Exchange Server 2003 Setup bypasses this setting and automatically
configures the necessary ISAPI extensions. After Exchange Server 2003 installs, avoid modifying the
IsapiRestrictionList metabase key, which controls the behavior for ISAPI extensions. Altering this
metabase key after the Exchange Server 2003 installation can cause some Exchange Server 2003
features to not function or to function incorrectly.
If you install Exchange Server 2003 on Windows 2000 Server, then later upgrade the OS to
Windows Server 2003, the Exchange System Attendant will automatically configure IIS 6.0 to operate
in worker process isolation mode because Exchange Server 2003 features such as OWA, WebDAV,
and Web forms will not function under IIS 5.0 isolation mode for IIS 6.0. Unfortunately some older
Web applications might not operate properly under IIS 6.0 worker process isolation mode so you
might need to move those applications to a different server. You can remotely manage servers
running Exchange Server 2003 from computers running Windows 2000 Server SP3 or later, Windows
2000 Server Professional SP3 or later, Windows XP Professional Edition SP1 or later, and of course,
Windows Server 2003. You must log on to the computer with a domain account that has administrator-level permissions for the local machine. Then you can run the Exchange Server 2003 Setup
program, specify Custom for the Component Selection dialog box, and select the Microsoft Exchange
System Management Tools component.

Upgrading from Exchange 2000 Server
Exchange Server 2003 supports both in-place upgrades from Exchange 2000 Server (upgrading an
existing Exchange 2000 Server system on the same physical server) and migration upgrades by
moving objects onto a new server. Because Exchange 2000 Server and Exchange Server 2003 both
require AD, transitioning from Exchange 2000 Server to Exchange Server 2003 is nowhere near as
involved as moving from Exchange Server 5.5 to Exchange Server 2003. The new Exchange Server
2003 Deployment Tools that ship on the CD-ROM help make upgrades go smoother.
For in-place upgrades, first you must upgrade an Exchange 2000 Server to Exchange Server 2003
before you attempt to upgrade the OS to Windows Server 2003 because Windows Server 2003 does
not support Exchange 2000 Server. Second, you must remove all the Exchange 2000 Server components that Windows Server 2003 does not support, such as the cc:Mail Connector, KMS, and the
Mobile Information Server as mentioned earlier in the Retired Features section of this chapter. Finally,
you can install Exchange Server 2003 as an upgrade on those servers that meet these criteria.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 1 Windows Server System

29

Migrating from Exchange Server 5.5
Exchange Server 2003 does not support in-place upgrades from Exchange Server 5.5; you must
perform a migration. Migrating from Exchange Server 5.5 to Exchange Server 2003 is more complex
than migrating or upgrading from Exchange 2000 Server to Exchange Server 2003. When migrating
users from NT 4.0, you must move the user accounts from the SAM to AD, and then you need to
merge the Exchange Server 5.5 directory mailboxes and other messaging objects into AD. Natively,
AD cannot communicate directly with the Exchange Server 5.5 directory service. You can either use
the ADC that ships with Exchange Server 2003 to make an Exchange Server 5.5 organization coexist
with Exchange Server 2003 and AD or use the ADC to migrate that organization to Exchange Server
2003 and AD.
The ADC, which Figure 6 shows, acts as a gateway between the Exchange Server 5.5 directory
and AD for copying user mailboxes, contacts (i.e., custom recipients in Exchange Server 5.5), public
folders, and DLs to AD. The ADC is also responsible for synchronizing the contents of both directory
services. The ADMT clones (i.e., copies) user accounts from the NT 4.0 SAM to AD. Before you use
the ADC, you can either use the ADMT or upgrade an NT 4.0 PDC to an AD DC running Windows
Server 2003 or Windows 2000 Server SP3 or later. You can download the ADMT 2.0 from Microsoft’s
Web site at http://www.microsoft.com/downloads/details.aspx?familyid=788975b1-5849-4707-98178c9773c25c6c&displaylang=en. After you either clone the user accounts using the ADMT or upgrade
them to AD, you can then install a copy of Exchange Server 2003 and you can use the ADC to copy
the Exchange Server objects.

Figure 6:
Viewing Active Directory Connector Services

This ends our overview of the new Windows Server 2003 and Exchange Server 2003 platforms,
their new features, and the key issues to consider before migrating to the new directory service and
messaging system. Chapter 2 will provide further details about migrating to Windows Server 2003
and AD.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

30

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Chapter 2

Active Directory Design
A solid Active Directory design is, of course, a prerequisite to migration. Without a well-thought-out
structure of forests, trees, domains, organizational units (OUs), and sites, your migration will be a
road to nowhere, fraught with failure. In this chapter, you will learn the ins and outs of Active
Directory design. We assume that you are familiar with fundamental constructs such as domains and
that you have had some Active Directory education or design experience. Therefore, our goal is to
recast design considerations in a real-world perspective and present the experience we’ve had with
good and bad designs. We also want to make sure to equip you with the latest knowledge regarding
design. Too many resources are based on early Microsoft Windows 2000 deployments. Since that time
there have been significant changes in both theory and practice.

A Brief Overview of Key Active Directory Elements
Before we begin examining design considerations, let’s briefly define key Active Directory structural
elements: domains, trees, forests, and sites. A domain is the fundamental logical structural unit of
Active Directory. You cannot have Active Directory without at least one domain and you cannot have
a Windows 2000 or Windows Server 2003 domain without Active Directory.
Each domain requires at least one domain controller (DC) that hosts a copy of the domain’s
database. Unlike Windows NT, Active Directory DCs are not divided into primary and backup domain
controllers. Each DC can write to the directory and replication takes place in a multimaster topology
that ensures any change to the directory on any DC will replicate to all appropriate DCs.
When diagramming Active Directory, domains are represented by triangles as Figure 1 shows.

Figure 1:
Representing an Active Directory domain

windomain.local
Active Directory domain names follow DNS standards, which provide a hierarchy in the domain
namespace of Active Directory. For example, the domain in Figure 1 might be called
windomain.local.
Figure 2 shows a tree, which is one or more domains in a contiguous DNS namespace (i.e., each
domain shares a common root in the DNS namespace).

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

31

Figure 2:
Representing an Active Directory tree
windomain.local

na.windomain.local

eu.windomain.local

A forest, which Figure 3 shows, is one or more trees that do not share a contiguous DNS
namespace. A forest is the boundary of an Active Directory. A forest must have at least one domain
(at least one tree) and can support many domains in many trees.

Figure 3:
Showing an Active Directory forest
windomain.local

xyz.com

sub.xyz.com
na.windomain.local

eu.windomain.local

Brought to you by NetIQ and Windows & .NET Magazine eBooks

32

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

The first DC installed in the forest creates the forest root domain. The forest root domain has
important characteristics, as you will learn, so think carefully about which domain you will install first.
The forest root domain is the first domain installed in an Active Directory enterprise regardless of its
location in any DNS namespace hierarchy.
The final key structural component of Active Directory is the site. An Active Directory site
represents a portion of your network topology that is highly connected. Active Directory sites will
often parallel what you refer to as your enterprise’s sites or locations.

Forest Design
Forest design discussions need to focus the relationship between specific forest and enterprise
characteristics. Too often, forest design discussions lose focus and consider issues that have nothing
to do with the true role of an Active Directory forest in an enterprise network. Careful evaluation
degrades into a “kitchen sink” conversation and poor design decisions result. The tendency to
consider less relevant and irrelevant issues is exacerbated by the plethora of outdated white papers
and Active Directory design guidelines written by Microsoft and others during beta phases of Windows NT 5.0 (later, Windows 2000). Five years of experience with Active Directory and thousands of
implementations have clarified the issues that are, and are not, relevant to an effective forest design.

Forest Characteristics
An Active Directory forest represents a single deployment of Active Directory. The forest is the
boundary of Active Directory —a forest can have only one Active Directory and an Active Directory
can have only one forest. An enterprise might have more than one forest, in which case it has
multiple, completely distinct implementations of Active Directory.
A forest has five important characteristics:
• A single schema defines the attributes and object classes that can exist within the forest. The
schema determines numerous other characteristics of the forest, including default security for
object classes and attributes, indexing behavior, and global catalog (GC) contents.

n Note
Members of the Schema Admins group, hosted in the forest root domain, can modify the
schema. The default member of the Schema Admins group is the Administrator account in the
forest root domain.

• A single configuration defines the domains, site topology, replication, and many of the services
within the forest.
• A single global catalog contains information about every object in the forest. Because the GC
includes an extensible subset of attributes for every object—specifically the attributes that are
most often used to search for an object—it facilitates finding objects in the forest.
• Two-way transitive Kerberos trust relationships provide for authentication of any security principal
(e.g., user, group, computer, inetOrgPerson) in the forest.
• An Enterprise Admins group, hosted in the forest root domain, is the default owner of all
domains in the forest and therefore can correct errors anywhere in the directory.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

33

Forest Design Tenets
The first question that you need to answer when designing your Active Directory is, “How many
forests do I need?” Keep the following considerations clearly in mind as you evaluate forest design
alternatives.

A single forest is the most straightforward design
Active Directory design guidelines commonly proclaim the single-forest design as the best practice.
It is without doubt the most straightforward design with the lowest cost in terms of hardware and
administrative overhead. The vast majority of Active Directory implementations are single-forest
designs.
However, the knowledge we’ve gained during our last five years of experience and recent
developments in the technology (including cross-forest trusts in Windows 2003 and metadirectory
services such as Microsoft Metadirectory Services, or MMS) suggest that the single-forest design is not
always the best practice. Being the most straightforward and lowest-overhead model does not make it
the best model in every circumstance.

A forest shares common security enforcement
The schema defines the default security for each attribute and object class. Therefore schema owners
can enforce compliance with certain security policies. For example, local laws might require that
personal data, such as social security numbers, be inaccessible to users but a directory-aware payroll
application might need access to social security numbers stored in the directory. In this situation the
schema owner can configure the ACL of the social security number attribute to let only the payroll
application access employee social security numbers. In this way, a forest can provide for enforcement of certain security policies.
However, the schema does not define many common security policies, such as password
policies, group membership, and resource access. These policies belong to directory data owners—
domain and OU administrators. So even within a single forest, you cannot easily enforce many
common security-hardening policies. You must instead configure the policies and monitor them for
compliance. Because most common security policies fall into this latter category, you need to
consider, but not overestimate, security policy enforcement in forest design.

A forest indicates and requires ownership of forest data and services
Forest data includes the objects in the schema and configuration as well as the forest root domain
and GC. Forest services include the administration and support of DCs in the forest root and of site
topology, replication, and services.
Some businesses have decentralized IT environments without individuals or teams capable of
supporting forest-level data and services. In these situations, ownership of forest data and services
might be more effectively placed in business units, regions, or divisions that can support forest
ownership.

A forest implies strong levels of trust between administrators of each domain within the forest
A single forest is characterized by an Enterprise Admins group, hosted in the forest root domain, that
is the default owner of each domain in the forest, and therefore can correct errors anywhere in the
forest. Although this group should be highly secure and Enterprise Admin credentials are rarely used,
Brought to you by NetIQ and Windows & .NET Magazine eBooks

34

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

members of this group can take ownership of and alter any data in the forest. Similarly, members of
the Schema Admins group can modify the schema and therefore affect the forest in a myriad of ways.
Domain and OU owners must trust the forest owner to secure and manage membership of Enterprise
Admins and Schema Admins carefully.
Because the forest is the security boundary of Active Directory, anyone with physical access
or administrative credentials to DCs anywhere in the forest can introduce, either accidentally or maliciously, elements that can circumvent the security and integrity of the GC, schema, or configuration,
and thereby present significant risk to all domains within the forest.
Therefore domain owners within a forest need to trust each other just as much as they trust
domain administrators in their own domain. Domain owners need to be certain that the administration of each domain is in compliance with security policies and procedures, and that all DCs are
physically secure. Alternatively, domain owners must be willing to accept the risks associated with
less secure administration and security practices.

A forest implies high levels of collaboration between administrators of each domain
within the forest
Because the configuration, schema, GC, and some services (e.g., DNS) must support the entire forest,
domain owners must collaborate to determine policies and procedures related to these components.
For example, a business unit might need to install a directory-aware application to respond to its
business drivers. That business unit will need to work carefully with the data owner of the forest
because the forest owner owns the schema. Only members of the Schema Admins group (hosted in
the forest root domain) can modify the schema on the schema operations master (typically, a DC in
the forest root domain). In addition, any schema extensions that the application creates will apply to
the entire forest, not just to the business unit, so procedures for evaluating, testing, piloting, and
deploying schema extensions must be in place and those procedures must be acceptable to all
domain owners within the forest. This typically dampens, to some extent, a business’ ability to adapt
Active Directory to its unique needs.
Similarly, when a business unit represented in Active Directory as a domain needs to add a child
domain, the forest owner must add the child domain. The domains in a forest also share the GC.
Therefore when one entity decides to add an attribute to the GC, the forest owner must add the
attribute and the attribute needs to be acceptable to all domains in the forest.
Finally, DNS must support name resolution for all domains in the forest. You need to consider
any other network services (i.e., Microsoft or third party) that relate to the forest. For example,
DHCP and Microsoft Remote Installation Services (RIS) servers running on Windows Server 2003 or
Windows 2000 Server need to be authorized by the forest owner before they begin to function.

A forest implies high levels of collaboration between users in various domains in the forest
The two-way transitive Kerberos trusts within a forest provide for authentication of any security principal (e.g., user, group, computer, inetOrgPerson) in any domain in the forest. These trusts facilitate
access to resources such as files and printers. To further facilitate access to common resources, users
in any domain in the forest are part of the Everyone group in Windows Server 2003 (Windows 2000’s
equivalent is the Authenticated Users group).

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

35

Evaluating Forest Design Factors
We advise that you begin forest design with the assumption that you will end up with a single forest
design. As mentioned earlier, a single forest is the most straightforward, lowcost model. Deciding
between a single and multiple forest design will depend on the relative weights of forest ownership
and administrative complexity.

Forest service and data ownership
However, if the enterprise cannot identify an appropriate forest owner (individual or group) to
support forest-level data and services, or if divisions in the enterprise cannot subscribe to the level
of trust and collaboration that is implicit within a forest, then a single forest might not be the best
design. Changes to the schema, configuration, and other forest-level data and services are rare, but
when changes are necessary it is usually due to a significant business driver. An entity in the forest
will likely be dependent upon other entities, including the forest owner, to respond to its needs for
modifications to forest data and services. The forest owner needs clear policies and procedures to
provide adequate levels of responsiveness to entities in the forest.

Administrative complexity
Do not underestimate the administrative complexity of multiple forest models, particularly when
collaboration across forests requires authentication. For enterprises in which cross-forest collaboration
is common, administrative overhead is significant.
Traditionally, when users collaborate between domains, those domains require trust relationships.
Those trust relationships multiply quickly. A simple scenario in which users in three domains in
Forest A collaborate with users in three domains in Forest B requires nine trust relationships.
Conversely, in environments in which cross-forest collaboration is uncommon, administrative
overhead (beyond forest service and data ownership concerns) is minimal. Consider also the type
of collaboration that occurs. Email, Web-based application, and online collaboration tools (e.g., Lotus
Sametime, Microsoft NetMeeting, Windows SharePoint Services) are often independent of Active
Directory and, therefore, independent of trust relationships. Collaboration that does not require
authentication by Active Directory does not depend upon trust relationships and therefore does not
affect administrative overhead.
Recent developments in technology reduce the complexity of multiple forest models.
Cross-forest trusts
Windows Server 2003 supports cross-forest trusts, which enable trusts be established between the
forest root domains of two forests. The cross-forest trust enables authentication for security principals
in all domains in both forests—a result similar to authentication between domains in a single forest.
You can secure cross-forest trusts in several ways to refine the level and type of authentication that
the domains in the two forests support.

n Note
Forests at the Windows Server 2003 functional level support cross-forest trusts. DCs in all
domains in both forests must be running Windows Server 2003.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

36

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Metadirectory services
Metadirectory services, including Microsoft Metadirectory Services (MMS), further facilitate multipleforest models by enabling the synchronization of objects in forests. For example, you can replicate a
user account or group to several forests and then give that account access to resources in each forest
without requiring a trust.

Domain Design
As with forest design, it is important to focus on the characteristics of domains that truly drive design.
It is also crucial to remove prejudice and experience with Windows NT 4.0 domains from the picture.
Windows NT 4.0 domains were severely limited based on the size restriction (40 MB of data) of the
Security Accounts Manager (SAM) database; by the single point of failure at the primary domain
controller (PDC); and the inability to delegate administrative control, such as control over a subset of
users or the a single task, such as resetting user passwords. Active Directory is not subject to these
limitations.

Domain Characteristics
Domains within a forest play several roles based on what are often referred to as boundaries:
administrative, data, authentication, user account security policy, and policy-based administration
boundaries.

Administrative boundary
Domains serve as the administrative boundary for managing directory objects including users, groups,
and computers. Within a domain, you can use OUs to create more granular administrative boundaries
and to further delegate authority over objects and attributes.
The Administrators group of a domain is the owner of the domain, and therefore has extensive
privileges and permissions to domain resources, including the directory. However, users who belong
to the Administrators group in one domain do not, by default, have any privileges or permissions
whatsoever in other domains in the forest. Note that this rule is true regardless of where a domain
appears in the diagram of an Active Directory forest. For example, in Figure 4, the Administrators
group of windomain.local does not have any authority over the na.windomain.local domain. The
domain boundary is an administrative boundary, even though windomain.local appears to be a
parent of na.windomain.local. The parent-child relationship is due to their DNS names and Kerberos
trust hierarchy—that’s all.
However, the administrators of windomain.local must have added the na.windomain.local domain
to the forest because without the involvement of administrators in the forest root, domains cannot be
added. When a child domain is added, the administrators of the parent domain are not granted any
administrative authority. You need to add user accounts from the parent domain into appropriate
groups in the child domain to achieve that type of administrative hierarchy.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

37

Figure 4:
Illustrating Active Directory domain boundaries
windomain.local

na.windomain.local

eu.windomain.local

Data boundary
Within a forest, domains act as a partition (i.e., division) of the Active Directory database. Each
domain maintains all information about objects. The Domain NC stores all attributes for all objects in
the domain. Using multimaster replication, the Domain NC replicates to each DC in the domain.
When more than one domain exists in a forest, the separate partitions for each domain ensure
that data in one domain does not replicate to DCs in other domains. This characteristic is similar to
Windows NT 4.0 domains.

n Note
Remember, however, that the Global Catalog contains a partial attribute set for all objects in
every domain in a forest, facilitating directory queries and object access.

Unlike Windows NT 4.0 domains, each Active Directory domain in a forest participates in the
security unit of the forest, through the forest’s trust relationships. In addition, as you learned earlier,
every domain in a forest shares a common:
• Schema
• Configuration
• Global Catalog

Authentication boundary
A domain is responsible for performing authentication for a user account stored in its domain NC,
even when that user is logging onto a computer in another domain. When a foreign user logs on to
a domain, that domain can refer the authentication to the correct DC elsewhere in the enterprise’s
Active Directory or to trusted external domains.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

38

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

User account security policy boundary
Domains in a forest also act as a boundary of directory related security policies. Administrators in the
domain can specify policies such as password, DC security, account lockout, and Kerberos policies.
The maximum scope of these policies is a domain. The policies that administrators specify in one
domain do not, by default, flow into other domains in the forest.

Policy-based administration boundary
Group Policy enables you to centralize the administration of change and configuration management.
Policies are implemented by linking group policy objects (GPOs) to sites, domains, and OUs. In a
multi-domain environment, domains generally become the broadest scope for policy application.

Domain Models
Within a forest, the primary question you must answer is, “How many domains are required?” The
only real difference between a tree and a forest is DNS namespace. Other than the default Kerberos
trust partners, no functional difference exists between two domains that are part of the same tree or
two separate trees in the forest. Therefore you do not yet need to consider the DNS hierarchy of the
domain names. Your most important consideration is simply the number of necessary domains,
including the justification for each domain.

Single domain model
In a single domain model, the forest root domain hosts all Active Directory objects—there is no
other domain in the forest. The single domain model is the lowest total cost of ownership (TCO)
implementation, and careful design of OUs lets the enterprise delegate and separate control of
enterprise resources.
In Windows NT 4.0, you had to create multiple domains to achieve separation of control and
delegation of administration. But by creating multiple domains, an organization sacrificed any ability
to represent the needs and goals of the enterprise as an entity in its directory services. With Active
Directory, the forest (even when it’s a single domain) serves the needs of the enterprise and OUs
serve the needs of units within that enterprise for various levels of autonomy and control.

n Note
The single domain model provides the most effective and lowest-cost design for many
organizations. It is a best practice for many enterprises, particularly smaller, simpler, or more
centralized organizations.

Understanding and using the forest root domain
The first DC that you install in the forest creates the forest root domain. Note that the forest root
domain is the first domain installed in an Active Directory enterprise regardless of its location in any
DNS namespace hierarchy.
The forest root has roles and properties that set it apart from any other domains in the forest:
• The Domain Naming master, a role initially performed by the first DC you install in the forest
root domain, manages the task of adding the first child domain or the first new tree in the forest.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

39

• The forest root serves as the Kerberos trust center for all trees in the forest. When you add a new
tree to the domain, the first domain in that tree (the new tree’s root) establishes a trust with the
forest root domain. The two-way trust lets the forest root domain and the new tree’s root domain
trust each other. Because all other trees’ roots trust the forest root and because Kerberos trusts
are transitive, the new tree root and its child domains are now in a trust relationship with all
other domains in the forest.
• The Schema master, a role initially performed by the first DC you install in the forest root
domain, manages the Active Directory Schema.
• The forest root domain hosts the Enterprise Admins and Schema Admins groups. These groups
have ultra-powerful privileges and characteristics that affect the entire Active Directory enterprise.
A dedicated forest root domain
In multiple-domain models, you have the option of dedicating the root domain to its core roles of
supporting forest-level data and services. Beyond the default and built-in objects, a dedicated forest
root domain will not contain objects. In other words, you won’t manage users, groups, or anything
else in a forest root domain. You don’t have a switch or checkbox to configure a dedicated forest
root—what you do with the forest root makes it dedicated.
A dedicated forest root domain provides numerous advantages, including:
• Critical enterprise (i.e., forest) operations can remain in the forest root and can be isolated from
other domains. These operations include the addition or deletion of other domains (by the
Domain Naming Master) and the maintenance of the Schema (by the Schema Master). You will
learn more about operations masters later in this chapter.
• The Enterprise Admins and Schema Admins groups enjoy the extra security afforded by their
isolation from other domains. Only administrators of the forest root domain can modify the
membership of these powerful groups.
• You can establish comprehensive auditing of the forest root without generating horribly unwieldy
logs.
• You can establish the forest root domain in the Windows Server 2003 functional level, regardless
of the existence of Windows 2000 DCs or Windows NT BDCs elsewhere in the Active Directory
environment. We will examine functional levels later in this chapter.

Single global child domain model
In an Active Directory design, an organization might elect to dedicate the forest root by creating a
second domain in the same tree (or a second tree in the forest) and by focusing all design decisions
on the structure of the second domain, any additional domains, and the OUs within those domains.
Figure 5 shows a single global child domain model with a dedicated forest root domain
(windomain.local) and a single domain that maintains all accounts and objects.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

40

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 5:
Representing a single global child domain model

windomain.local

na.windomain.local
Large or complex enterprises will find that a single global child domain model, with a dedicated
forest root and a second active domain, provides an important enhancement to the stability and
security of their enterprise. This stability and security provides pluses that outweigh the increased
TCO of a multidomain model. This single global child domain model is a best design practice for
many enterprises.

Multiple domain models
Multiple domain models consist of more than one domain in which you maintain regular
directory data (e.g., users, groups).

n Note
We highly recommend that if your organization will have more than one domain now or in the
future that you develop a design with a dedicated forest root domain.

In Figure 6, windomain.local is the dedicated forest root domain. Two domains,
na.windomain.local and eu.windomain.local, contain the actively supported directory objects.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

41

Figure 6:
Representing two regionally located Active Directory domains
windomain.local

na.windomain.local

eu.windomain.local

Evaluating Domain Models
In many—some would say most—enterprises, a single domain or a single global child domain model
is the best practice design. There are a limited number of reasons why you would want more than
one domain.

Divergent security policies
As we discussed earlier, you can configure certain security settings only at the domain level.
Password policies (including length, complexity requirements, and how often they need to be
changed) are an example of domain level security settings. You also have to configure Kerberos
and lockout policies as well as trusted certificate authorities for the entire domain.
If your enterprise has divergent security requirements that cannot be reconciled, you will need
to implement multiple domains to support that diversity. The need for divergent security requirements
is a showstopper design consideration because user account policies are configured for all users in a
domain.

Minimizing replication traffic
The most commonly cited justification for separate domains is the management of replication traffic.
Because a domain is a partition (the Domain NC) in Active Directory, and because the Domain NC
for a domain replicates only to DCs in that domain, you can reduce replication traffic with multiple
domains. For example, in a two-domain model, attributes and objects in Domain A replicate only to
DCs in Domain A and attributes and objects in Domain B replicate only to DCs in Domain B. Some
organizations might consider creating domains for major regions, such as North America and Europe,
as Figure 6 shows, to minimize replication over the slower and more expensive WAN links between
regions.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

42

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Although this justification for separate domains is technically correct, you must evaluate it
carefully given your specific environment. Replication traffic is minimal. Conservative best practice
guidelines suggest that when the slowest link between two DCs in your environment is 28 Kbps, you
need to limit the domain to 50,000 users. With a 56 Kbps or greater minimum link speed, the limit
doubles to 100,000 users. Those guidelines applied to Windows 2000 and with improvements in
replication for Windows Server 2003, the recommended limits will increase.
Replication will probably be one of the smallest consumers of network bandwidth in your
enterprise. A typical email message is larger than most replication transactions. So although
minimizing replication is a technically accurate justification for multiple domains, it is generally not a
salient consideration in the real world.

Data isolation requirements
In some rare situations, an enterprise can be restricted from replicating certain data in the directory
service. An example is an international bank with offices in Switzerland. If Active Directory stores the
customer data, that institution has to isolate that data within a Swiss domain.
In the real world, data isolation requirements driving domain design is highly unusual. First,
fine-tuning Active Directory to truly quarantine restricted data within a single domain in a forest is
difficult because the GC replicates information about every object in the forest. Total data isolation
occurs only in separate forests. Second, in situations with highly restricted data, Active Directory
doesn’t generally host the data. A separate isolated, secured and encrypted database would store
the data.

Data autonomy requirements
Data autonomy relates to the idea of administrator realms of control in which administrators have
full control of a realm and want to limit or prevent access by other administrators. Sometimes data
autonomy reflects the reality of distributed, decentralized IT and other times it reflects politics.
In either situation, separate domains are rarely the answer. OUs provide data autonomy to the
same extent as a domain. In addition to data autonomy, a domain denotes service autonomy and
responsibility. A domain must have a coordinated user account security policy and must have
ownership and support for Active Directory services (e.g., maintaining DC security, troubleshooting,
disaster recovery). Rarely will a forest owner (for the enterprise) be willing to delegate authority over
services in the forest solely to achieve data autonomy.
Remember that within a forest, administrators of all domains must have extraordinary levels of
trust and confidence, as poor administrative practices in any domain have the potential for adversely
affecting all domains in the forest. In other words, work through the politics by educating constituents
as to the true nature of domains, forests, and OUs.

DNS Namespace Design
After determining how many domains are necessary to address your design drivers, you can plan the
DNS names for the domains. Windows Server 2003 uses DNS as its preferred name resolution
method, and Active Directory domains map directly to a DNS namespace.
When determining DNS names, be certain that they meet the following criteria:
1. Uniqueness. Each domain name must be unique, and not likely to change.
2. Standards compliant. Names should contain only standard characters (A-Z, a-z, 0-9, -).
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

43

3. Secure. Names should not be able to be resolved by external queries. To achieve this, use split
brain DNS, in which a zone is maintained outside the firewall that contains host records for only
those systems you want accessible by external clients. Internal DNS servers maintain a complete
DNS zone with all records for hosts and services.
4. Easy. Make names that are easy to type and remember.

Typical DNS Designs
Many organizations choose to create a domain that is a subdomain of their existing namespace. Other
organizations choose to use a .local namespace.

Subdomain
An enterprise might select to root their Active Directory in a subdomain of their existing namespace.
For example, an enterprise with the registered domain name, windomain.com, might create a
subdomain named ad (for Active Directory). Then its forest root domain becomes ad.windomain.com.
Although this approach ensures a unique, standard domain name for Active Directory, it poses one
disadvantage: host names become rather lengthy and difficult to type and remember. For example,
the name of a server in the single global child domain might be server01.na.ad.windomain.com.
Organizations whose root Active Directory domain name lies deep in the DNS namespace might end
up with incredibly long host names.

A .local domain
Alternatively, an enterprise might root its Active Directory in the .local namespace. Organizations can
use the .local top-level domain name for internal name resolution without risk of interference or
conflicts with other enterprises. The .local domain has no top-level DNS name servers, so external
clients cannot resolve internal hosts on a .local namespace.
For example, an enterprise might create a forest root domain named windomain.local. This
option ensures unique names that external hosts cannot resolve. This option also lets host names be
higher in the namespace hierarchy. For example, a server in the North America domain might be
named server01.na.windomain.local.

Interoperating with Existing DNS Infrastructures
Windows Server 2003 relies heavily on DNS and in an Active Directory domain every server, host,
site, and service registers DNS records. Therefore, a rock-solid and dynamic DNS infrastructure is
crucial to a successful implementation. An Active Directory domain can interoperate with third-party
DNS, such as BIND. However, the best practice is to leverage Windows Server 2003’s own DNS,
which provides secure, dynamic DNS record registration and uses Active Directory’s native replication
mechanisms to provide incremental replication to targeted servers.
In an environment in which a DNS infrastructure already exists, you need to consider whether
to integrate the Windows DNS domains into the infrastructure or to host them separately and link the
two systems. By creating a DNS subdomain for Active Directory (e.g., ad.windomain.com) or using a
unique namespace (e.g., windomain.local), you have the option of hosting DNS for your Active
Directory domain on Windows Server 2003 DCs. By simply configuring forwarders on the DNS
service, Windows clients can resolve names in the existing DNS namespace. By creating stub zones
or secondary zones on the existing DNS servers, clients outside the Windows network can resolve
Brought to you by NetIQ and Windows & .NET Magazine eBooks

44

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Windows hosts correctly. This approach lets an enterprise build an Active Directory domain and
leverage the advantages of integrated DNS with very minimal effect on the existing DNS zones and
servers.

NetBIOS Names
In addition to a unique DNS name, each Active Directory domain requires a NetBIOS name for
compatibility with downlevel clients. For simplicity’s sake, most organizations choose to use the DNS
domain name (e.g., NA for North America) as the NetBIOS name.

UPN Suffixes
The user principal name (UPN) uniquely identifies a user within an Active Directory. A user’s UPN
must be unique to the Active Directory forest.
The UPN consists of a name and a suffix separated by the @ symbol (so it ends up looking like
an email address). The UPN suffix is, by default, the DNS name of the domain. However, you can
add any suffix you desire to the list of available UPN suffixes.
In multidomain models an enterprise might want to unify the namespace of UPN suffixes. For
example, if your enterprise contains the domains windomain.local, na.windomain.local, and
eu.windomain.local, you might want all users to log on as [email protected].
To customize the list of UPN suffixes that are available to assign to a user account, follow the
steps in the following procedure:
1. Open the Active Directory Domains and Trusts snap-in.
2. In the console tree right-click Active Directory Domains and Trusts, then select Properties.
3. Use the UPN Suffixes property sheet to add and remove suffixes.

OU Design
Within a domain, OUs are used to group objects that share common administration, configuration,
or visibility. The meaning of this will become clearer as you learn more about OU design and
management, but suffice it to say at this point that OUs provide an administrative hierarchy that
accomplishes everything that individual Windows NT 4.0 domains did and much, much more.
An OU can contain millions of objects, but obviously it would not make sense to host every
object in a single container. It is likely that objects are owned, administered, or configured in different
ways, and that, at a minimum, you would want to collect objects to make them easier for administrators to find. You need to divide objects into logical, administrative containers.
As you do so, you will begin to create a hierarchy of OUs. A child OU, by default, inherits
properties of its parent OU, including administrative delegation and Group Policy. Therefore, when
you consider dividing one container into two containers, you must decide whether the new container
needs to be a child of the existing container or a peer of (at the same level as) the existing container.
Base your decision on whether the new container will have distinct properties from the existing
container or whether the new container needs to inherit the properties of the existing container and
have some unique properties as well. In the first case, the new container needs to be a peer at the
same level. In the latter case, the new container needs to be a child of the existing container.
Creating an OU structure within an organization needs to follow a specific order and thought
process:
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

45

1. Collect objects sharing common administration
OUs represent realms of data ownership or scopes of administrative responsibility. They are
administrative containers used to facilitate the management of Active Directory objects. It is easier to
perform many administrative and support tasks for users, groups, computers, and printers on a
collection of objects rather than on individual objects. OUs are that collection and OUs can be nested
to create a hierarchical structure of administrative containers.
You need to determine how to divide objects among a hierarchy of OUs. Start by imagining all
of your users, groups, computers, and other directory objects in a single container. Then ask yourself,
“How can I divide these objects based on how they are administered?” Identify how the objects
should be grouped based on who owns or administers the objects. You are beginning the first phase
of OU design: OUs should be structured, first, to reflect administration.
Let’s say, for example, that your organization has regional IT administration centers, which
support users in the eastern, central, and western divisions, and job tasks are divided such that the
eastern administration center supports only eastern users and so on. Then you will probably want to
divide the objects regional containers such as East, Central, and West. Each container—an OU—
becomes a point of delegation. You can delegate levels of administrative authority over the objects
in each regional OU to an appropriate group representing that region’s administrators.
Continue dividing containers based on further administrative granularity. After this initial step of
OU design, your OUs will reflect your enterprise’s administrative model.
OUs need to provide sufficient data autonomy for administrators of business units, divisions,
departments, and regions in most environments. Delegation of administration lets the enterprise grant
either full control or any combination of granular permissions to an OU. In this way, OUs provide the
administrative autonomy seen in Windows NT 4.0 domains without responsibility for domain and
forest-level services. Therefore, as we discussed earlier in this chapter, you generally need to have
more than one child domain when the enterprise requires unique user account security requirements.

2. Collect objects sharing similar configuration, application, or security settings
Because Group Policy lets you easily manage application, security, and configuration settings, you
will want to collect objects that share similar configuration settings in a container or branch to which
GPOs can be linked.
Therefore, in the second phase of OU subdivision, you need to divide objects that share similar
configuration settings. Continuing the above example, let’s assume you have engineers and
accountants in the East regional OU. If the accountants will have a locked-down and tightly
controlled user environment, but the engineers need more standard access and control of their
systems, then you might want to divide the users in the East regional OU into Accounting and
Engineering OUs. Then you can link a GPO that locks down the desktop to the Accounting OU
without affecting the engineers.
Be wary of dividing OUs into too many levels. The best practice is to average only three to five
levels deep. Group Policy is easiest to filter based on the OUs to which GPOs are linked. However,
you can also filter GPOs based on group membership or Windows Management Instrumentation
(WMI) information. So when you find yourself creating seventh-level and eighth-level OUs to link
GPOs, you need to consider linking the GPOs to a higher-level OU and filtering the GPO. Then you
won’t require excessively deep OU structures. Deep OU structures affect object discovery and will

Brought to you by NetIQ and Windows & .NET Magazine eBooks

46

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

impede the performance of the directory. In addition, when you link GPOs to multiple levels of an
OU tree, you increase the amount of time required for system startup and user log on.

n Note
For more information about Group Policy design, implementation, and troubleshooting, see
“Windows 2000 Group Policy, Profiles, and IntelliMirror,” published by Sybex and written by
Jeremy Moskowitz (http://www.sybex.com)

3. Collect objects for visibility
Administering objects within an OU that contains too many objects is difficult. One solution is to
separate the objects in a large OU into smaller, child OUs. You can concentrate all administrative
delegation and a Group Policy driven configuration on the parent OU. Child OUs and the objects
they contain will inherit the configuration of the parent.
Note that this division for convenience and visibility is the last step in OU design. OU design
needs to reflect administration, first; GPO requirements, second; and visibility, third.

Site Design
Whereas forests, domains, and OUs provide the logical structure to Active Directory, sites represent
the physical topology of the enterprise. A site is an area of high connectivity, separated from other
sites by slower links. Site design is independent of domain and OU design—a site can contain more
than one domain, and a domain can contain more than one site.

The Functions of Sites
Sites support two major functions for the enterprise: service localization and control over replication.
Service localization refers to the ability of clients in a distributed environment to locate and use a
service closest to the client such as authentication services that DCs provide. When a client logs on to
an Active Directory domain, the client will attempt to use DCs in its site. Only when there are no
DCs in its site will the client authenticate against remote DCs. Other services, including the GC and
DFS, are site aware, which means clients will automatically use a local service when the service is
available in both a local and a remote site.
Sites also drive the behavior of Active Directory replication. Within a site connectivity is good, so
intrasite replication occurs frequently and uses uncompressed RPC over TCP/IP to ensure quick
replication with minimal impact on the DC’s processor. In a Windows Server 2003 site, a change to
Active Directory replicates to all other DCs in the site within a few minutes. Between sites bandwidth
can be at a premium, so replication is compressed and occurs less frequently. Administrators can
configure the frequency and schedule of intersite replication.
The rules used to define sites vary widely from enterprise to enterprise. Microsoft’s published best
practices suggest that the minimum link speed within a site should be 512 Kbps. Any link slower
than that should be used to define the boundary between two sites. In practice, some organizations
have links as slow as 28 Kbps within a site.
The reason some organizations keep slow links within a site is that an Active Directory site
should be used only to define service localization and replication, not to reflect what you call sites or
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

47

locations when you refer to your network topology. A slow link might connect a location in your
network topology that is small and does not warrant having DCs or other services. Defining the small
location as an Active Directory site would make no sense because the site would offer no benefits.
You need to examine each location and each link carefully. Generally, if a location doesn’t
warrant a DC, you are unlikely to define that location as an Active Directory site. This point will
become clearer as we look at server placement later in this chapter.
So, when defining your sites, examine your network topology, locations, and link speeds. For
each location that is connected using a slower link, consider whether the location warrants being
defined as an Active Directory site based on whether it will support services—particularly DCs.

Server Placement
The services that are most crucial to Windows clients include authentication (by DCs), DNS, WINS,
DHCP, and the GC. When considering a branch, an office, or a remote location, you need to be
certain that these services are available to users in that location. Either the link needs to be sufficient
and reliable or the services need to be hosted on local servers.

Domain Controllers
Before you start placing DCs in every remote site, consider the management and security
implications. Additional DCs mean additional administrative overhead, and anyone with physical
access to a DC can introduce problems into the domain. Some enterprises migrating to Windows
Server 2003 are choosing to centralize the DCs in their environment, rather than continuing to
support DCs in remote sites.
When you decide whether or not to place a DC in a remote site, consider where the greatest
pain will lie if the link to the site goes down. Consider an organization in which a datacenter at the
corporate headquarters hosts the user data and email. If the link between a remote site and the
headquarters goes down, users at the remote site won’t be able to access data or email. And in such
a case the presence of a local DC will not mitigate the pain. However, if there are significant local
resources (e.g., files, printers, applications), then a local DC will let users authenticate for those
resources even when the link to the headquarters is unavailable.
In Windows 2000, it was important to configure a GC server on a DC in every site. In a
multidomain environment in the Windows Server 2003 or Windows 2000 functional level, users
cannot log on unless their universal group membership can be determined (members of the
Administrators group are exempt). The GC stores universal group membership. So when a Windows
client cannot contact a GC server, it will deny logon.
Windows Server 2003 DCs now support universal group membership caching. With the feature
enabled, when a user logs on for the first time, a DC will contact a GC server and will cache the
user’s universal group membership. Therefore, if a GC is unavailable on a subsequent logon, the DC
can authenticate the user successfully.

Operations Masters
In any replicated database, certain functions can be performed by only one replica. Active Directory
is no exception: certain operations are the responsibility of only one DC in a domain or forest. The
terms below refer to these operations:
• Operations Masters
Brought to you by NetIQ and Windows & .NET Magazine eBooks

48






Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Single-Master Operations
Flexible Single-Master Operation roles (FSMOs)
Single-Master roles
Operations tokens

Regardless of the term used, the idea is the same. One DC performs a function, and while it
does, no other DC can perform that function.
Although this might sound like a rehash of the Windows NT 4.0 PDC concept, it is not. SingleMaster Operations are characteristic of any replicated database, and Active Directory Single- Master
Operations bear striking differences to Windows NT 4.0 PDCs. All DCs are capable of performing
operations. The DC that performs an operation is the DC that holds the operation token. An
operation token, and thus the role, can be transferred easily to another DC without a reboot. To
reduce the risk of a single point of the failure, the operations tokens can be distributed among
multiple DCs.

Forest-wide operations
Domain naming and schema maintenance are the two Single-Master Operations roles in an Active
Directory forest:
Domain naming
The domain naming role is used to add and remove child domains in the forest. The domain naming
master must be connected and accessible to successfully add or remove domains.
Schema maintenance
The schema maintenance role lets the DC hold the token to make changes to the forest’s schema. All
other DCs hold read-only replicas of the schema.

Domain operations
Each domain supports three Single-Master Operations roles:
Relative Identifier assignment
The Relative Identifier (RID) master plays an integral part in the generation of security identifiers
(SIDs) for security principals (e.g., users, groups, computers). Because any DC can create accounts
and therefore SIDs, a mechanism is necessary to ensure that SIDs are unique. Active Directory DCs
generate SIDs by appending a unique RID to the domain SID. The domain’s RID master allocates
pools of unique RIDs to each DC to ensure the SIDs that each DC generates are unique to the
domain.
Infrastructure master
In a multidomain environment, it is common for an object to reference objects in other domains. For
example, a group can include users, groups, or computers from another domain in its membership.
The group’s domain might not always have access to a DC from the account’s domain, or even to a
GC, so Active Directory creates a phantom object to represent the account. The phantom object
includes only the object’s SID, distinguished name (DN), and globally unique identifier (GUID). If that
object is moved or renamed in its domain, its GUID does not change, but its DN changes. If that

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

49

object is moved between domains, its SID also changes. The infrastructure master contacts a GC or a
DC in the foreign domain to periodically (every 2 days by default) examine phantom objects. Then
the infrastructure master updates the phantom objects’ properties with any changes and replicates
those changes to other DCs in the domain.
PDC Emulator
The PDC Emulator role supports multiple, crucial functions for a domain:
• Facilitates replication to downlevel BDCs. An Active Directory domain in mixed mode
supports the existence of Windows NT 4.0 backup DCs. BDCs don’t understand Active Directory
and don’t participate in multimaster replication. Instead, they expect to receive directory updates
from the PDC. One Active Directory DC in a domain must act like the PDC for these BDCs. The
DC with the PDC Emulator token assumes this role.
• Acts as a PDC for downlevel clients and tools. To perform certain tasks such as password
changes, Windows NT 4.0 and Windows 9x clients without the Active Directory client contact the
PDC of a Windows NT domain because only the PDC can write to the domain’s directory.
Downlevel clients are unaware that all Windows Server 2003 and Windows 2000 DCs can write
to the directory. So the DC holding the PDC Emulator token registers itself and responds like a
Windows NT 4.0 PDC. Downlevel tools, such as Windows NT’s User Manager for Domains, and
other Microsoft and third-party tools written for Windows NT domains, are also hard wired to
connect to a PDC and will connect to the PDC Emulator.
• Participates in special password update handling for the domain. When a password is
reset or changed, the DC making the change ignores all replication rules related to sites, site
links, notification periods, and replication schedules, and replicates that change to the PDC
Emulator. This special replication handling of password changes helps ensure that two DCs know
about the new password as quickly as possible. When a user attempts to log on immediately
after implementing a new password, the DC responding to the user’s logon request might not
know about the new password. But before it denies authentication, it authenticates against the
PDC Emulator, which verifies the new password correctly and enables successful authentication.
• Manages Group Policy updates within a domain. Group Policy Editor attempts to bind to the
PDC Emulator to avoid a situation in which a policy has been modified on two different DCs,
thus creating a collision. Policy collisions cannot be resolved, and are almost certain to result in
the loss of one or more policy updates. By binding to a specific DC, namely the PDC Emulator,
the tool encourages administrators to focus on one source of policy information.
• Manages time within a domain. Active Directory, File Replication Service (FRS) and Kerberos
rely on time stamps, so having all systems synchronized is crucial. The PDC Emulator in the
forest root domain (the first domain installed in the forest) is the time master. The PDC Emulator
in each domain in the forest synchronizes its time with the forest root PDC Emulator. The other
DCs in a domain synchronize from the domain’s PDC Emulator. All other domain members
synchronize their time with their preferred DC. This hierarchical structure of synchronization, all
implemented through the Win32Time service, ensures synchronization. Having the forest root
domain’s PDC Emulator synchronized with an external time server is crucial. If it is not, the event
log will contain errors reflecting the situation. The Knowledge Base contains simple instructions
for setting up the forest root domain’s PDC Emulator to synchronize with an external time source.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

50

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Acts as the Domain Master Browser within the browse function. A master browser in each
network segment creates the browse list: the list of workgroups, domains, and servers. The
domain master browser serves to merge the lists of each master browser so that browse clients
can retrieve a comprehensive browse list.

Placement of Operations Masters
The best practice placement of operations masters is as follows:
Forest operations
The schema master and domain naming master roles should be placed on a single DC that is a GC
server. These roles are rarely used and the DC hosting them should be tightly secured. The domain
naming master should be hosted on a global catalog server, because the master must ensure that no
other object of any type has the same name as a new domain being added. The GCs partial replica
contains the name of every object in the forest.
Domain operations
The RID and PDC Emulator roles need to be hosted on only one DC. If the load mandates that the
roles be placed on two DCs, those two systems should be physically well connected and have
explicit connection objects created in Active Directory, so that they are direct replication partners.
They should also be direct replication partners with standby RID and PDC Emulator DCs. In a
mixed-mode domain, it is particularly important that the standby PDC Emulator is the same site as
the active master.
The infrastructure master should be on a DC that is not a GC server, but should be physically
well connected to a GC server. The infrastructure master should have explicit connection objects in
Active Directory to that GC server so that they are direct replication partners. Note that if there is only
one DC, or if every DC is a GC server, then it is OK to host the infrastructure master on a GC server.
The infrastructure can be placed on the same server that acts as the RID and PDC Emulator.

Key Points
After a careful analysis of your enterprise, its network topology, and its administration, you can determine the following key components of your Active Directory design:
• The number of forests. The most straightforward and common practice is a single forest,
although security concerns and service ownership concerns can result in an enterprise opting for
a multiple-forest model. Due to cross-forest trust relationships and the availability of metadirectory
tools such as MMS, supporting multiple-forest models in Windows Server 2003 is easier than in
Windows 2000.
• The number of domains. The best practice and most common models are a single domain
model and a dedicated forest root with a single, global child domain. In both of these models,
the focus of all day-to-day administration is on one domain that contains the user, group, computer, and other objects representing the enterprise’s resources, and ownership of those objects
can be delegated using OUs. The dedicated forest root domain provides additional security for
forest-level data and services, such as the schema and configuration.
• The DNS namespace. Active Directory domains need to follow DNS naming standards with
common characters and short, easy-to-remember domain names. Using a subdomain of an

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 2 Active Directory Design

51

existing DNS namespace (e.g., ad.windomain.com) or a .local domain name (e.g.,
windomain.local) are common and effective.
• The OU hierarchy. Objects in Active Directory should be grouped first according to common
administrative requirements, then according to change management (Group Policy) needs, and
finally to make them easy to find.
• Site topology. Active Directory sites represent replication and service boundaries. Within a site,
DCs replicate frequently. To conserve WAN link bandwidth, replication occurs less frequently
between sites. In addition, clients using directory-aware services will use servers local to their site.
By examining your network topology, including the location of services and bandwidth
availability, you can design an effective site topology.
• Server placement. Ideally, crucial services such as DCs and name resolution services should be
local to any site in which users need to access resources. In addition, you should plan for the
placement of operations master roles including the domain naming, schema, RID, PDC, and
infrastructure masters.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

52

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Chapter 3

Migration Planning
In a rush to migrate, enterprises tend to short-change information gathering and testing phases.
This chapter examines the information you must know about your existing environment before you
migrate to Microsoft Windows Server 2003 Active Directory. This information will facilitate planning,
testing, and documenting—all of which are crucial to a successful deployment of a new directory
service.

Assembling the Planning and Migration Team
The first step in planning is to gather the appropriate human resources and to make certain that
those resources understand and support the business and strategic drivers for migration. When you
assemble the migration planning team, you need to include those individuals who are directly
involved with and required for the technical aspect of migration
• Project management
• Directory services
• Infrastructure (e.g., DNS, DHCP)
• Security
• Messaging
• Help desk
Including input and support from departments indirectly involved is also important. For example,
the facilities team might understand datacenter power and HVAC concerns and the communications
team will support the migration by generating awareness and buy-in throughout the organization.
Finally, you should include key stakeholders: those departments that Active Directory will directly
affect; including human resources (HR), whose processes will undoubtedly be modified to align with
administration of user accounts in the directory; finance and procurement, who will be funding the
project; and representatives of the end-user community, whose feedback and perspective is often
valuable and overlooked.

Identifying the Big Picture Elements
You should treat a directory service such as Active Directory as a strategic initiative, through which
the IT infrastructure of the organization can more closely support the broader strategies of the
organization. If you treat directory migration as solely a technical issue, you will deprive the
enterprise of the long-term, larger impact of the technology.
Therefore after you assemble the migration team, you need to build awareness, understanding,
and consensus with regard to the business drivers for migration. The team should fully understand
• The strategic vision for Active Directory: why the technology is important, what pain it addresses,
and what value it provides.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

• The goals and timeframe for the migration.
• The business drivers for the migration and obstacles between the current environment and
achieving the desired environment.
• Political concerns and personnel concerns that may influence migration.
• Human, monetary, and other resources being applied to migration.
• The roles and expertise of migration personnel.
Some of first information you should gather and provide to the migration team is a high-level
overview of the existing environment and migration plan. An outline of these key components
follows.
• You need to include contact information for key personnel including
– The executive sponsors: the individuals at the executive level who are charged with the
directory services migration.
– Project architects
– Project managers
– The forest owners
– The Active Directory DNS owners
– The site topology owners
– Developers with experience and availability for automated migration projects
• You need to include business-critical services and applications. Be sure to describe the
ownership of and service used for
– Email
– DNS
– DHCP
– Remote access
– Security
– Virus scans
– Backup
– Defragmentation
– Patch management
– Software deployment
– Web services (i.e., intranet, extranet)
– Collaboration (e.g., conferencing, Instant Messaging—IM)
– Other services
• You need to include visual aides that describe
– The organization including an org chart for the entire business
– The IT department including a detailed org chart
Brought to you by NetIQ and Windows & .NET Magazine eBooks

53

54

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003








The project team including a detailed org chart
The site plan
Network topology
Windows NT4 domains
DNS namespace
Present plans including information about how they came to be and any ownership concerns

You need to coordinate key strategies as part of the migration plan. Each strategy should have
assigned owners, who are responsible for facilitating the development of related vision, planning, and
communication. While information gathering, testing, piloting, and migration progress, make sure that
the owners keep the entire migration team aware of the status and any changes in their assigned
areas. The key strategies include
• Design and standards setting
• Testing and pilot (including lab details)
• Directory services migration
• Authentication
• Security hardening
• Certificate and PKI
• Desktop migration
• Communications
• Training

Migration Tasks
You should organize the migration team to ensure that crucial tasks are accomplished. These tasks
include
• Training IT staff and end users
• Auditing the existing environment including
– The network infrastructure
– The directory services infrastructure
– Servers
– Applications
– Resources
– Clients and user environments
• Planning Active Directory design
• Evaluating an upgrade migration versus a restructure migration
• Planning the migration path
The remainder of this chapter describes these tasks.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

55

Training IT Staff and End Users
Lack of knowledge is a dangerous thing, particularly in regards to an initiative with the strategic
importance and reach of a directory services migration. Not only can insufficient knowledge lead to
an incomplete, insecure, or inefficient implementation of the technology but it can also bring the
planning phase to a grinding halt. Training is an extremely important component of any migration
plan.
Unless your organization has significant expertise in the technology and the most effective ways
to communicate about—to teach—the technology, you will likely find turning to an organization that
can provide that expertise more efficient, more effective, and less costly. Organizations believe they
can save money by asking their administrators to learn on their own about Active Directory; our
experience shows quite the opposite. IT professionals, because they have to support the enterprise
on a day-to-day basis, are not equipped to efficiently weed through the mass of information
regarding the technology. Time is wasted, results are less than ideal, and the soft costs in inefficiency
are much higher than if effective training had been provided.
When evaluating training providers, you must look carefully at your needs and their capabilities.
You will find training companies that have significant course offerings of both instructor-led and
e-Learning methods at reasonable prices. Microsoft provides training through its channel of Certified
Technical Education Centers (CTECs) and through e-Learning products. You will find the gateway to
Microsoft training services at its new Learning Web site, http://www.microsoft.com/learning.
Training products from trusted vendors such as Microsoft are useful, particularly when staff is
new to the Windows platform. However, these training products are less efficient with more
experienced staff or when logistics such as limited available time for training come into play. The
disadvantage of training products is that you have little ability to tune the content: you are subject to
learning the objectives that the provider sets forth even when you already understand those
objectives or when they are not applicable to your environment. Although some vendors and
some trainers can tailor the content to a certain extent, at some point the course will be limiting
because it was developed to apply to the market as a whole, not to your unique enterprise and its
specific needs.
On the other end of the spectrum you will find consulting firms that can provide resources and
assistance at any phase of planning and migration. Such solutions are useful when internal resources
are not available. These firms will target solutions to your enterprise and its specific needs. However,
consultants can often be expensive, particularly when minimum commitments are required. When
choosing a consulting firm, be sure to examine its experience and the types of organizations it has
migrated. Microsoft Consulting Services, Hewlett-Packard, and Avanade are large consulting firms that
provide migration services. Numerous small, boutique firms can also offer high-quality services.
A handful of companies provide a blend of training and consulting. Their knowledge base
and content is more dynamic: it can be tuned to the learning objectives of your staff and can be
customized to reflect the specific characteristics of your implementation of the technology. This type
of training provides very targeted knowledge and gives you the tools you need to succeed.
Some of these vendors will also provide consulting and support services to fill in the gaps in
your team’s skill set or resources. Blended consulting and customized training solutions are most
valuable to organizations with experienced IT staff who require knowledge and solutions to achieve
particular goals—in this case, migration—and who have the resources to later implement those
solutions with minimal need for additional outside resources. Such solutions are extremely
Brought to you by NetIQ and Windows & .NET Magazine eBooks

56

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

cost-effective and time-effective in these environments. Intelliem (http://www.intelliem.com) is a
leading provider of customized training and consulting services and has experience with some of the
largest Active Directory implementations in the world.
You should plan to train end users concurrently with the migration of their desktops to the
new directory service. The extent of training required hinges less on whether they will use the new
directory service and more on whether their desktop OS will be migrated. In the case of a desktop
OS migration, significant training should be provided to ensure continuity of operations with minimal
pain, frustration, and Help desk escalation. If the desktop OS remains constant, then the amount of
training required decreases significantly.
As with IT staff, you should evaluate the users’ needs against the capabilities of learning
providers. Off-the-shelf training products will have the lowest hard cost, but might not address the
specifics of your environment sufficiently to ensure job task success. Customized training might have
a higher hard cost, but when well executed will provide a greater Return on Investment (ROI).
When addressing the learning needs of IT staff, our experience has shown that instructor-led
training (or blended training and consulting) is most effective because the staff’s particular needs and
questions are best addressed in a highly interactive environment. Such interaction is certainly beneficial
for training end users also, however if minimal training is necessary and can be delivered effectively
through e-Learning channels, then e-Learning tends to provide the greatest ROI for end users.

Auditing the Existing Environment
In the information-gathering phase, you should examine your present environment with an eye
towards compatibility, interoperability, and other potential roadblocks to a smooth migration. The
lists that follows should be treated as more than just rudimentary exercises in assembling data
points—you should approach each task with the attempt to understand why your current
environment is configured the way it is. You will later use that understanding to make informed
design, testing, and deployment plans.

Auditing the Network Infrastructure
An individual or team should be responsible for documenting the network infrastructure. Diagrams
indicating locations, link types, bandwidth, reliability, and performance will be extraordinarily helpful
as you plan your site topology and migration path.
Be certain to look not only at bandwidth capacity of the network, but also at current bandwidth
usage. A fully-loaded T1 is less useful than a barely used DSL connection. If you overlook bandwidth
usage, you are likely to make inappropriate design decisions.
For each location within the enterprise network, document the following
• A description of location and business conducted at location
• Key personnel contact information and roles
• Users at location (i.e., number, role, special needs)
• Systems in place, broken down by OS
– Desktops
– Servers
– Domain controllers (DCs)
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

• Network infrastructure
_ Internal bandwidth
– Links to external locations
– Other locations that share the link
– Bandwidth (gross and net based on usage and availability)
•Network protocols
– Protocols in use (detail and purpose for any protocol other than TCP/IP)
– Site name
– IP subnets in use
– DNS suffix
• Network services at or used by the location
– Domains and DCs
– DNS servers
– DHCP servers
– WINS servers
– Proxy configuration

Auditing the Directory Services Infrastructure
This migration task requires a detailed examination of the existing directory services infrastructure.
With a Windows network that means looking at present domains, trust relationships, policies, and
administrative tasks and roles.
For each domain, document the following
• Key personnel contact information and roles
• NetBIOS name
• Type of domain (account and resource)
• Reason for existence
• Summary of each DC in the domain
– Name
– Location
– IP configuration
• Locations in domain in which no DC exists and reason why no DC exists
• For each trust relationship in which the domain participates
– Trusted and trusting domain
– Reason for trust
• Account inventory
– Number of users
– Number of computers
Brought to you by NetIQ and Windows & .NET Magazine eBooks

57

58

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003














Number of global groups
Number of local groups on DCs
The name and purpose of service accounts running in the domain and on DCs
Group enumeration: name, scope (global and local), purpose, and membership of all groups
User enumeration: logon name, full name, description, and group membership of all user
accounts. Describe any special or exceptional properties (e.g., password never expires) and
justification.
Security policies
– Password policy
– Password length
– Complexity required
– Maximum password age
– Minimum password age
– Account lockout
– Bad logon count
– Bad logon duration
– Reset account after
– Logon banner
– Message
– Logon limitations
– Logon schedules
– Workstation restrictions
– Certificate, smart card, or other external authentication mechanism
Remote access
– Describe who, why, and how
LanMan Directory Replication (LMRepl): replication of Netlogon share between DCs
– Name of export servers
– Name of import servers
Account management tasks and roles: list the user or group accounts that can do the following
– Create new user accounts
– Reset user passwords
– Reset account lockouts
– Disable user accounts
– Delete user accounts
– Create group accounts
– Modify group membership
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning








59

Delete group accounts
Create computer accounts
Join a workstation to the domain
Join a server to the domain
Delete computer accounts
Reset computer accounts

Auditing Servers
The migration to Windows Server 2003 will affect servers, so it is important to have a comprehensive
inventory of each server, its role and configuration. For each DC and member server, document the
following
• NetBIOS name
• Directory service role
– PDC and BDC
– Member server
• Location
• Domain membership
• Key personnel contact information and roles
• IP configuration
– IP address
– Subnet mask
– Gateway
– DNS servers
– WINS servers
• Hardware inventory
– Make and model
– Processor
– RAM
– Hard disk capacity and free space
– Network card
• Hardware compliance
• Present OS and service pack
• Services and applications running on the server
– Name
– Description
– Reason why it is running on this server
– Security context (account used to run the service)
Brought to you by NetIQ and Windows & .NET Magazine eBooks

60

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Data resources (e.g., shared folders)
– Name
– Description
– Reason why this server hosts this resource
• Printer queues
– Name
– Description
– Reason why this server hosts this printer
• Other considerations
– Physical location of system (describe)
– Who can access or physically touch
– Backup and disaster recovery process (detail tools, policies, and procedures)
– Interoperability requirements
• Logon rights and privileges: list the user or group accounts that can do the following
– Log on locally
– Deny logon locally
– Access from network
– Deny access from network
– Log on over network
– Backup
– Restore

Auditing Applications and Services
Applications and services might be running on one or more than one server. For each application,
document the characteristics noted in the following list. Then in your testing and piloting plan, make
absolutely certain that you include those applications and services.
• Purpose and description
• Application owner contact information
• Contact information for vendor or internal developer
• Importance of the application
• Where the application runs
– System type: DC, server, or desktop
– OSs
• Deployment method
• Compatibility with Windows Server 2003 and Active Directory
• Compatibility with appropriate desktop platform

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

61

• Servers hosting the application (list each)
– Name
– Location
– Domain
• For WINS servers
– Replication topology (push and pull partners)
• For DHCP servers, describe each scope
– Name and description
– IP address ranges
– Excluded addresses
– Lease duration
– Reservations
– Scope options
– Gateway
– DNS
– DNS suffix
– WINS
– WINS node type
• For DNS servers
– Forwarders to (server name, IP, and location)
– Root hints
– Other server configuration
– For each zone
– DNS zone
– Zone type
– Replication partners (server name, IP, and location)
• For remote access servers
– Describe solution and interoperability with Active Directory

Auditing Resources
Resources, in this context, include shared folders and printers. You should have a thorough inventory
of their location and configuration to ensure uninterrupted access during and after migration.
For each data resource (shared folder), document the following:
• Servers hosting resource (name, IP address, and location)
• Folder root path
• Folder share name

Brought to you by NetIQ and Windows & .NET Magazine eBooks

62

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003






Description or role of resource
Importance (for triage)
Access needed (describe in human or business terms)
Access configured (list permissions and groups) at root (share and NTFS permissions) and each
subfolder that has an access configuration different from its parent folder
• Resources replicated to other servers (list name, location, domain, and IP)
For each printer document the following:
Make and model
Compatibility of printer drivers
Physical location of printer
IP address or port of printer
Description or role of printer
Importance (for triage)
Access needed (describe in human or business terms)
Access configured (list permissions and groups)
Servers hosting printer queues for the printer
– Server name
– Location
– Domain
– IP address
– Printer share name
– Special properties of shared printer
• Do users print directly to printer or through a print server?










Auditing Clients and the User Environment
A complete inventory of desktops, laptops, and other devices is particularly important when you
are upgrading or redeploying the desktop OS concurrently with your directory services migration.
But even when you are not upgrading or redeploying—when you are simply changing the domain
membership of the client—you should take the time to inventory each client to identify potential
interoperability and compatibility problems.
For each client system (desktop and laptop) document the following:
• NetBIOS name
• Location
• Primary users
• Domain membership
• IP configuration

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning








63

– IP address or DHCP
– Subnet mask
– Gateway
– DNS servers
– WINS servers
Hardware inventory
– Make and model
– Processor
– RAM
– Hard disk capacity and available space
– Network card
Hardware compliance
Present OS and service pack
Interoperability requirements
Applications installed locally (be certain to fully document the applications)
– Compatibility with the desktop OS

The user environment refers to the bundle of configuration that makes up the user experience.
For example, your finance department might consist of a normal desktop with a mapped drive to a
common, shared departmental folder, plus My Documents redirection for each user. Your sales team
might have a more locked-down desktop with shortcuts to productivity applications and the customer
relationship management application, My Documents redirection, a logon script, and no mapped
drives. These scenarios qualify as two distinct user environments.
For each unique user environment configuration, document the following:
• User profiles configuration
– Roaming or local
– Roaming profile storage location
• Home directories
– Storage location
• Folder redirection
– Storage location
• For each common (shared) folder
– Description and purpose of common folder
– Location (path)
– Mapped drive letter
– Shared with
• Disk quotas
Brought to you by NetIQ and Windows & .NET Magazine eBooks

64

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Desktop configuration
– Offline files
– Lockdown (describe)
– Group Policies
• User data and environment backup and disaster recovery (describe tools, policies, procedures)
• For each script that is run
– Description and purpose of script (be detailed!)
– Filename full path to script
– How the script is applied (e.g., logon, scheduled, SMS)
– Source (e.g., .bat, .vbs, .exe)
– Who does it apply to?

Getting Help in the Auditing Phase
You have certainly seen the vast amount of information that is important to gather and analyze in
preparation for a migration to Active Directory. In a small organization, you or one of your team
members might have sufficient resources to assemble the information manually. In a large
organization, however, the auditing phase can be daunting, and you will certainly want tools to
help automate the process.
Microsoft provides some tools as part of the Windows Server 2003 Resource Kit and the
Windows Server 2003 Deployment Kit, which are both available at http://www.microsoft.com/reskit.
In Chapter 4, we will examine one of the most useful tools, the Active Directory Migration Tool
(ADMT) 2.0.
Although Microsoft’s tools will be completely satisfactory for some implementations, they do not
provide comprehensive and customizable reporting capabilities that larger enterprises demanded. And
for the most part, these tools are presented as either command-line utilities or GUI tools with limited
UIs. Finally, Microsoft does not provide technical support for Resource Kit tools, which can be
problematic when the tool does not behave as expected or produce the desired results.
NetIQ provides a suite of tools based on the same technologies as Microsoft’s ADMT but with a
more comprehensive set of features. Other vendors of tools that facilitate auditing and reporting the
enterprise environment include Quest Software (http://www.quest.com), BMC Software
(http://www.bmc.com), BindView (http://www.bindview.com), DameWare Development
(http://www.dameware.com), and SystemTools (http://www.systemtools.com).

Planning Active Directory Design
Chapter 2 discussed Active Directory design in detail. The information you collect in the auditing
phase will inform your decisions regarding forest, domain, OU, and site design.

Evaluating Upgrade vs. Restructure Migration
Chapter 1 examined the fundamental migration decision you must make: whether to upgrade the
existing domain (called an in-place upgrade) or to create a pristine forest and recreate accounts in
the new directory service (called a restructure or, simply, migration). You should remember that an
in-place upgrade entails upgrading the DCs to Windows Server 2003. All accounts, policies, and
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

65

configuration remain intact. A migration involves copying or otherwise recreating accounts and,
because those accounts have new security IDs (SIDs), determining how to provide uninterrupted
access to existing resources. To accomplish this, you can repermission the resources or add the
account’s old SID to the SIDHistory attribute of the account in Active Directory.
Although an upgrade is clear-cut, it provides limited opportunity for rollback in the event of
failure. In addition, because an upgrade is so straightforward, it encourages organizations to forego
evaluating their enterprise and aligning the directory service with business strategies through a new,
improved design. Therefore, a more-involved restructure is often preferred. A clean installation
encourages a thorough plan and design. And it lets you harden DCs appropriately—rather than
simply upgrading and inheriting their outdated security configuration.

Planning the Migration Path
You have considered whether to upgrade or restructure and completed an inventory of your
environment. Now you can evaluate the information you have collected about your existing
environment in terms of upgrading or restructuring.

Evaluating DCs
If you are restructuring, you will need to evaluate hardware and compatibility of the systems that will
be the DCs in the new directory service. Chapter 1 laid out the hardware requirements for Windows
Server 2003 and the tools available to analyze compatibility.
If you are upgrading, you also need to evaluate hardware and compatibility of DCs, which
Chapter 1 described, and need to ensure that the OS upgrade path is supported. The following list
summarizes supported upgrade paths
• Windows NT 4.0 Standard Edition, Service Pack 5 (SP5) or later will upgrade to Windows Server
2003, Standard Edition and Enterprise Edition.
• Windows NT 4.0 Enterprise Edition, SP5 or later will upgrade to Windows Server 2003,
Enterprise Edition.
• Windows 2000 Server, SP3 or later will upgrade to Windows Server 2003, Standard Edition or
Enterprise Edition.
• Windows 2000 Advanced Server, SP3 or later will upgrade to Windows Server 2003,
Enterprise Edition.
• Windows 2000 Datacenter Server, SP3 or later will upgrade to Windows Server 2003,
Datacenter Edition.

Identifying Opportunity for Server Consolidation and Reappropriation
Based on your Active Directory design and the information you collected about your existing
environment, you are likely to identify opportunities to consolidate and reappropriate servers. Many
organizations have a proliferation of Windows NT 4.0 domains, which can be consolidated into a
single Active Directory domain or perhaps a dedicated forest root with one global child domain. In
these scenarios, you can significantly reduce the number of DCs required to support the directory
service. When moving to Active Directory, many organizations who have greatly upgraded their
network infrastructure during the tenure of their Windows NT 4.0 domains will commonly pull back

Brought to you by NetIQ and Windows & .NET Magazine eBooks

66

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

DCs from small, remote sites into central hub sites and datacenters. Such scenarios further reduce the
number of required DCs.
Migration to Windows Server 2003 is also an ideal time to evaluate the location of services and
applications. With the inventory of your present environment as a guide, you should plan to move
applications and services to systems in such a way to maximize security and performance and to
facilitate migration. For example, to minimize the vulnerability surface of the systems dedicating your
DCs whenever possible is a best practice. If your DCs currently host printers or shared folders or run
applications such as SQL Server, consider moving those to member servers. Many design guides
suggest that DCs should serve as base infrastructure services, such as the DC, DHCP, DNS, and
WINS server, and should perform no other roles.
The cleaner the DC is, the cleaner the migration will be, particularly in an upgrade scenario. To
reduce the complexity when upgrading your DCs, consider moving all services off of the DC before
you upgrade it. You can always move services back to the DC after the upgrade is successful.

Evaluating Server Migration Order
A question administrators often ask regarding migration is, “Should I migrate my servers or my DCs
first?” Not surprising, the answer is, “It depends.” You should look at the costs and benefits of each.
If you determine that your organization will benefit more from the capabilities of Active Directory in
the enterprise, then your DCs might be the priority. If you see server features such as shadow copies,
Windows SharePoint Services, or enhanced security as providing a greater immediate benefit, then
migrating servers might be higher on your list.
Most likely, you will migrate in a more blended manner. As you examine the information you
gathered about your servers and DCs, you are likely to identify dependencies that will drive your
decision regarding migration order. For example, if you follow our recommendation to clean a DC of
unrelated services before upgrading it, you will have to determine which server will host the service
before migration, and whether that service will be moved back to the DC after migration.
As another example, we recommend upgrading Windows RAS servers before upgrading the
directory service. Windows NT 4.0 Servers running RAS will be unable to communicate with Active
Directory and users will be unable to connect (unless you relax the default security settings for AD,
which is not a recommended practice). Therefore, before migrating the domain to AD, upgrading RAS
servers to Windows Server 2003 or Windows 2000 is best.
In an upgrade scenario, you will also need to plan for the maintenance of logon scripts and
system policy files on BDCs. If changes to files are likely to occur while Windows NT DCs remain,
you will need to either copy the files manually into the Netlogon shares of the BDCs or reconfigure
the LMRepl service. LMRepl is responsible for replicating logon scripts to the Netlogon shares of
Windows NT DCs. The best practice is to ensure that you upgrade the Windows NT DC that acts as
the export server last. You might need to reconfigure the export server to achieve this. For example,
if the PDC is the export server, you must upgrade the PDC first, so you configure a BDC as the
export server and upgrade that BDC last.
After you have evaluated dependencies that drive migration order and have looked at the costs
and benefits of migrating each server, you might want to factor in one last consideration: learning.
The first server and DC you migrate will provide valuable lessons and an opportunity to put your
planning to a test. We suggest you migrate servers that you identify as more straightforward and less

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 3 Migration Planning

67

critical first. In this way you can provide the team with a successful experience and a learning
experience with a reduced likelihood of risk to the organization.

Next Steps
After thoroughly auditing your existing environment and planning the migration path for servers and
DCs in the enterprise, you should ensure that you have budgeted for ample time in the lab. As with
information gathering and planning, testing tends to be minimized even though it is crucial to the
success of a migration. Each application and each job task should be evaluated in the lab. And you
should test each process that will be used to migrate systems and services.
In Chapter 4, we will look at the tools and procedures used to perform an in-place upgrade and
domain restructure.

Resources
Microsoft has centralized the best resources about migration in two areas: the Windows Server 2003
site at http://www.microsoft.com/windowsserver2003/upgrading and in the Deployment Kit available
for download at http://www.microsoft.com/reskit.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

68

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Chapter 4

Migration Implementation
This chapter will detail the process of implementing a migration planned according to the earlier
chapters in this book. We will clarify terminology and examine the tools and procedures related to
two types of migration: domain upgrade and domain restructure. We will focus on the migration from
Microsoft Windows NT Server 4.0 to Windows Server 2003. And to show the user migration process
step by step, we will examine restructuring a Windows NT Server 4.0 domain into a Windows Server
2003 Active Directory domain. To perform the migration we will use the Active Directory Migration
Tool (ADMT) because it is freely available from Microsoft, plus we will provide guidance in the
selection of third-party tools that deliver enhanced feature sets and performance.

Overview of Migration
First, let’s clarify some terminology that you might have found confusing thus far. The term migration
refers to the transition between two platforms—in this case two directory service platforms. You can
migrate one of two ways: upgrading a domain or restructuring a domain.

Domain Upgrade
A domain upgrade involves upgrading the PDC of a Windows NT Server 4.0 domain to Windows
Server 2003. When you upgrade the OS of the existing domain, rather than installing the new OS
on a new server, you retain the existing domain structure, users, groups, and computer accounts.
Therefore, domain upgrades are sometimes called in-place upgrades or in-place migrations.
Although the process is straightforward and effective, a domain upgrade is an all-or-nothing
operation in that after you have upgraded, the old environment ceases to exist (with the exception
of backups or other recovery methods). A domain upgrade does not immediately provide the
opportunity to improve the administrative model of your domain, and you cannot leverage many of
the capabilities of Active Directory until you upgrade all Windows NT Server 4.0 BDCs and raise the
domain functional level to Windows 2000 native or higher.

Domain Restructure
Due to the limitations of domain upgrades, most organizations choose a domain restructure
migration. When you migrate by restructuring, you move or copy the accounts from one domain
(the source domain) into another domain (the target domain). Restructuring is sometimes called
parallel migration (or parallel upgrade), incremental migration (or incremental upgrade), or simply,
migration.
This chapter, and this book, focus on restructuring from a Windows NT Server 4.0 source domain
to a Windows Server 2003 target domain in a new, pristine forest. Because Windows NT Server 4.0
domains cannot participate in an Active Directory forest, such restructuring is always an interforest
migration: a migration between domains in separate forests. However, domain restructuring
terminology, concepts, and procedures also apply to interforest migrations between a Windows Server
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

69

2003 or Windows 2000 Server source domain and an Active Directory domain in a separate forest;
and to intraforest migration—that is, the restructuring or moving of accounts between domains in the
same forest.
An interforest domain restructure preserves the existing source domain and clones (or copies)
accounts into the target domain. This method allows an enterprise to time the transition and even
migrate in phases. Operations go uninterrupted because both domains are maintained in parallel to
support operations for users in either domain. This method also provides a level of fallback because
the original environment remains unaltered in any significant way. After the migration is complete,
you can simply decommission the source domain by moving any remaining accounts, member
servers, and workstations into the new domain, then taking source DCs offline, at which point you
can redeploy those DCs for roles in the new domain.
Equally important to the other benefits, a domain restructure lets you consolidate operations and
build a domain and OU structure that more accurately reflects your administrative model. Many
organizations consolidate multiple Windows NT Server 4.0 domains into one Active Directory
domain—either the forest root domain or a single global child domain. This consolidation can result
in significant cost savings and simplified administration. Because the target domain must be at the
Windows 2000 native or higher functional level, you can immediately leverage important Active
Directory features including increased capacity, flexible group nesting, and universal security groups.

Resource Access During and After Migration
Uninterrupted resource access is the primary concern during any migration. And to perform a
migration you must be comfortable with the concepts of Security Identifiers (SIDs), tokens, access
control lists (ACLs), and sIDHistory.

A review of security fundamentals
The SIDs are domain-unique values that are assigned to the accounts of security principals (e.g.,
users, groups, computers) when those accounts are created. When a user logs on, a token is
generated that includes the primary SID of the user account and the SIDs of domain groups to which
the user belongs. That token is appended with the SIDs of local groups to which the user belongs
directly or through group nesting. The token thus represents the user with all the SIDs associated
with the user and the user’s group memberships.
Resources are secured using a Security Descriptor (SD) that describes the permissions, ownership,
extended rights, and auditing of the resource. Within the SD are two ACLs. The system ACL (SACL)
describes auditing. The discretionary ACL (DACL) describes resource access permissions. Many
administrators and documents refer to the DACL as the ACL. Although this usage is not technically
exact, it is widely recognized.
The DACL lists permissions that are associated with security principals. Within the list, individual
access control entries (ACEs) link a specific permission with the SID of a security principal. The ACE
can be an allow or deny permission.
Best practices suggest that you should manage DACLs by assigning allow ACEs (permissions) to
domain local groups. In the case of files and folders on disk drives, best practices further
suggest configuring the DACL on a high-level folder and letting lower-level files and folders
inherit the permissions through the default NTFS permission propagation. In the case of Active
Brought to you by NetIQ and Windows & .NET Magazine eBooks

70

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Directory objects, best practices suggest configuring DACLs on containers (e.g., sites, domains,
OUs), then letting individual objects within those containers inherit the permissions through the
default AD permission propagation.

When a user attempts to access a resource, the Local Security Authority Subsystem (LSASS) compares
the SIDs in the user’s token against the SIDs in the ACEs in the resource’s ACL.

The effect of domain restructure
With a domain upgrade, accounts are maintained, so the SIDs of security principals remain
unchanged. Users will have no interruption or modification of access to resources that are secured
using ACLs that describe resource permissions, auditing, and ownership based on those SIDs.
However, when performing an interforest domain restructure, accounts are copied or cloned from
the source domain to the target domain. The SIDs are generated for the new accounts in the target
domain, and because the SIDs include the domain’s SID, the SIDs of new accounts will not be the
same as the SIDs of the accounts they represent in the old domain. In other words, even though the
cloned accounts have the same name and many of the same properties, because the SIDs are
different, the accounts are technically different and will not have access to resources in the source
domain. You have two ways to address this problem: security translation or sIDHistory.
Security translation
Security translation is the process of examining each resource’s SD, including its ACLs, identifying
each SID that refers to an account in the source domain, and replacing that SID with the SID of the
account in the target domain that maps the source domain account. This process of changing the
ACLs (and other elements in the SD) to refer to migrated accounts in the target domain is also called
re-ACLing. As you can imagine, security translation or re-ACLing would be a tedious process to
perform manually in anything but the simplest environment. Migration tools such as ADMT automate
security translation.
Security translation also relates to other components of resource migration. In addition to ACLs,
user rights, share permissions, and group memberships must be altered to point to accounts in the
new environment.
sIDHistory
Enterprises typically prefer to take advantage of the sIDHistory attribute to perform effective domain
restructuring. The capitalization, which appears odd, reflects the capitalization of the attribute in the
AD schema. The sIDHistory attribute is supported when an Active Directory domain is running at the
Windows 2000 native or higher domain functional level.
AD security principals (which include users, groups, and the new special-purpose InetOrgPerson
object) have a principal SID and a sIDHistory attribute, which can contain one or more SIDs that are
also associated with the account. When an account is cloned in an interforest domain restructure, the
unique principal SID is generated by Active Directory, and the sIDHistory can be loaded with the
SID of the source account. When a user logs on to an Active Directory domain, the user’s token is
populated with the principal SID and the sIDHistory of the user account and groups to which the

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

71

user belongs. The LSASS uses the SIDs from the sIDHistory just like any other SID in the token to
maintain the user’s access to resources in the source domain.
Group membership
The final concern related to resource access is that of group membership. Global groups can contain
members in only the same domain. Therefore, if you clone a user to a target domain, the new user
account cannot be a member of the global groups in the source domain to which the source user
account belonged. To address this issue, you will first migrate global groups to the target domain.
Those global groups will maintain the source groups’ SIDs in their sIDHistory attributes, thus
maintaining resource access. Then you will migrate users. Migration tools simplify and automate this
process. In fact, when migrating users, the most straightforward process is to simultaneously indicate
that you want to migrate the global groups to which the user belongs. We describe this process in
more detail later in this chapter.

Understanding ADMT
You can use ADMT to migrate objects between a source and a target domain. The migration can take
place between domains in the same forest (an intraforest migration), between domains in different
forests, or, most commonly, between a source domain running Windows NT Server 4.0 and an Active
Directory domain. These latter migration types are interforest migrations.
Many organizations that are running Windows NT have account domains and resource domains.
The tasks performed during a migration to Windows Server 2003 include migrating user and group
accounts in the account domains; migrating the service accounts, local profiles, and shared local
groups in the resource domains; then updating the rights of the migrated users. When the migration
is complete, you can decommission the source domains, then join the computers to the target
domain. Organizations that are migrating domains from one Active Directory forest to domains in a
different forest perform essentially the same tasks.
ADMT 2.0 is on the Windows Server 2003 CD-ROM in the i386\admt folder and is available for
download from Microsoft’s Web site at http://www.microsoft.com/windowsserver2003/downloads
/tools/default.mspx. Figure 1 shows ADMT displayed in the Microsoft Management Console (MMC),
which provides a wizard-driven interface for each migration task. ADMT also supports executing tasks
from the command line, where you can simplify and automate the admt.exe command with option
files that specify parameters for the migration task. Then with a simple text file you can list objects to
migrate, rather than having to enter each object on the command line. ADMT also provides interfaces
that let you script migration tasks with languages such as VBScript. Run the ADMT console and open
the online Help function for details about how to use ADMT from the command shell and about
scripting the ADMT.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

72

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 1:
Viewing ADMT in the MMC

When performing migration tasks, ADMT lets you simulate the migration so that you can evaluate
potential results and errors without making changes to the target domain. Wizards provide an option
to Test the migration settings and migrate later. You can then configure the migration task, test the
settings, and review the log files and wizard generated reports. After identifying and resolving any
problems, you can perform the migration task. You will repeat this process of testing, analyzing
results, then migrating as you migrate users, groups, computer, and perform security translations.
As mentioned earlier, when migrating a user or group in an interforest migration, you are
recreating or cloning the account in the target domain. Although the new account may have the same
name as the original account, it does not belong to the same groups as the original account, nor does
it have the same SID as the original account. ADMT lets you migrate group membership and the
SIDs.
To migrate group membership ADMT evaluates the membership of the source account and adds
the new account to the same group in the target domain. If the group does not yet exist in the target
domain, ADMT can create it automatically.
SIDs are migrated by copying the source account’s SIDs into the sIDHistory attribute of the target
account. The SIDHistory attribute exists in domains that are configured at the Windows 2000 native or
higher functional level. When a user logs on to an Active Directory domain, the user’s security token
includes not only the SIDs of the user account and of the groups to which the user belongs, but also
the SIDs in the sIDHistory attribute of the user and group accounts. Therefore, when a user accesses
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

73

a resource that is secured using a SID from the source domain, the SIDs in the user’s security token
can be used to evaluate the resource’s ACL.
Note that migrating the SIDs is not the default behavior of the ADMT User Account Migration
Wizard. Be certain to select the option to migrate the SIDs.

Alternatively, you can choose not to migrate the SIDs and, instead, perform a security translation.
ADMT can translate the SDs and policies of resources in the source domain to refer to the
corresponding accounts in the target domain. ADMT can translate:
• file and folder permissions
• printer permissions
• share permissions
• registry permissions
• user rights
• local profiles, which involves changing file, folder, and registry permissions
• group memberships

Other Considerations in a Domain Restructure
If you choose to migrate to Windows Server 2003 by restructuring your domains (cloning accounts
from your Windows NT Server 4.0 domains to your Active Directory forest), you need to bear in
mind these other considerations:
• Password migration—ADMT supports migrating user passwords, however it cannot confirm that
those passwords comply with the policies of the target domain regarding password length and
complexity. Non-blank passwords will migrate regardless of the target domain password policy,
and users will be able to log on with those passwords until they expire, at which time a new,
compliant password must be created. If you are concerned about locking down the environment
at the time of migration, this might not be a satisfactory process. You might, instead, want to let
ADMT configure complex passwords, or script an initial password, then force the user to change
the password at the first logon.
• Objects that cannot be migrated—Some objects cannot be seamlessly migrated. ADMT cannot
migrate built-in groups, such as Domain Admins or the domain local Administrators group. We
will explore options for addressing these groups later in this chapter.

Deploying the New Environment
The first step in implementing a migration is to build the new Active Directory environment you
have designed and planned. This section will describe the tasks and procedures necessary to build a
Windows Server 2003 Active Directory forest. The Help and Support Center in Windows Server 2003
provides detailed step-by-step instructions for each procedure.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

74

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Delegate the DNS Zone for the Forest Root Domain
If you will run DNS on Windows domain controllers (DCs), and if the forest root domain name is a
subdomain in an existing DNS namespace, the administrator of the parent DNS zone must delegate
the zone for the forest root domain. This delegation is not necessary if the forest root domain is at
the root of the DNS namespace, such as domain.local.
In the parent DNS zone, create a Name Server (NS) resource record. The NS record designates
the DNS domain names for authoritative DNS servers in the parent zone, and follows the format:
forest_root_domain IN NS authoritative_server_name

where forest_root_domain is the leftmost portion of the forest root domain name—the portion of the
name that is added as a prefix to the parent domain name; and authoritative_server_name is the full
DNS name of the DC that is the authoritative DNS server for the zone of the forest root domain—in
other words, the first DC in the forest root domain.
Then create a host address (A) resource record in the parent zone for the authoritative DNS
server. Use the full DNS name of the DC. The A record follows the format:
authoritative_server_name IN A authoritative_server_IP_address

where authoritative_server_name is, again, the DNS name of the first DC in the forest root domain,
and authoritative_server_IP_address is its IP address.

Install the First DC in the Forest Root Domain
You are now ready to install the first DC in the forest root domain.

Install Windows Server 2003
Install Windows Server 2003 on a server. Be certain to select to use the NTFS file system on all
volumes and configure TCP/IP according to your DC design specifications.
You will install DNS on the server, but to do so, we recommend that you use the Active
Directory Installation Wizard (dcpromo.exe), which reduces the likelihood of errors. Although
different documents recommend different procedures, we suggest that immediately before running
dcpromo.exe, you configure the server’s TCP/IP properties with no DNS servers. In other words,
remove the DNS server configuration from the network adapters of the server. This procedure is
necessary only on the first DC in the forest root domain. It will help ensure that the wizard installs
and configures DNS settings correctly.

Install Active Directory
Run the Active Directory Installation Wizard (dcpromo.exe). Denote that the server is a DC for a new
domain, and that the domain is in a new forest. In the DNS Registration Diagnostics dialog, select the
option to Install and configure the DNS server on this computer and set this computer to use this
DNS server as its preferred DNS server, as Figure 2 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

75

Figure 2:
Displaying the DNS Registration Diagnostics dialog

Alternately, use an answer file to perform an unattended installation of Windows Server 2003
on the server, and optionally an unattended installation of Active Directory. You can also elect to
perform a Sysprep installation of the server, then run dcpromo.exe in attended or unattended mode.

Post-installation tasks
After installation, be certain to consider whether the following best practices are appropriate for your
environment:
• Review the event log and resolve any errors.
• At the command line, type
ipconfig /all

and ensure that the server is pointing to itself as its primary DNS server.
• Install Windows Support Tools, which are available in the \Support\Tools folder on the
Windows Server 2003 OS CD-ROM.
• At the command line, run netdiag.exe and dcdiag.exe and resolve any errors.
• Verify DNS Forward Lookup Zones, which Figure 3 shows. Open the DNS snap-in, navigate to
Forward Lookup Zones, and verify that the zones _msdcs.forest_root_domain_name and
forest_root_domain_name were created. Expand the forest_root_domain_name node and verify
that DomainDnsZones and ForestDnsZones were created.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

76

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 3:
Verifying DNS zones in an Active Directory domain

• Verify recursive query configuration. While in the DNS snap-in, confirm that recursive queries
have been configured correctly to use either root hints or forwarders. From the Properties dialog
box of the DC, click the Root Hints or Forwarders tab to confirm configuration.
If you followed our recommendation to remove DNS server addresses from the TCP/IP
properties of the server before running dcpromo.exe, you will need to add DNS forwarders.

You can also use the Monitoring tab to perform tests of simple and recursive queries.
• Configure the Windows Time Service. The PDC Emulator of the forest root domain should be set
to synchronize from a reliable external time service, such as a Global Position System (GPS),
radio clock, or external time service such as the Network Time Protocol (NTP) servers,
ntp2.usno.navy.mil (192.5.41.209) or tock.usno.navy.mil (192.5.41.41). To configure the service:
1. At the command line, type the command
W32tm /config /manualpeerlist:peers /syncfromflags:manual

where peers is a space-delimited list of DNS names or IP addresses. If you need to specify
more than one peer, enclose the list in quotes.
2. Then type the command
W32tm /config /update

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

77

• When you migrate by restructuring (rather than upgrading Windows NT Server 4.0 domains), you
can immediately raise the domain and the forest to the Windows Server 2003 functional level.
Use the Active Directory Domains and Trusts tool to perform these tasks. The Help and Support
Center provides detailed steps for this procedure.
• Enable Remote Desktop for Administration (formerly known as Terminal Services in Remote
Administration mode) to enable administrators to log on remotely when necessary. To enable
Remote Desktop for Administration, in Control Panel, double-click System, click the Remote tab,
then select Allow users to connect remotely to this computer. Note that after enabling Remote
Desktop for Administration, by default only administrators can connect to DCs. This contrasts
member servers, which let the Remote Desktop Users group connect when Remote Desktop for
Administration is enabled.
For further details regarding verification of a successful controller installation, see the Microsoft
article “How to Verify an Active Directory Installation in Windows Server 2003” at
http://support.microsoft.com/default.aspx?scid=kb;en-us;816106 or the Microsoft article
“How to Verify an Active Directory Installation” at
http://support.microsoft.com/default.aspx?scid=kb;en-us;298143.

Install Additional DCs in the Forest Root Domain
You follow similar procedures for the second and any additional DCs in the forest root domain.
Among the important differences are:
• When you run the Active Directory Installation Wizard (dcpromo.exe), indicate that the server
should be an Additional DC for an existing domain.
• The Active Directory Installation Wizard will replicate data from an existing DC to the new DC.
This process can take a significant amount of time, particularly in large domains or over slow
links. Windows Server 2003 supports creating a DC from a backup of AD from an existing DC.
You must restore a backup of a DCs System State to a folder on a hard disk, DVD-ROM, or other
local media. Then, run the Active Directory Installation Wizard with the /adv switch:
dcpromo.exe /adv. The wizard will prompt you for the location of the restored System State
backup. The Help and Support Center describes this process in detail.
• DNS does not automatically install on additional DCs. Following the installation of Active
Directory, you need to install DNS manually.
1. Open Add or Remove Programs from Control Panel.
2. Click Add/Remove Windows Components.
3. In Components, select the Networking Services check box, then click Details.
4. In Subcomponents of Networking Services, select the Domain Name System (DNS) checkbox,
click OK, then click Next.
5. If prompted, in Copy files from, type the full path to the distribution files then click OK. The
required files will be copied to your hard disk.
• Follow the same post-installation tasks as on the first DC, but don’t use the DNS snap-in to verify
the creation of ForestDNSZones and DomainDNSZones. From the command line, type
Brought to you by NetIQ and Windows & .NET Magazine eBooks

78

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

repadmin /showreps

and verify that the ForestDnsZones and DomainDnsZones application directory partitions replicated
successfully.
• You should still use the DNS snap-in to verify that recursive queries are configured correctly.
• To account for the second DNS server
1. Configure DNS on both servers. Enable Aging and Scavenging to allow automatic cleanup
and removal of stale Resource Records (RRs), which can accumulate in zone data over time,
particularly in zones that accept dynamic updates. Aging and scavenging is an important
feature to configure, but it is also important that you read “Understanding aging and scavenging” in Help and Support Center for Windows Server 2003 before enabling aging and
scavenging. Incorrectly configuring the feature can lead to failed queries or security concerns.
2. Configure the DNS client settings on the DNS servers to reflect your DNS infrastructure design.
For example, the first DC might use itself as its primary DNS server and the second DC as its
alternate DNS server. Similarly, the second DC might use itself as its primary DNS server and
the first DC as its alternate.
3. Update the DNS delegation in the parent zone with an appropriate NS and A record for the
new DNS server.
• You will not need to raise the domain or forest functional level again. You perform that
procedure only once.

Configure Site Topology
The forest owner is responsible for delegating the administration of site topology, including site and
subnet objects, site links, site link bridges, servers, and connection objects. To do this, you use the
Active Directory Sites and Services snap-in. Right-click the Sites node and choose Delegate Control.
Give an appropriate administrative group Full Control.
Because the administration of site topology is a sensitive task and is not performed on a day-today basis, we recommend that you create separate administrative user accounts. Then using these
administrative credentials, administrators can use the Run As command to launch the snap-in. Create
these administrative user accounts in the forest root domain. Create a global security group with an
appropriate name, such as SiteAdmins, and place the user accounts in the group. If you want to
place user accounts from other domains in the SiteAdmins group, then the group must be a domain
local group or, as we recommend, a universal group. The forest must be at Windows 2000 native or
higher functional level to support universal security groups.
After delegating the administration of site topology, create sites and subnets according to your
design. If the design identifies site links or site link bridges or outlines modifications to other
site-related objects and properties, you can configure Active Directory accordingly.

Complete the Installation of the Forest Root Domain
If your design calls for more than two DCs in the forest root domains, follow steps described in the
installation of the second DC to bring remaining DCs into the domain. As you add additional DCs,
you might need to modify the DNS client configuration on existing DCs to ensure that DCs are

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

79

configured to use an alternate DNS server that is most accessible in terms of responsiveness and
reliability.
Use the Active Directory Sites and Services snap-in to designate global catalog servers. Expand
the Sites node, the site, and the DC that you want to host a copy of the global catalog. Right-click the
NTDS Settings node and select Global Catalog.
Relocate operations masters as shown in your Active Directory design. See the Help and Support
Center for information about how to transfer operations master roles. To implement a standby
operations master, you should ensure that replication occurs directly between the active operations
master and the standby master. Manually create connection objects as required.

Create Additional Domains in the Forest
After creating the forest root domain, you can add more domains to the forest by creating a new
Windows Server 2003 domain in the forest or by upgrading an existing Windows NT Server 4.0
domain to Windows Server 2003 and, in the process, joining that domain to the forest.
Review the design information related to DC configuration, placement, and hardware, as you
did in preparation for deploying the forest root domain.
Before deploying the domain, create the delegation for the new domain in the parent domain’s
zone. In the DNS snap-in, right-click the forest root domain and choose New Delegation. A wizard
will guide you through the delegation process. In the wizard’s Delegated Domain Name dialog, enter
only the leftmost portion of the new domain’s name—the part of the name that makes it a child of
the parent. In the Name Servers dialog, add the names and IP addresses of at least two DCs that you
plan to install in the new domain.
You will not redelegate or recreate site topology, as site topology is common to every domain in
the forest. But you should make sure that you update the site topology to include subnets in use by
new domains before creating those domains. If you define subnets before DC installation, then the
DC will automatically end up in the correct site container.
The steps you follow for the first DC in each new domain will be similar to those followed for
the first DC in the forest root domain. While running the Active Directory Installation Wizard
(dcpromo.exe), indicate that the server is a DC for a new domain and that you want to Create a new
child domain in an existing domain tree. The wizard will offer to install DNS automatically on the first
DC in each new domain. Select Install and configure the DNS server on this computer and set this
computer to use this DNS server as its preferred DNS server.
Follow the post-installation steps described for the first forest root DC. When verifying DNS
forward lookup zones, you will instead verify that the zones _msdcs.forest_root_domain_name and
new_domain_name were created.
For additional DCs, follow steps described for the second and additional DCs in the forest root
domain. You will need to identify which DCs are global catalog servers and operations masters.

Preparing to Migrate with ADMT
Before migrating with ADMT you must perform several tasks, including:
• Establishing a two-way trust between the source and the target domains.
• Establishing migration credentials. To run ADMT you will use user accounts and those accounts
must have appropriate credentials on the computer running ADMT, in the target domain, in the
source domain, and on all computers that you migrate.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

80






Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Installing ADMT.
Preparing the source domain.
Preparing the target domain.
Preparing the Password Export Server (PES). The PES is a DC in the source domain that must be
configured when you plan to migrate user passwords.

Like many tools, ADMT provides several ways for you to perform each of these tasks. The
Windows Server 2003 Deployment Kit contains several chapters that detail alternative approaches to
these tasks. The following sections will provide a straightforward method for accomplishing these
tasks. You can apply the steps in the lab to familiarize yourself with ADMT. In fact, if you follow
these sections in order, you will find a nifty shortcut that will do some of the required configuration
for you automatically.

Establishing a two-way trust between the source and target
To create a two-way trust between the target (Windows Server 2003) and source (Windows NT
Server 4.0) domain
1. On the Windows 2003 DC, open the Active Directory Domains and Trusts snap-in.
2. Right-click the target domain and select Properties.
3. Click the Trusts tab.
4. Click New Trust.
5. The New Trust Wizard opens. Follow the instructions provided by the wizard. Create a two-way
trust, as Figure 4 shows, with the source Windows NT Server 4.0 domain. Select domain-wide
authentication and create a trust password. Until you have configured the Windows NT Server 4.0
side of the trust, you cannot validate the trust, so choose No when prompted to validate the trust.
When you receive the dialog box regarding SID Filtering, close it.

Figure 4:
Using the trust wizard to create a two-way trust

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

81

6. On the Windows NT Server 4.0 DC, open User Manager for Domains.
7. Click the Policies menu and select Trust Relationships.
8. Add the name of the target domain to both the Trusting Domains and Trusted Domains list, as
Figure 5 shows.

Figure 5:
Adding the target domain in the trust relationships dialog box

9. Click OK.
10. To validate the trust open the Active Directory Domains and Trusts snap-in on the Windows
2003 DC.
11. Right-click the target domain and select Properties.
12. Click the Trusts tab.
13. For each trust, click Properties, then click Validate. Follow the instructions that the wizard provides. You will be prompted for administrative credentials in the source domain.
Successful migration might require additional trusts. Be sure to reference the sections discussing
trust migration and the migration of account and resource domains for more information.

Establishing migration credentials
The accounts used to perform migration tasks require administrative credentials. In other words, the
accounts should belong directly or indirectly to the local Administrators group. This requirement is
true for the account used in the source domain, in the target domain, on the computer running
ADMT, and on computers targeted for migration or security translation.
The user account you use to log on and run ADMT will require the following specific permissions for these particular tasks:
• Run ADMT—Local administrator on the machine on which ADMT is running.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

82

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Migrate users and groups—Administrators group membership in the source domain; delegated
permission to create user or group objects in the target OU.
• Migrate the SIDs along with users and groups—Administrators group membership in the source
domain; delegated permission to create objects and to have full control of those objects in the
target OU and the delegated extended right MigrateSIDHistory on the domain object
(DC=<domain_name>) or target OU.
• Migrate computers—Administrators group membership in the source domain and on each computer being migrated; delegated permission to create computers and to have full control of computer objects in the target OU.
• Migrate roaming user profiles—Administrators group membership in the source domain and delegated permission to modify user objects on the target; Administrators group membership on the
server that maintains the roaming user profiles.
• Migrate security (files, folders, printers, shares, user rights, local user profiles, group memberships)—Administrator rights on the computer on which you translate security.
With such a complex list, you can understand why we recommend that, for simplicity’s sake, the
account used to run ADMT belongs to the Administrators group on the ADMT computer, in both the
source and target domains and on each machine in the source domain.
The easiest way to achieve this is to create a user account in each domain and nest it, directly or
indirectly, in the Domain Admins group of its domain and in the local Administrators group of the
other domain. We recommend configuring the accounts and memberships as Figure 6 shows.

Figure 6:
Displaying the recommended migration credentials scheme

SourceUser

TargetUser

Domain Admins
global group

Source_MigAdmins
Administrators
local group

Target_MigAdmins
global group

Administrators
local group

Domain Admins
global group

Administrators local
group on DCs
Computer

Administrators built-in
local group on DCs

Computer

Source (NT4) Domain

Two-way Trust

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Target (Active Directory)
Domain

Chapter 4 Migratiion Implementation

83

The key features of this credential scheme are
• The TargetUser account in the target domain has Domain Admins and Administrators credentials
in the target domain and local Administrators credentials in the source domain. This user account
will be used to run ADMT when performing user and group migration tasks.
• The SourceUser account in the source domain has Domain Admins and Administrators credentials
in the source domain and local Administrators credentials in the target domain. Through its
membership in the source domain’s Domain Admin group, it is a default member of the
Administrators group on every server and workstation in the source domain. You will log on
with SourceUser credentials to perform resource migration tasks, such as security translation and
computer migration.
Although there are simpler ways of creating appropriate credentials, this web of accounts and
memberships makes it easier to understand what is happening during a migration and makes clearer
which credentials are in use. In addition, our recommendation lets you easily remove all migrationrelated accounts after the migration has been completed.
To provide sufficient administrative credentials for the migration of user accounts
1. In the Windows Server 2003 domain, open the Active Directory Users and Computers snap-in.
2. Create a user account called TargetUser.
The names of the user and group accounts you create are not important, but we will use the
names we recommend, such as TargetUser, consistently throughout this chapter.

3. You will use this account to log on to the computer running ADMT for most migration tasks.
We will refer to this user account as the target domain migration account.

4. Create a global security group. We will use the name Target_MigAdmins.
5. Add TargetUser to the Target_MigAdmins group.
6. Add the Target_MigAdmins group to the Domain Admins group.
You can nest global groups in global groups and domain local groups in domain local groups in
Active Directory when the domain is at Windows 2000 native or higher functional level.

7. In the Windows NT Server 4.0 source domain, open User Manager for Domains.
8. Open the Administrators group and add the Target_MigAdmins group from the target domain as
a member.
9. Create a user account called SourceUser. You will use this account to log on to the computer
running ADMT to perform resource migration and security translation.
We will refer to this user account as the source domain migration account.

10. Create a global group. We will use the name Source_MigAdmins.
11. Add SourceUser to Source_MigAdmins.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

84

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

12. Add SourceUser to the Domain Admins group.
13. Add the Source_MigAdmins group to the Administrators group.
14. Returning to the Windows Server 2003 domain, open the Active Directory Users and Computers
snap-in.
15. Add the Source_MigAdmins group from the source domain to the local Administrators group in
the target domain.
The cross-domain credentials (source user account is in the local Administrators group of the
target domain and vice versa) are particularly important. Be sure to double-check your account
nesting to be sure you covered all of your bases.

Microsoft Exchange Server migration requires a user account that has Exchange Administrator
privileges. The Exchange Migration Wizard within ADMT will prompt you for these credentials.

Installing ADMT
You will find ADMT located in the i386\admt folder of the Windows Server 2003 CD-ROM. Be
certain to read the entire readme.doc file in the same folder. You can install ADMT on any Windows
Server 2003 or Windows XP computer that meets the following requirements:
• Pentium II or later CPU.
• Enough memory to accommodate the migration process. The minimum amount of available RAM
is 10MB, plus 4KB for each user to be migrated.
• A hard disk partition with at least 35MB of free space, which includes 7MB for ADMT installation
and 25MB for data and log files.
You can also use Remote Desktop to run ADMT. However, you need to know the trick to installing
the tool within a Remote Desktop session. The admt.msi file must be copied to the server and run
from a local hard drive or CD-ROM drive: it cannot be installed from a network drive.
For each operation, ADMT makes a connection to a DC in the target domain. If that DC becomes
unavailable during the operation, the operation will fail—ADMT does not connect to an alternate DC.
You must restart the operation. Therefore we recommend, when possible, that you run ADMT on a
DC in the target domain. In addition, ADMT must have connectivity to the RID Pool Master. So
installing ADMT on the RID Pool Master will conserve network traffic.
When migrating objects from computers in a source domain to a target domain, ADMT installs
services, called agents, on the source computers. Using the security credentials of the user account
used to run ADMT, these agents are dispatched from the computer on which ADMT is running and
are installed on other computers. After installation, the agents run as a service and use the local
system security credentials. Loading software on the source computers before the migration is not
necessary. To dispatch the agent successfully
• ADMT must be running with credentials that are in the Administrators group of the computer
• remote registry must be enabled
• NetBIOS must be enabled
• the Server service must be running
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

85

Preparing the target domain
To prepare for migration, first ensure that the domain is at the Windows 2000 native or Windows
Server 2003 functional level, which is required to support the sIDHistory attribute. For more
information about domain functional levels, see the Microsoft TechNet information at http://www
.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/sag_changedomlevel.asp
and the Microsoft article “HOW TO: Raise Domain and Forest Functional Levels in Windows Server
2003” at http://support.microsoft.com/?kbid=322692.
Next, disconnect any mapped drives or other connections to the source domain. If you do not,
you might encounter “credentials conflict” errors. Finally, check that the default administrative shares
(e.g., c$, admin$) exist.
Finally, auditing for account management (success and failure events) must be enabled. But, if
you follow the steps in the upcoming section, “A nifty shortcut,” ADMT will enable appropriate
auditing automatically.

Preparing the source domain
The source domain can be Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0.
The focus of this chapter is migrating from Windows NT Server 4.0 source domains. And the PDC
must run Windows NT Server 4.0 Service Pack 4 (SP4) or later.
If the domain is a Windows NT Server 4.0 domain or an Active Directory domain in a separate
forest, the migration is an interforest migration. If the domain is within the same Active Directory
forest, the operation is an intraforest migration.
The following conditions must exist:
• The source domain must have a two-way trust established with the target domain, as described
earlier. In many Windows NT Server 4.0 migration scenarios, you will have account domains
(containing users and global groups) and resource domains (containing computers and local
groups). In such scenarios, the account and resource domains must trust the target domain in
order to maintain smooth access to resources during migration.
• Mapped drives or other connections to the target domain must be disconnected. If you do not,
you might encounter “credentials conflict” errors.
• The default administrative shares, such as admin$ and c$, must exist.
In addition, several modifications must be made to the source domain PDC. You will learn in the
next section about a shortcut that will make these changes automatically:
• The PDC, or PDC emulator, in the source domain must have a specific registry value created.
As mentioned earlier, if the entry is not present, ADMT creates it automatically. Therefore, we
recommend running a test migration and, when prompted to make the change to the registry,
click OK. Alternatively, you can manually create the entry by opening the registry editor and
navigating to HKLM\System\CurrentControlSet\Control\Lsa and creating a DWORD registry value
called TcpipClientSupport and setting its data to 1.
• Auditing for account management (success and failure events) must be enabled. ADMT will
enable appropriate auditing automatically.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

86

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• A new local group called DomainName$$$, where DomainName is the NetBIOS name of the
source domain, must be created with no members. You do not need to create this group—
ADMT does so automatically—but if a group already has this name, ADMT will be unable to
create the group and the migration operation will fail.
A nifty shortcut
When the source domain PDC is running Windows NT Server 4.0 SP5 or later and has 128-bit
encryption installed, the target DC is running Windows Server 2003, and you run ADMT on the target
DC, ADMT automatically does some of the remaining configuration for you. Simply perform the
following tasks:
1. Using the steps in the preceding sections, establish trusts and credentials.
2. Log on to the ADMT computer as the target domain user account (TargetUser).
Troubleshooting tip: At this first ADMT procedure we want to note that if a migration task fails,
you should check whether you are logged on with the correct user name and whether you
have correctly established user and group accounts as detailed earlier in this chapter.

3. Open the ADMT console from the Admin Tools group.
4. Right-click the ADMT node in the tree pane and choose Group Account Migration Wizard.
5. Follow the instructions provided by the wizard. Be certain to select the following options:
o Test or Make Changes: Select Test the migration settings and migrate later.
o Group Selection: Click Add and select any one group from the source domain.
6. When the Group Options dialog appears, select Migrate Group SIDs to the target domain and do
not rename accounts. Deselect other options in this dialog.
7. Click Next. The wizard will prompt you with a series of messages explaining that changes need
to be made in order for the SID migration to be successful. Confirm each message by clicking
Yes. The final message informs you that the source DC must reboot. Confirm by clicking Yes.
8. A message will appear explaining that the DC must reboot. Wait for the source DC to restart then
click OK.
The PDC requires a restart for the changes to take effect. If your PDC did not automatically
reboot, restart it manually.

9. Continue following the instructions provided by the wizard. Be certain to select the following
options
• User Account: Type the name and password of the source domain user account (SourceUser).
• Naming Conflicts: Select Ignore conflicting accounts and don’t migrate.
10. When the wizard has finished, click View Log and check the log for any errors.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

87

To verify that configuration has been completed, do the following:
• Check the source domain. You should find a new local group named source_domain$$$. This
account supports ADMT auditing of SIDhistory migration.
• Open regedit.exe on the source domain PDC. Navigate to the
HKLM\System\CurrentControlSet\Control\Lsa key. You should see a DWORD registry value
named TcpipClientSupport and its data should be set to 1.
• Account management auditing for successes and failures should be enabled on both the source
and target domains.
This shortcut to initializing ADMT will not prepare the environment for user password migration.
If you will be migrating passwords, follow the instructions related to password migration in the next
section.

Preparing to migrate passwords
ADMT 2.0 can migrate user passwords. To accomplish this, ADMT configures a PES in the source
domain. ADMT then connects to the PES to transfer password information, which is encrypted using
a key generated by ADMT. Before migrating passwords, you must perform additional tasks to prepare
the target domain, generate the encryption key, and configure the PES.
Preparing the target domain
Ensure that you have performed the following tasks in the target domain:
• Have 128-bit encryption installed. 128-bit encryption is installed by default on Windows Server
2003, Windows XP, and Windows 2000 Server SP3 or later.
• The PES requires that the “Pre-Windows 2000 Compatible Access” group has “Read All
Properties” rights on the object CN=Server,CN=System,DC=<domain_name>. On Windows Server
2003 this setting is the default.
• Change the Default Domain Controller Security Policy.
To change the Default Domain Controller Security Policy
1. Open the Domain Security Policy administrative tool on the target DC.
2. Navigate to Local Policies\Security Options.
If you want to use the Group Policy Management Console or the Group Policy Object Editor to
modify the policy, navigate to Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options.

3. Double-click the policy setting: Network Access: Let Everyone permissions apply to anonymous
users.
4. Select Define this policy setting.
5. Select Enabled.
6. Click OK.
7. Close the Default Domain Controller Security Settings console.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

88

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

8. At the command prompt, type the command
gpupdate

• The Everyone special identity must be a member of the Pre-Windows 2000 Compatible Access
group or else ADMT will log an “Access Denied” error. Type the following command at the
command prompt of a DC:
NET LOCALGROUP “Pre-Windows 2000 Compatible Access" Everyone /ADD

• Reboot the DC.
Generating the encryption key
Before installing the password export service on the PES, you must create an encryption key that will
be used when configuring the PES. You perform this task on the ADMT computer.
To generate the PES encryption key
1. At the command line, type:
admt key SourceDomainName FolderPath Password

• SourceDomainName is the NetBIOS name of the source domain.
• FolderPath is a valid folder path, in which the encryption key will be created. We recommend
saving the key on a floppy disk, but you can save it to any folder, and you can copy or move
the key at a later time.
o Password is the encryption key password, which will be required to successfully install the
password export service on the source DC. You can use an asterisk (*) for this command
option and admt.exe will prompt you for the encryption key password.
2. For more information about the comand’s syntax, at the command line type
admt key

3. Transfer the encryption key—a .pes file—to the PES.
You must transfer the encryption key to the source domain password export computer on a
local drive (floppy or hard disk). We recommend you use a floppy disk so you can destroy,
reformat, or store it in a secure location after migration.

Configuring the PES
When migrating from a Windows NT Server 4.0 domain to an Active Directory domain
• We recommend the password export server be a BDC dedicated to the purpose.
• NT 4.0 SP5 or later and 128-bit encryption must be installed. To achieve both requirements, you
can install the high encryption version of SP6a on the PES.
Log on to the PES with administrative credentials and install the password export service by
launching pwdmig.exe, located in the i386\admt\pwdmig folder of the Windows Server 2003
CD-ROM.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

89

If you have not previously installed Windows Installer on the PES, Windows Installer will
automatically load, after which you must reboot and rerun the installation routine.

You will be asked to provide the location of the encryption key and enter the encryption key
password. You will be prompted to reboot the DC to complete the installation—but you can save a
reboot by answering “No” and completing the next step.
Open the registry editor (regedit.exe) and navigate to the registry key HKLM\ SYSTEM
\CurrentControlSet\Control\Lsa. Change the value of the AllowPasswordExport DWORD registry
entry to 1. Reboot the DC for the change to take effect and for the password migration DLL to
activate.
After migrating passwords, you can disable a PES from supporting password migration by
setting the value of the AllowPasswordExport registry value (found in HKLM\
SYSTEM\CurrentControlSet\Control\Lsa) to 0. Reboot the PES for the change to take effect.

Password migration cannot verify that passwords meet the password requirements of the target
domain. If passwords violate the password policy of the target domain (for example, minimum
length), users will be able to log on but will be required to change their password at the first logon.
However, if passwords are blank, ADMT will automatically generate a complex password for the
user. When ADMT generates a password for a user automatically, for any reason, it logs the password
in the file: C:\Program Files\Active Directory Migration Tool\logs\Passwords.txt.
By default, all users will be required to change their password at their first logon, regardless of
how their password was migrated or generated by ADMT.

Using ADMT to Migrate from Windows NT Server 4.0
to Windows Server 2003
After all that preparation, you are probably itching to begin using ADMT. Well the time has come!
Migrating from Windows NT Server 4.0 to Windows Server 2003 is inherently an interforest domain
restructure. The migrating tasks involved include:
• migrating or recreating trust relationships
• identifying service accounts
• migrating desired global groups
• creating a group mapping and merging plan
• migrating user accounts (You will often want to migrate users’ workstations and profiles
concurrently.)
• migrating shared (domain) local groups
• migrating service accounts
• migrating or translating resources, including:
– servers and workstations
– user profiles
Brought to you by NetIQ and Windows & .NET Magazine eBooks

90

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

– local group membership
– permissions on files, folders, shares, printers, and the registry
– user rights
• decommissioning the source domain
From a best practices perspective, identifying service accounts and migrating global groups
before migrating user accounts is important. Migrating user accounts before migrating computers or
translating resources that they use is also important. This means if you have a Windows NT Server 4.0
master domain model, migrating account domains before migrating resource domains is best.
Decommissioning the source domain is advisable only after all other migration tasks are successful.
The order in which you perform the remaining tasks is dependent upon your migration plan
(i.e., the source environment, the target environment, the desired migration procedures). In some
environments, some of these tasks might not be necessary. Quite often, you will jump around:
migrate some users, computers, and resources, then start again with additional users, computers, and
resources. ADMT is effective at ensuring that you accomplish all tasks effectively, regardless of the
order in which you perform them.
Throughout this section, we will point out best practices and mention ways to avoid making
common mistakes. One important best practices is migrating each type of object (e.g., groups, users,
computers) separately. If you try to simultaneously migrate multiple types of objects, such as users
and groups, the interaction of options in the wizard become too complex to effectively analyze. Keep
the process simple by migrating users and groups in separate procedures. Similarly, don’t try to
migrate all users in one pass or all groups at once. Migrate in batches.
ADMT is wizard-driven. Because migration is an advanced task, we assume you can follow
instructions in a wizard and describe only steps, choices, or actions that are specific to ADMT or are
not selfexplanatory. For more control and automation, you can use a scriptable interface or a
command-line tool (admt.exe) to perform most ADMT operations. For information about using the
command-line tool, type admt.exe and press enter or see the Help documentation. TemplateScript.vbs
is a template script that installs with ADMT and explains most of the interface.
The Undo Wizard is not available through the command-line or scripting interfaces. However,
you can use the GUI Undo Wizard to undo operations that you originally performed through scripts
or the command-line interface.
The Undo wizard will undo major operations performed by ADMT, such as creating a group or
user, but it cannot clean up every transaction. Third-party migration tools offer more
sophisticated, transaction-based migration with more complete rollback capabilities.

Migrating or Recreating Trust Relationships
Resource access across domains requires trust relationships. Trust relationships let user and global
group accounts in a trusted domain be members of local groups in a trusting domain and have
permission to access resources in the trusting domain. You learned earlier that a two-way trust must
exist between the source and the target domain.
In addition, your target domain should have trust relationships with the domains that were
trusted by or trusting of the source domain. ADMT has a Trust Migration Wizard that will facilitate the
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

91

migration of trusts from the source domain to the target domain. However, we recommend that you
take the opportunity to carefully examine your existing trust structure, determine which trusts are
required, and rebuild those trusts manually in the new environment.

Identifying Service Accounts
When an application runs as a service, it requires an account that enables the service to log on and
start without a user being interactively logged onto the system. Some services run under the context
of the special, builtin System account. Because the System account is local to each computer and
does not support domain-wide activity, other services—particularly those that affect more than one
computer such as enterprise backup, virus scanning, or defragmentation—are configured to log on
with a domain user account. The account is granted the Log on as a service user right on each system
hosting the service. This right distinguishes these service accounts from standard user accounts. In
addition, a service account is typically set so that the user is not required to change the password at
the first logon and the password does not expire.
When migrating user accounts, ADMT clears the account attribute Password never expires and
sets the attribute Password must be changed at next logon. If you migrate a user account assigned to
a service, these settings will prevent the service account from starting properly. To avoid this
problem, ADMT can identify service accounts based on the Log on as a service user right. ADMT
keeps track of the service accounts it has identified, and when it migrates those accounts, it does not
clear the Password never expires attribute or set the Password must be changed at next logon attribute.
Therefore, before migrating any users, you should identify service accounts.
To identify service accounts
1. Use the source domain user account (SourceUser) to log on to the ADMT computer.
Administrative credentials are required on each machine in the source domain that you will be
scanning for service accounts.

2. Open the ADMT console.
3. Right-click the ADMT node and select Service Account Migration Wizard.
4. Follow the instructions provided by the wizard. Use the list below to guide your choices and
input.
• In the Update Information dialog, select Yes.
• In the Service Account Selection dialog, select the names of all computers with service
accounts.
• In the Service Account Information dialog, select any user accounts that do not need to be
marked as service accounts and click Skip/Include to mark them as Skip.
5. When the wizard has finished running on all computers, the Server List dialog will appear. Click
View Log. Examine the log to determine whether and why the wizard failed on any computers.
You can perform this process of scanning for and logging service accounts on one or multiple
computers, and you can repeat the procedure. Just be sure that you have identified all service
accounts before migrating any of those accounts.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

92

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

To identify service accounts, ADMT dispatches an agent to the server in the source domain. The
agent records services running to a file named dctlog.txt, stored in the %temp% folder, typically
%systemroot%\windows\temp, and tracks the user accounts given the Log on as service right in the
ADMT database.

Migrating Global Groups
The members of a global group must be defined in the same domain as the group. If you want to
migrate a user account to a target domain, then the account cannot be a member of global groups in
the source domain. If a user were to log on to the account in the target domain, the user would not
have access to any source domain resources that were secured using the user’s source domain global
groups, or secured using local groups in the source domain in which source domain global groups
are a member.
Therefore, to ensure a smooth migration, you should migrate global groups before migrating user
accounts that belong to those groups. The new global group in the target domain will receive a new
principal SID, and because you will select the option to migrate SIDs, the SIDs of the source domain
groups will be added to the sIDHistory attribute of the target domain groups.
To migrate global groups
1. Use the target domain user account (TargetUser) to log on to the ADMT computer.
2. Open the ADMT console.
3. Right-click the ADMT node and select Group Account Migration Wizard.
4. Follow the instructions provided by the wizard. Use the list below to guide your choices and
input:
• In the Test or Make Changes dialog, select the Migrate now? option.
We recommend performing a test migration before migrating the accounts. To perform a test
migration, select Test the migration settings and migrate later in this dialog.

• In the Group Selection dialog, select the global groups you want to migrate. Do not select
builtin groups. Using this wizard, you cannot migrate builtin groups.
• In the Group Options dialog, select Migrate group SIDs to target domains and Do Not Rename
Accounts. Ensure that no other settings are selected.
• In the User Account dialog, enter the credentials of the source domain user account
(SourceUser).
• In the Naming Conflicts dialog, select Ignore conflicting accounts and don’t migrate.
5. When the wizard has finished running, click View Log, and review the migration log for any
errors.
6. Using Active Directory Users and Computers, verify that the group accounts exist in the target
domain OU.

Remigrating groups
During the migration, although both domains exist, administering the environment (e.g., modifying
group memberships) in the source domain is a best practice. You can rerun the Group Account
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

93

Migration Wizard as described below to update the target domain. If you need to make changes to
the target domain (i.e., add a global group, change group membership), you should repeat the
change in the source domain so that the source domain is, in effect, synchronized. This step will
make rollback to the source domain (if necessary) easier for you.
If your migration takes place over an extended period of time, group memberships might
change and you will need to remigrate groups to update their membership in the target domain. To
remigrate groups, run the Group Account Migration Wizard. The process is the same as any group
migration, with these exceptions:
• In the Group Options dialog, select Fix membership of Group. This option scans the membership
of the source group and, after creating the group in the target domain, makes sure that the
membership is correct. ADMT adds to the target domain group the target domain accounts for all
migrated users who belong to the group in the source domain.
• In the Naming Conflicts dialog, select Replace conflicting accounts. Because the groups were
migrated previously, they will already exist in the target domain. The typical approach is to leave
all other options in this dialog cleared, as Figure 7 shows.

Figure 7:
Selecting options from the Group Account Migration Wizard

With this configuration, the groups selected for migration will replace existing groups through
merging their memberships. Therefore, if a user had been added to a group in the target domain and
the group were remigrated, the user would belong to the remigrated group.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

94

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

However, if you select Remove existing members of groups being replaced, the re-migrated group
would not include the user from the target domain—only users who belonged to the group in the
source domain would belong in the target domain.

Creating a Group Mapping and Merging Plan
The Group Mapping and Merging Wizard lets you map a group in the source domain to a different
group in the target domain. After mapping a source group to a target group, source domain users
belonging to the source domain group are added to the mapped group in the target domain when
they are migrated.
This mapping process enables several important capabilities. First, it lets you merge the
memberships of multiple groups into a new or different group in the target domain. Many Windows
NT Server 4.0 environments suffered from group proliferation, due to the limitations of the server
domain and the buildup of less-than-ideal group management practices. The Group Mapping and
Merging Wizard makes cleaning up unnecessary groups easier.
Second, mapping helps when consolidating domains. You might, for example, create a group
called Management in the target domain and use the Group Mapping and Merging Wizard to map
the Management groups in each of your source domains to the Management group in the target
domain. You will then have a group in the target domain that represents all the administrators in the
former domains.
If you have mapped a source domain group to a different group in the target domain, you will
then migrate users who belong to the source domain group, and those users will become members
of the mapped group in the target domain. You will most likely not migrate the source domain
group. If you were to migrate the source domain group to the target domain, the mapping
information would be replaced and any users who are then migrated will be placed in the migrated
group in the target domain.

Builtin Groups
ADMT does not migrate builtin groups, such as Administrators, Domain Admins, Backup Operators,
and Power Users. Nor does ADMT modify the membership of these groups in the target domain
when migrating users and groups. So a user who belongs to Domain Admins (or any other builtin
group) in the source domain will not be added to the equivalent group in the target domain when
the user is migrated.
This behavior is by design and is intended to encourage administrators to lock down these
groups in the new environment and carefully consider their membership. Remember that the vast
majority of administrative tasks can be delegated in Windows Server 2003 without requiring
Administrators-equivalent credentials.
A workaround to migrate built-in groups is leveraging the group mapping capability of ADMT.
If you create a group in the target domain called NT4_Admins, for example, and map the source
domain’s Domain Admins group to that group, then users who are members of the Domain Admins
group in the source domain will, when migrated, be added to the NT4_Admins group. Simply make
that group a member of the target domain’s Domain Admins group.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

95

A Summary of Group Migration Tasks
Now that we’ve discussed each group migration task and concept, let’s review some best practices:
• Spend some time reviewing the design of your group structure in the new domain. Verify that
you have carefully planned group membership and nesting.
• Migrate only the global groups that you plan to use in the target domain.
• After migrating necessary global groups, use the Group Mapping and Merging Wizard to map
source domain groups to the target domain so that you can consolidate groups appropriately.
• Do not bother trying to migrate builtin groups such as Domain Admins and Administrators.
Although you can create a mapping file that maps these groups in the source domain to
nonbuiltin groups in the target domain, and thereby migrate the users who belong to those
groups, you cannot directly migrate builtin groups.
• Although you have other options, including migrating groups concurrently with users, you will
want to migrate global groups before migrating users. This best practice lets you segregate and
monitor success of global group migration and ensures that the groups exist so that when you
migrate users the accounts can be added to already-migrated global groups. Assuming you have
migrated SIDs, the target domain global groups include the source domain global groups’ SIDs in
their sIDHistory. Therefore, the users and global groups in the target domain can continue
accessing resources in the source domain.

Migrating Users
Relocating user accounts and passwords is perhaps the most important and most involved process in
a migration. We recommend that you create some test user accounts and perform migrations of those
accounts to become familiar with the process and its nuances.
ADMT lets you run test migrations and migrate as few or as many users as you desire. We highly
recommend performing a test migration before migrating user accounts. We also recommend
migrating users in batches by selecting no more than 100 users during each run of the User Account
Migration Wizard.
When ADMT migrates users, it maintains global group membership by identifying the groups in
the source domain to which a user belongs, locating the same group in the target domain and adding
the new, migrated user account to the target domain group. The tool also gives you the option to
migrate associated global groups along with migrated user accounts. Using this option, when a user
account is migrated and a source domain global group to which the user belongs does not exist in
the target domain, ADMT creates the group automatically and adds the user to it.
ADMT provides several options for managing the password on a migrated user account. You can
select to base the password on the user’s name, to generate a complex password, or to migrate the
user’s password from the source domain. In the first two cases, ADMT creates a password file,
Program Files\Active Directory Migration Tool\Logs\Password.txt, which contains each user’s
password.
If you choose to migrate user passwords, you must have configured a PES in the source domain.
Earlier in this chapter we explained how to configure the environment for password migration. The
passwords are not transmitted during migration. DCs do not store a user’s password—they store a
hash code representing the password. The PES transfers the hash code to the target domain, then the
hash code is encrypted using the key generated during the PES installation.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

96

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Because the target domain receives and stores the password hash code from the PES, it cannot
evaluate the user’s password for complexity or length. Password length and complexity evaluation
can be performed only when a password is initially created. Therefore, passwords from the source
domain might not conform to the password policies of the new domain, but those passwords will
nonetheless be migrated.
However, if a user has a blank password in the source domain and the target domain includes a
password policy specifying a password length of greater than zero, the password migration for that
user will fail. An error will be entered in the log, and a complex password will be generated and
stored in the password file.
Regardless of which password option you select, users will be required to change their
password at the first logon.

You will need to communicate the initial password to each user and inform them that they will
be asked to create a new password at the first logon. Include your procedure for communicating the
initial password to users as part of your communications plan.
To migrate user accounts
1. Use the target domain user account (TargetUser) to log on to the ADMT computer.
2. Open the ADMT console.
3. Right-click the ADMT node and select User Account Migration Wizard.
4. Follow the instructions provided by the wizard. Use the list below to guide your choices and
input in each dialog:
• In the Test or Make Changes dialog, select the Migrate now? option.
We recommend performing a test migration before migrating the accounts. To perform a test
migration, select Test the migration settings and migrate later in this dialog.

• In the User Selection dialog, select the user accounts you want to migrate. Do not select
builtin users such as Administrator or Guest.
• In the Password Options dialog, select Migrate Passwords.
• In the Account Transition Options dialog, select Migrate user SIDs to target domains. Select
the option for the target and source domain accounts that corresponds to your migration
procedure.
• In the User Account dialog, enter the credentials of the source domain user account
(SourceUser).
• In the User Options dialog, select Translate roaming profiles, Update user rights, and Do not
rename accounts. Clear the Migrate associated user groups check box. You do not need to
migrate groups, as you did so in an earlier procedure. Select Fix users’ group memberships.
This ensures that a user account in the target domain is a member of the same groups as the
source domain user account.
• In the Naming Conflicts dialog, select Ignore conflicting accounts and don’t migrate.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

97

5. When the wizard has finished running, click View Log, and review the migration log for any
errors.
6. Using Active Directory Users and Computers, verify that the user accounts exist in the target
domain OU.

User account properties
Because not every property of the user account in the source domain is migrated, testing the
migration to review the migration results and identify any properties that need to be populated
following the migration is important.
Be aware of the following nuances of user migration:
• Migrated user accounts are set to require a password change at the first logon. If the User cannot
change password check box is selected for a user account, then (because the user is not able to
change the password as required) that migrated user account is locked until the administrator
resets the password.
• The user principal name (UPN) suffix attribute of migrated user accounts is left empty by default,
but an implicit UPN suffix of the current domain exists by default for each domain. For example,
if the target domain is windomain.com, then the implicit UPN for users migrated to that domain
is [email protected].
• When migrating an object that already exists in the target domain, if the object in the target
domain already has a value for a particular property and the object in the source domain does
not have a value for that property, then the value of the property in the target domain is
preserved—the null value of the property in the source domain does not overwrite it.
• ADMT truncates object names that are more than 20 characters long.
• If you choose to generate a complex password, ADMT can generate complex passwords that
meet the minimum password length requirement and contain at least three lowercase letters,
three uppercase letters, three numerical digits, and three symbols. If this generated password
does not comply with the password complexity rules in the target domain, then the migrated
user account is disabled.
• A user’s logon script property is migrated to Active Directory. Be sure you have copied the logon
script from the netlogon share of the source domain to the netlogon share of the target domain.

Migrating Computers
Using ADMT’s Computer Migration Wizard, you can migrate computer accounts from the source to
the target domain. The ADMT agent that is dispatched to each computer changes the computer’s
domain membership, reboots the computer, and sets the default domain name (which appears in the
logon dialog box as the default choice in the Log on to dropdown list) to the target domain.
ADMT does not migrate the computer description to Active Directory. The description is stored
locally on the system, not in the Windows NT Server 4.0 SAM database, so the Description property
in Active Directory is initially null.
If you are migrating pre-Windows 2000 systems that were managed by using System Policy, copy
the ntconfig.pol file from the netlogon share of the source domain to the netlogon share of the target
domain.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

98

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Migrating servers and workstations
Workstations and member servers store local accounts in their SAM databases. The SAM, and the
local user and group accounts it contains, are not affected when migrating a computer. Local group
membership will remain the same and can contain users and groups from the target domain or the
source domain because of the two-way trust between those domains.
As mentioned earlier, as long as the target domain trusts the same domains that the source
domain trusts, any users or groups from trusted domains that are members of local groups will
continue to be valid members.
Eventually, you will want to translate local group membership. You will recall that translation will
replace each group member from the source domain with the equivalent group member in the target
domain. To translate a workstation or server’s local groups before or after migrating the system, you
can use the Security Translation Wizard, which we describe next. Or, you can use the Computer
Migration Wizard to perform the translation concurrently with migration.

Translating Security
Migrating resources involves migrating computers to the target domain and translating security.
Security translation is an important concept, which we described earlier in this chapter. Security
translation involves modifying a resource that points to an account in the source domain so that it
points to the mapped account in the target domain.
ADMT’s Security Translation Wizard will step you through the process. You are prompted to
select the computers you want to target for translation and the types of objects you want to translate.
As Figure 8 shows, the wizard can translate:
• permissions on files and folders, including DACL, SACL, and SD information such as object
ownership
• membership of local groups
• permissions on printer queues
• permissions on registry keys
• permissions on shared folders
• local user profiles, which involves changing file and folder permissions on the profile and registry
key permissions in the profile’s ntuser.dat file
• user rights

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

99

Figure 8:
Displaying the Security Translation Wizard’s Translate Objects dialog

After you select which objects you want to translate, you are given the option for what type of
translation to perform. As Figure 9 shows, you have three options:
• Replace—This type of translation is what we have described so far in this chapter. Any
permission, member, or right that references a migrated account in the source domain is changed
to refer to the account in the target domain.
• Add—This translation is additive and nondestructive. When a permission, member, or right
references a migrated account in the source domain, an identical permission, member, or right is
added in the target domain to refer to the account. The original permission, member, or right is
not removed.
• Remove—This translation option deletes any permission, member, or right that references a
migrated account in the source domain.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

100

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 9:
Viewing the Security Translation Wizard’s Security Translation Options dialog

As you can imagine, a Replace translation is equivalent to an Add translation followed by a
Remove translation. You might opt to perform an Add translation during the migration so that
permissions, rights, and memberships include references to target domain accounts, then later
perform a Remove translation to cleanup references to source domain accounts. Performing an Add
translation first and a Remove translation later lets you translate in “baby steps” and provides a more
direct rollback capability because the Add translation does not destroy references to source domain
accounts.
On a similar note, when possible we recommend translating one class of object at a time and
selecting as few computers as necessary—perhaps only one. This approach will let you monitor the
logs more closely and to watch for errors. Although ADMT can translate many objects on many
systems simultaneously, we as human administrators might not do as well verifying its success.
ADMT migrates user rights only in additive mode. This means that the user rights of any
existing users and groups in the target domain will not be removed during a migration
operation.

Because the Computer Migration Wizard lets you select objects and translation options, you can
also perform security translation at the time you use the wizard. However, we recommend when
possible breaking migration into small steps, which suggests translating security on a computer’s
resources just before or just after computer migration, rather than doing so concurrently.
In considering when to translate security on a resource, keep two things in mind. First, the
migrated user account will be able to access the resource because of the sIDHistory attribute.
However, after the source account is deleted (or the source domain is decommissioned), a resource
on a Windows NT 4.0 server can no longer resolve the SID to a name, and “account unknown” will
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

101

display. For cosmetic reasons, you will probably want to translate security before deleting the source
account. Second, if you ever cleanup an object’s sIDHistory, you should certainly translate security
first. If an object’s sIDHistory is removed, the user will not be able to access resources secured by
permissions referring to source domain accounts.

Creating a SID mapping file
Security translation uses ADMT’s internal database to identify migrated source domain accounts and
their corresponding accounts in the target domain. You can create a SID mapping file to override this
behavior so that you can manually control how a source object maps to a target object, thereby
controlling security translation.
A SID mapping file is simply a text file that lists a source object and a target object separated by
a comma. You can map as many objects as you like—place each pairing on a separate line. The
reference to the source and target object can be made with a SID or a name. The following lines
show the valid syntax for a SID mapping file:
NT4DOMAIN\JoeU, WINDOMAIN\JoeUser
NT4DOMAIN\JoeU, S-1-5-21-397955417-626881126-188441444-1234
S-1-5-21-397955417-626881126-188441444-1234, WINDOMAIN\JoeUser
S-1-5-21-199510109-51795589-310601177-1010, S-1-5-21-397955417-626881126-188441444-1234

The Security Translation Wizard produces a dialog, which Figure 10 shows, that lets you use the SID
mapping file to drive the translation.

Figure 10:
Selecting a SID mapping file as a source for security translation

When the wizard runs, it translates security for the objects you select (see Figure 8) on the
computers you select, and either adds, removes, or replaces (see Figure 9) references to accounts in
the translation source. The translation source is either ADMT’s own database or the mapping file you
specify (see Figure 10).

Brought to you by NetIQ and Windows & .NET Magazine eBooks

102

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

One of the biggest advantages of a SID mapping is that you can use it to translate security for
accounts that ADMT did not migrate. For example, the Domain Admins, Administrators, Backup
Operators, and other builtin global and shared groups on the source domain’s DCs cannot be
migrated. You can, however, translate the permissions, memberships, and rights that refer to those
source domain accounts.
For example, assume you have created a group in your target domain called
NT4_Domain_Admins to represent the domain administrators in the source domain. You might have
used the Group Mapping and Merging Wizard, described earlier, to migrate members of the Domain
Admins group into the NT4_Domain_Admins group in the target domain. Now assume that in the
source domain, you had assigned the Domain Admins group Full Control over users’ home folders
on Server03. Simply create a text file with this line:
NT4DOMAIN\Domain Admins, WINDOMAIN\NT4_Domain_Admins

Next, run the Security Translation Wizard. Select the SID mapping file (see Figure 10) as the
source, select Server03 as the computer to translate, select Files and Folders as the translation object,
and choose whether to Add or Replace permissions. When the wizard finishes, you will find that the
WINDOMAIN\NT4_Domain_Admins group now has full control over users’ home folders on
Server03.

Translate Local User Profiles
The user profile contains application, desktop, and other settings that produce the user environment.
Migrating user profiles correctly is important so that users have an uninterrupted experience. When
you migrate user accounts, you can choose to translate roaming user profiles. This option makes
appropriate changes so that the new user account in the target domain continues to use the same
roaming profile as the user account in the source domain.
Whether or not you have roaming profiles, you must be sure to translate the users’ local profiles.
The users’ workstations store the local profiles. They can be cached copies of a roaming profile
stored on a server, or they can be the only (authoritative) copy of the user’s profile. A local profile is
secured so that only that user can access it. Access to the profile is associated with the SID of the
user account in the source domain. In addition, the system’s registry has information that links the
user’s SID to the specific folder that stores their local profile. When an account has been migrated
and has received a new principal SID in the target domain, the account will no longer be linked to
the user’s local profile—the process of loading a user’s profile does not look at the sIDHistory
attribute of the new user account.
Therefore, after migrating a user account and immediately before the user logs on to the target
domain for the first time, you must translate the user profile. This process modifies the profile folder
permissions and the registry pointers to reflect the principal SID of the user’s account in the target
domain. Note the terminology: the profile is not being migrated or copied; it is being translated—
modified to reflect the change in the environment.
Most organizations choose to migrate the local user profile just before, just after, or
concurrently with migrating the computer to the target domain. Then the user uses the target
domain account to log on to their computer for the first time.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

103

ADMT can translate local user profiles on workstations running Windows XP, Windows 2000
Server, and Windows NT Server 4.0. To perform this task with ADMT you will use the source
domain user account (SourceUser). Using the account that is a local administrator of each user’s
workstation is important for this task. You will remember that we created a user account in the
source domain and added it to the Domain Admins group, which is, by default, a member of the
local Administrators group on each workstation.
To translate local user profiles
1. Use the source domain user account (SourceUser) to log on to the ADMT computer.
2. Open the ADMT console.
3. Right-click the ADMT node and select Security Translation Wizard.
You can also use the Computer Migration Wizard to perform this task concurrently with
computer migration.

4. Follow the instructions provided by the wizard. Use the list below to guide your choices and
input:
• In the Test or Make Changes dialog, select the Migrate now? option.
We recommend performing a test migration before migrating the accounts. To perform a test
migration, select Test the migration settings and migrate later in this dialog.

• In the Security Translation Options, dialog select Previously migrated accounts.
• In the Computer Selection dialog select Add the users’ computer accounts.
• In the Translate Objects dialog, select User profiles.
• In the Security Translation Options dialog, select Replace.
5. Verifying the success of the operation is important. For each computer that was selected, review
the status message.
• If the message is not Success, identify the cause of failure. Click View Dispatch Log for more
information about the failure.
• Select each computer for which the agent dispatch was successful and click Agent Detail.
• Click View Log and review any errors that occurred during the local profile translation process.
• For computers to which the agent could not be dispatched, fix the problem and use the Retry
Wizard to dispatch agents to those computers.

Migrating Local Groups
The Group Migration Wizard lets you migrate shared local groups from the source Windows NT
Server 4.0 domain.
Keep in mind migrating the local groups that are defined only on a member server or
workstation is unnecessary because the system’s SAM maintains those groups, not the domain SAM
or Active Directory. However, you will probably elect to translate these groups’ membership.
Translating a group’s membership involves looking at each of the group’s members and, if the
Brought to you by NetIQ and Windows & .NET Magazine eBooks

104

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

member is a user or group in the source domain, replacing it with the equivalent migrated object in
the target domain. ADMT translates local group membership as part of the Security Translation
Wizard or the Computer Migration Wizard.

Establishing appropriate trust relationships
Local groups can contain members defined in other domains. Therefore, migrating local groups
before migrating users is not that crucial, whereas you learned migrating global groups before
migrating users is important. However, if your local groups do contain members defined in other
domains—either migrated accounts in the target domain or accounts in external domains—you need
to make certain that appropriate trust relationships are configured.
Let’s look at the example Figure 11 shows. User A resides in a Windows NT Server 4.0 master
account domain—Domain A. Resource domains R1 and R2 contain workstation and server accounts.
User A belongs to local Group L on Server01 in Domain R1. The group also contains User X from a
partner’s domain, Domain X (which is possible because Domain R1 trusts Domain X).

Figure 11:
Illustrating users, local groups, computers, and trusts

User

User X

Domain X

User A

Domain A
Group L
Server

Domain R2

Group L

Existing trust
relationships

Server01

Domain R1

Brought to you by NetIQ and Windows & .NET Magazine eBooks

New trusts required
to migrate User A,
Group L, and Server01

Chapter 4 Migratiion Implementation

105

If User A is migrated with SIDs to a target Active Directory domain, Domain T, that user will still
have access to resources on Server01 thanks to the sIDHistory attribute. The user’s access token will
include the sIDHistory attribute with the user’s Domain A SID. Server01 will then recognize User A as
a member of Group L. But that is possible only if Domain R1 is configured to trust Domain T.
ADMT can perform a security translation on the local group memberships on Server01. To do
this, you can use the Security Translation Wizard or the Computer Migration Wizard. During security
translation, the group will be modified to include User A’s SID from Domain T. The user will
continue to be able to access resources on Server01.
However, if Server01 is migrated to Domain T, User X will no longer be authenticated because
Domain T does not trust Domain X. After establishing that trust, Server01 can be successfully
migrated to Domain T, its group memberships can be translated, and Users A and X can access
resources on the system.

Migrating shared local groups
ADMT lets you migrate shared local groups on Windows NT source domains or domain local groups
on Active Directory source domains. Windows NT DCs maintain local groups that are common to all
DCs. In Windows NT Server 4.0 these groups were referred to as domain local groups (however that
term has fallen out of favor because of the improved domain local groups in Active Directory). You
can use ADMT’s Group Migration Wizard to migrate a shared local group just like a global group.
Processing group membership
Local groups can contain members defined in other domains. Therefore, processing local groups can
be more complicated than processing global groups and user accounts. When adding a local group
member in the target domain, ADMT processes the group members in the following order:
1. If the source member is also being migrated, ADMT adds the copied account to the local group
in the target domain.
2. If the source member is known in the target domain, then its SID is added to the group. To be
known by the target domain, the user account or group must be defined in a domain trusted by
both the source and target domains.
3. If the source member name exists in the target domain, this name is resolved to the target
domain SID.
4. If the source member name does not exist in the target domain, ADMT searches domains that the
target domain trusts for the source member name, and if found the name is resolved to its SID. If
this search fails, ADMT does not add the member.

When to migrate shared local groups
You typically perform this step later in the process, but discussing the procedures as part of our
examination of group migration to clarify the concepts makes sense. ADMT is intelligent in its
processing of group membership, which provides flexibility.
If you migrate a shared local group before migrating its members (for example, global groups or
users in the source domain), the migrated domain local group will contain the accounts in the source
domain as members. When you migrate those accounts, the group’s membership will automatically
adjust to reflect the target domain accounts.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

106

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Migrating service accounts
Service accounts are migrated separately from standard user accounts so that you can control their
migration. For example, you migrate service accounts to a separate OU, then determine how to
migrate their password most effectively.
Migrating service accounts involves the following tasks:
1. Migrating the service accounts from the Windows NT Server 4.0 source account domain to the
Windows Server 2003 target domain.
2. Modifying the services on each server in the source domain to use the service account in the
target domain instead of the service account in the Windows NT Server 4.0 source domain.
ADMT takes care of both of these tasks. You will migrate service accounts with the User
Migration Wizard, not the Service Account Migration Wizard as you might expect.
To migrate service accounts, use the following steps:
1. Use the source domain user account (SourceUser) to log on to the ADMT computer.
To run ADMT you must log on as the source domain user account (SourceUser) because a
service account migration makes changes that require local administrative credentials on the
servers and workstations in your environment.

2. Open the ADMT console.
3. Right-click the ADMT node and select User Account Migration Wizard.
4. Follow the instructions provided by the wizard. Use the list below to guide your choices and
input:
• In the Test or Make Changes dialog, select the Migrate now? option.
We recommend performing a test migration before migrating the accounts. To perform a test
migration, select Test the migration settings and migrate later in this dialog.

• In the Source Domain dialog, select the account domain of the service accounts as the source
(not the resource domain of the computers running the service), if you are migrating services
for computers in a resource domain of a Windows NT Server 4.0 master domain model.
• In the Select Users dialog, select all the service accounts that the Service Account Migration
Wizard identified.
• In the Password Options dialog, click Complex passwords or if you have configured a PES,
click Migrate user passwords.
• In the Account Transition Options dialog, select Enable target accounts and Migrate user SIDs
to target domains.
• In the User Account dialog, enter the credentials of the source domain user account
(SourceUser).
• In the User Options dialog, select Do Not Rename Accounts. Ensure that no other settings are
selected, including the Migrate associated user groups option.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

107

• In the Naming Conflicts dialog, select Ignore conflicting accounts.
The process is identical to migrating a user, except that ADMT can recognize the account as a
service because you ran the Service Account Migration Wizard earlier in the migration, and ADMT has
kept track of service accounts it identified. You are therefore presented with a dialog that Figure 12
shows.

Figure 12:
Choosing to migrate service accounts

If you choose to migrate service accounts and update the Service Control Manager (SCM), the
following occur:
• The user account is migrated.
• Unlike standard user accounts, the Password Never Expires flag is not cleared and the
Password Must Change flag is not set.
• A complex password is generated, regardless of which option you select in the Password
Options dialog. The password log stores that password.
• ADMT updates the SCM of the machine and configures the service to start with the username
and new password of the migrated account.
• The migrated account is given appropriate rights—the right to log on as a service—to each
machine on which a service uses the account.
5. When the wizard has finished running, click View Log, and review the migration log for any
errors.
6. Using Active Directory Users and Computers, verify that the service accounts exist in the target
domain OU.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

108

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

7. Verify that each application for which a service account was migrated continues to function
correctly.
ADMT takes care of just about everything for you. As long as you use the Service Account
Migration Wizard to identify service accounts early on, and as long as you use the User Migration
Wizard to perform the migration of the service account, ADMT ensures that the service continues to
function using the migrated account.
If a service account is assigned the Log on as service right through a group to which it belongs,
you must also run the Security Translation Wizard to update the user rights and group memberships
of the service account and the group. We will describe this process in more detail later in this
chapter.
Many applications, including Exchange Server 5.5, use service account mappings that ADMT is
not coded to modify. These service accounts usually require configuration through registry
settings or from within the application. You must manually update these accounts after the
migration is complete.

Decommissioning DCs
Windows NT DCs cannot be migrated to the target domain. Instead, they are upgraded or reinstalled.
This process is referred to as decommissioning a DC because the DC ceases to be a DC in the source
domain.
You can do one of the following with a Windows NT DC:
• You can upgrade the server OS to Windows 2000 Server or Windows Server 2003, and the Active
Directory Installation Wizard will run automatically. Then you can demote the server to a
member server and join it to the target domain. This option preserves files, folders, and
applications running on the Windows NT server (be certain to test compatibility of applications
first). However, the potential for baggage is considerable, and we always strongly discourage
customers from upgrading an OS unless there is no other choice.
• You can reinstall the server. During installation, you can join the server to the target domain.
Following installation, you can reinstall applications and restore data. A clean installation,
although it takes more time to perform, will provide a more standard, reliable, and secure system.
– If you have reinstalled or upgraded the server to Windows 2000 Server or Windows Server
2003, you can run dcpromo.exe to promote the system to become a DC in the target domain.
Because DCs are not migrated, but rather upgraded or reinstalled, domain local groups—shared
local groups on the DCs—are lost. Be certain to move shared local groups to the target domain
before decommissioning the source domain DCs. See the section on migrating shared local groups for
details.
Decommissioning DCs is a drastic and irreversible action that is usually reserved as the final
step in migration. Be sure you have migrated all other users, groups, and computers; and have
successfully translated security before decommissioning the last DC in the source domain. After the

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

109

source domain is gone, any SIDs on SDs that refer to source domain accounts will not map to a
name, and you will see Account Unknown entries in the SDs.
We recommend maintaining the source domain PDC online for as long as possible while you
ensure that migration is 100 percent complete. Decommissioning the PDC, which is the last
source domain object to be migrated, is the definitive final step in migration. On a similar note,
in a Windows NT Server 4.0 master domain model, be sure to decommission all resource
domains before decommissioning an account domain.

Troubleshooting
As mentioned earlier, the easiest place to make mistakes with ADMT is in credentials. You must be
logged on to the computer running ADMT with correct credentials—typically target domain user
(TargetUser) for migrating users and groups, and source domain user (SourceUser) for migrating
computers, service accounts, and translating security. You must select the correct domain as the
source domain in the wizards’ dialog, and you must enter appropriate credentials in the source
domain credentials dialog.
ADMT creates a log called migration.log for each migration operation. When an operation begins,
the previous migration.log is renamed migrationxxxx.log, where xxxx is an incremented four-digit
number. Therefore, the current log is always migration.log, and the previous log is the file with the
highest sequence number. ADMT maintains only the most recent 20 logs—to configure the number of
logs, you can use the registry entry HKLM\SOFTWARE\Microsoft\ADMT\LogHistory.
For more information about troubleshooting ADMT, see the Microsoft article “How to
Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2” at http://support.microsoft.com/default
.aspx?scid=kb;en-us;322970.

Advanced Migration Tools
ADMT, which Microsoft provides for free, is a capable, effective tool when it comes to performing
distinct migration tasks. However, the tool is not comprehensive in its feature set. Some of the gaps
in the tool’s capabilities might mean that ADMT is not suited to a migration in your environment. So
when evaluating migration options, examining third-party tools as well as ADMT is important.

Third-Party Migration Tools
Although migration is typically a one-time exercise, the significance and effort required to migrate
successfully warrants investing the time to explore all options, particularly third-party tools that can
reduce the total cost of your migration. Well-respected third-party migration tools are available from
the following vendors:
BindView
http://www.bindview.com
Javelina Software
http://www.javelinasoftware.com
NetIQ
http://www.netiq.com
Quest Software
http://www.quest.com

Brought to you by NetIQ and Windows & .NET Magazine eBooks

110

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Even Microsoft turned to a third-party tool for migration support. Although Microsoft released
several resource kit tools (e.g., Movetree, Clone Principals, SIDWalker) with Windows 2000, they
partnered with Mission Critical Software to create what is today ADMT. NetIQ, the proud sponsor of
this eBook, purchased Mission Critical Software in 2000. Domain Migration Administrator (DMA),
NetIQ’s king of migration tools, is one of the most widely-used migration tools in the industry.

High-level features to evaluate
Most vendors provide evaluation versions of their tools so you can evaluate them fully against your
environment. Examine each migration tool’s benefits and costs in the context of your enterprise. You
will want to keep an eye on several feature sets, which we examine next.
Support for complex environments
The first category of features that distinguish third-party tools from ADMT is support for more
complex migration environments. ADMT can migrate source domains that are running Windows
Server 2003, Windows 2000 Server, and Windows NT Server 4.0 to target domains running Windows
Server 2003 and Windows 2000 Server. ADMT does not support migration to Windows NT Server 4.0
target domains, which is important if your migration plan involves collapsing Windows NT Server 4.0
domains before the move to Active Directory. Nor, as you have learned, does ADMT support
migration to Active Directory domains running in Windows 2000 Server mixed mode. ADMT also
does not support migration from other directory services, such as Banyan, Novell Directory Services
(NDS), or iPlanet.
Project-based migration
ADMT is a task-based tool. It does not provide a framework with which to lay out the migration
project: tie together all migration tasks, plan for timed migration, delegate distinct migration tasks, and
monitor the overall status of the migration. Third-party tools support varying degrees of project-based
migration, which will be important in larger or more complex environments. Some tools even provide
for migration modeling, through which you can test your plan and experiment safely with various
migration paths.
Monitoring and reporting
In Chapter 3 we discussed the information you must gather to plan a migration. Third-party tools
typically perform much of that premigration reporting for you and give you the opportunity to tie the
results of discovery and assessment directly into the tasks of the migration project.
During and after the migration, you might want detailed reporting capabilities. ADMT’s reports
are simplistic at best. ADMT monitors only its own actions, not the health of the source or target
domains. If robust reporting, logging, and monitoring are a priority, then third-party tools will fit
the bill.
Roll-forward and rollback
If you are looking for granular roll-forward and rollback, ADMT will not satisfy those requirements.
ADMT provides an undo wizard which attempts to rollback the previous migration task, but it cannot
rollback earlier tasks, and its rollback does not always return the target environment to the same state
that existed before the rolled-back task. Roll-forward can be just as important. Third-party tools can
provide transaction-based migration tasks, such that if one piece of a task fails (for example, one user
in a group cannot be migrated) the entire task can be rolled back safely and completely. You should
examine each tool with the migration tasks you anticipate in mind.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

111

Email migration
If you need to migrate Exchange Server accounts, ADMT can help—we will detail the use of ADMT
to migrate Exchange accounts in a later chapter. Third-party tools often provide a more flexible and
complete solution, such as integration with the Exchange 2000 Active Directory Connector and
support for re-ACLing public folders. If you are migrating email accounts on platforms other than
Exchange, you will definitely want to look at third-party tools because ADMT provides no solution.
Desktop migration features
The migration of desktops is likely to be a significant factor in your choice of tools, simply because
of the number of desktops in your environment, and the crucial importance of maintaining user
environments and providing seamless resource access. Pay attention to how tools support cloning
computer accounts, joining computers to the target domain, and ensuring that user profiles—whether
roaming or local—are migrated correctly. If you have remote users or locations that connect with
slow or unreliable WAN connections, you will want to evaluate each tool’s support for that
environment.
Desktop upgrade or deployment
If you plan to upgrade the desktop OS or redeploy desktops concurrently with the migration, you
should examine tools to help you do so efficiently. We recommend that you consider the desktop
upgrade as a separate project and evaluate tools accordingly. A third-party tool that meets your needs
for directory service migration might not be the best-suited tool for desktop deployment. However, if
you do find that a suite of tools from one vendor accomplishes both tasks, the interoperability and
common support for those tools will certainly be a big plus.
Terminal Server profile support
Some third-party tools support migration of Terminal Server profiles. This support is an important
consideration for companies using Windows NT Server 4.0, Terminal Server Edition (WTS).
Security translation in complex environments
To perform security translation ADMT dispatches an agent. This practice will not be successful when
translating files and folders stored on a Network Attached Storage (NAS) device. To accomplish this
task, third-party tools use an account with the change permissions right to remotely re-ACL the
device.
Migration cleanup
When migration is complete, you will want to cleanup the sIDHistory of objects. Although you might
desire the flexibility, control, monitoring, and reporting that a third-party tool provides, you can use
scripting to clean up the sIDHistory of objects. For more information about scripting, see the
Microsoft article “HOWTO: Use Visual Basic Script to Clear SidHistory” at
http://support.microsoft.com/default.aspx?scid=kb;en-us;295758.

Other features
The features listed earlier are among those identified as high-priority by many enterprises as they
migrate to Active Directory. In addition, you will find that third-party tools support features such as:
• Scheduling of migration tasks—This feature lets you run tasks during periods of low-utilization.
• User account provisioning—Provisioning typically relates to support for template-based user
creation during or after migration.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

112

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Account rename—Some third-party tools let you rename individual objects during migration.
ADMT supports adding only a prefix or suffix to the existing name.
• Granular control over property migration—ADMT does not provide easy methods to manage
individual property migration. For example, you’ve learned that all user accounts are configured
to require password change at the first logon and for passwords to expire. You cannot easily
modify this behavior.
• Integration with other databases—Active Directory objects support far more attributes than those
in Windows NT. You might want to populate properties such as phone numbers, addresses,
managers, and job titles. Some third-party tools let you tie into external data sources such as
human resources (HR) databases or simple Microsoft Excel worksheets to provide those attributes
to the account creation process.
• Password migration options—ADMT has limited capabilities to generate complex passwords and
to migrate passwords from the source domain. For more control and flexibility, turn to third-party
tools.
• Extensibility—To provide scripting capabilities, advanced third-party tools use VBScript, JavaScript,
or other scripting languages.
• Improved performance—ADMT is single-threaded and somewhat of a bandwidth hog.
Third-party tools can provide multithreaded and network-friendly performance boosts.
• Improved UIs—ADMT’s wizard-size interface is frustrating when migrating large numbers of
objects, and its labels, instructions, and online Help are not as self-explanatory as you might
hope.

Migration Services and Support
Migration can be a complex task, particularly in midsize to large environments or enterprises with
multiple source domains or directories. Numerous indirect costs come from the time required to
study, understand, and test a migration strategy, as well as perform, monitor, and troubleshoot the
migration.
We’ve seen too many enterprises neglect to account for these significant factors in total cost of
migration. Include in your migration plan an assessment of how your team will be trained and
supported for the migration.
Microsoft is not likely to provide extensive support for an ADMT-based migration. Third-party
tools are likely to be better documented and to be accompanied by services and support before,
during, and after the migration. You may also choose to turn to an external firm to guide you
through the migration process. Because you will migrate once, but consultants migrate repeatedly, the
savings can be significant.
Intelliem provides several levels of migration support. If your enterprise has the resources to plan
and perform the migration, then effective, customized training at each phase can make the process
significantly smoother, less error-prone, and less costly. If you need help performing any aspect of
migration, Intelliem’s directory design, consulting, and migration planning and support services can
bridge the gap. You can visit Intelliem’s Web site at http://www.intelliem.com.
In addition to Intelliem, other boutique consulting firms as well as large firms (e.g., IBM, HP,
Avanade—a partnership between Accenture and Microsoft) can support you through what can be a
complex, onetime operation.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 4 Migratiion Implementation

113

Finally, vendors of third-party migration tools often provide migration services that are bundled
with the tool. These bundles can be particularly cost-effective and headache reducing.

Next Steps
After you have completed migration, the fun really begins. Windows Server 2003 offers numerous
powerful tools and features with which to increase the productivity of administrators and end users
alike. In the next chapter, we will examine some of the capabilities of the new OS and some of the
key administrative tasks you will perform while administering your new enterprise network.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

114

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Chapter 5

Maintaining Windows Server 2003 in a
Post-Migration Environment
After migrating your directory services to Windows Server 2003 Active Directory, you are ready to
leverage Active Directory for more effective management of your enterprise network. This chapter
will jump-start administrators who are new to either Windows Server 2003 or Active Directory. We
will examine key concepts and procedures that affect day-to-day administration of users, groups,
computers, and permissions.

Preparing for the Administration of Windows Server 2003
After migrating, you will want to familiarize yourself with the suite of administrative tools available for
Windows Server 2003 and provide those tools to appropriate administrative personnel.

Native Administrative Tools
You will immediately notice a new Start menu, which is also called the Start panel. The administrative
tools reside in several places:
• Start menu
• All Programs menu
• Control Panel
If you do not see the Administrative Tools folder in the Start menu or the All Programs menu, or if
you want to control when and where the folder appears, then follow this next procedure:

Customize the Location of the Administrative Tools Folder
1. Right-click the Start button and choose Properties.
2. Click the Customize button.
3. Click the Advanced tab.
4. Scroll down to the System Administrative Tools option group and select the option that meets
your needs: Display on the All Programs menu, Display on the All Programs menu and the Start
menu (i.e., the default selection), or Don’t display this item.
The Administrative Tools folder remains visible in the Control Panel, unless you use policy settings to
modify the behavior of the Control Panel.
The default administrative tools on Windows XP Professional and Windows 2000 Professional are
sufficient for managing the client system, but don’t come close to providing the comprehensive
toolset you need to support an enterprise Windows network. For example, you will need tools to
support servers, services, and Active Directory.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

115

Install the Full Suite of Native Administrative Tools
To install the Windows Server 2003 Administration Tools Pack (adminpak.msi) on a Windows XP
Professional Service Pack 1 (SP1) or later client, open the adminpak.msi file, which is in the I386
folder of the CD-ROM. The Windows Installer package is also available in the System32 folder of a
computer running Windows Server 2003. To access this folder remotely, administrators of the server
can connect to \\servername\admin$\system32. The wizard, which Figure 1 shows, will guide you
through the installation of the administrative tools.

Figure 1:
Viewing the Windows Server 2003 Administration Tools Pack Setup Wizard

You can install Windows Server 2003 Administration Tools Pack on Windows XP Professional
SP1 or later and Windows Server 2003 systems, but not on Windows 2000 systems. The tools are
backward compatible so you can use them to administer any Windows Server 2003 or Windows 2000
Server system. The tools include enhanced functionality, such as the drag-and-drop feature, and
additional useful utilities. You can use most, but not all, of these new features to support Windows
2000 Server.
Keep the following notes in mind:
• You can install the Windows 2000 adminpak.msi on only Windows 2000 machines and use it to
administer only Windows 2000 servers and domain controllers (DCs).

Brought to you by NetIQ and Windows & .NET Magazine eBooks

116

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

• Adminpak.msi is typically updated with service packs, so you should install the latest version of
the administrative tools that matches your service pack level.
• Client, tool, and server matching is required in a few situations. In other words, when performing
certain tasks remotely, you must use a Windows 2000 client running the Windows 2000
administrative tools against a Windows 2000 server. Similarly, you must perform certain tasks
with a Windows XP or Windows 2003 client running the Windows 2003 administrative tools
against a Windows 2003 server.

j

Tip
In a mixed Windows 2000 Server and Windows Server 2003 environment, your best bet is to
use Windows XP SP1 or later with the Windows 2003 Server Administration Tools Pack to
administer your enterprise. For those rare occasions when you run into limitations, use Remote
Desktop to administer your Windows 2000 Servers or have available a Windows 2000 client
with Windows 2000 administrative tools.

The information we provided earlier should be sufficient to get you running effectively with the
full suite of native administrative tools. However for more information and for support with any
problems, we recommend that you refer to these additional resources:

n Note
For more indepth information regarding the ins and outs of cross-platform remote
administration, see the Microsoft article, “Administering Windows Server-Based Computers
Using Windows XP Professional-Based Clients,” at http://support.microsoft.com/default
.aspx?scid=kb;en-us;304718.

n Note
For details about Windows 2003 administration and scripting, see the Microsoft Windows
Server 2003 Resources Web site at http://www.microsoft.com/technet/prodtechnol
/windowsnetserver/proddocs/server/strategies_and_tools.asp and the Microsoft article,
“How to use Adminpak.msi to install a specific server administration tool in Windows,” at
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B314978.

Introduction to the Microsoft Management Console
Windows administrative tools share a common framework called the Microsoft Management Console
(MMC). (For more information about the MMC, see the Microsoft Management Console Center Web
site at http://www.microsoft.com/windows2000/technologies/management/mmc/.) The MMC displays
tools in a customizable window with a left pane that displays a tree structure (similar to the Windows
Explorer tree) and a right pane that displays details.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

j

117

Tip
The one thing to remember about the MMC is that you right-click to do everything. Although
the MMC provides menus, they are not conveniently positioned and are not administrator
friendly.

Tools or snap-ins use the two-paned console to provide administrative functionality. Snap-ins
cannot run as standalone tools; they can function only within the context of the MMC.

Familiar Snap-ins
Most native administrative tools, which are available in the Administrative Tools folder, are one
console with one snap-in. If you have supported Windows NT 4.0, then you will recognize several of
the native consoles, such as Event Viewer. Some tools have had minor modifications, including the
Performance tool.
The new Performance console has the functionality of earlier Performance Monitor versions
divided into two snap-ins: one that graphically shows performance from realtime measurements or
log files and one that creates and manages logs and alerts.

Tools Relocated to the MMC Framework
As with any change in technology, half the fun is finding the things you are familiar with. For
example, you’ll see that the old Services applet from the Windows NT Control Panel is now the
Services snap-in, which is in the default Services console called Services.

New Snap-ins and Consoles
One of the tools you will use most often to support a Windows enterprise is Active Directory Users
and Computers. This snap-in lets you administer common objects in Active Directory.

n Note
To launch the Active Directory Users and Computers snap-in, select Start, Run, then type the
filename dsa.msc.

Super Consoles with Multiple Snap-ins
Microsoft has provided a particularly powerful console, the Computer Management console.
Computer Management is the super console to use to do just about anything to a system. You’ll notice
it contains multiple snap-ins, including some of those we’ve already seen as standalone consoles:
• Event Viewer
• Performance Logs and Alerts
• Services

Brought to you by NetIQ and Windows & .NET Magazine eBooks

118

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Computer Management also contains numerous, highly-useful snap-ins such as:
• Shared Folders
• Local Users and Groups
• Device Manager
• Disk Management
• Disk Defragmentation
And this super console contains snap-ins to administer services installed on the local machine,
including Microsoft Internet Information Server (IIS).

j

Tip
You will use Computer Management often, so memorize the shortcut: Right-click My Computer
and select Manage.

Creating Simple Customized Consoles
An important benefit of the MMC framework is that you can create customized consoles with
shortcuts, Web pages, file-system access, and task pads that focus on the specific systems and duties
for which you are responsible.
Create a Simple Customized MMC Snap-in
1. Choose Start, Run, and MMC. The empty MMC appears, as Figure 2 shows.

Figure 2:
Showing the Empty MMC

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

119

2. Choose File, then Add/Remove Snap-in. The Add/Remove Snap-in dialog box opens.
3. Click Add.
The Add Standalone Snap-In dialog box (which Figure 3 shows) appears, listing the snap-ins installed
on your computer.

Figure 3:
Viewing the Add Standalone Snap-in Dialog Box

n Note
If you only see a partial list, then some administrative tools have probably not been installed on
the system. Don’t forget to install the Administration Tools Pack (adminpak.msi).

4. Select a snap-in.
5. Click Add.
6. Many snap-ins will then give you additional options, including the ability to select the focus of
the snap-in (i.e., the computer to which the snap-in will connect). Figure 4 shows the selection to
manage a local computer. Make your selections and click Finish.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

120

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 4:
Selecting Snap-in Options in the Computer Management Dialog Box

7. When you’ve added all desired snap-ins, click OK in the Add/Remove Snap-in dialog box.
8. Select File, then Save to save the snap-ins.
Snap-ins are saved as small .msc files, which specify the console configuration. Their small size makes
them easy to distribute (for example, through email applications).
The default save location is the Administrative Tools folder of your user profile. The path to the
folder is not intuitive.

n Note
By default snap-ins are saved in the %userprofile%\Start Menu\Programs\Administrative Tools
folder.

You can save an .msc file wherever you want, but the default location lets your custom snap-ins
follow you when you have implemented a roaming user profile for yourself (which we highly
recommend for administrators). However, snap-ins will function properly only when run on a system
that has had the appropriate administrative tools installed on it.
The default location for saving Administrative Tools unveils a design flaw in Windows Server
2003. The custom snap-ins you create are not available in the Administrative Tools folder in Control
Panel or on the Start Menu. They are available only in the Administrative Tools folder in the All
Programs menu.

Other Important Administrative Tools
The native Windows Server 2003 administrative tools provide basic functionality that will support
your environment, but additional tools that are available free of charge will further augment your
capabilities.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

121

Support Tools
The Windows Server 2003 CD-ROM includes many useful utilities and documents in the Support
folder.

n Note
Support tools are usually updated with service packs and reside in the Support folder of the
service pack CD-ROM. Make sure to install the tools that match your system’s service pack
level.

Among the most valuable support tools are:
• ADSI Edit
• Setup Manager
• Replication Monitor
and several command-line tools (such as netdom.exe and netdiag.exe) to enhance your scripting and
administration.

Group Policy Management Console
We examine the Group Policy Management Console (GPMC) below in the Group Policy section. You
will definitely want to install the GPMC on the systems you use to manage Group Policy.

Resource Kit
Intermediate and advanced administrators will find it impossible to live without the Windows Server
2003 Resource Kit Tools. The Resource Kit is available from multiple sources including from the
Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?familyid=9d467
a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.

Service-Specific Administrative Tools
Of course you will want to install tools that are specific to the services you support, such as Microsoft
SQL Server, Microsoft Exchange Server, Microsoft Systems Management Server, Microsoft Acceleration
Server, IIS, or Lotus Notes. The installation and use of these tools falls outside the scope of this
discussion.

Remote Desktop
All Windows Server 2003 installations include a license for two concurrent connections to the server
when using Remote Desktop for Administration. This technology, formerly called Windows 2000
Server Terminal Services, provides an administrator full access to the server and its installed tools,
applications, and services.
Configuring Remote Desktop for Administration
Remote Desktop for Administration is installed by default on Windows Server 2003, but you must
enable Remote Desktop Connections (RDCs) before administrators can begin to connect remotely
to a server.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

122

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Enable Remote Desktop for Administration
1. Right-click My Computer and choose Properties.
2. Click the Remote tab.
3. Select Allow users to connect remotely to this computer.
On a DC, members of the DC’s builtin Administrators group are allowed to use Remote Desktop for
Administration to connect to the server. On member servers, members of the server’s Remote
Desktop Users local group are allowed to connect to the server. Modify membership of these groups
to establish which users are permitted to use Remote Desktop for Administration.
The Client Side
A Windows Server 2003, Windows XP, or Windows 2000 system can use the Remote Desktop client
to connect to a Windows Server 2003 server.
Install the Remote Desktop Client
The Terminal Services or Remote Desktop client must be installed. The client can be installed on
Windows Server 2003, Windows XP, or Windows 2000 computers.
The Remote Desktop client installer package is named msrdpcli.msi. It resides in the
\\servername\admin$\system32\clients\tsclient\win32 folder on a Windows Server 2003 computer.

j

Tip
The client also installs the Remote Desktops snap-in, which lets you build a custom MMC with
direct remote desktop connections to the servers that you administer. We recommend you
build a custom administrative console that includes the Remote Desktops snap-in.

After installing the client, you might discover that is hard to find because it is buried. Go to Start,
All Programs (or Programs in Windows 2000), Accessories, then Communications to uncover it. We
recommend you copy the shortcut to your desktop or some other easily accessible location. To
connect to a server, simply open the client and enter the server’s name or IP address. The client
provides options that let you configure session properties, display size, etc.
Managing RDCs
As mentioned earlier, Remote Desktop for Administration supports two concurrent connections. When
an administrator is finished performing tasks that require a RDC to a server, it is important that the
administrator log off the server. By logging off, the administrator releases the connection so that
another administrator can use it. If the administrator simply disconnects the session (by closing the
Remote Desktop client window or by selecting the Disconnect option), then the session remains
active and the connection is not available for other administrators. If an administrator attempts to
connect to a server and both of its connections are taken, then the administrator will not be able
to log on to the server. You can manage remote connections to minimize and troubleshoot such
scenarios.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

123

End a User’s RDC to a Server
Sometimes you might try to use Remote Desktop for Administration to connect to a server and
receive a message that no connections are available. You can use the Terminal Services Manager
console to connect to a server and examine the sessions that are active on the server.
1. Open Terminal Services Manager from the Administrative Tools folder.
2. If you do not see the server listed that you want to manage, then right-click the All Listed Servers
node and choose Connect to computer.
3. Select the server you want to manage and ensure the Users tab is visible.
4. Right-click the connection that you want to manage and choose Log off.

n Note
Logging off a user session will close all active processes in the session and can result in the loss
of unsaved data. Use the Reset command only when a session has become unresponsive.

Configure Remote Desktop Session Behavior
You can configure the server so that inactive or disconnected sessions are automatically logged off.
1. Open Terminal Services Configuration from the Administrative Tools folder.
2. Click the Connections node in the tree pane.
3. Double-click RDP-Tcp in the details pane.
4. Click the Sessions tab.
5. Select Override user settings.
6. Modify the settings to reflect your desired configuration.

n Note
The most common problem with Remote Desktop for Administration is that administrators
finish their task and disconnect, rather than log off. To address this problem, set the Idle
session limit, select the second Override user settings box, then select End session. Remember
that ending a session closes all processes and can result in the loss of unsaved data.

Using Alternate Credentials (aka Secondary Logon or Runas)
Most administrators log on using their administrative account. This practice is dangerous because the
account has access to much more of the network than a standard user account. Thus a virus or trojan
horse can cause significant damage—in fact administrators are often the biggest culprit in spreading
viruses that do serious damage to an enterprise network.
To avoid this problem and other problems like it, don’t log on as an administrator. Instead, log
on as a standard user and use the Run As feature to launch administrative tools in the security
context of an administrative account.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

124

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Run a Program with Administrative Credentials
1. Shift+right-click the shortcut for an executable, Control Panel applet, or MMC snap-in that you
want to launch and choose Run as.
2. Select The following user.
3. Type the username (in the format domain\username if the account exists in a different domain)
and password of the administrative account you want to use. When using the local Administrator
account, enter the account as machinename\Administrator.
4. Click OK.

Other Run As Options
You can also configure shortcut properties so that you will be prompted for alternate credentials
when you use the shortcut. To do this, right-click the shortcut, choose Properties, click the Advanced
button, then select Run with different credentials.
Finally, you can use the Runas command from the Run box or command shell. For Help, open
the command shell and type
runas /?

Important Notes About the Runas Command
• If you use Runas to try to run a program from a network share, you might encounter credential
errors because the credentials used to connect to the share are in effect.
• If Runas fails, the Secondary Logon Service might not be running.
• For more information, see Windows Help.

j

Tip
An extremely important best practice for administrators and support personnel is to maintain at
least two accounts: a user account with rights, privileges, and permissions common to other
users in the enterprise, and an administrative account with rights, privileges, and permissions
necessary to perform appropriate administrative tasks. To log on administrators should use their
user account, then use Runas and their administrative credentials to launch administrative
tools.

n Note
For more information about the Runas command, see the Microsoft article, “Step-by-Step
Guide to Using Secondary Logon in Windows 2000,” at http://www.microsoft.com
/technet/prodtechnol/windows2000serv/howto/seclogon.asp.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

125

Models for Providing Administrative Tools
There are several popular ways to provide administrative tools to appropriate personnel:
• Distribute the tools and install them directly on computers that administrators use. Remember that
Windows Server 2003 administrative tools run on only Windows XP SP1 or later and Windows
Server 2003 computers.
• Provide the Remote Desktop Client to administrators, and let them connect directly to the servers
to perform administrative tasks. Remember that a server supports only two concurrent
connections in the Remote Desktop for Administration mode.
• Install administrative tools on a server running Windows Server 2003 and use Terminal Services
to let multiple administrators connect to the server with the Remote Desktop.
• Install administrative tools on a desktop running Windows XP SP1 or later, then use a third-party
tool to provide remote access to the administrative desktop. Tools such as Virtual Network
Computing (VNC) or Symantec pcAnywhere can provide remote access to a Windows XP
desktop to multiple administrators.
Select the method that meets your needs most effectively. If you do not implement Windows XP
on the desktop, then you cannot distribute Windows Server 2003 administrative tools directly to
administrators and will likely need a remote desktop administrative model. If you do not use
Windows XP and you have many administrators, then Remote Desktop for Administration’s
two-connection limit might not suffice, so you might need to implement Terminal Services to provide
administrative tools.

Active Directory Administration 101
Many organizations migrate to Windows Server 2003 that have little or no experience administering
Active Directory. Even though you are familiar with the concepts of users, groups, and computers,
you might be less familiar with how to use the new directory service and its administrative tools
to manage those objects. This section will give you the skills you need to perform day-to-day
administrative tasks in the new environment.

j

Tip
In the event that you are already familiar with fundamental administrative tasks in Active
Directory, we recommend you skim this section and look at the items identified as tips (with
formatting similar to this paragraph). You will find some tips that can enhance your
productivity.

User Accounts
To manage user accounts, you can use the Active Directory Users and Computers snap-in.

Create a User Account
1. Open Active Directory Users and Computers.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

126

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

2. Expand the domain node and drill down to the organizational unit (OU) where you want to
create the user account.
3. Right-click the OU and choose New, then User.
4. In First name, type the user’s first name.
5. In Initials, type the user’s middle initial.
6. In Last name, type the user’s last name.
7. Modify Full Name when necessary.
8. In User logon name, type the name that the user will log on with and (from the drop-down list)
click the UPN suffix that must be appended to the user logon name following the @ symbol.

n Note
Usernames in Windows 2000 can contain some special characters (including periods, hyphens,
and apostrophes), which let you generate accurate usernames.

9. If the user will logon from Windows NT, Windows 98, or Windows 95 computers with a different
name, then change the user logon name as it appears in Downlevel logon name to the different
name.
10. Click Next.
11. Enter the user’s initial password in both password boxes.

j

Tip
We recommended selecting User must change password at next logon so that the user can
create a new password unknown to the IT staff. Appropriate support staff can always reset the
user’s password at a future date if they need to log on as the user or access the user’s
resources. But only users should know their passwords on a day-to-day basis.

12. Click Finish.
After a user has been created, the user object contains dozens of properties you might want to
configure. To configure user properties, right-click the user and choose Properties.

Manage a User Object or Account
To perform almost all common administrative tasks on user objects, you right-click the user
object and select the appropriate command from the shortcut menu. Among the commands available
on the shortcut menu are:
• Rename
• Reset password
• Disable (when the account is currently enabled)

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

127

• Enable (when the account is currently disabled)
• Add to group

Unlock a User Account
If a user attempts to log on with an incorrect password, a logon failure is generated. When too many
logon failures occur within a short period of time, the account is locked on the assumption that an
intruder is attempting to penetrate the account by trying various passwords. Later we examine the
Account Lockout policy that drives this behavior.
If a user account is locked out, the user will be notified when they attempt to log on. The
message that appears clearly states that the account is locked out (not that an incorrect username or
password was entered). To unlock a user account:
1. Right-click the user account and select Properties.
2. Click the Account tab.
3. Clear the checkbox labeled Account is locked out.

Groups
To manage groups, you can use the Active Directory Users and Computers snap-in.

Create a Group
1.
2.
3.
4.

Open Active Directory Users and Computers.
Expand the domain node and drill down to the OU where you want to create the group.
Right-click the OU and select New, then Group.
Type the name of the new group. (By default, the name you type is also entered as the
downlevel name of the new group.)
5. Select the Group type and scope. For information about group type and scope refer to the later
section.
6. Click OK.
When you create a group, you must specify the group’s type and scope.

Group Type
Distribution and security are the two types of groups.
Distribution Groups
Distribution groups are used with email applications. These groups are not security enabled—they do
not have Security Identifiers (SIDs)—so they cannot be given permissions to resources. Sending a
message to a group sends the message to all members of the group.
Security Groups
Security groups are security principals and have SIDs. These groups can be placed in access control
lists (ACLs), and therefore can be used to control security for resource access. Security groups can
also be used as a distribution list by email applications.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

128

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

n Note
Most organizations use only security groups, because they fill both email and security
requirements.

Group Scopes
Global, domain local, and universal are the three group scopes. Each group scope has unique
characteristics related to the types of objects that can be members and the replication of the group,
which affects their availability for use in ACLs.
Domain Local Groups
Domain local groups are designed to manage resource access within a domain. For example, when
users in an organization need access to a high-speed printer, you can create a High-Speed Printer
Users domain local group and give appropriate permissions to the printer. Then you can add users to
the group, and through their group membership they will have access to the printer.
Domain local groups can contain user accounts, global groups, and universal groups from its
domain or any trusted domain. In native mode, domain local groups can also contain other domain
local groups.
Domain local groups replicate within the Domain naming context (NC). They are not available
outside of their domain. So domain local groups can be members of only domain local groups in
their domain and can be placed in ACLs in only the same domain.
Global Groups
Global groups are designed to identify collections of users in a single domain. Their members
share a common characteristic such as job function, location, or departmental membership. For
example, a global group can identify the SalesReps, the SalesManagers, and the FinanceManagers
users in an organization.
Global groups can include accounts from only the same domain as members. In mixed mode,
global groups can contain only users from the same domain. In native mode, global groups can
include other global groups as members—for example, a Management group can include both the
SalesManagers and FinanceManagers global groups.
To provide permissions to resources, you can add global groups to domain local groups. For
example, both the SalesManagers and FinanceManagers might require access to the high-speed
printer. You can add them both to the High-Speed Printer Users group. This process is much easier
than adding each individual user to the High-Speed Printer Users group.
Job function, geography, and other identifying criteria usually do not map one-to-one with
resource access needs. The existence of global and domain local groups lets you easily identify users
and easily manage those users’ resource access.
Global groups replicate to the global catalog, but their memberships do not. All domains in the
forest, and all trusting domains, can use global groups as members of their domain local and
universal groups. Other domains can also place them in ACLs, but this is not best practice.
Universal Groups
Universal groups are used to identify users in a multidomain forest. Universal groups are available as
security groups in a native mode domain and can contain user accounts, global groups, or universal
groups from any domain in the forest. A universal group can be used to collect global groups from
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

129

multiple domains in a forest. For example, a universal Engineers group might contain the global
engineering groups from multiple divisions and domains.
Then universal groups can be placed into an ACL or (as a better practice) nested into a domain
local group anywhere in the forest. Universal groups are replicated entirely in the global catalog,
including both the group name and the membership. Therefore, you should keep the membership of
universal groups fairly static and to a minimum. A universal group that contains only groups, and not
individual user accounts, will meet these criteria.
Local Groups
Local groups are not created in Active Directory. To create local groups, you use the Local Users and
Groups snap-in. Then they are stored in the SAM database on member servers and workstations. DCs
do not support local groups. These groups might sound familiar because they are just like those in
Windows NT 4.0.

n Note
In native mode when you use domain local groups, you will most likely use only the builtin and
default local groups and not create or manage any custom local groups.

Nesting
Nesting, or adding a user or group to another group, simplifies administration and reduces replication
traffic. You can nest user accounts and groups in any combinations that the rules mentioned earlier
allow.
For example, if we want to give permission to the 35 accountants in the accounting department
to the Accounts Payable and Accounts Receivable folders, we can create individual access control
entries (ACEs) to do so. Imagine the nightmare of adding the account of every new user who joins
our company to the ACL of every resource to which they must have permission. Best practice dictates
that we use nesting to simplify our lives. When a new accountant joins the firm, we simply add the
user’s account to the global Accountants group, which is nested in all the domain local groups
necessary to ensure proper permissions to the resources accountants need.
The best practice for nesting in Windows Server 2003 domains at Windows 2000 native functional
level or higher is:

n Note
User accounts should go into
Global groups, which in turn go into
Domain Local groups with
Access permissions to the appropriate resource.

In a multidomain Active Directory forest with domains set to Windows 2000 native functional
level or higher, the guidelines we provided earlier outline the best practice. When using universal
groups, remember the following note, which provides additional guidelines:

Brought to you by NetIQ and Windows & .NET Magazine eBooks

130

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

n Note
User accounts should go into
Global groups, which may go into
Universal Groups, which in turn can go into
Domain Local groups with
Access permissions to the appropriate resource.

Adding Users to Groups
Although you can add users to groups and manage the membership of groups in several ways, we
will discuss three options:
• From the user object, select Properties and the Member Of tab.
• From group object, select Properties and the Members tab.
• From user object, right-click and select Add Members To A Group.
In any of these cases, a Select dialog box appears to let you choose the appropriate group or user.

j

Tip
A very important tip is to learn the best way to use the Select dialog box. Type the first few
letters of the user or group and click OK. Then a short list of accounts will display from which
you select the exact object you want. When you type enough letters to uniquely identify the
account, the tool will select it correctly and automatically.

Remember that access is granted by comparing the ACL to the user’s security token, which is
generated at logon and includes the user’s SID and SIDs representing each group of which the user
is a member.

j

Tip
When a user or group is added to a group, each must reauthenticate to add the SID from the
new group to its token.

Computer Objects
Computers in an Active Directory domain are security principals which means, like users, they have
an account (an object in Active Directory) with an internal username and password and, of course, a
SID. Like a user, a computer uses its account to authenticate, audit, and access domain resources.

Creating Computer Accounts
The following can add computers to the domain:
• Domain Administrators can add computer accounts to a domain.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

131

• Authenticated Users can add 10 computer accounts to a domain. This ability is controlled by the
ms-DS-MachineAccountQuota attribute, which you can change using ldp.exe or ADSI. Users
cannot use this capability to add workstations with Microsoft Remote Installation Services (RIS).
With RIS, users must have permissions to create child computer objects for the OU in which the
computer will be added.
• Any user with the permission to create child computer objects on an OU can add a computer
account.
Create a Computer Object or Account
1. Open the Active Directory Users and Computers snap-in.
2. Right-click the OU or container in which you want to add the computer.
3. Choose New, then Computer.
4. Type the computer name.
After a computer object has been created, it contains properties you might want to configure. To
configure computer properties, right-click the computer and choose Properties.
Manage a Computer Object or Account
To perform almost all common administrative tasks on user objects, you right-click the user object
and select the appropriate command from the shortcut menu. Among the commands available on the
shortcut menu are:
• Reset
• Disable (when the computer object is enabled)
• Enable (when the computer object is disabled)
• Move
• Manage

j

Tip
When you choose Manage, the Computer Management console opens and focuses on the
computer. This console provides a very slick way to begin remote administration of that
computer.

Joining to a Domain
After you have created the computer object in Active Directory, you need to join the computer to
the domain.
Join a Computer to a Domain
1. Log on to the computer with credentials that belong to the local Administrators group on the
computer.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

132

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

n Note
Only local administrators can alter the domain or workgroup membership of a computer.

2. Open the System applet:
• Right-click My Computer and select Properties.
Or
• Choose Start, Settings, Control Panel, then System.
3. Click the Network Identification tab (Windows 2000) or the Computer Name tab (Windows XP).
4. Click Properties (Windows 2000) or Change (Windows XP).

n Note
On Windows 2000 systems, avoid the evil Network Identification Wizard, which forces you
through multiple steps to accomplish what you can do quite easily from the Properties
dialog box.

5. Under Member of, click Domain.
6. Type the name of the domain you want to join.

j

Tip
Use the full DNS name of the Active Directory domain. This practice is this more accurate and
more likely to succeed, and when using this practice, a failure indicates a problem with DNS
name resolution that you should rectify before joining the machine to the domain.

7. Click OK.
If the computer does not yet have an account in the domain, you will be prompted to provide
domain credentials that have sufficient privileges or permissions to create a computer account.
8. Click OK to close the System Properties dialog box.
Now use the procedure below to provide the correct domain credentials to create a computer
account:
1. A user with local administrator credentials logs on to the machine.
2. The administrator uses the System applet in Control Panel to direct the machine to join a domain.
3. The computer locates a DC for the target domain.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

133

Note
This step is often the weakest link in the process, so when you have any problems joining a
domain, suspect and troubleshoot DNS name resolution first.

4. The domain requests domain credentials to authenticate the user.
5. The domain checks (based on the computer’s name) to see if an object or account already exists
for the computer.
6. If not, the domain confirms that the user (domain account) has sufficient permissions or
privileges to join a workstation to the domain and creates an object for the computer in the
default Computers container.
7. The computer assumes the identity of its Active Directory object. It configures its SID to match
the domain computer account’s SID and sets an initial password with the domain.
8. The computer performs other tasks related to joining the domain. It adds the Domain Admins
group to the local Administrators group and the Domain Users group to the local Users group.
9. You are prompted to reboot the system.
10. The next time the system starts, you will have the opportunity to log on to your domain account.

j

Tip
The very first time you start a computer that has just joined the domain (including newly
imaged systems), you need to click the Options button in the Log on to Windows dialog box
and select the appropriate domain from the Log on to drop-down list.

Managing Group Policy
In Windows NT 4.0, security settings (e.g., user rights), policies (e.g., password policy), and
configuration of the computer and user environment were managed using disparate tools. With the
introduction of Windows 2000, Microsoft consolidated much of this administration into the framework
of Group Policy—a fundamental component of change and configuration management in Microsoft’s
newer OSs. Now, hundreds of settings can be configured centrally for one or multiple systems or
users. Settings are pulled automatically by Group Policy client-side extensions that operate on each
computer running Windows 2000 or later.
This section provides sufficient coverage to enable you to use default Group Policy Objects
(GPOs) to manage the most important policy settings. For a comprehensive discussion of Group
Policy we recommend, “Group Policy, Profiles and IntelliMirror for Windows 2003, Windows 2000
and Windows XP,” by Jeremy Moskowitz.

Installing the GPMC
To manage Group Policy most effectively use the appropriately-named GPMC—a new MMC snap-in
that centralizes and facilitates the creation, linking, application, management, and analysis of GPOs. In
Windows 2000, you can administer GPOs only from the Properties dialog box of a site, domain, or
Brought to you by NetIQ and Windows & .NET Magazine eBooks

134

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

OU. And the UI makes locating and understanding options related to the application and functioning
of the GPO difficult.
The GPMC, which Figure 5 shows, provides one interface with drag-and-drop functionality to
enable an administrator to manage Group Policy settings across multiple sites, domains, or even
forests. Some of the capabilities of GPMC include the ability to backup, restore, import, and copy
GPOs, while providing an intuitive reporting interface displaying GPO deployment. For example,
using this tool an administrator can easily determine exactly which GPOs apply to a given domain,
how inheritance settings are configured, and which users or groups have been delegated the ability
to manage these objects. The GPMC is available for download from Microsoft at
http://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

Figure 5:
Displaying the GPMC

Group Policy Terminology and Concepts
Over the years, Microsoft has honed its use of terminology related to change and configuration
management—and Group Policy in particular. This section will introduce you to fundamental Group
Policy concepts and terminology.
The goal of change and configuration management is to centralize the administration of the user
and computer environment in your enterprise. This goal includes controlling application availability,
security configuration, and the behavior and availability of system features for specific users or
computers.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

135

Policy Settings
You will be interested in the configuration of a specific setting or feature at the most granular (i.e.,
most detailed) level. Group Policy represents the configuration as a policy setting: an individual setting
that determines a specific configuration. A commonly cited policy setting is the Remove Run from
Start menu policy setting. As its label describes, after enabling this policy setting, the Run command
does not appear on the Start menu.
A policy setting can be enabled, disabled, or not configured. When a policy setting is either
enabled or disabled, it can determine the configuration of the element it controls. You must be
careful about interpreting policy settings, because you can end up with single-, double-, and even
triple-negative situations. For example, when you disable the setting Remove Run from Start menu,
you are in fact ensuring that the Run command does appear on the Start menu. When a policy setting
is not configured, it has no affect on the configuration of the computer or user environment. This rule
is important because you will likely end up with an environment that is configured by more than one
GPO. If a policy setting is enabled (or disabled) in one GPO and is not configured in another GPO,
then the first GPO determines the resulting configuration.

GPOs and the GPO Editor
Policy settings are collected in GPOs. To configure the policy settings in a GPO, you use the GPO
Editor, which Figure 6 shows. To launch the GPO Editor, right-click a GPO and select Edit. Policy
settings are organized into two top nodes: Computer Configuration and User Configuration. Computer
Configuration policy settings are applied by a computer at startup. User Configuration policy settings
are applied by a computer when a user logs on. As you drill down into each node, you will find a
hierarchy of folders that organize hundreds of policy settings. By default, each policy setting in a new
GPO is set to not configured.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

136

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 6:
Using the GPO Editor to Configure Policy Settings

Many policy settings include explanatory text, which displays in the left side of the details pane
(as Figure 6 shows) or on the Explain tab of the policy setting’s Properties dialog box. Almost all
policy settings appear either in the Computer Configuration or the User Configuration node because
they either affect a computer (regardless of which user is logged on) or a user (regardless or which
computer the user is logged on to). A few policy settings appear in both nodes of a GPO. In those
cases, the policy’s explanation text will tell you how the two settings interact when both are
configured.

j

Tip
If a GPO contains policy settings only in the User Configuration or Computer Configuration
node, we recommend disabling settings in the unused node. Select the GPO in the GPMC, click
the Details tab, and use the GPO Status drop-down list. By disabling the unused node of the
GPO, you will improve GPO processing because the client-side extensions will not attempt to
evaluate that GPO when applying user or computer policy settings.

A GPO can configure (enable or disable) one policy setting or many policy settings. To learn
what policy settings are configured in a GPO, select the GPO in the GPMC and click the Settings tab.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

137

GPO Scope
The computers or users that are affected by a policy setting are within the scope of the GPO
containing the policy setting. A GPO can be linked to one or more Active Directory sites, domains, or
OUs. After a policy is linked to a site, domain, or OU, the users or computers in that container are
within the scope of the GPO. Select a GPO and click the Scope tab to identify the containers to
which the GPO is linked.
You can further refine the scope of a GPO by filtering the scope of the GPO. You have two
ways to filter the scope: through security filtering or Windows Management Instrumentation (WMI)
filtering.
Security Filtering
The first way to filter the scope, Security filtering, involves modifying the delegation (i.e., permissions)
of the GPO. To administer GPO permissions, you use the Delegation tab of a GPO in the GPMC, as
Figure 7 shows. The Apply Group Policy permission of a GPO determines the security filtering of a
GPO. When a user or computer is within the scope of the GPO and the Apply Group Policy
permission is set to Allow, the GPO will apply to that user or computer. By default, the Authenticated
Users group is granted Allow (Apply Group Policy), meaning that all users and computers within the
GPO’s scope are governed by the policy settings in that GPO.

Figure 7:
Displaying the Delegation tab of a GPO in the GPMC

Brought to you by NetIQ and Windows & .NET Magazine eBooks

138

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

By modifying this permission, you can reduce the effect of the GPO. For example, when a policy
is linked to the domain, but you do not want the policy to apply to the Managers group, you can
add a permission Deny (Apply Group Policy) to the Managers group. As you know from Windows
NT 4.0, a deny permission overrides an allow permission, so that all users (i.e., Authenticated Users)
will apply the policy except for those who belong to the Managers group.
Alternatively, to specify that only users (or computers) in a particular group should be affected by
a GPO, remove the Allow (Apply Group Policy) permission that is assigned to the Authenticated
Users group. By doing so, the GPO will not apply to any users or computers. Then add a group and
grant it Allow (Apply Group Policy). The GPO will affect only users and computers in that group.
WMI Filtering
The second way to filter the scope of a GPO is through WMI filtering. WMI filters can detect and
respond according to a system’s characteristics. For example, you can configure a WMI filter that
applies a GPO only when a computer has sufficient free disk space or when a computer is running a
particular OS or service pack.

GPO Precedence and Inheritance
A policy setting can be configured in more than one GPO, and GPOs can be in conflict with one
another. For example, a policy setting can be enabled in one GPO, disabled in another GPO, and not
configured in a third GPO. In this case, the precedence of the GPOs determines which policy setting
the client applies. A GPO with higher precedence will win over a GPO with lower precedence.
Whether the policy setting is enabled or disabled in a GPO with higher precedence, the configured
setting takes effect. However, if the policy setting is not configured in the GPO with higher
precedence, the policy setting (either enabled or disabled) in the GPO with lower precedence will
take effect.
A site, domain, or OU can have more than one GPO linked to it. The link order of GPOs
determines the precedence of GPOs in such a scenario. GPOs with higher-link order take precedence
over GPOs with lower-link order. When you select an OU in the GPMC, the Linked GPOs tab shows
the link order of GPOs linked to that OU, as Figure 8 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

139

Figure 8:
Selecting the Linked GPOs Tab to Review Link Order

The default behavior of Group Policy is that lower-level containers inherit GPOs linked to a
higher-level container.

n Note
When a computer starts up or a user logs on, the Group Policy client-side extensions examine
the location of the computer or user object in Active Directory and evaluate the GPOs with
scopes that include the computer or user. Then the client-side extensions apply policy settings
from these GPOs. Policies are applied sequentially, beginning with the policies linked to the
site, followed by those linked to the domain, followed by those linked to OUs—from the top
level OU down to the OU in which the user or computer object exists. This sequential
application of GPOs creates an effect called inheritance.

By default, inherited GPOs take lower precedence than GPOs linked directly to the container.
In a practical example, you might configure a policy setting to disable the use of registry-editing tools
for all users in the domain by configuring the policy setting in a GPO linked to the domain. All users
within the domain will inherit that GPO and its policy setting. However, you probably want
administrators to be able to use registry-editing tools, so you will link a GPO to the OU that contains
administrators’ accounts and configure the policy setting to allow the use of registry-editing tools.
Because the GPO linked to the administrators’ OU takes higher precedence than the inherited GPO,
administrators will be able to use registry-editing tools. As you can see from this simple example, the
default order of precedence ensures that the policy that is closest to the user or computer wins.
Precedence can be further complicated because a container can be configured to Block
Inheritance. For example, when an OU is blocking inheritance, GPO application begins with any

Brought to you by NetIQ and Windows & .NET Magazine eBooks

140

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

GPOs linked directly to that OU—GPOs linked to higher-level OUs, the domain, or the site will not
apply.
In addition, a GPO link can be enabled (the default), disabled, or set to Enforced. To do this,
right-click a GPO link, as Figure 9 highlights. When a GPO link is set to Enforced, the GPO takes the
highest level of precedence—policy settings in that GPO will win over any conflicting policy settings
in other GPOs. In addition, a link that is Enforced will apply to child containers even when those
containers are set to Block Inheritance.
To facilitate evaluation of GPO precedence, you can simply select an OU (or domain) and click
the Group Policy Inheritance tab, as Figure 9 shows. This tab will display the precedence in effect,
accounting for GPO application, link order, inheritance blocking, and GPO link enforcement. This tab
does not account for policies that are linked to a site, nor does it account for GPO security or WMI
filtering.

Figure 9:
Reviewing the GPO Status from the Group Policy Inheritance Tab

Resultant Set of Policies
Because a GPO can contain many policy settings, each of which can be enabled, disabled, or not
configured, and because multiple GPOs with various scopes and filters exist in your enterprise,
ascertaining what will happen to a user or computer can be difficult. The settings that end up
applying to a user or computer—based on the user or computer’s location in Active Directory, the
GPOs that contain the user or computer in their scope, security filters, WMI filters, GPO status, link
order, inheritance, and enforcement—are called the Resultant Set of Policies (RSoP).
The GPMC provides two graphical tools with which to analyze RSoP: the Group Policy Modeling
Wizard and the Group Policy Results Wizard. To access either wizard, right-click the appropriate node

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

141

in the GPMC. You will find a full discussion of these tools in the book by Jeremy Moskowitz, which
we mentioned earlier.

Creating and Linking GPOs
To use the GPMC to create a GPO, right-click a site, domain, or OU to which you want to link the
GPO and choose Create and Link a GPO Here. Alternatively, right-click the Group Policy Objects
container and choose New.
To link an existing GPO to a site, domain, or OU, click the Group Policy Objects container and
drag a GPO from the details pane to the appropriate container. To delete a GPO link, expand the
site, domain, or OU containing the GPO link, then select the link and press the Delete key. To delete
a GPO, expand the Group Policy Objects container, select a GPO and press the Delete key. When
you delete a GPO, you are deleting it entirely; a deleted GPO will no longer be linked to any of the
containers it was previously.

Default Domain Policy
The Default Domain Policy GPO determines several important policy settings. The Default Domain
Policy is linked to the domain responsible for configuring the password and account lockout policies
for the domain, as well as Kerberos and certificate policies. Using the Default Domain Policy GPO to
configure these policies—and only these policies—is a best practice. Do not create another GPO to
configure these policies. Conversely, do not use the Default Domain Policy GPO to configure any
other policies .
As we mentioned in the discussion about Active Directory design, a domain can have only one
password, lockout, Kerberos, and trusted Certificate Authority (CA) policy. A common mistake is for
administrators to create GPOs linked to OUs and attempt to configure password policies, which is not
possible—such GPOs determine the password policies only for local accounts on computers in the
OU, not on domain accounts.
For example, if you have a situation in which some users require long passwords and others
require short passwords, then you will need to have two domains or use a third-party utility to
manage that requirement.

Default Domain Controller Policy
The Default Domain Controller Policy GPO is linked to the DCs OU and controls the computer
configuration for machines in that OU. Keeping all DCs in the DCs OU, and refraining from putting
other computer accounts in the OU, is a best practice. By segregating DCs in an OU with a policy
linked to it, you can ensure consistent configuration of DCs across the enterprise.
The Default Domain Controller Policy GPO specifies many security settings including auditing
and user rights. By default, DCs are more secure than member servers because they have a more
limited set of logon rights and privileges. To generate a full report of the settings in the Default
Domain Controller Policy GPO, select the GPO in the GPMC and click the Settings tab.
The best practice is to configure all DC-specific settings in the Default Domain Controller Policy
GPO, so you have an authoritative source of settings specific to DCs.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

142

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Member Server and Workstation Policies
Windows Server 2003 provides no default GPO to configure policies on member servers and
workstations. You can use the procedures mentioned earlier to create a GPO linked to an OU that
contains computer accounts for member servers, workstations, or both. Configure policy settings in
the GPO, and those settings will apply to computers in that OU and in child OUs.
Among the most useful nodes in a GPO are the User Rights Assignment node and the Security
Options node, which are in the Computer Configuration\Windows Settings\Security Settings\Local
Policy folder. These two nodes contain many of the policy settings that you configured using User
Manager and Server Manager in Windows NT 4.0.

Managing File and Folder Access
As discussed in earlier chapters, file and folder permissions are called ACEs and are collected in the
discretionary ACL (DACL) within the Security Descriptor (SD) of the file or folder.
The ACL of a resource is exposed in the UI by the ACL Editor. The Windows Server 2003 ACL
Editor is strikingly different from Windows NT 4.0. It has several levels, each accessible by command
buttons. For example, if you right-click any NTFS file or folder, select Properties, then click the
Security tab, you will see a general overview of the SD—what we call ACL 101—or the Security
Settings dialog box. Click the Advanced button to see more detailed information—what we call Level
2—or the Advanced Security Settings dialog box. Select any permission and click View/Edit to see
even more detail—what we call Level 3—or the Permission Entry dialog box.

Default Permissions
The default permissions on a file or folder on a Windows Server 2003 system are significantly
different than in Windows 2000 or Windows NT 4.0, in which the default permission was Everyone:
Allow (Full Control). Windows Server 2003’s default permissions are inherited from the parent object:
in the end, the root of the disk volume. The default permissions on a folder are:
• System: Allow (Full Control). The System account represents the local computer. Many native and
third-party services use the System account, and we recommend that you allow the System
account Full Control of files and folders on the computer’s local disk volumes. Therefore, the best
practice is not to modify this permission.
• Administrators: Allow (Full Control). The local Administrators account is allowed full control by
default. The local Administrators account is able to access all resources on the system and,
through a variety of mechanisms, change permissions and grant itself full control. Administrators
can always gain full control of local resources; and preventing the local Administrators group
from accessing local resources is not always possible. Therefore, unless you want to force
Administrators to jump through the hoops required to take ownership, change permissions, and
access a resource (each of which can be audited), allowing Administrators full control is
customary.
• Creator Owner: Allow (Full Control). This permission has the effect that the user that creates a
new file or folder gains full control of that file or folder. The Creator Owner special account is a
placeholder on a container object. When a new child object is created, the permission assigned
to Creator Owner is assigned to the object’s creator.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

143

• Users: Allow (Read and Execute). This permission allows members of the local Users group
(which contains the Domain Users group by default) the ability to read files and folders.
• Users: Allow (Create File) and Users: Allow (Create Folder). This permission allows members of
the local Users group to create new files and folders inside a folder. As we mentioned earlier, the
user that does create a new file or folder gains full control of that object through the Creator
Owner permission.
In summary, Administrators and the System have Full Control and Users have the ability to open
and read files and folders. In addition, any user can create a new file or folder at which point that
user has Full Control permission to that resource.

Configuring Permissions
You can use the ACL Editor to add, remove, or change permissions to a resource through accounts.

Add a Security Principal to the ACL
1. Right-click the resource and select Properties.
2. On the Security tab of the Properties sheet, select the account for which the permission is
needed; or if the account name is not present, click the Add button, then select the security
principal.
3. To select the appropriate permissions template, click the checkbox for the template.
For advanced permissions:
1. On the Security tab of the properties sheet, click the Advanced button.
2. To select the appropriate security principal or add the security principal to the list, use the Add
button.
3. Select the checkbox next to the desired permissions settings.
Keep these tips in mind:
• Configure permissions only on groups (not users) and preferably domain local or universal
groups (local groups in mixed mode).
• Click each account in the Names list and confirm all permissions in the Permissions list before
clicking OK to finish.
• Watch for the item on the Security tab’s permissions list labeled Special. This tab shows that
there are permissions that do not comply to a standard permissions template. Click the
Advanced button to see all permissions on the object.

Inheritance
ACLs, like several other Windows components, are characterized by inheritance. With ACL
inheritance, you can configure permissions of a container, such as a folder, and those permissions
will propagate automatically to that container’s contents.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

144

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

n Note
When a folder is given a set of permissions, most of those permissions are inheritable and will
be passed down to all the objects in that folder by default. This inheritance is because child
objects are configured to allow inheritable permissions from the parent to propagate to this
object by default.

An administrator needs to set permissions only once at the parent folder level, and those permissions
will propagate to child objects.
Review these important notes regarding inheritance:
• Windows Server 2003 inheritance is granular and dynamic. If a child object is configured to
Allow inheritable permissions from the parent to propagate to this object, then any changes to
permissions on the parent container will automatically propagate to the child without any
administrator intervention. Inherited permissions do not remove permissions assigned explicitly to
the child object.
• Inheritance in Windows Server 2003 is very different from inheritance in Windows NT 4.0.
Inheritance in Windows NT 4.0 was similar to the Replace permission entries on all child objects
option in the Windows Server 2003 ACL Editor—it forced the permissions of a folder down the
folder tree, removing all other permissions in the process.
• Inheritance is the combined effect of inheritable properties of a parent (Level 3 of the ACL Editor)
and a child that allows inheritance (Level 2 of the ACL Editor).
• Managing with inheritance wherever possible, so that properties can be administered at a point
high in the folder tree, is a best practice.
• Inheritance can be blocked for objects low in the tree and can be forced back down the tree
from a parent.

Blocking Inheritance
However, in certain situations applying a different set of permissions to a child object than those
applied to a parent folder is necessary. Then blocking inheritance or overriding inheritance with
explicit permissions on the child object becomes necessary.

j

Tip
If you need to block inheritance or set explicit permissions too often, you should check
whether or not your file management (your folder structure) needs modification.

Block Inheritance
1. Right-click an object and select Properties.
2. Select the Security tab.
3. Click the Advanced button.
4. Clear the Allow inheritable permissions from parent to propagate to this object checkbox.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

145

5. Choose to either Copy the parent’s permissions explicitly to the resource’s ACL or to Remove
them entirely from the resource’s ACL, as Figure 10 shows.

Figure 10:
Selecting Copy or Remove Permissions in a Security Dialog Box

The message that Figure 10 shows is the cause of much confusion on the part of new
administrators of Windows Server 2003. In the end, the choice you make doesn’t affect the results.
You will end up with an ACL on the object that contains only explicit permissions—the object will no
longer inherit the permissions of the parent object, and the explicit permissions assigned to the object
will solely determine access to the object.
The Copy or Remove Permissions dialog box asks how you want to build the new ACL. To start
with an empty ACL, select Remove, then you can add permissions that you desire on the ACL. Or
you can choose Copy, in which case the new ACL is populated with explicit permissions that match
the permissions that were previously inherited. Then you can remove the permissions you do not
want to keep and add new permissions. So this dialog box lets you choose the easiest method for
you to create the new ACL.

j

Tip
When deciding whether to copy or remove permission settings, choose the option that is
closest to the explicit permission settings that you want to set on the object. For example, if
you want essentially the same settings with just a few changes to a lengthy and complex ACL,
then the best choice would be to Copy the permission settings and make the changes
afterward.

6. Modify the permission settings as necessary.

Reinstating Inheritance
If reinstating inheritance to an object becomes necessary, you can use two methods to do so. Each
produces different results.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

146

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Reinstate Inheritance on an Object
The first method is to reinstate inheritance on the child object.
1. Right-click the child object and select Properties.
2. Select the Security tab.
3. Select the Allow inheritable permissions from parent to propagate to this object checkbox.

n Note
This action will result in the inheritable permissions from the parent folder becoming again
inherited by the child object with the existing explicit permissions of the child object remaining
in force.

Reset Permissions to Enforce Inheritance from a Parent Folder
The second method is to reinstate inheritance from the parent folder by resetting child permissions
and enforcing inheritance.
1. Right-click the parent folder and select Properties.
2. Select the Security tab.
3. Click the Advanced button.
4. Select the Reset permissions on all child objects and enable propagation of all inheritable
permissions checkbox.

n Note
Note that this checkbox control acts like a command button: It applies the requested action
one time; it does not enforce inheritance into the future. When you return to the dialog box, it
will be cleared.

5. To confirm the selection click Yes.

n Note
This option removes all the explicit permissions on the child objects. The ACLs on child objects
will be clean with only the permissions inherited from the parent folder.

Effective Permissions
The effective permissions, which ultimately determine the level of access, are determined by the
cumulative effect of allowed, denied, explicit, and inherited permissions. To understand how the
effective permissions are derived, we must look at the hierarchy of permission settings and their
precedence on an ACL.
Following are the golden rules of permission settings.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

147

File Permissions Override Folder Permissions
The only ACL that matters is the ACL for the object that is being accessed. When a user has only
Read permission on a folder and when Full Control permissions are given to a child object, such as a
file, the user will have Full Control over that object. The same is true in reverse, so when the user
has Full Control for a folder, but only Read permission on the file, the user can read but not modify
the file.

Permission Settings
Permissions have five states:
• Not Specified (both Allow and Deny are cleared)
• Explicit Allow (Allow checkbox is checked)
• Inherited Allow (Allow checkbox is grey and checked—the permission is inherited from the
parent folder)
• Explicit Deny (Deny checkbox is checked)
• Inherited Deny (Deny checkbox is grey and checked—the permission is inherited from the
parent folder)

Implicit No Access
A setting that is unspecified has the effect of not allowing access because there is no specific
permission setting. For example when a user is a member of eight groups, none of which is given an
Allow permission to a resource, the user is denied access. However, if one group has an Allow
permission, the user will have access at the level specified.

Allow Permissions Are Cumulative
Whether you assign permissions to a user or to a group or groups to which a user belongs, all the
permissions apply to the user. For example, when a user is individually given Read permissions to a
file and is a member of a group that has Write permissions, the user will have both Read and Write
permissions. If that user is also a member of another group that has Full Control of the parent folder
and inheritance is in use, then the user will have Full Control of the resource.

Deny Overrides Allow
A Deny permission takes precedence over an Allow permission, so even when a user is a member
seven of groups that have Allow permissions to a resource specified, the user will be denied access if
one group is assigned a Deny permission.

Explicit Permissions Override Inherited Permissions
A checked gray checkbox in the ACL editor indicates that permissions are being inherited from a
parent folder or multiple parent folders. Although the default condition is that the permissions will be
cumulative between inherited permissions and explicit permissions, indicated by a checked white
checkbox, in the event the two should contradict, the explicit permission will override the inherited.
For example, suppose a user has an inherited Deny Read permission, but a group to which that user
belongs has an explicit Allow Read permission. The Allow permission will take precedence and the
user will be able to read the file.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

148

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Evaluating Effective Permissions
Windows Server 2003’s ACL Editor provides a handy way to evaluate what permission a user or
group has for that object. Click the Advanced button on the Security tab of the object’s Property
dialog box. Then click the Effective Permissions tab. Select the user or group for which you want to
evaluate effective permissions. Then the tab calculates permissions based on the rules described
earlier.

Best Practices for ACLs
The following summarizes best practices for ACLs on files or folders:
• Assign the minimum permissions necessary for resource access.
• The default permissions are adequate for many scenarios in Windows Server 2003.
• The Full Control permission is usually appropriate only for administrators, the System account,
the Creator Owner account, and the user or group that owns the resource.
• You should typically grant other accounts Read and Execute or Modify permission at most. The
Modify permission provides read and write capability, but does not allow the user to change
permissions on the object or delete the object. Full Control adds those two permissions plus the
Delete Subfolders and Files permission.
• Unlike Windows 2000 and Windows NT 4.0, in Windows Server 2003 the Everyone group is
restricted so that anonymous connections are not included. Therefore, the Everyone group can
be used with more regularity on ACLs.
• Use a broad, shallow folder structure and aim to manage all permissions through inheritance.
• Do not use share permissions to restrict access. The correct share permission is Everyone
(Full Control).

Sharing a Folder
After a folder has been appropriately secured, you can make it accessible to remote users by sharing
the folder. The process of sharing a folder has not changed: right-click the folder, select Properties,
click the Sharing tab (or select Sharing and Security from the shortcut menu), and select Share this
folder.
However, the default permissions applied to a shared folder have changed. Windows Server 2003
sets the default share permission to Everyone (Allow Read). Although this default setting is technically
more secure, it violates the best practice of securing a file or folder only with NTFS permissions.
Because share permissions (which are more restrictive than NTFS permissions) will win, even
administrators are prevented from modifying the contents of a shared folder.
Most enterprises have a written policy that specifies that shares should be configured with
Everyone (Allow Full Control), then secured with NTFS permissions.

j

Tip
When configuring a shared folder, be sure to click the Share Permissions button and grant the
Everyone group Full Control.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

149

Other Guidance on What Is New
To help you maintain continuity of administration, the earlier sections of this chapter guide you
through the most common day-to-day administrative tasks. A full discussion of administering
Windows Server 2003 and Active Directory is beyond the scope of this eBook. For a comprehensive
discussion of Windows Server 2003 administration, check out the eBook, “Windows 2003: Active
Directory Administration Essentials,” available at http://www.windowsitlibrary.com/Ebooks
/AdministeringAd/Index.cfm.
The following sections will help you to identify other administrative features and concerns that
might warrant additional attention.

Help and Support Center
The Windows Server 2003 online Help feature is extraordinary. The Help and Support Center (in the
Start menu) centralizes tools and documentation. The Search functionality searches across the online
Help documentation as well as the Microsoft Knowledge Base (when you have an Internet
connection). And the online Help is extremely well written: comprehensive and easy to follow.
You can even install the Windows Server 2003 Help on a Windows XP client (and vice versa),
which lets you easily access Help and support for both platforms.

n Note
For more information about how to install Windows Server 2003 Help on a Windows XP
system, see the Microsoft Web site at http://www.microsoft.com/resources/documentation
/WindowsServ/2003/enterprise/proddocs/en-us/Default.asp?url=/resources/documentation
/WindowsServ/2003/enterprise/proddocs/en-us/sag_ATP_sharehelp.asp.

Microsoft IE Enhanced Security Configuration
The Internet Explorer (IE) Enhanced Security Configuration locks down IE on Windows Server 2003.
This configuration prevents access to untrusted sites and in the end requires you to authorize each
site you want to visit.
You can disable the configuration for all users on a server (for example, in a Terminal Services
configuration) or just for administrators. Use the Add/Remove Programs application in Control Panel
and select Add/Remove Windows Components. In the components list, select the IE Enhanced
Security Configuration and click Details. You can specify whether the configuration should apply to
administrators, nonadministrative users, or both.

Shadow Copies
The Shadow Copies feature lets administrators or users recover previous versions of files when the
current version is corrupted, overwritten, or deleted. This feature is an easy and effective alternative
to restoring the file from backup media and can be implemented in conjunction with a complete
backup plan. To enable shadow copies, right-click a volume on a Windows Server 2003 computer
and click the Shadow Copies tab. Then click the Enable button.
To use the shadow copies functionality to recover a file, you must use a Universal Naming
Convention (UNC), for example \\servername\sharename), to access the appropriate folder, then
Brought to you by NetIQ and Windows & .NET Magazine eBooks

150

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

right-click the folder or file, choose Properties, and click the Previous Versions tab. This interface—the
Previous Versions client—is native to Windows Server 2003 computers but can be installed on
Windows XP and Windows 2000 systems.
The Shadow Copies feature has many possible configurations and nuances. Use the Help and
Support Center documentation to learn the ins and outs of Shadow Copies.

Disaster Planning and Recovery
Including Active Directory in your disaster recovery planning is important. To back up Active
Directory, back up the System State of a DC. The System State is a collection of components,
including Active Directory, the Sysvol, the registry, and other items that drive the configuration of the
server. You cannot back up an individual element of the System State: the System State is backed up
as an entirety. Using a backup utility, such as the builtin Backup Utility (ntbackup.exe), select the
System State node, which Figure 11 shows.

Figure11:
Displaying the System State in the Backup Utility Dialog Box

To restore Active Directory on a failed DC, you must restart the DC and press F8 when
prompted. A series of startup options will appear including the Directory Services Restore Mode.
Select this mode and the DC will start without directory services being active—it is a kind of safe
mode for directory services. Because directory services is not running, related files are not locked and
can therefore be restored from the backup media. Using the backup utility of choice, restore the
System State onto the DC.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 5 Maintaining Windows Server 2003 in a Post-Migration Environment

151

After the restore operation has completed, restart the DC in the normal manner. The DC will
initiate replication from its partners to get up to date, because its directory database will be accurate
as of the date of the System State backup.
Active Directory backup and recovery has many nuances. Be certain to read the information in
the Help and Support Center.

Monitoring DC Health
A few tools are available in the native administrative tools to monitor DC health. Monitoring DC
health is important, unless you are comfortable with the firealarm monitoring methodology in which
you find out something has broken only when it causes enough pain that people notice.
Among the important components of Active Directory that you should monitor are:
• DNS records. Periodically query the DNS zone to ensure all required service and host records
are registered so that clients can locate all DCs and services.
• DC accessibility. Perform tests such as simple as pings to appropriate ports to check whether
DCs can be accessed across the network.
• Replication. Replication is a complex process that works amazingly well with little intervention
in most enterprises. But when it breaks, it is painful. Replication checks will report any problems
with replication, and with any luck, before replication problems cause pain.
• Trust relationships. Validate trust relationships with external domains.

Third-Party Administrative Tools
The native administrative tools support basic administrative tasks in simple environments. If your
enterprise is more complex (with multiple domains, multiple forests, or multiple directory services),
you might require tools that create virtual views of the organization to let you manage the
environment more flexibly. Native administrative tools are also weak in the areas of monitoring and
reporting.
NetIQ, the sponsor of this eBook, offers several products that enhance your ability to monitor,
manage, and troubleshoot Active Directory and Windows Server 2003. NetPro specializes in
monitoring Active Directory, and information about its tools is available at http://www.netpro.com.
Chapter 4 provides a list of other companies that offer administrative tool suites that you might want
to evaluate.

Next Steps
Windows Server 2003 and Active Directory provide a stable, secure, scalable platform on which to
deploy enterprise services. In the next chapters, we focus on what has become an indispensable
enterprise application: email. We will migrate older versions of Microsoft Exchange Server to
Exchange Server 2003, and you will find that tools such as the Active Directory Migration Tool will
again serve an indispensable role.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

152

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Chapter 6

Planning an Exchange Server 2003
Migration
Planning a Microsoft Exchange Server migration can seem incredibly complicated: You need to
consider many factors, particularly if you are migrating from Exchange Server 5.5, which uses an
entirely different architecture and user directory. To make your planning easier, ignore for a moment
all the tools and techniques available to you and focus on what you have and where you need to go.
Then you can more easily select the correct migration methodology to get you there.

Considerations
What sort of Exchange Server migration do you need? Intraorganizational migrations offer relative
ease, but don’t provide opportunities to clean up your existing environment. In-place upgrades are
the easiest type, but are available in only limited circumstances.

Intraorg or Interorg?
An important consideration is whether to perform an intraorganizational or interorganizational
migration. In an intraorg migration, you join Exchange Server 2003 to an existing Exchange (either
Exchange 5.5 or Exchange 2000 Server) organization, gradually move mailboxes to Exchange 2003,
then decommission older servers one at a time. In an interorg migration, you bring up Exchange
2003 in an entirely new domain and move mailboxes out of the old organization and into the new
one. Upon completion, you decommission the original organization.
Interorg migrations generally create the least impact on the production environment and are
typically the preferred type. However, coexistence between the two organizations can be somewhat
complicated and may require additional tools (especially with Exchange 5.5 migrations). Interorg
migrations result in the cleanest final organization because the old organization is eventually removed
from service. However, intraorg migrations can still require significant postmigration cleanup, and if
you’re coming from Exchange 5.5, will require Microsoft Active Directory Connector (ADC) to connect Exchange 5.5 to your Active Directory domain. Still, intraorg migrations can be somewhat easier.
Because with an intraorg migration all the servers reside in the same organization, you can use
Exchange Server’s built-in tools to move mailboxes between servers. After moving all the mailboxes
to new servers, your migration is complete.
An in-place upgrade from Exchange 2000 to Exchange 2003 is technically a form of intraorg
migration, although no migration per se takes place. Servers are simply upgraded one at a time to
Exchange 2003. Other than the downtime required for the upgrade, end users generally see no
effects. An in-place upgrade is one of the easiest ways to migrate your messaging environment to
Exchange 2003. Note that there is no in-place upgrade option to move from Exchange 5.5. We’ll
discuss this in the next section.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

153

Another consideration between intraorg and interorg migrations is that intraorg migrations
don’t provide the opportunity to restructure your Exchange organization. You’ll start with your old
organization and basically keep it intact; with an interorg migration, you move mailboxes from one
organization to another and structure the new organization how you want it. Therefore, interorg
migrations offer a fresh start and the opportunity to change decisions about your Exchange Server
structure. In an intraorg migration, you can still—eventually—reorganize organizational units and
other aspects of Exchange Server, but you’ll have to wait to do so until after you decommission all
your old servers.

n Note
While native facilities don’t allow admin group restructuring, with the use of third-party tools
like NetIQ Migration Suite, this can be easily accomplished

Another change you might want to make to the Exchange organization is its name. Perhaps
your company has merged with another, changed its name, or gone through some other type of
restructuring, and therefore renaming the Exchange organization is now desirable. In an intraorg
migration, you’ll never have that opportunity: Exchange 2003 still does not provide a fully supported
means of changing the organization name. However, in an interorg migration, you can name the new
organization whatever you like.

In-Place Upgrades
An in-place upgrade—simply upgrading your servers’ software to Exchange 2003—is certainly the
easiest approach. An in-place upgrade is not technically a migration because all your mailboxes and
data remain in place. Therefore, you won’t need additional third-party tools or utilities.
However, in-place upgrades are possible only in very limited scenarios. For example, if you’re
running Exchange 2000, then an in-place upgrade might make sense. If you’re installing on top of
Windows 2000 Server, you’ll need to ensure that each Exchange server that you will upgrade is
running at least Windows 2000 Server with Service Pack 3 (SP3). In this scenario, you can simply
install Exchange 2003 right on top of the existing Exchange server installation. Afterward, you can
install Windows Server 2003 for a complete migration. This scenario—a direct upgrade from
Exchange 2000—is about the only easy one, though.
The problem is that Exchange 2003 won’t run on Microsoft Windows NT, and it can’t be used to
directly upgrade Exchange 5.5 installations. If you want to do an in-place upgrade of an Exchange 5.5
server, you need to perform the following steps:
1. Upgrade the OS to Windows 2000, SP3 or later.
2. Upgrade Exchange 5.5 to Exchange 2000.
3. Upgrade Exchange 2000 to Exchange 2003.
4. Upgrade the OS to Windows 2003.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

154

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

This path allows plenty of opportunities for something to go wrong, and you’ll wind up with the
same old hardware that you used for Exchange 5.5. We’ll bet that the machine running Exchange 5.5
on top of Windows NT 4.0 Server won’t be robust enough for Windows 2003 and Exchange 2003,
meaning you’ll wind up migrating to new servers anyway.

Front-End Servers vs. Back-End Servers
To maintain functionality within your Exchange Server organization, be sure to first upgrade all your
front-end servers before you upgrade any of your back-end servers. Under Exchange 2003 and
Exchange 2000, you can designate servers to act as protocol servers so that all client requests can run
through these front-end proxy machines, which relay the requests to the users’ back-end servers that
store their mailboxes. This structure shields the back-end servers that store users’ private and public
Exchange server data from direct Internet exposure. Under Exchange 2000, you can designate
computers running only Enterprise Edition as front-end servers, and this tends to be a very pricey
option. Under Exchange 2003, computers running both Standard Edition and Enterprise Edition have
the capability to be front-end servers.
Front-end servers act as the primary point of contact for users accessing POP3, IMAP4, and HTTP
services. By default, each new installation of Exchange 2003 becomes a back-end server, unless you
are upgrading an existing Exchange 2000 front-end server. To configure a server as a front-end
server:
1. Launch the Exchange System Manager (ESM) and expand the Servers node.
2. Right-click the server that you want to configure as a front-end server and select Properties.
3. From the General tab, as Figure 1 shows, select the This is a front-end server checkbox and click
OK.
You can designate a server as a front-end server only when you have two or more Exchange servers
running within your Exchange organization: You can’t have a front-end server without at least one
back-end server.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

155

Figure 1:
Enabling a front-end server from Exchange Server Properties

System Requirements
Exchange 2003 will run on either Windows 2003 or Windows 2000—this capability is unique. By
contrast, Exchange 2000 will run on only Windows 2000. Exchange 2003’s flexibility makes it easier
to incorporate into your environment. Note that Exchange 2003 does require SP3 or later to run on
Windows 2000.
Exchange 2003 has some hefty hardware requirements. Microsoft’s minimum requirements are
not very realistic. According to Microsoft, you can install Exchange 2003 on any Intel-compatible
Pentium-based computer with a clock speed of 133MHz or faster. Microsoft’s minimum hardware
requirements specify only 128MB of RAM and 500MB of available disk space on the drive in which
Exchange 2003 will reside. At a minimum, we suggest that you install and run Exchange 2003 on a
Pentium III server with at least 1GB of RAM and with at least 2GB of available disk space. We make
this our starting point.
Whether you install Exchange 2003 on top of Windows 2003 or on top of Windows 2000 SP3 or
later, Exchange 2003 requires the NTFS file system for both the system drive (e.g., C) and for all other

Brought to you by NetIQ and Windows & .NET Magazine eBooks

156

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

drives hosting Exchange 2003-related files. Exchange 2003 drives store the Exchange 2003 program
files, the transaction log files, the messaging database files, as well as other Exchange-related files.
During Exchange 2003 Setup, the installation program must be able to contact at least one Active
Directory domain controller (DC) running Windows 2003 or Windows 2000 SP3 or later within the
same Active Directory site.
To install Exchange 2003 under Windows 2003 or Windows 2000 SP3, the Network News
Transfer Protocol (NNTP) service, the SMTP service, and the WWW service must all be installed and
running on the server computer on which you want to install Exchange 2003. In addition, to install
Exchange 2003 under Windows 2003, you must also install the ASP.NET subcomponent of the
Application Server component in the Add or Remove Programs dialog box.

Standard or Enterprise Edition?
You have two editions to choose from with Exchange 2003: Standard or Enterprise. The two editions
have many of the same features, with the following exceptions:
• Enterprise Edition supports up to four storage groups, and each group can have up to five
databases. Standard Edition can have only one storage group with only two databases. Therefore,
Standard Edition limits your ability to balance your users across multiple databases, which is a
useful practice for improving performance and reducing the impact of database corruption.
• Enterprise Edition places no limitations on database size; Standard Edition allows a maximum
database size of 16GB. Therefore, a Standard Edition server (with its maximum of two databases)
supports no more than 32GB of message storage. Larger organizations will quickly outgrow this
limit.
• Enterprise Edition supports clustering; Standard Edition does not.
• Enterprise Edition includes a connector for integration with X.400-based messaging systems;
Standard Edition does not.
Exchange 2003 also has basic system requirements regarding processor speed, memory, and so
forth. In general, these stated minimums aren’t sufficient for a production deployment. Instead you
need to consider the workload your Exchange servers will need to handle and equip them accordingly. It’s not unusual for larger Exchange servers to do well with dual (or even quad) processors and
2GB to 4GB of RAM.
Exchange 2003 requires the installation of some underlying Windows components. You must
install Internet Information Services (IIS) 6.0 with the optional NNTP, SMTP, and WWW services. As
previously mentioned, you must also install and enable ASP.NET—simply installing ASP.NET does not
automatically enable it in the IIS Web Services Extensions list. You need use the IIS management
console to manually enable ASP.NET.

Exchange and Active Directory
Like Exchange 2000, Exchange 2003 uses Active Directory as its user directory and global address
book. This practice is in stark contrast with Exchange 5.5, which provides its own user directory. To
assign permissions, the Exchange 5.5 directory links Exchange 5.5 mailboxes to a Windows NT user
account. In effect these links mean that every user is represented by at least two objects: a mailbox

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

157

and a user account. Under Exchange 2003 and Exchange 2000, each user is represented by only an
Active Directory user account. Each user account must be mailbox-enabled—a process which creates
an Exchange mailbox for the user. Note that it is impossible for any one user account in Active
Directory to be associated with more than one mailbox. Although this capability is possible in
Exchange 5.5, you will have to ensure that all mailboxes are mapped one-to-one to a unique domain
user account before migrating.
The Exchange 2003 Setup Wizard installs an updated version of the Active Directory Users and
Computers Microsoft Management Console (MMC) snap-in. This updated edition supports all the
added functionality that Exchange 2003 provides. For example, to display the email properties of
mail-enabled users and groups you can add Exchange Server-specific column headings in the
Exchange version of the Active Directory Users and Computers console. To move mailboxes, delete
mailboxes, and configure Exchange features for users and groups, as Figure 2 shows, you can select
one or more objects, right-click the objects, then select Exchange Tasks.

Figure 2:
Configuring Exchange Features from the Exchange Task Wizard

All the settings for mailbox-enabled users, mail-enabled users (contacts), and mail-enabled groups
(distribution lists) for Exchange 2003 and Exchange 2000 are stored in Active Directory. When you
install Exchange 2003, the Setup program places an enhanced MMC snap-in for the Active Directory
Users and Computers console within the Microsoft Exchange program folder of the Start menu. This
enhanced snap-in provides the interface for accessing all Exchange Server’s extended properties for
users, contacts, and groups. The name of the enhanced snap-in is Users and Computers.msc, whereas
the name of the standard Active Directory snap-in is dsa.msc.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

158

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

The Exchange 2003 Active Directory Users and Computers console adds three tabs to each user’s
Properties sheet: Exchange General, Exchange Features, and Exchange Advanced. The Exchange
General tab displays the user’s mailbox store name, the storage group name in which the mailbox
resides, and the name of the Exchange server that is hosting the storage group. The Exchange
General tab also lets you specify the user’s alias, and it lets you configure any Delivery Restrictions,
Delivery Options, and individual Storage Limits. The Exchange Features tab lets you enable and
disable Exchange Server’s mobile services and messaging protocols. Mobile services include the
new Outlook Mobile Access (OMA), User Initiated Synchronization, and Up-to-date Notifications.
Messaging protocols include Outlook Web Access (OWA), POP3, and IMAP4. The Exchange
Advanced tab lets you specify a Simple Display Name, hide the user from Exchange address lists,
and view and modify custom attributes. It also provides the ability to view and modify Mailbox Rights
(permissions) for the user.

The Active Directory Connector
With Exchange 2003 and Exchange 2000, Microsoft provides the ADC. (The Exchange 2003 version
is updated and is the preferred version to use.) Essentially, the ADC’s job is to replicate entries from
the Exchange 5.5 directory to Active Directory and to keep those entries synchronized. The practical
purpose of this synchronization is to make AD’s information available to Exchange 5.5 and vice-versa.
If you’re migrating from Exchange 5.5 to Exchange 2003 and you expect the two products to
interoperate for an extended period of time (as opposed to just during a weekend migration), then
the ADC will be a part of your life. The ADC is absolutely not necessary in any migration that does
not involve Exchange 5.5. Moving from Exchange 2000 to Exchange 2003 is a very straightforward
task and doesn’t use the ADC. In fact, the easiest way to move from Exchange 2000 to Exchange 2003
is to simply upgrade each server in-place, rather than migrating to new servers.
A basic rundown of the two broad migration scenarios and what you’ll need for each follows:
• From Exchange 5.5: Deploy or upgrade the ADC. Use Exchange’s Move Mailbox Wizard to
move mailboxes from one server to another.
• From Exchange 2000, with no Exchange 5.5 present: ADC is unnecessary. Simply move
mailboxes from one server to another.

Global Catalog Servers
If you’re upgrading or migrating from Exchange 2000, then you probably already know about
Global Catalog (GC) servers. However, if you’re coming from Exchange 5.5, it’s a topic you need to
understand.
In Exchange 5.5, the Exchange server maintains its own directory of users. When someone sends
an email message, Exchange validates the recipient email address against the Global Address List
(GAL). When users click the To: button in Outlook to access the GAL, it’s Exchange that provides the
list. However, in Exchange 2000 and later, Exchange doesn’t have a directory and doesn’t maintain
the GAL. Instead Active Directory and more specifically, DCs that act as GC servers, maintain the
GAL. In other words, users need access to a GC server to send email messages and for address
lookups.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

159

This behavior places a significant burden on GC servers. The old rule of one GC per four DCs
isn’t sufficient in an Exchange 2003 or Exchange 2000 environment; you’ll instead find that every
couple of hundred users needs a separate GC. Each Exchange server also needs a GC on the LAN,
because the GCs provide Exchange with necessary information about the Active Directory forest.
Smaller branch offices that previously did not require a DC—let alone a GC—might suddenly
need one. Otherwise, users will have to access the GAL across a WAN link, which can severely
impact Outlook performance. When users’ mailboxes are on the corporate Exchange server on the
other side of a WAN link, having a local GC makes Outlook seem much more responsive. Outlook
communicates with the Exchange server in the background when sending and retrieving email
messages and communications with the GC are generally immediate. When those communications
are slow, they make Outlook seem to hang when sending email or accessing the GAL.

The Exchange System Manager
Under Exchange 5.5, all the administrative chores were performed with the System Administrator
utility. Under Exchange 2003 and Exchange 2000, administration is divided between the Active Directory Users and Computers console for user- and group-related management and the ESM for managing global settings, address lists, servers, storage groups, protocols, connectors, tools, public folders,
and replication. The ESM is a MMC snap-in, similar to the Active Directory Users and Computers
snap-in. By default the ESM snap-in is stored in the \Program Files\Exchsrvr\bin folder and is named
Exchange System Manager.msc. One of ESM’s most important jobs is to provide support for administering both the private Mailbox Stores and the Public Folder Stores.
For example, if you expand a storage group’s node in ESM, then click to expand the subnode for
one of the Mailbox Stores, you can select the Mailboxes folder. Select one or more existing mailboxes, then right-click and select Exchange Tasks to move those mailboxes to another Exchange
server or delete the selected mailboxes. You have the ability to right-click a Mailbox Store or a Public
Folder Store and view or modify its properties. The properties for a Mailbox Store, as Figure 3 shows,
include setting storage limits for the entire storage database, specifying deleted items retention settings
for the store, enabling message archiving, and setting the file name and location for the Exchange
database file (e.g., priv1.edb) and the Exchange streaming database file (e.g., priv1.stm). Right-clicking
a Mailbox Store or a Public Folder Store also lets you mount or dismount the store or create a fulltext index of the store.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

160

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 3:
Selecting the Database tab of the Mailbox Store Properties sheet

From the Protocols node in ESM, you can configure, stop, and start the virtual server instances
that are available for the following messaging protocols: HTTP, IMAP4, NNTP, POP3, and SMTP.
To also create new instances of these virtual servers, you can right-click a virtual server and select the
Start option. Under HTTP, the Exchange virtual server is responsible for presenting OWA, OMA, and
Microsoft Server ActiveSync. Under IMAP4, the default IMAP4 virtual server is responsible for
publishing IMAP4 data to clients. Similarly, the default NNTP virtual server publishes news group
feeds to NNTP clients and the default POP3 virtual server delivers incoming messages to POP3 email
clients. The default SMTP server is responsible for sending outgoing messages to their properly
addressed recipients.

Client Deployment
Exchange 2003 is compatible with all recent versions of Microsoft Outlook, and Outlook is considered
the official client for Exchange. Your users can run Outlook 2003, Outlook 2002, Outlook 2000, or
even Outlook 98 with Service Release 2 (SR2) or later. Users can also use traditional POP3 or IMAP4
clients, such as Outlook Express, Netscape Communicator, and so forth; however, these clients will
not provide the full functionality that Exchange offers, such as integrated calendars, tasks, and notes.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

161

In many cases, purchasing an Exchange 2003 Client Access License (CAL) also provides you with
a license to run the latest version of Microsoft Outlook, giving you a built-in ability to run Exchange’s
full-featured client software. To deploy Outlook, you can easily use Group Policy, Microsoft Systems
Management Server (SMS), or other software deployment techniques. Although Outlook is often sold
as part of Microsoft Office, you do not have to install the entire Office suite to use Outlook, and you
can install a more recent version of Outlook (such as Outlook 2003) on computers running an older
version of the other Office applications (such as Office XP). However, you need to understand the
built-in limitations of running Outlook 2003 alongside a previous version of Microsoft Word or
Microsoft Excel: Outlook 2003 will not perform mail merges with any earlier version of Office (e.g.,
Office XP, Office 2000). So consider yourself forewarned.
Finally, because of Exchange’s built-in Outlook Web Access (OWA) functionality, clients will also
have the ability—when enabled—to use a Web browser to connect to their mailboxes. OWA works
with any Web browser, including non-Microsoft browsers, but provides the best user experience
when accessed through Internet Explorer (IE) 5.5 or later. When used with these browsers, OWA’s
appearance is remarkably similar to Outlook 2003, as Figure 4 shows, and it provides most of the
same basic functionality as Outlook 2003.

Figure 4:
Viewing the OWA client for Exchange 2003

Brought to you by NetIQ and Windows & .NET Magazine eBooks

162

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

If you plan to use Exchange 2003’s new remote procedure call (RPC) over HTTP functionality,
which lets Outlook connect to Exchange over the Internet with full functionality and without a VPN,
then you’ll need to meet a strict set of client requirements: RPC over HTTP is provided only on
Windows XP Professional with SP1 or later running Outlook 2003. Server-side requirements for RPC
over HTTP include Windows 2003, the optional RPC over HTTP proxy (which you can install with
other Windows components), and IIS 6.0. For full details about how to deploy RPC over HTTP
(which is a fairly complex process), see the Microsoft Exchange Server 2003 Web site at
http://www.microsoft.com/exchange.
You can also install and use Outlook 2003 within a Remote Desktop environment on a
Windows 2000 or later Terminal Services computer. Office 2003 and Outlook 2003 both install easily
on Windows 2003 and Windows 2000 computers running Terminal Services—no transform (.mst) file
is required during installation, as was the case for the Office 2000 suite. Outlook 2003 performs well
under Terminal Services.
Keep in mind that Office 2003 and Outlook 2003 can be installed only on computers running
Windows 2003, Windows XP, or Windows 2000. The Microsoft Office System 2003 does not support
computers running Windows NT 4.0 or Windows 9x. Fortunately, Exchange 2003 is backward
compatible with previous versions of Outlook, but you lose its newest features, such as the
redesigned navigation pane, the new reading pane, and Cached Exchange mode. Microsoft has
redesigned the Outlook 2003 interface to make it easier and faster to use. The navigation pane
integrates the basic navigation and sharing features of Outlook into a central, easy-to-use location
and replaces the Outlook bar. As Figure 5 shows, when using the Inbox, called Mail, you see more
mail folders than before, and you can add your favorite folders to the top of the list. In Calendar, you
can view other users’ shared calendars along side your calendar.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 6 Planning an Exchange Server 2003 Migration

163

Figure 5:
Viewing Mail folders in Microsoft Office Outlook 2003

The redesigned reading pane displays email messages vertically, similar to an 8.5" x 11" sheet of
paper. This layout is easier on the eyes and with the new multiline message list, users can view
nearly twice as much of an email message on the same size monitor as with the preview pane in
earlier Outlook versions. With the reading pane, users no longer need to open a separate window to
read each email message. New Search Folders contain constantly-updated search results of all email
messages matching specific search criteria. Using the default Search Folder named Unread Mail, users
can view all unread email messages from every folder in their mailbox. To help reduce the size of
users’ mailboxes, the default Large Mail Search Folder shows the largest messages in each user’s
mailbox, no matter which folder stores the messages. To create Search Folders, users can select from
a list of predefined templates or create custom Search Folders based on specific criteria.
Using the new Cached Exchange mode, Exchange 2003 and Outlook 2003 need to communicate
much less frequently because Outlook 2003 stores each user’s mailbox data on the local workstation
when possible. In this manner, RPCs and overall network traffic is reduced between the Outlook
2003 clients and Exchange 2003. Additionally, the data that is sent between Outlook 2003 clients and
Exchange 2003 servers is now compressed. So, data synchronization between clients and servers is
faster and less frequent than before. To enable Cached Exchange mode in Outlook 2003, go to Tools,
Email Accounts, then Exchange Server Options.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

164

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

However, in certain circumstances you might need to consider turning off Cached Exchange
mode. If a user’s offline storage (.OST) file exceeds 1.5GBs, the Exchange Cached mode can slow
performance in Outlook. Besides the overall size of a user’s OST file, the sheer number of items
stored in any one folder can also hinder performance. If a user has more than 9000 items stored in
any one folder in his or her mailbox, you need to consider disabling Cached Exchange mode to
improve Outlook’s performance for that user.
Under earlier versions of Outlook the maximum file size for both an offline folder (.ost) file and
a personal folder (.pst) file is approximately 2GBs. Under Outlook 2003, in the new Unicode file
format, an .ost file can grow to 20GBs. You also have the option to create and use .pst files under
the older ANSI file format, which supports only file sizes up to approximately 2GBs. The new
Unicode file format has a much higher limit of 20GBs—the same restriction as placed on OST files
under Outlook 2003. For additional information about Outlook 2003 file size limits and configuration
options, see the Microsoft article “How to configure the size limit for both .pst and .ost files in
Outlook 2003,” at http://support.microsoft.com/?kbid=832925.

Putting It All Together
Be sure to plan your migration to Exchange 2003 carefully. Choose the better migration method for
your organization’s unique environment and needs—either intraorg or interorg. Make sure that the
hardware and OS software on which you will install Exchange 2003 can properly support the new
messaging platform, for the immediate future and for the long term. Select the appropriate edition of
Exchange 2003 for your environment—the Standard Edition or the Enterprise Edition—and remember
that the Standard Edition limits the maximum message store size to 16GBs. If you will be migrating
from Exchange 5.5, be sure to know how to set up and use the ADC and map out where you need
to place Active Directory GC servers to insure adequate performance from Microsoft Outlook clients.
Understand when to use the Active Directory Users and Computers console (i.e., for user and
group administration) versus the ESM (i.e., for administering servers, storage groups, protocols,
address lists, public folders, tools, and replication). Decide which Exchange 2003 clients you will
support, including Microsoft Outlook, POP3 clients, IMAP4 clients, OWA, and OMA. If deploying
Outlook 2003, consider enabling Cached Exchange mode unless certain users’ .ost files will exceed
1.5GBs or unless specific users will be storing more than 9000 messages within one folder. To take
advantage of the increased storage capacity for users under Outlook 2003, create new .ost or .pst files
that use the Unicode file format option. And remember, using the Unicode file format, .ost and .pst
files can support file sizes up to 20GBs, as opposed to the 2GB limit for ANSI files.
In the next chapter we will use the information you gathered during the planning stage to
explain the procedures for installing Exchange 2003. The next chapter will cover Exchange server
configuration, upgrading and migrating Exchange server, and post-installation concerns.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

165

Chapter 7

Installing Exchange Server 2003
In Chapter 6, we examined the migration planning that needs to occur before you attempt to
implement or migrate to a Microsoft Exchange Server 2003 messaging environment. Even with a
detailed implementation or migration plan in place, you still need to address some concerns before
you insert the Exchange Server 2003 CD-ROM into your server’s CD or DVD drive. For example,
Exchange server naming conventions are important. Many organizations have server-naming standards
that provide server name consistency across geographic boundaries. When naming conventions are
well thought out, they offer clear, concise, and meaningful definitions for each server’s primary role
on the network and in the organization.

Preinstallation Considerations for Exchange Server 2003
In this chapter, we will use a naming convention that describes each server’s main function. The
name for the first Exchange Server 2003 computer that we will install is EX2003-BE-01. The prefix
EX2003 designates the server to be running Exchange Server 2003 as opposed to Exchange 2000
Server or Exchange Server 5.5. The letters BE identify the server as a back-end server that stores
Exchange mailboxes and public folders. (Exchange front-end servers do not store mailboxes or public
folders. If we chose to designate this computer as a front-end server, we might identify it with FE,
but you cannot install a front-end server without at least one back-end server already present in the
organization.) Finally, the 01 suffix identifies it as the first back-end server within our organization.
Chapter 6 outlines in detail the hardware and software requirements for Exchange Server 2003.
As a review, remember that you need the following components in place on the target server before
you can perform a successful Exchange Server 2003 installation:
• WWW service
• SMTP service
• ASP.NET component (required on Windows Server 2003 only)
• Network News Transfer Protocol (NNTP) service
• Windows 2000 Server with Service Pack 3 (SP3) or the Windows Server 2003 OS
• Windows 2000 Server or Windows Server 2003 Active Directory (TCP/IP and the DNS service are
required by Active Directory)
• One or more drives formatted with the NTFS file system for storing all Exchange Server 2003
data, logs, and components

Performing the Installation
Running Exchange Server 2003’s Setup program without any command-line options reveals a series
of HTML-based checklists that guide you through the installation of your first server, additional
servers, and the post-installation process. The basic installation steps are the same for both the
Standard and the Enterprise editions. The first server you install is an important one. The Exchange
Brought to you by NetIQ and Windows & .NET Magazine eBooks

166

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Server Deployment Tools setup can accommodate scenarios requiring Exchange 5.5 coexistence,
Exchange 2000 coexistence, and so forth, as Figure 1 shows.

Figure 1:
Choosing the best deployment option for the first Exchange Server 2003 computer

The four installation scenarios are:
• Coexistence with Exchange 5.5. In this scenario, you run Exchange 5.5 but haven’t yet
connected it to Active Directory. When adding the first Exchange 2003 server, setup installs and
configures the Active Directory Connector (ADC) for you, thereby setting up your basic migration
environment.
• Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5. This scenario is for
environments already running the ADC to connect Exchange 5.5 and Exchange 2000; Setup will
upgrade the ADC and let Exchange Server 2003 become a part of the environment.
• Upgrade from Exchange 2000 Native Mode. This option is for organizations that have only
Exchange 2000 running (no Exchange 5.5 servers). You will join the Exchange 2003 server to the
existing Exchange organization.
• New Exchange 2003 Installation. This option installs a new Exchange Server 2003
organization and doesn’t provide interoperability with earlier Exchange versions.
When you perform an in-place upgrade of an Exchange 2000 server, you will need to remove
the Mobile Information Server (MIS) Exchange Event sink, if it is present. This component is
replicated in Exchange Server 2003 as the mobile browser component. Exchange Server 2003 does
not support MIS but provides much of the same functionality built-in. You will also need to remove
the Instant Messaging (IM) service, the Chat service, the Key Management Server (KMS), the Lotus
cc:Mail connector, and Microsoft Mail (MS Mail) connector, if any of these components are present.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

167

None of these components are supplied with Exchange Server 2003; the Microsoft Office Live
Communications Server 2003 replaces the IM service as well as the Exchange 2000 Conferencing
Server product, and Windows Certificate Services replaces the KMS.
Your first installation step is to prepare the Active Directory schema for Exchange Server 2003. In
anything but a completely native Windows Server 2003 forest, modifying the Active Directory schema
will cause all forest Global Catalog (GC) servers to rebuild their databases from scratch. Therefore, we
recommend that you not modify the Active Directory schema (a process known as ForestPrep) during
business hours, when users rely on the availability of GC servers. To run ForestPrep, simply run
Exchange Server 2003’s Setup utility: It will automatically detect that ForestPrep has not been
performed and offer to run it for you. Alternately, to explicitly specify ForestPrep to run, you can
navigate to the \Setup\I386 folder on the Exchange Server 2003 installation CD-ROM (e.g., <CD drive
letter>:\English\Exch2003\Ent\Setup\I386) and launch the command setup /forestprep. The process
takes several minutes, although the GC rebuild process can take much longer in a large forest. Figure
2 shows the Microsoft Exchange Setup Wizard preparing to run ForestPrep.

Figure 2:
Running the ForestPrep installation phase for Exchange Server 2003

After performing ForestPrep, you will need to wait until the schema changes have replicated and
your GCs have rebuilt before continuing. To help speed this process somewhat, you can run ForestPrep directly on the domain controller (DC) that holds the Schema Master role in your forest. Doing
so ensures that the schema changes are applied quickly and correctly (if you run ForestPrep on

Brought to you by NetIQ and Windows & .NET Magazine eBooks

168

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

another computer, the Schema Master must still be available over the network to accept the schema
changes).
You need to run ForestPrep only once per forest; you need to run a similar process called
DomainPrep once per domain for each domain that will provide Exchange Server 2003 functionality.
DomainPrep sets up some initial user groups and permissions, takes only a few minutes, and does
not affect domain performance or operation. In other words, it’s safe to run DomainPrep almost any
time you want. To do so, simply rerun Exchange Server 2003 Setup and it will default to running
DomainPrep if necessary. You can also run DomainPrep as a separate operation—the same as for
ForestPrep—just substitute the /domainprep command-line switch for the /forestprep command-line
switch (i.e., setup /domainprep). Note that DomainPrep, because it has no production effect, can also
be run during the main Exchange installation process, instead of running it as an individual step.

n Note
During the DomainPrep phase, you might see a message box appear that warns you about
mail-enabled groups that have their distribution list (DL) membership hidden, as Figure 3
shows. Any Active Directory domain that has the built-in local Pre-Windows 2000 Compatible
Access security group is considered an insecure domain because any members of this built-in
group can view the properties of all users and groups within the domain, including hidden DL
membership. To remedy this security vulnerability, simply remove unnecessary members from
the built-in local Pre-Windows 2000 Compatible Access security group.

Figure 3:
Warning message advising you to remove unnecessary members from the Pre-Windows 2000
Compatible Access security group

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

169

With both ForestPrep and DomainPrep out of the way, you can run the Setup routine for Exchange.
You’ll do this on each server that needs to run Exchange. The process is as follows:
1. Run Exchange Server 2003 Setup. Navigate through the usual license agreement dialog boxes
until you come to the main component selection dialog.
2. Select an installation option. The default option, Typical, will display if all Exchange Server 2003
prerequisite components are installed. If Typical is not preselected, select it manually, then Setup
will tell you which components are missing, as Figure 4 shows.

Figure 4:
Showing which Windows Server components need to be installed

3. As Figure 5 shows, you have the option to create a new Exchange organization or to join to an
existing 5.5 organization. Select the appropriate option. For an interorg migration, you’ll always
create a new organization.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

170

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 5:
Choosing an installation type for Exchange Server 2003

4. If you’re creating a new organization, provide its name. Note that the organization name cannot
be easily changed later (in fact, no means of doing so is supported), so make sure you choose a
name that won’t need to change later. The organization name cannot be blank, nor can it contain
any of the following invalid characters:
~ ` ! @ # $ % ^ & * ( ) _ + = { [ ] } | \ : ; “ ‘ < , > . ? /
Setup will run and need several minutes to complete the installation. Setup does not usually
require you to restart your server after Exchange is installed.
When you install subsequent servers into the Exchange organization, you’ll be prompted for the
name of an Administrative Group into which the servers will be placed. Administrative Groups are
a way of organizing individual servers within Exchange, so that administrative permissions can be
more readily assigned to many servers at once. In other words, permissions are assigned at the
Administrative Group level, and all servers within that Group inherit those permissions. Deciding the
selection of an Administrative Group is important because servers cannot be moved out of their
Administrative Group without uninstalling and reinstalling Exchange. Therefore, carefully consider
how your Exchange servers will be managed and how to create the appropriate Administrative Group
structure at the outset. Note that the first server in a new Exchange organization is automatically
installed into a default Administrative Group named First Administrative Group. You can easily
rename this default group to any name that you prefer.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

171

Post-Installation Tasks
Immediately after installation, you should take these steps:
• Sign up for Microsoft’s security bulletins at http://www.microsoft.com/security. Exchange
is a major attack target and thanks to its mission-critical nature, you’ll miss it if it’s down. Security
bulletins can help you quickly get new patches and security updates installed.
• Optimize Exchange’s memory use. On servers with more than 1GB of physical RAM, set the
/3GB switch in the Windows boot.ini file so that Windows’ extended memory support is enabled.
If you don’t configure this setting, then expect to see Event ID 9665 logged to the application
event log. Unfortunately, this special Boot.ini file setting is not supported under Windows 2000
Server, Standard Edition—it is only supported under the Advanced Server and DataCenter
Server editions. Under Windows Server 2003, it is supported for the Standard, Enterprise, and
DataCenter editions. You should also go to registry key HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\MSExchangeIS\ParametersSystem and set the value “Suppress Memory
Configuration Notification” to 1.
• For Windows Server 2003 servers only—configure the /USERVA=3030 switch in
Boot.ini to allow for more system page table entries. For more information on the /3GB
and the /Userva=3030 switches, see the Microsoft Knowledge Base article “XADM: Using
the /Userva Switch on Windows Server 2003-Based Exchange Servers,” at http://www
.support.microsoft.com/?kbid=810371 and “How to Use the /USERVA Switch in the Boot.ini
File to Tune /3GB Configurations,” at http://www.support.microsoft.com/?kbid=316739.
• Use the Internet Mail Wizard to configure at least one Exchange server in your
organization to deliver Internet mail. To do so, open the Exchange System Manager (ESM),
right-click your organization, then select Internet Mail Wizard from the context menu. Select the
server that will serve as the Internet mail gateway and the wizard will configure it. Note that you
can have different servers handling incoming and outgoing email messages, thereby letting you
create a more scalable Internet gateway infrastructure.

Exchange Server Configuration Settings
You’ll want to set up, or at least verify, several configuration options within Exchange before
beginning a migration. Note that an in-place upgrade from Exchange 2000 will preserve your old
configuration settings as much as possible, but that you still need to verify that all settings are
configured the way you want.
Our recommended first step is to configure the ESM to display (which it doesn’t do by default)
routing groups and administrative groups. To modify this configuration, right-click the organization,
then select Properties. As Figure 6 shows, you can force the ESM to display routing groups and
administrative groups.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

172

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 6:
Configuring the ESM to display routing groups and administrative groups

Figure 7 shows the new configuration in the ESM: both routing groups and administrative groups
are displayed in the organization tree. By default, the first Exchange 2003 server is placed within the
First Administrative Group along with any existing Exchange servers that are part of the same
organization. You can drill down into each server displayed within the Servers subnode to view the
mailbox stores and the public folder stores for each storage group. To view routing information, you
can expand the Routing Groups subnode to reveal the Connectors and Members objects.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

173

Figure 7:
Displaying administrative and routing groups in the Administrative Groups node

You might also want to configure message delivery options. To do this, right-click Message
Delivery (under Global Settings in the ESM), then select Properties. Figure 8 shows the Defaults tab,
which lets you configure maximum sizes for incoming and outgoing messages and the maximum
number of recipients per message. You can also use this dialog box to configure sender and recipient
filters, which block messages (on an organization-wide basis) from specific senders or messages sent
to specific recipients.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

174

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 8:
Specifying the maximum messaging limits from the Defaults tab

You can also review the address templates. To do so, expand the Recipients folder in the ESM,
expand the Address Templates folder, then select the appropriate language. A template, which Figure
9 shows, is provided for each address type that Exchange supports. You can modify any of these to
change the address templates for that message type.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

175

Figure 9:
Working with Exchange Server 2003 Address Templates for supported languages

To configure the email addresses created for recipients, expand Recipients, click Recipient
Policies, then double-click the Default Policy in the right-hand pane. The Default Policy defines an
SMTP and X.400 address that is assigned to each user. You can modify this policy: For example, if
your company accepts email messages sent to @mycompany.com as well as @mycomp.com, you can
have the Default Policy generate both SMTP addresses for all recipients. One of them is designated as
the default SMTP address (displayed in bold letters) and is used as the reply-to address when your
users send email messages. Figure 10 shows the Default Policy E-Mail Addresses (Policy) generation
rules with two additional SMTP addresses added by the person responsible for administering this
Exchange organization.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

176

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 10:
Configuring E-Mail Addresses generation rules for Default Policy

When you add or change email addresses to the Default Policy and click OK, a message box
appears asking you if you want to update all corresponding recipient email addresses to match the
new address generation rule settings. Click Yes to update the recipients or click No to cancel the
update for existing recipients and just have the new settings apply to new recipients. The ESM will
prompt you with this same message box for each modification or additional email address that you
specify.
Configuring address lists is another common task. Exchange supports multiple address lists and
comes preconfigured with lists for all Contact objects, all Groups, and all users. To create a new list,
simply right-click All Address Lists, then select New Address List, as Figure 11 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

177

Figure 11:
Creating a new address list in the ESM

You’ll provide a name for the address list and have the option to provide Filter Rules. By default,
all Address Lists contain all users in the directory; by filtering, you can create a list that contains a
subset of your users, such as the users from a particular office or department. Figure 12 shows a filter
configured to display only users with an Exchange mailbox, users with external email addresses,
contacts with external email addresses, and mail-enabled public folders. By selecting the Storage tab
or the Advanced tab on the Find Exchange Recipients dialog box, you can also use more advanced
search criteria to set a filter for a custom address list.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

178

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 12:
Setting search criteria for generating a custom address list

You can configure several additional attributes on a per-server basis, particularly with regard to
stores and storage groups. Remember that a storage group is simply a means of organizing and
managing stores, or databases. By default, new Exchange servers have one storage group, named First
Storage Group, that contains one mailbox store and one public folder store. Every store within the
storage group shares a single transaction log, and as Figure 13 shows, the only properties associated
with the storage group are related to that log—its location and filename—whether or not deleted
pages are zeroed out (or erased in such a way that data reconstruction is impossible) and whether or
not circular logging is enabled. To work with storage groups and messaging databases, expand the
First Administrative Group node in ESM, expand the Servers folder, expand the <server name>
container, then expand the First Storage Group container. You can right-click the First Storage Group
container and select Properties to review and modify its configuration settings.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

179

Figure 13:
Showing the Properties sheet for the default First Storage Group

By default, Exchange transaction logs are never emptied out until a full backup of the associated
databases is made. This behavior ensures that, in the event of a database failure, the transaction log
can be used to replay, or recreate, any database activity that occurred since the most recent backup.
Circular logging causes the log to discard old transactions to make room for new transactions; this
will prevent more than a couple of transaction logs from being created on the server, but will
severely limit your ability to recover data in the event of a database failure. Unless absolutely
necessary because of disk space limitations, you should never enable circular logging.
Another best practice for Exchange Server, as with SQL Server, is to place the transaction log files
on a separate physical disk from the data files. Placing the transaction logs on a different disk (or disk
array) provides another level of fault tolerance for the Exchange system because the transaction logs
will survive a disk failure to the drive that stores the data files and the data files will survive a disk
failure to the drive that stores the transaction logs. By default, the data and the transaction logs are
stored in the same physical location—<drive letter>:\Program Files\Exchsrvr\mdbdata. From the
Properties sheet of a storage group, you can click the Browse button to move the transaction logs for
that storage group to a new local physical location. You can also click the Browse button for the
System Path Location box to move the Exchange data files to a new local physical location for that

Brought to you by NetIQ and Windows & .NET Magazine eBooks

180

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

storage group. Both transaction log location and system path location refer to a folder on a drive
letter; all the log files and data files for a particular storage group are stored within the specified
folder locations for that storage group.
Many options are available for each store. Figure 14 shows the Database tab of the Properties
sheet for the default user mailbox database, named Mailbox Store. Here, you can see the physical
location of the database file. Note that each database consists of two files: A basic Exchange database
file and a secondary database for streaming data, such as video (.avi) files sent as attachments. You
can specify the automated maintenance period for the database, and you can see when it was last
backed up. From Mailbox Store Properties you can also configure the database to be overwritten by a
copy that you’re restoring from a backup.

Figure 14:
Configuring the Database settings on the default Mailbox Store Properties sheet

Restoring directly over a database is not necessary. In fact, if you need to restore only one
mailbox, then restoring the entire database would be a bad idea because every user whose mailbox
resides in that database would be offline during the process. Instead, Exchange lets you create a
special storage group called a Recovery Storage Group. You can restore any database to this special
group, which then enables you to export single mailboxes to a personal store (.pst) file for recovery.
Message stores can also specify storage quotas or limits for users, which Figure 15 shows. To override
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

181

these values on a per-user basis, modify the user’s account profile in Active Directory. You can also
specify deleted item retention on a per-store basis.

Figure 15:
Displaying the Limits settings on the default Mailbox Store Properties sheet

The default public store name is listed on the General tab of a mailbox store’s Properties sheet.
However, to work with configuration settings for the default Public Folder Store, right-click the Public
Folder Store container found within the First Storage Group container, then select Properties. The
properties that you can configure are similar to the properties for a mailbox store. However, a public
folder store has one additional tab called Replication that lets you configure the replication interval
and replication message size limit for synchronizing public folder replicas. Public folder replicas add
fault tolerance and load balancing features to an Exchange Server 2003-based organization that relies
on data stored in public folders. Public folders are very useful for things like department-wide or
company-wide shared calendars, shared contacts, and shared message postings (similar to a public
bulletin board).
To add one or more replicas for a given public folder, you can expand the administrative group
in which the public folder resides and expand the Folders node. Next, expand the Public Folders
container, right-click the public folder for which you want to add or remove a replica, and click
Properties. Select the Replication tab to work with replication settings, as Figure 16 shows. Obviously,
Brought to you by NetIQ and Windows & .NET Magazine eBooks

182

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

the server on which a public folder has been created initially stores the first and only replica. To add
a replica for the public folder to additional Exchange servers, click the Add button. To remove a
replica from a server, select the replica and click Remove.

Figure 16:
Selecting the Replication tab on a public folder’s Properties sheet

You might want to set up and use routing groups to manage the flow of message traffic between
Exchange servers in different physical locations or sites. The planning, design, and implementation of
routing groups is beyond the scope of this chapter, but you can learn more about them from the
Exchange server documentation or from the planning documentation available from the Microsoft
Exchange Web site at http://www.microsoft.com/exchange.

Migrating from Exchange 5.5 to Exchange 2003
Exchange Server 2003 will not run under Windows NT Server 4.0; therefore you cannot perform a
direct in-place upgrade from Exchange 5.5 to Exchange 2003. In theory, you could first upgrade the
OS to Windows 2000 Server SP3 or later. Then you could upgrade Exchange Server 5.5 to Exchange
2000 Server. After that, you could upgrade Exchange 2000 Server to Exchange Server 2003. Finally,
you could upgrade from the OS from Windows 2000 Server SP3 or later to Windows Server 2003. In
reality, however, you are most likely not going to want to run Windows Server 2003 or Exchange
Server 2003 on old hardware designed for Windows NT 4.0. In most cases, you will want to migrate
from old Exchange 5.5 servers to new Exchange 2003 servers.
Microsoft documents several different methods that you can use to successfully migrate from
Exchange 5.5 to Exchange 2003. Each method has its advantages and disadvantages. The method you
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

183

choose depends on the complexity of your network—the number of domains, DCs, Exchange 5.5
sites, and Exchange 5.5 servers involved. Each Exchange 5.5 server that you want to migrate needs to
have at least Exchange 5.5 SP3 installed; Exchange 5.5 SP4 is even better.
For small environments, a fairly straightforward method is to install a new Windows NT 4.0
Backup Domain Controller (BDC), take it offline as a precautionary backup procedure, then upgrade
the Primary Domain Controller (PDC) to Windows Server 2003. Then you can run the DCPROMO
wizard to make the upgraded Windows NT 4.0 PDC into an Active Directory DC so that the
Windows NT 4.0 user accounts and groups are brought into Active Directory. From that point, you
can use the ADC to import users’ mailboxes and other messaging data into Exchange Server 2003
from Exchange Server 5.5. The ADC also enables synchronization between the Exchange 5.5 directory
and Active Directory.
Another method you can use is to take advantage of the ADC to import domain user accounts,
groups, mailboxes, DLs, and other messaging objects into Active Directory from Windows NT Server
4.0 and Exchange Server 5.5. The balance of this section takes you through the major steps of using
the ADC to migrate users and their mailboxes from Windows NT Server 4.0 and Exchange Server 5.5
to Windows Server 2003 and Exchange Server 2003. At the end of this section, you’ll see how easy a
migration can be when you use the Microsoft Exchange Server Migration Wizard.
Fortunately, the Exchange Server Deployment Tools Help files offer you a detailed step-by-step
outline for migrating from Exchange 5.5 and coexisting with Exchange 2003. When you click
Exchange Deployment Tools on the Welcome To Exchange Server 2003 Setup dialog box, click
Deploy the first Exchange 2003 server, then click Coexistence with Exchange 5.5. The first two steps
involve verifying that you have a server in place that is ready for Exchange 2003 as we’ve discussed
throughout this chapter. The Exchange Server 2003 Deployment Tools break down the necessary
steps for installing Exchange 2003 for coexistence with Exchange 5.5 into three phases: Planning,
Prepare Active Directory, and Installing Exchange Server 2003 on the Initial Server.

Phase One: Planning
In step three of the Exchange 5.5 Coexistence Prerequisites for the Exchange Server Deployment
Tools, type in the name of the Exchange 5.5 server and the Active Directory GC server, then click
Run DSScopeScan now. Review the log files that are written by default to the C:\ExDeploy Logs
folder. This utility generates seven log files. You must manually review each log to determine if you
need to make any configuration changes to the Exchange 5.5 environment to insure a smooth
migration to Exchange 2003.
Next, you need to install the Windows Server Support Tools which are found on the Windows
2000 Server CD-ROM and on the Windows Server 2003 CD-ROM. Install the version that corresponds
to the OS on top of which you will be installing Exchange 2003. Next, run the Dcdiag.exe commandline utility on the server that will run Exchange 2003. This tool examines network connectivity and
proper DNS name resolution for Active Directory. The results from running this utility will display on
the screen; you must manually fix any problems discovered by the Dcdiag.exe utility.
After you have run Dcdiag.exe and made any necessary corrections to network settings or DNS
settings, you need to run the command-line tool Netdiag.exe to test for proper DNS and network
functionality. The results from running this utility will display on the screen; you must manually fix
any problems discovered by the Netdiag.exe utility.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

184

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Phase Two: Prepare Active Directory
In phase two of the Deployment Tools for installing Exchange Server 2003 for coexistence with
Exchange 5.5, you need to run the first two installation steps for the first Exchange 2003 server—
ForestPrep and DomainPrep—just as we describe earlier in this chapter. After you have successfully
run these two installation steps, you need to run the OrgPrepCheck tool to verify that all the required
Active Directory schema extensions, security descriptors, and DC permissions settings were properly
applied by the ForestPrep and DomainPrep installation options of the Exchange 2003 Setup program.
Review the exdeploy-polcheck.log file and the ExDeploy.log file in the default C:\ExDeploy Logs
folder, which Figure 17 shows, and remedy any problems listed in these files.

Figure 17:
Reviewing the ExDeploy.log file after running the OrgPrepCheck tool

Steps five and six of the Exchange Server 2003 Deployment Tools for coexistence with Exchange 5.5
involve installing and running the ADC. The ADC lets you set up connection agreements between
Active Directory and the Exchange Server 5.5 directory service. The ADC supports coexistence
between Exchange 5.5 and Exchange 2003 for as long as you might need both messaging systems to
run simultaneously. To install the ADC from the Exchange Server 2003 CD-ROM in the \ADC\I386
folder, double-click Setup.exe. Install both the Connector and the ADC Tools. Now to launch the
ADC Services console and run the ADC, right-click the Active Directory Connector icon in the
left-hand pane, point to New, and select Recipient Connection Agreement. On the General tab of the
Properties sheet that appears, type a name for this connection agreement, such as “From Exchange
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

185

5.5 To Active Directory”. Choose the Replication Direction: Two-way, From Exchange to Windows,
or From Windows to Exchange. To maintain coexistence between Exchange Server 2003 (Active
Directory) and Exchange Server 5.5, select the Two-way option, but you’ll have to make sure that the
Exchange 5.5 organization is configured with the necessary permissions for interfacing with Active
Directory. To export user mailboxes from Exchange 5.5 into Active Directory, select the From
Exchange to Windows option.
Click the Connections tab, as Figure 18 shows, to specify the required Connect as information.
Click the Schedule tab, then select the Replicate the entire directory the next time the agreement is run
checkbox. Click the From Exchange tab to specify from which Exchange 5.5 containers to export user
accounts. Select the default container (or organizational unit—OU) into which the user accounts will
be imported within Active Directory. Choose which object types that you want imported (replicated)
into Active Directory, such as custom recipients, mailboxes, and DLs.

Figure 18:
Specifying Connection Agreement information from the Connections tab

Click the Advanced tab and select the This is an Inter-Organizational Connection Agreement
checkbox, only when you will be creating a brand new Exchange organization and not installing
Exchange Server 2003 as part of an existing Exchange 5.5 organization. Click OK when you have
completed filling in all the required information for the connection agreement. Then you should
receive a message box that resembles Figure 19. After a connection agreement has been created, you

Brought to you by NetIQ and Windows & .NET Magazine eBooks

186

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

can right-click the connection agreement object in the right-hand pane of the ADC Services console
and select Replicate Now to manually initiate the synchronization process.

Figure 19:
Receiving a message confirming the first connection agreement’s creation

Instead of using the ADC as we’ve just outlined, you can use the ADC Tools from the ADC
Services console and walk through steps one through four to set up and verify a new connection
agreement between Active Directory and Exchange 5.5. Step four of the ADC Tools lets you verify
the results of the connection agreement. In the Active Directory Users and Computers console, also
be sure to visually verify that the users are replicated from the Exchange Server 5.5 directory.

Phase Three: Installing Exchange Server 2003 on the Initial Server
The initial step for phase three is to run the SetupPrep utility to ensure that DNS is functioning
properly, to check which versions of Exchange are running on other servers (if any), and to validate
the conversion of public folder permissions to Active Directory access control lists (ACLs). Review
the results at the end of the ExDeploy.log file and in the orgnamecheck.log file stored in the
C:\ExDeploy Logs folder and make any necessary changes on the network, on the Exchange 5.5
server, or on the designated Exchange 2003 server.
You can perform an IntraOrg migration by installing the first Exchange 2003 server within the
same site as an existing Exchange 5.5 server. Run the Setup program and select the Join or upgrade

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

187

an existing Exchange 5.5 Organization option, as Figure 20 shows, and then click Next. Type in the
name of the Exchange 5.5 server and complete the balance of the Setup program.
After the installation has been successfully completed, modify the settings on the connection
agreements to point to the server running Exchange 2003, if this server is not the same server as
the one initially used as the Active Directory DC. The final step is to run the ADCConfigCheck,
ConfigDSInteg, ReceipientDSInteg, and PrivFoldCheck utilities to validate the Exchange 2003
installation. The user account that runs these tools must be a member of the Domain Admins group
in Active Directory and must have permission to at least view objects in the Exchange 5.5 directory.

Figure 20:
Joining an existing Exchange Server 5.5 Organization

The Easier Road: Exchange Server Migration Wizard
An easier way to perform a migration from Exchange 5.5 to Exchange 2003 is to simply install
Exchange 2003 and the use the Migration Wizard. In our recent experience, the updated Exchange
2003 SP1 edition of the Migration Wizard seems to work better than the original version. Although the
Exchange Server 2003 Migration Wizard is not a full-featured migration tool, it can do the basic task
of importing user accounts and mailboxes from Exchange 5.5 to Exchange 2003 and Active Directory.
Before using the Migration Wizard, you should consider using the Active Directory Migration Tool
(ADMT) 2.0. You can download the ADMT from the Microsoft Web site at http://www.microsoft.com
/downloads/details.aspx?FamilyID=788975b1-5849-4707-9817-8c9773c25c6c&DisplayLang=en. After
using the ADMT to import user accounts, groups, and other objects from a Windows NT Server 4.0
domain to Active Directory, you can use the Exchange Server 2003 Migration Wizard to transfer the
Exchange 5.5 user mailboxes and match them up with the new Active Directory user accounts.
On an Exchange 2003 server, click Start, Programs, Microsoft Exchange, Deployment, and then
Migration Wizard to launch this tool. Click Next at the Welcome window, then select the type of
migration you want to perform—in this case, choose Migrate from Microsoft Exchange and click Next.
Verify that the Lightweight Directory Access Protocol (LDAP) is active, then click Next again. From the
Migration Destination dialog box, which Figure 21 shows, choose the Exchange 2003 server and the
Information Store that will import the Exchange 5.5 mailboxes and click Next. You can migrate to .pst
files instead of first migrating directly to an Information Store, if you want.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

188

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 21:
Using the Migration Wizard to select the migration destination

On the Source Exchange Server dialog box, verify that the Exchange 5.5 server checkbox is
selected. Type in the Exchange 5.5 server name, administrator user account name, and password,
then click Next again. On the Migration Information dialog box, you can filter the messages that the
Migration Wizard will transfer to Exchange 2003. Click Next after specifying any message filter
settings. On the Account Migration dialog box, select the user accounts that you want migrated, as
Figure 22 shows, and click Next. Specify into which Active Directory container you want to place the
migrated user accounts at the Container For New Windows Accounts dialog box. Click the Options
button to specify how to generate user passwords, to select a template object for nonpersonal
attributes (selecting an existing Active Directory user account to use as a template for the new
migrated user accounts), and to create new accounts as InetOrgPerson account types. Click OK to
close the Account Options dialog box and click Next to continue.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

189

Figure 22:
Selecting user accounts to migrate to Exchange 2003

Review the list of user accounts to be migrated from the Exchange 5.5 directory to Active
Directory and Exchange 2003, as Figure 23 shows. Right-click an account and select Edit to modify
the new Windows account information or right-click an account and select Match to assign the
account to an existing Active Directory user account. Click Next to start the migration process and
click Finish when it is complete.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

190

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 23:
Reviewing Exchange 5.5 user accounts to migrate to Exchange 2003 and Active Directory

Any errors that occur during the migration process are logged to the Application Log in the Event
Viewer. Each new Active Directory user account that is migrated from Exchange 5.5 is disabled by
default. You can select individual accounts (some accounts or all accounts), right-click, and choose
Enable Account to make the user accounts active. In addition to enabling the migrated user accounts
in Active Directory, you also need to clean up the Pre-Windows 2000 Logon Name for each user. The
Migration Wizard assigns a random set of letters (using the prefix MIGWIZ_) as the logon name for
each user account. So, a migrated account for a user named Alison Jones would be assigned a
random logon name similar to MIGWIZ_GMBGTWQHFYLKU—not exactly a user-friendly logon
name. You will probably want to change these hard-to-remember logon names.

SP1 for Exchange Server 2003
In May 2004, Microsoft released SP1 for Exchange Server 2003. SP1 is more than just a smattering
of bug fixes. SP1 introduces some new product functionality. One big improvement in SP1 is the
capability to move users’ mailboxes between Exchange Server 5.5 sites and Exchange Server 2003
(or Exchange 2000 Server) administrative groups in a mixed-mode Exchange organization. This new
functionality lets you update the home site name for Exchange 5.5 mailboxes when user mailboxes
are moved across sites. The following five new or updated components are responsible for providing
support for cross-site mailbox moves:

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

191

• The Exchange Server 2003 Deployment Tools (ExDeploy) package has been updated and
enhanced with new instructions for cross-site mailbox migrations under mixed mode Exchange.
This guide now offers references to new and improved tools and documentation.
• The ADC in SP1 has been updated. This utility now supports synchronization for Exchange 5.5
mailboxes that have been moved to Exchange 2003 servers.
• The ESM Move Mailbox utility now supports cross-site mailbox moves.
• The Object Rehome tool, also called the LegacyDN tool, updates a mailbox’s legacyExchangeDN property for DLs and custom recipients. This means that if you move Dan’s
mailbox homed on an Exchange 5.5 server from site three to site four, any DLs stored in site
three with references to Dan’s mailbox will no longer be able to route messages to Dan. The
Rehome Object utility now has the ability to update those DLs with the new routing information
for Dan’s mailbox.
• The Exchange Profile Redirector tool, also called the Exchange Profile Update tool,
updates Microsoft Outlook profiles when mailboxes are moved into a different administrative
group. Outlook profiles are updated automatically when mailboxes are moved between servers
within the same administrative group. However, the Messaging API (MAPI) referral mechanism
does not work when mailboxes are moved across administrative group boundaries. Users need to
run this utility just one time on their workstations to update their Outlook profile so that it points
to their mailbox on the correct server.
You can download SP1 for Exchange 2003 from the Microsoft Web site at http://www.microsoft
.com/exchange/downloads/2003/sp1.asp. You can read about and download many utilities from
Microsoft for Exchange Server 2003 from the Microsoft Web site at http://www.microsoft.com
/exchange/downloads/2003.asp. Be sure to read through the release notes found in the
ReleaseNotes.htm file that you download with SP1. Also, be sure to completely backup all of your
Exchange 2003 servers before and after you perform the upgrade to SP1. If your organization’s mobile
users depend on Exchange ActiveSync for synchronizing data and you are running Exchange 2003
under Windows 2000 Server SP3, you must install Windows 2000 SP4 or later so that Exchange
ActiveSync will continue to function properly. You can install SP1 for Exchange 2003 without
installing SP4 or later for Windows 2000 Server, but Exchange ActiveSync will no longer work.
Finally, Microsoft recommends that you upgrade all front-end servers that are set up within the
same load-balanced configuration at roughly the same time. Obviously, you probably can’t upgrade
all of them at exactly the same time, but you should make a concerted effort to upgrade them
within a fairly narrow timeframe to minimize “receive sync key” errors for mobile clients. These
errors occur when mobile client requests are redirected from front-end servers running Exchange
2003 SP1 to front-end servers that have not been upgraded to SP1 (e.g., servers running the release to
manufacturing—RTM—version).
To install SP1, as previously mentioned, completely backup each server that you will upgrade
both before and after installing the service pack. After you have downloaded SP1 from the Microsoft
Web site, you can run the E3SP1ENG.exe (the English language version) program to extract the
compressed SP1 files to a local or network location. If you have the SP1 CD-ROM, you can run the
Update.exe program to launch the setup program directly. After you extract the compressed files from
the SP1 download file, navigate to the folder where you placed the SP1 setup files. Open the
Brought to you by NetIQ and Windows & .NET Magazine eBooks

192

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

E3SP1ENG folder created during the extraction process, next open the SETUP folder, then open the
I386 folder. Double-click the Update.exe program file to begin the upgrade.
Click Next for the Welcome page, click I agree on the License Agreement page, and click Next
again. Amazingly, you might see an error message appear at the Component Selection dialog box for
the Microsoft Exchange Installation Wizard for SP1, which Figure 24 shows. The Microsoft Knowledge
Base article number 831464 at http://support.microsoft.com/?kbid=831464 states that if you receive
this error message during SP1 Setup, you must install a patch (hotfix) to enable GNU zip (Gzip)
compression under Windows Server 2003 for the ESM. You can download the patch from the
Microsoft Web site at http://www.microsoft.com/downloads/details.aspx?familyid=0BC9B5BCA094-49BF-89A5-C8A2D32345A2&displaylang=en. Install the patch, restart the server, then run the
SP1 Setup program again.

Figure 24:
Receiving a message that you need to install a patch before you can install SP1

After you have applied the patch to your server, if necessary, the Component Selection dialog
box for the SP1 Installation Wizard should look like Figure 25. Click Next to review your installation
choices, then click Next again to start the upgrade installation.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 7 Installing Exchange Server 2003

193

Figure 25:
Viewing the Component Selection dialog box for updating Exchange 2003 to SP1

After the SP1 installation has completed, you need to verify that the Exchange 2003 server has
been updated to SP1. Open the ESM and click Help, About Exchange System… from the menu bar.
The version number should be 6.5.7226.0, as Figure 26 shows, when SP1 has been properly installed,
instead of the RTM release number: 6.5.6944.0.

Figure 26:
Verifying the ESM SP1 version from the About Exchange System message box

Brought to you by NetIQ and Windows & .NET Magazine eBooks

194

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

The Grand Finale
As this chapter describes, you have important preinstallation decisions to make before performing the
Exchange Server 2003 installation. Having carefully outlined these considerations, you can move on to
the installation and post-installation tasks. Upon successfully completing the installation and upgrading
to the latest available service pack, you can then configure Exchange to meet the needs of your
organization.
In the next and final chapter of this eBook we will examine how to manage Exchange Server
2003. We will look at administering Exchange, employing Outlook Web Access (OWA), implementing
security, and avoiding unsolicited commercial email (UCE). At that point, you’ll be ready to migrate to
Windows Server 2003 and deploy Exchange Server 2003 with confidence.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

195

Chapter 8

Managing Exchange Server 2003
In Chapter 7, we revealed the many steps that you need to go through to properly install and
configure an Exchange 2003 server and an Exchange 2003 messaging environment. We looked at
performing upgrades and migrations from earlier versions of Exchange Server and looked at several
important post-installation steps that you should take to set up each Exchange 2003 server for optimal
performance. As a bonus, we discussed the enhancements and useful new features available when
you install Service Pack 1 (SP1) for Exchange Server 2003.
In this final chapter, we examine important day-to-day administration concerns that can help
keep your Exchange 2003 messaging infrastructure up and running and minimize potential downtime.
We also discuss how to set up Outlook Web Access (OWA), how to implement important security
measures, and how to fight the battle against the ever-increasing barrage of unsolicited commercial
email (UCE), also known as spam.

Common Administrative Chores
Much of your day-to-day management of Exchange will take place in the Active Directory Users and
Computers Microsoft Management Console (MMC) snap-in because you conduct all Exchange
management of users (aka email recipients) within Active Directory. For example, you can mailenable all users, groups, and contact objects within Active Directory, meaning you can configure
them to receive email messages. This is different from being mailbox-enabled, which associates an
Exchange mailbox with a user account; for example, mail-enabled contacts simply accept email
messages and redirect those messages to another email address. Suppose you’ve created a contact
object in Active Directory that represents an external vendor who works with your company. This
contact object, as Figure 1 shows, can include an email address and other contact information,
providing a useful reference for your company’s users.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

196

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 1:
Examining Exchange Server contact information in Active Directory Users and Computers

Mail-enabling a contact adds messaging functionality. To mail-enable the contact, right-click it in
the Active Directory Users and Computers console, select Exchange Tasks, then select Establish E-mail
Address from the list of available tasks. As Figure 2 shows, you’ll provide an alias for the contact and
an external email address. This external email address should be the actual address where this contact
receives email messages.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

197

Figure 2:
Mail-enabling a contact in Active Directory Users and Computers

This mail-enabled contact can now receive email messages at [email protected]
(i.e., the company’s Internet email domain for Exchange Server) and that email will be redirected, or
forwarded, to the vendor’s outside email address at [email protected]. You can mail-enable
both users and groups.
You follow a similar set of steps to Mailbox-enable a user; you need to select Create Mailbox on
the list of available Exchange tasks. As Figure 3 shows, you also must specify the server on which the
mailbox will be created and the mailbox store where the mailbox will reside.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

198

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 3:
Mailbox-enabling a user in Active Directory Users and Computers

Mailbox-enabled users have several additional tabs available in their Properties sheet within
Active Directory Users and Computers. As Figure 4 shows, you can enable or disable specific
Exchange features, such as access to Outlook Mobile Access (OMA), OWA, POP3, and IMAP4. You
can also modify users’ email addresses on the E-mail Addresses tab.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

199

Figure 4:
Configuring Exchange Server features from a user’s Properties sheet

On the Exchange General tab, you can modify a user’s delivery restrictions, as Figure 5 shows.
You have the option here of modifying the delivery restrictions from the default settings for the
Exchange organization, thereby overriding the organizational settings. You can also change the user’s
storage limits, as Figure 6 shows, which also overrides the default settings established for the mailbox
store where the user’s mailbox is hosted.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

200

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 5:
Specifying override settings for an individual user’s Delivery Restrictions

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

201

Figure 6:
Specifying override settings for an individual user’s Storage Limits

The management of individual Exchange servers, or managing the entire Exchange organization,
is accomplished within the Exchange System Manager (ESM) console, not the Active Directory Users
and Computers console, and typically consists of monitoring and troubleshooting tasks.

Monitoring and Troubleshooting
Both Windows 2000 Server and Windows Server 2003 provide the Performance snap-in for
monitoring a server’s vital signs. Within the Performance snap-in you’ll find the System Monitor tool.
The System Monitor provides built-in status monitoring for each Exchange server in your organization,
which is useful. Although not as full-featured as other monitoring and notification software (such as
the Microsoft Operations Manager—MOM), the basic status monitoring that System Monitor provides
is useful and can be customized to fit your needs. For example, as Figure 7 shows, you can configure
a server with multiple monitoring metrics, such as the status of a particular service or CPU utilization.
These monitors define the conditions under which the server’s status will be considered Available,
Warning, or Critical. In Figure 7, the server will enter a Critical state if the CPU percentage exceeds
100 percent for 5 minutes or if the default Exchange services are stopped.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

202

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 7:
Configuring Performance Monitoring Metrics in the ESM

Any server or service that enters the Warning or Critical state will generate a notification—a
message signaling a problem. In addition to monitoring individual Exchange servers, you can also
have status monitors for things like the Internet Mail SMTP Connector. You can use the ESM (under
Tools, Monitoring and Status, Notifications) to define how notifications are treated. By configuring
an email notification (which Figure 8 shows), you can receive an email message when a problem
occurs. You can also create script notifications, which execute a specified command-line executable
whenever a monitored item enters either the Warning or Critical state.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

203

Figure 8:
Configuring email notification parameters for monitoring Exchange server

For troubleshooting, the ESM provides the Message Tracking Center. The Message Tracking
Center lets you follow a particular message through the delivery process so that you can see exactly
how Exchange deals with it. This understanding can be invaluable in troubleshooting various
problems. You must first enable message tracking on a per-server basis, as Figure 9 shows. In the
ESM, you’ll find the Enable Message Tracking checkbox on the General tab of an Exchange server’s
Properties sheet. Don’t leave message tracking enabled for longer than necessary, as it can place a
significant additional burden on the server.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

204

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 9:
Turning on Message Tracking for an Exchange server

After message tracking is turned on, you can use the Message Tracking Center to search for
messages and view their tracking status within the server. As Figure 10 shows, the Message Tracking
Center lets you enter search criteria for messages, such as the sender or recipient names and the
approximate time and date that the message was sent.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

205

Figure 10:
Specifying search criteria in the Message Tracking Center

From the list of matching messages, you can double-click each message to view its status, which
Figure 11 shows. Each step of the message routing and delivery operation is listed, helping you to
determine exactly where a message is in the process. In Figure 11, a message destined for an external
recipient has been queued for delivery, but not yet delivered.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

206

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 11:
Viewing Message History in the Message Tracking Center

You can also directly monitor the queues on each server. In the ESM, expand the administrative
group in which the server that you want to monitor is located. Next, expand the Servers folder,
expand the container icon for the server, then click the Queues object to display the various message
queues for that server in the right-hand pane. For example, Figure 12 shows the Internet Mail SMTP
Connector queue with that single outgoing message ready for delivery. The message hasn’t yet been
delivered, which might indicate a problem with the connector, with SMTP connectivity to the Internet,
or even a DNS name resolution problem. The status message at the bottom of the window—The
remote server did not respond to the connection attempt—provides a good clue that the problem is
likely that the recipient’s email server is unavailable or can’t be reached.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

207

Figure 12:
Monitoring message queues on an individual Exchange server

Outlook Web Access
OWA is managed almost entirely from within the Internet Information Services (IIS) Manager, not
the ESM. As Figure 13 shows, the properties for the Exchange virtual root, under IIS’ Default Web
Site, points to the Exchange store (BackOfficeStorage) as its default path. To configure OWA to
require Secure Sockets Layer (SSL) connections or to modify the ports OWA uses, simply modify the
properties of the Default Web Site within IIS. SSL uses port 443 by default instead of port 80, which
is the default port for unsecured HTTP Web connections.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

208

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 13:
Modifying OWA settings in the IIS Manager console

Figure 14 shows practically the only OWA property that you need to manage within the ESM,
and you access it as a property of the Exchange Virtual Server from within System Manager (under
the HTTP section of the Protocols folder within each server running OWA). This property enables
forms-based authentication, letting users log on to OWA from a Web page, rather than a pop-up
authentication dialog box.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

Figure 14:
Enabling forms-based authentication for OWA in the ESM

OWA for Exchange Server 2003 is otherwise almost entirely self-configured and, as Figure 15
shows, provides a user experience remarkably similar to Outlook 2003.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

209

210

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 15:
An example of OWA displayed within Microsoft Internet Explorer (IE)

Implementing Security
Other than implementing strict relay restrictions to ensure your server isn’t used as a base for
spammers, Exchange lets you configure granular security permissions for nearly every object in
System Manager. Most commonly, you’ll delegate control over entire Administrative Groups, allowing
other administrators to perform specific administrative tasks on the servers and mailboxes in those
groups. To do so, simply right-click the Administrative Group in question and select Delegate control
from the context menu.
Start by selecting the users or groups that you want to delegate control to. Following best
practices, you should try to always delegate permissions to groups, rather than to users, then place
the appropriate users within the groups. You can delegate three basic types of permissions:
• Exchange View Only Administrator: This permission lets the delegated group view Exchange
configuration information.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

211

• Exchange Administrator: This permission lets the delegated group modify only Exchange system
information (and not individual mailboxes).
• Exchange Full Administrator: This permission lets the delegated group do anything.
Figure 16 shows a sample delegation, with two different users being granted two different types
of permissions: Exchange Full Administrator for the Administrator and Exchange Administrator for
sallys. Note that the built-in Administrator account is given Exchange Full Administrator permission by
default at the organization level and the Administrative Group to which control is being delegated
inherits that permission. You can also delegate control at the organization level.

Figure 16:
Delegating control to users and groups at the Administrative Group level

As Figure 17 shows, security can also be applied individually to servers and many other objects
within an Exchange Server messaging infrastructure. Exchange Server security permissions work in
very much the same way as NTFS or Active Directory security permissions, but of course, the permissions that apply to Exchange are somewhat different than the permissions that apply to NTFS drives
or to Active Directory objects. However, managing security on a per-server or per-object basis can be
time-consuming, tedious, and confusing—you need to check many levels when problems occur or
whenever security permissions need to be changed.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

212

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

As a rule, try to delegate permissions at the organization or Administrative Group level,
whichever is appropriate, to minimize security maintenance overhead. Troubleshooting is much easier
when permissions have been delegated; trying to diagnose security permissions problems when many
settings have been configured individually can be likened to looking for a needle in a haystack.

Figure 17:
Configuring Exchange Server security permissions for a specific server

Avoiding Spam
When Exchange Server 2003 was first released, it had rather primitive built-in features for dealing with
spam; although Outlook 2003 has a fairly robust, Bayesian spam filter, that filtering occurs entirely
client-side. For the release to manufacturing (RTM) version of Exchange 2003, its primary antispam
capability comes in the form of Realtime Block Lists or Realtime Blackhole Lists (RBLs). You configure
RBLs on the Connection Filters tab of the Message Delivery Properties dialog, under Global Settings
in Exchange System Manager. Figure 18 shows an RBL configured to use a public RBL service, which
provides an updated list of known spam relays. Exchange will simply drop any incoming connections
from these relays, unless you provide an exception list on the dialog box. Exceptions will always be
allowed to connect to deliver mail.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

213

Figure 18:
Viewing the Connection Filtering tab for configuring RBL settings and exceptions

You should seriously consider adding a third-party mail-filtering service to your Exchange
servers. These services work by scanning the content of incoming mail and assigning a score, which
represents the likelihood that the message is spam. Some products automatically move messages to
users’ Junk Email folder so that users can manually review spam to check for false positives (i.e.,
blocked legitimate email messages); other products require an administrator to scan through blocked
messages for false positives.
You’ll want to ensure that your Exchange servers don’t become a potential source of spam sent
from unauthorized users. The best way to accomplish this is to configure relay restrictions, which
prevent unauthenticated users from using your server to send email messages. You configure these
restrictions on a per-server basis. Open the Protocols folder in the ESM, select Protocols, then select
SMTP. Modify the properties of the Default SMTP Virtual Server and select the Access tab. Click the
Relay button to modify relay restrictions. The defaults, which Figure 19 shows, are fairly secure:
Messages cannot be relayed from any computer, unless its user has authenticated to Exchange.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

214

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Figure 19:
Setting relay restrictions for the Default SMTP Virtual Server in the ESM

Relaying is the act of delivering a message not intended for a local recipient. So, accepting
incoming email messages for your users is not considered relaying because they are local to the
Exchange organization (meaning they have mailboxes in the organization). Relaying is accepting
email messages for nonlocal users, then redelivering those email messages to those users; it is how
most spammers do their dirty work. Relaying helps spammers cover their tracks and makes it seem as
if their spam is coming from your network. Your users need the ability to relay, because they will be
asking your Exchange server to deliver email messages to nonlocal users; that’s the very essence of
sending email messages, after all.
On May 26, 2004, Microsoft released the Intelligent Message Filter for Exchange Server 2003. The
Intelligent Message Filter uses a new technology called SmartScreen developed by Microsoft Research.
SmartScreen technology is a patented computer-based learning algorithm that can distinguish between
the characteristics of legitimate email messages and UCE. By analyzing thousands, if not millions, of
email messages sent to Microsoft employees and to some of Microsoft’s joint development program
customers, Microsoft developed this innovative technology. Microsoft embedded preliminary releases
of SmartScreen technology in MSN 8, Microsoft Hotmail, and Microsoft Office Outlook 2003, but its
first major starring role is as the engine for the Intelligent Message Filter.
The Intelligent Message Filter is designed to detect spam messages as they arrive at Exchange
2003 SMTP connectors. Unfortunately, you cannot install the Intelligent Message Filter in a clustered
Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

215

Exchange 2003 environment or on versions of Exchange Server earlier than Exchange 2003. However,
Microsoft does support deploying the Intelligent Message Filter on Exchange 2003 servers that act as
gateways to protect Exchange 2000 or Exchange 5.5 servers. However, this type of configuration
cannot take full advantage of all the Intelligent Message Filter’s features. To obtain the Intelligent
Message Filter, you must download it from Microsoft’s Web site and install it as an add-on to
Exchange 2003.
To download a copy of the ExchangeIMF.msi file (about 9MB), go to http://www.microsoft.com
/exchange/downloads/2003/imf/default.asp. Double-click the MSI file to launch the installation
routine—the setup program is very straightforward. Be sure to install the Intelligent Message Filter
during nonproduction hours because IIS and Exchange services are stopped then restarted during the
installation. Naturally, you need to first install the Intelligent Message Filter in a test environment to
determine its usefulness and its drawbacks for your particular organization.
After you successfully install the Intelligent Message Filter, you’ll notice that a new component
has been installed under the Exchange server’s SMTP folder in the ESM. Expand the administrative
group for the server in which the Intelligent Message Filter is installed, expand the Servers folder,
expand the Protocols folder, then expand the SMTP folder. You’ll see the new Intelligent Message
Filtering component listed beneath the Default SMTP Virtual Server object. To enable the Intelligent
Message Filter, right-click the Intelligent Message Filtering icon, then select Properties. By default, the
Intelligent Message Filter is turned off. Mark the checkbox for each appropriate SMTP Virtual Server
and click OK to turn on Intelligent Message Filtering, which Figure 20 shows.

Figure 20:
Enabling Intelligent Message Filtering for the Default SMTP Virtual Server

Brought to you by NetIQ and Windows & .NET Magazine eBooks

216

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

After you have turned on Intelligent Message Filtering, you need to configure the preliminary
threshold tolerances for your organization for both Gateway Blocking and Junk E-mail settings. The
Intelligent Message Filter assigns a Spam Confidence Level (SCL) number between 1 and 9 to each
message that passes through each SMTP Connector on which the Intelligent Message Filter has been
enabled. For example, an email message that is assigned an SCL rating of 1 is almost guaranteed to
be a legitimate message. Conversely, an email that is assigned a rating of 5 or greater is virtually
certain to be a UCE message—spam. In establishing the Intelligent Message Filter thresholds for your
Exchange 2003 organization, keep in mind that if you specify a lower setting for the Gateway
Blocking Configuration, the Intelligent Message Filter will block more potential spam messages, but
you also increase the likelihood of blocking legitimate email messages.
To configure SCL threshold settings in the ESM expand the Global Settings folder, right-click the
Message Delivery object, and select Properties. The Intelligent Message Filter adds a new tab to the
Properties sheet called Intelligent Message Filtering, which Figure 21 shows. From the Intelligent
Message Filtering tab, specify the Gateway Blocking Configuration number and an action for blocking
messages for those messages that are assigned a rating equal-to or greater-than the specified setting:
No Action, Reject, Archive, or Delete. Remember that these settings apply to the entire Exchange Server
organization. The No Action setting allows the message to pass through the SMTP connector. The
Reject setting tells the SMTP Connector to return (or bounce) the message back to the sender. The
Archive setting causes the SMTP Connector to route those messages to be stored as .eml files in the
<drive letter:>\Program Files\exchsrvr\mailroot\vsi 1\UceArchive folder.
To review these messages, double-click each one to open it within Outlook Express. Be aware
that this folder can fill up rapidly with thousands of messages—too many messages to manually look
at. You might consider using a third-party tool, such as Intelligent Message Filter Archive Manager
from GotDotNet, to more efficiently cycle through hundreds or thousands of archived emails. (You
can download this utility at http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id
=e8728572-3a4e-425a-9b26-a3fda0d06fee.) Finally, the Delete setting tells the SMTP Connector to
immediately drop all the messages that meet the criterion.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Chapter 8 Managing Exchange Server 2003

217

Figure 21:
Specifying SCL thresholds for the Intelligent Message Filter in the ESM

Messages that have been assigned a lower SCL rating than the threshold specified for the
Gateway Blocking Configuration can pass through the SMTP Connector and find their way to the
proper recipient’s mailbox. However, you might have noticed the Store Junk E-mail Configuration
section at the bottom of the Properties sheet. This threshold determines whether messages are to be
moved into users’ Junk E-mail folders based on each message’s SCL rating. The Store Junk E-mail
Configuration threshold setting must be lower than the Gateway Blocking Configuration threshold
setting or else an error message will inform you of this rule. So, a message might get past the
Gateway Blocking threshold setting, but it might not survive the Store Junk E-mail threshold setting,
depending on the threshold settings and the message’s SLC rating.

n Note
If you change either of the SLC threshold settings for the Intelligent Message Filter on the
Message Delivery Properties sheet, we recommended that you stop then restart the Exchange
Information Store service. If you do not restart this service, you might experience unpredictable
results when using the Intelligent Message Filter.
Brought to you by NetIQ and Windows & .NET Magazine eBooks

218

Migrating to Windows Server 2003, Active Directory and Exchange Server 2003

Of course, the Intelligent Message Filter add-on for Exchange Server 2003 is not the only antispam solution floating around. Third-party vendors provide several valuable tools that you should
consider before choosing an antispam product. Some of the most popular products include:
• GFI MailEssentials
• McAfee SpamKiller
• Nemx Power Tools
• NetIQ MailMarshal
• Sunbelt Software iHateSpam for Exchange
• SurfControl E-mail Filter
• Sybari Spam Manager
• Symantec Brightmail Anti-Spam
• Symantec Mail Security for Microsoft Exchange
• TrendMicro ScanMail for Microsoft Exchange
• Vamsoft Open Relay Filter (ORF)

Migration, Administration, and Beyond
This chapter provides the major fundamentals to help you manage your newly upgraded Exchange
server environment including setting up OWA, mailbox-enabling users, mail-enabling contacts,
implementing security measures, and applying the latest antispam technology to keep your Exchange
messaging infrastructure stable, secure, and as free from spam as possible. This chapter also covers
the basics of how to set up performance monitoring and how you can troubleshoot message delivery
problems with the Message Tracking Center.
Throughout this eBook, we have laid the major groundwork necessary to migrate your network
infrastructure to Windows Server 2003 and your messaging infrastructure to Exchange Server 2003.
Remember that throughout the book we pointed out many additional resources to review for further
information and many other tools to consider for assistance with your migration. Because of the
complexity and individuality of networks, you will undoubtedly need to analyze and prioritize this
information appropriately to meet the needs of your particular environment. Naturally, due to the
evolving nature and the fast-moving world of computers and information technology, you will
undoubtedly need to continue making changes, installing service packs, and applying new feature
packs on a continuing basis to maintain optimal functionality and performance. With this eBook as a
guide and learning tool, you can begin to upgrade your network environment to Windows Server
2003 and Exchange Server 2003 and manage it with confidence.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close