Windows-2003 Active Directory Administration Essentials 7

ii
Books
Contents
Chapter 1 Windows Server 2003 — What’s New . . . . . . . . . . . . . . . . . . . 1
Introduction .................................................... 1
A Chapter-by-Chapter Roadmap to the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Windows 2003 Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Windows 2003, Standard Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Features Common to Three Windows 2003 Editions . . . . . . . . . . . . . . . . . . . . . . . . 4
Active Directory (AD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Network Load Balancing (NLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Internet Information Services (IIS) 6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Internet Connection Firewall (ICF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Remote Desktop for Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Server Event Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Manage Your Server Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Help File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Volume Shadow Copy for Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
IP Security (IPSec) over NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Microsoft .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Windows 2003, Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Windows 2003, Datacenter Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Windows 2003, Web Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Windows 2003 32-Bit and 64-Bit Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Windows 2003 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Real-World Windows 2003 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15
Keeping Your System Updated and Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Driver Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Driver Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Automatic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Software Updates with SUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IIS Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
IIS Remote Administration Mode ..................................... 20
Should You Deploy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Onward — to Windows 2003 AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iii
Books
Contents
Chapter 2 What’s New in Windows Server 2003 Active Directory . . . . . . 23
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Working with Domain Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Analyzing Your Current Network . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 24
If You Have Combined Win2K and NT 4.0 BDCs . . . . . . . . . . . . . . . . . . . . . . . 24
If You Have All Win2K DCs . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 28
If You Have All NT 4.0 Domain Controllers . . . . .. . . . . . . . . . . . . . . . . . . . . . . 29
Decision Point . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 30
Getting to Interim Mode . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 30
Sidebar: Why Does Interim Mode Exist? . . .. . . . . . . . . . . . . . . . . . . . . . . 30
If You Have No Windows-based Domains . . . . .. . . . . . . . . . . . . . . . . . . . . . . 32
Domain Level Review . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 34
Domain Functional Level Diagram . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 35
Working with Forest Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Windows 2003 Forest Functional Level Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Preparing for the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Using Adprep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Running Adprep /forestprep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Running Adprep /domainprep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Next: Window 2003 AD Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
iv
Books
Contents
Chapter 3 What’s New in Windows 2003 Active Directory
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
New Administration Console Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Drag-and-Drop Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Multiple Select Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Saved Queries Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Group Policy Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Installation and Initial Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
GPMC Basic Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
the GPMC’s New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
New Forest Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Defining the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Win2K’s Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Windows 2003’s Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
What a Federation Does and Doesn’t Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Creating Cross-Forest Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Next: Delegation and Security in Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . 62
v
Books
Contents
Chapter 4 Inside Windows Server 2003 Forests and DNS . . . . . . . . . . . . . 63
Securing Forest Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Cross-Forest Trust Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Authentication Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
SID Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Windows 2003 DNS Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
DNS Health Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Windows 2003 DNSLINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conditional Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Setting Up Conditional Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Stub Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Creating Stub Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Conditional Forwarding vs. Stub-Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Next: Windows 2003 Security Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
vi
Books
Contents
Chapter 5 Windows Server 2003 Security Enhancements . . . . . . . . . . . . . 81
Securing the Wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Shoring Up with SMB Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Win98 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
NT 4.0 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Win95 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Manipulating the Servers to Not Require SMB Signing . . . . . . . . . . . . . . . . . . . . . 85
Shoring Up with Secure Channel Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Shoring Up with LDAP Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Shoring Up by Eliminating NTLM and LM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Enabling NTLMv2 Authentication at the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
NTLMv2 for NT 4.0 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
NTLMv2 for Win9x Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Disabling NTLM and LM at the Domain Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
ACL Viewing and Editing Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Security Principals Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Schema Updates and Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Next: Backup, Restore, and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
vii
Books
Contents
Chapter 6 Backup, Restore, and Recovery for Windows Server 2003
and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using the RC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Deploying EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Understanding Out-of-Band Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring the SAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Understanding !SAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Additional EMS Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Performing an AD Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
AD Backup Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Performing a System State Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Creating an AD Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
AD Nonauthritative Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
AD Authoritative Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
The New Windows 2003 Backup API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Enabling ASR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Replicating DCs from Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Next: New Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
viii
Books
Contents
Chapter 7 Command-Line, Support, and
Microsoft Windows Server 2003 Resource Kit Tools . . . . . . . . . . . . . . . . . 123
Windows 2003 Built-In Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Built-In Command-Line Event-Log Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Eventcreate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Eventquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Eventtriggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Built-In AD Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Dsadd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Dsadd User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Dsquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Dsquery User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Windows 2003 Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Support Tools Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
AD Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Dcdiag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Dcdiag with Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Dcdiag with Dcpromo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Replmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Windows 2003 Resource Kit Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Active Directory Users and Computers Enancement Tools . . . . . . . . . . . . . . . . . . . . 139
Acctinfo.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Rcontrolad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Event Manipulation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Custreasonedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
EventCombMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Next: Special Domain Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
ix
Books
Contents
Chapter 8 Special Domain Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
FSMO Role Review and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Knowing Role Holders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Dumpfsmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Replmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Transferring Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Role Transfer Through the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Role Transfer Through the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Seizing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Cleaning Up the AD Metabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Metabase Clean-Up Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Renaming DCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
DC Rename Through the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
DE Rename Through the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Renaming Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Domain Rename — A History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Windows 2003 Domain Rename — An Alternative . . . . . . . . . . . . . . . . . . . . . . . . . 165
Windows 2003 Domain Rename — How To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Thank You . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
1
Chapter 1
Windows Server 2003 — What’s New

Introduction
If you’re downloading this eBook, you probably want to know why you should care about
Microsoft’s latest server OS — Windows Server 2003 (Windows 2003). Inside, you’ll discover
which features might be important to you and why. Whether you’re a Windows 2000-with-Active
Directory (AD) expert or a Windows NT administrator who’s been reading all the trade journals
about Microsoft’s new server family — this book is for you.
To get the most from this eBook, you should have a working knowledge of Win2K and some
AD experience. However, if you’re new to AD, you can still make good use of the information
that you find here.
Windows 2003 brings much that’s either new or improved to the table. I discuss the new fea-
tures and improvements in some depth. In addition, I discuss key topics that many Windows texts
fail to cover, such as AD backup and recovery. I occasionally compare Windows 2003 to Win2K to
illustrate both the similarities and the important new differences between the two server OSs.
n Note This book differs from several currently available Windows 2003 books in that it’s based on
experience with the actual product — not with beta code and outdated screens. The advan-
tage to you is that you won’t be missing any “late-breaking” information.
A Chapter-by-Chapter Roadmap to the Book

To begin, let me give you a chapter-by-chapter roadmap for the book:
Chapter 1: Windows Server 2003 — What’s New

Chapter 1 introduces Windows 2003’s notable new non-AD-related features. You’ll want to
become familiar with what Windows 2003 offers in preparation for the in-depth discussions
of Windows 2003 and AD. In addition, knowing these features can help you make a solid
business case for deploying Windows 2003.
Chapter 2: What’s New in Windows Server 2003 Active Directory
Chapter 2 covers the different AD domain and forest modes. You might be familiar with
Windows 2000’s Mixed and Native modes. Windows 2003 adds a new mode specific to this
new server OS. In this chapter, I discuss how to prepare your existing domains for Windows
2003 with AD.
Chapter 3: What’s New in Windows Server 2003 Management
Chapter 3 introduces some excellent Windows 2003 management features, including new Active
Directory Users and Computers features and the Group Policy Management Console (GPMC). I
Brought to you by NetIQ and Windows & .NET Magazine eBooks

2 Windows 2003: Active Directory Administration Essentials
also review how to use AD’s advanced management features to tie together your Windows 2003,
Win2K, and NT domains.
Chapter 4: Inside Windows Server 2003 Forests and DNS
Chapter 4 explores Windows 2003’s new cross-forest trusts – demonstrating precisely how
to control resources – via the new Authentication Firewall and SIDFiltering techniques.
Additionally, I cover what’s new with Windows 2003 DNS: Conditional Forwarding, DNS
Stub zones, and the new DNSLint tool.
Chapter 5: Windows Server 2003 Security Enhancements
Chapter 5 covers client side security with Windows 2003’s new required server rules. I'll
discuss the new ACL editor and explain how Windows 2003 deals with schema changes and
revisions, along with other security enhancements.
Chapter 6: Backup, Restore, and Recovery for Windows Server 2003 and Active Directory
Chapter 6 discusses Windows 2003 AD backup and restore features, including the ins and outs
of resurrecting objects after they’ve been deleted. You’ll want to know how Windows 2003
addresses this situation.
Chapter 7: Command-Line, Support, and Microsoft Windows Server 2003 Resource Kit Tools
Chapter 7 introduces Windows 2003’s extensive set of tools. I cover the plethora of command-
line tools, support tools, and the Microsoft Windows Server 2003 Resource Kit tools.
Chapter 8: Windows Server 2003 Special Domain Operations
Chapter 8 reviews a new Windows 2003 domain renaming feature. You can now rename both
domain controllers (DCs) and complete domains. Should your organization name change from
smallcollege.edu to huge-u.edu, for example, you won’t be plagued by the old name remaining
in the domain.
Windows 2003 offers much that’s new and even more that’s improved. Over the next several
months, I’ll cover the key features in bite-sized chunks. So, welcome to Windows 2003 and AD. It
won’t be long until you’re ready to go forth and deploy!
Jeremy Moskowitz
jeremym@moskowitz-inc.com
If you want to contact me with specific Windows 2003 questions, I’ll take a shot at answering
them or directing you to a solid specific resource. However, I might not be able to research every
question in depth.
Windows 2003 Editions

Like the Win2K and NT server OSs, Windows 2003 comes in several sizes. According to Microsoft,
you can find a size for every type of business. Win2K offers three servers editions and one client.
Windows 2003 offers four server editions and no client — that is, the client comes in the form of
Windows XP Professional. Table 1.1 presents the different versions of Win2K Server and Windows
2003 and their clients side by side.
The two most commonly deployed Windows 2003 server editions will probably be
Windows 2003, Standard Edition and Windows 2003, Enterprise Edition. You might well be asked

Chapter 1 Command Shell Scripting Basics 3
to influence a purchasing decision between the two. Knowing which features each edition offers
can help you and your company make the best business decision.
n Note Windows 2003, Standard Edition might be just the ticket for most businesses’ day-to-day
needs. However, to weigh which server edition might be right for your business, examine
the features listed in the following text.
Table 1.1
Win2K and Windows 2003 servers and clients
Windows 2000 Windows 2003
Departmental server Win2K Server Windows 2003, Standard Edition
General use server Win2K Advanced Server Windows 2003, Enterprise Edition
Mission-critical server Win2K Datacenter Server Windows 2003, Datacenter Edition
One-stop-shop server for all Win2K Small Business Server Windows 2003, Small Business
business needs Server Edition
Web server None Windows 2003, Web Edition
Preferred client Win2K and Windows XP Windows XP supports extra features and
work equally well optimization.
I explore the different Windows 2003 server editions to give you an overview of each server’s
capabilities, beginning with Windows 2003, Standard Edition to establish a baseline. I then list the
features common to Windows 2003, Standard Edition, Windows 2003, Enterprise Edition, and
Windows 2003, Datacenter Server, before I continue with individual edition overviews.
Windows 2003, Standard Edition

According to Microsoft, Windows 2003, Standard Edition targets departments and small businesses
with IT departments for use as a general purpose server. It performs the usual server functions of
ensuring that users can access data in all forms (e.g., through file and print services), housing
database systems, running complex business processes, and providing a communications gateway,
such as a VPN.
Windows 2003, Standard Edition can accommodate Four-way Symmetric Multiprocessing
(SMP) machines, which means that the Standard Edition servers can contain up to four processors.
Windows 2003, Standard Edition can accommodate up to 4GB of memory — no matter how many
processors you have in the system. You’ll enjoy the room.

j Tip
Windows 2003 introduces a new feature that – if you have enough RAM to support it – lets
you eliminate your Windows swap file completely. Consider using this feature only if you
have enough RAM to do without your swap file completely. In Task Manager, view the
Performance tab. Inspect the “Commit Charge” entry to see if the peak commit is less than
the physical memory. If it is, you should be able to eliminate the swap file.
Windows 2003, Standard Edition is the follow-on to Win2K Server. In theory, you can simply
pop the Windows 2003, Standard Edition CD-ROM into existing Win2K servers and upgrade them
“in place.” However, note the caution below.
d Caution
Only upgrade your Win2K servers to Windows 2003 with a change-management plan.
Features Common to Three Windows 2003 Editions

Now that I’ve introduced Windows 2003, Standard Edition, let me briefly review features common
to several of the server editions. The Windows 2003, Standard Edition, Windows 2003, Enterprise
Edition, and Windows 2003, Datacenter Server Edition servers provide a gaggle of new or updated
features. In the following text, I discuss some of these features. Windows 2003, Web Edition’s
features are significantly different, as I point out later in this chapter. (Windows 2003, Small
Business Server Edition hasn’t yet been released. The server will include many features, such as a
built-in version of Exchange. However, specifications aren’t currently available.)
n Note I mention the features that Microsoft introduced in the various Win2K Server editions for
comparison only.
Active Directory (AD)

Win2K Server brought us AD. Although the first iteration of AD wasn’t designated AD 1.0, it
sometimes seemed to be missing features. That situation has changed in Windows 2003 with what
I call “Active Directory 1.1.” As was true with Win2K, DCs still house AD components, respond to
client authentication requests, and share the AD database. I discuss these basic units of AD and the
newest AD features in Chapter 2, Chapter 3, and Chapter 8. Windows 2003 offers too many new
AD features to list here.
Network Load Balancing (NLB)

Win2K Server didn’t support NLB. However, Windows 2003, Standard Edition supports two-node
NLB. Windows 2003, Enterprise Edition and Windows 2003, Datacenter Edition support additional
nodes, as you’ll see where they’re covered individually. (My research indicates that Windows 2003,
Web Edition doesn’t support NLB.)

Chapter 1 Windows Server 2003 — What’s New 5
Internet Information Services (IIS) 6.0

Windows 2003 IIS 6.0 offers improved architecture and improved speed. The increased speed is
impressive. The Lockdown Wizard is now included rather than being a downloadable add-on.
Internet Connection Firewall (ICF)

All Windows servers now have a basic stateful Internet firewall, which Figure 1.1 shows. ICF can
block or permit traffic by specific traffic type or to specific ports. The “big brother” of this built-in
feature is Microsoft’s Internet Security and Acceleration (ISA) Server 2000. Although ICF isn’t
“industrial strength,” it performs basic security functions.
Remote Access
Microsoft has improved Windows remote access. Specifically, remote access includes a useful new
feature — the Network Access Quarantine Control feature — that lets you “quarantine” users.
Briefly, here’s how the feature works: If client systems don’t run software that you specify, such
as a service pack or a virus scanner, those client systems are quarantined and can’t access your
network.
Figure 1.1
The Internet Connection Firewall
j Tip
The remote access quarantine is a bit difficult to work with. You can download the complete
details at the following URL:
http://www.microsoft.com/windowsserver2003/docs/quarantine.doc

Remote Desktop for Administration (Terminal Services in Remote Administration mode)

Win2K introduced many of us to the world of Terminal Services. You’ll recall that Win2K has two
modes for Terminal Services — Full Terminal Services mode (also called Application server mode)
and Terminal Services — Administration Mode (also called Remote administration mode). The latter
mode let two administrators remotely administer the server as if they were practically standing at
the console. With Win2K, you could choose one of the two modes mentioned or choose not to
select a terminal services mode. After loading Terminal Services mode, Win2K requires a reboot. In
contrast, Windows 2003 by default loads the necessary files for the equivalent of Terminal Services
— Administration Mode. To finish enabling Terminal Services — Administration Mode, you need
only select the Remote Desktop check box on the Remote tab of the server’s System Properties,
which Figure 1.2 shows.
Figure 1.2
Enabling Remote Desktop
Server Event Tracking

Microsoft has tried to ensure that latest server editions are the most reliable ever. In the past, many
users shut down and restarted their servers for various reasons, some of them inappropriate. With
NT, for example, it might often have made sense to reboot a server on a Saturday night to clear
out the memory and prevent server crashes the following week. With Windows 2003, Microsoft

intends to prove to everyone — including your management — that the servers will stay up until
administrators take them down.
To that end, Microsoft has included a small reporting window into which administrators can
type precisely why they choose to shut down a server. The EventcombMT tool from the Windows
Server 2003 Resource Kit can parse the logs from all servers and highlight why administrators
reboot servers.
n Note I discuss more Resource Kit tools in Chapter 7: Command-Line, Support, and Microsoft
Windows Server 2003 Resource Kit Tools.
Figure 1.3 shows a Windows 2003 Event tracking Shut Down Windows screen. In the
Shutdown Event Tracker Option segment of the dialog box, you can specify by category why
you’re shutting the server down.
Figure 1.3
Windows 2003 event-tracking Shut Down Windows screen
Figure 1.4 shows the option selected in Figure 1.3, including the comment field that lets
you enter more detailed information about why you shut down the server. The record of server
shutdowns might be valuable both to you and to Microsoft.

Figure 1.4
Shutdown Event Tracker comment field
You might not want to use the Shutdown Event Tracker. Figure 1.5 shows the policy you use
to disable the mechanism. You can enable and disable Shutdown Event Tracker through the
Group Policy Object Editor.
j Tip
You might find the mechanism for disabling the shutdown event annoying, especially in a
testing environment in which machines are rebooted all the time. You might want to turn
this feature off for some servers, but certainly not for all. With that in mind, you can use
these steps to turn off the Server Event Tracking on a particular server.
1. Click Start, Run, and type in GPEDIT.MSC.
2. Traverse to Computer Settings, System, Display Shutdown Event Tracker.
3. Disable the policy.

Figure 1.5
The Display Shutdown Event Tracker policy
Manage Your Server Wizard

Windows 2003 updates the Manage Your Server Wizard. Even if the Win2K wizards turned you
off, give the Windows 2003 wizards a shot. You might still choose to do your day-to-day tasks
manually, but know that the Windows 2003 wizards often offer a faster way to accomplish a task.
For example, the Manage Your Server Wizard that Figure 1.6 shows lets you easily add or remove
a server role.

Figure 1.6
The Manage Your Server Wizard
Help File
Figure 1.7 shows the Windows 2003 Help file, which you’ll find highly useful. Microsoft and the
entire Online Help team have outdone themselves in the level of detail provided at each turn of
the virtual page. I usually click the Index button (circled in the screen shot), then track down what
I need instead of relying on the (somewhat slow) Search facility.
Volume Shadow Copy for Shares

In conjunction with an XP client, this feature lets users “roll back” a data file to a particular point
in time or restore a deleted file.
IP Security (IPSec) over NAT

IPSec is a superior way to secure wired communications between any client and server. In the
past, the problem has been that if either machine were behind a NAT or NAT-style router or
firewall, IPSec didn’t work 100 percent. Windows 2003’s IPSec over NAT feature can encrypt both
the header and payload parts of a packet over NAT. IPSec over NAT is an excellent new feature
for servers in DMZs or in other areas that use NAT.
Microsoft .NET Framework

The .NET Framework lets programmers do new magic — and much of that new magic will take
the form of Web services and IIS. System administrators and AD administrators won’t need to use

or know much about the .NET Framework. Because the framework is already deployed inside the
OS, it’s one less thing you need to address today.
Figure 1.7
The Windows 2003 Help file
Windows 2003, Standard Edition might offer all the server firepower you need to run your
business. However, as I explore Windows 2003, Enterprise Edition, you’ll see that it offers
considerably more.
Windows 2003, Enterprise Edition

Windows 2003, Enterprise Edition can accommodate from 1 to 8 processors and up to 32GB of
memory. In addition to the general increase in hardware support, you might find support for key
features that your business needs. Consider whether your business could benefit now (or might
benefit soon) from one of the features listed here.
j Tip
If you think you might not use all the Windows 2003, Enterprise Edition features immediately
but might use them in the future, it’s best to invest the dollars up front and get Enterprise
Edition today, rather than deploying Windows 2003, Standard Edition. Why? Because you
can’t “upgrade” from Windows 2003, Standard Edition to Windows 2003, Enterprise Edition.
Choosing wisely at this stage is paramount.

Windows 2003, Enterprise Edition offers more scalability features than either Windows 2003,
Standard Edition or Win2K AS.
• Clustering has been increased from the four nodes available in Win2K AS to eight nodes.
• NLB has increased from the four nodes available in Win2K AS to eight nodes.
• Terminal Services offers a new load-balancing feature in the new Terminal Services Session
Directory. The feature provides a front-end NLB that lets clients easily find an available
Terminal Server in a Terminal Server farm.
• Microsoft will support the Microsoft Metadirectory Services (MMS) add-on, a centralized service
meant to bridge the gap between disparate directories such as AD and iPlanet. Apparently,
Microsoft is designing the Windows 2003 version of MMS for deployment upon Enterprise
Edition servers only.
Still other Windows 2003, Enterprise Edition features are available only if your hardware can
leverage those features. The features listed below require high-end servers.
• “Hot-add memory” lets you add memory to a server while it’s running and allocate that memory
to the rest of the server.
• Non-Uniform Memory Access (NUMA) is a hardware-specific feature that returns low-level
information from the hardware to NUMA-compliant applications. This returned data can
fine-tune NUMA-aware applications in real time based on the system’s total stress level.
Windows 2003, Datacenter Edition

Windows 2003, Datacenter Edition is Microsoft’s “big-boy” OS. Datacenter Edition integrates OEM
hardware tightly with Microsoft software to guarantee specific levels of uptime.
Because Windows 2003, Datacenter Server is available only from OEMs, it might be the least
often deployed of the Windows 2003 servers. Nevertheless, when you see it deployed, you’ll
recognize its tremendous power.
Windows 2003, Datacenter Edition supports up to 32 processors and up to 64GB of RAM. The
clustering capability equals that of the Windows 2003, Enterprise Edition (eight nodes), which is
greater than that of its Win2K Datacenter counterpart (four nodes).
The Datacenter Edition adds one special hardware hook — hyperthreading support. Hyper-
threading lets certain Intel processors perform almost double duty. In fact, the Datacenter Edition
server can abstract a single processor and make it appear and work as if it were really two
physical processors. On some single-processor hyperthreading systems, Windows appears to be
using two processors.
n Note For more information about the Windows 2003, Datacenter Edition server program, visit the
URL below.
http://www.microsoft.com/windowsserver2003/evaluation/overview/datacenter.mspx

Windows 2003, Web Edition

Windows 2003, Web Edition is totally new among the Windows server progeny. Microsoft has one
short-term goal in selling this server: to compete with Linux — at least in the Web services market.
Linux is popular among Web systems, and Microsoft’s Windows 2003, Web Edition is meant to
tackle this growing threat head on.
Like the Windows 2003, Datacenter Edition, Windows 2003, Web Edition is not for sale through
retail channels. To purchase a Windows 2003, Web Edition server, you must work with specific
Windows 2003, Web Edition partners (e.g., Hewlett Packard — HP, Dell, IBM, NEC, Unisys).
Windows 2003, Web Edition isn’t as packed with features as other server family members. In
fact, you can quickly grasp the nature of this edition by considering what it can’t do. Windows
2003, Web Edition
• can’t be a DC (however, it can be a domain member)

• is limited to 2GB of memory and two processors
• can’t be clustered
• doesn’t support NLB
• lacks services for Macintosh
• lacks Windows Media Services
• lacks Remote Installation Services (RIS)
• doesn’t support 64-bit Itanium-family processors
• doesn’t support Hot-Add memory
• doesn’t support NUMA
• doesn’t support ICF
Windows 2003, Web Edition is both the least costly and the least flexible of the server family.
Its single purpose is to serve Web pages.
j Tip
You can find more information about Windows 2003 at the following URL:
http://www.microsoft.com/windowsserver2003/evaluation/overview/web.mspx
Windows 2003 32-Bit and 64-Bit Processing

Microsoft plans to revise its Windows 2003 server line for the new 64-bit Itanium processors. In
fact, some pieces of the 64-bit puzzle are available today. Clearly, 64-bit computing should jump
processing muscle forward much as the change from 16-bit to 32-bit computing jumped it forward
several years ago. Microsoft is betting on the Itanium-family of processors, including Itanium 1 and
Itanium 2. With that in mind, Table 1.2 shows you what each 64-bit version can handle.

Table 1.2
Windows 2003 64-bit capabilities
Product Processors RAM
Windows 2003, Standard Edition Won’t be available in a 64-bit edition.
Windows 2003, 64-Bit Enterprise Edition 1—8 64GB Maximum
Windows 2003, 64-Bit Datacenter Edition 8 — 64 512GB Maximum
Windows 2003, Web Edition 1—2 2GB Maximum
Windows XP Pro, 64-Bit Edition 2 (Itanium 1 or Itanium 2) 16 GB
j Tip
You can find more information about XP Professional 64-bit edition at the
following URL:
http://www.microsoft.com/windowsxp/64bit/techinfo/planning/techoverview/default.asp
Windows 2003 Hardware Requirements

Your move to a Windows 2003 installation must start with adequate hardware. Microsoft has
published specifications for minimum required hardware, which Table 1.3 shows.
Table 1.3
Minimum hardware requirements for Windows 2003 installations
Standard Enterprise Enterprise 64-Bit Web Datacenter
CPU Type Pentium II Pentium II Itanium 1 Pentium II Contact a
Speed 133MHz 133MHz 733MHz 133MHz Datacenter
RAM 128MB 128MB 128MB 128MB vendor for
details.
Disk 1.5GB 1.5GB 2.0GB 1.5GB
n Note Although processor speed and processor type aren’t strictly enforced when you attempt to
install, the amount of RAM is. For example, if you don’t have 128MB of RAM, you can’t
load Windows 2003 on a Pentium-class system.

Real-World Windows 2003 Hardware Requirements

Minimum requirements might work well for a test machine or two, but true production systems
require a bit more firepower. Table 1.4 shows my recommended minimum hardware requirements
for real-world systems.
Table 1.4
Real-world minimum hardware requirements for Windows 2003 installations
Standard Enterprise Enterprise 64-Bit Web Datacenter
CPU type Pentium 4 Pentium 4 Itanium 1 or Pentium 4
Itanium 2 Contact a
Speed 2GHz 2GHz 733MHz 2GHz Datacenter
RAM 256MB – 1GB 256MB – 1GB 256MB – 1GB 256MB – 512MB vendor for
details.
Disk 9GB + 9GB + 9GB + 9GB +
Storage for data Storage for data Storage for data Storage for data
Keeping Your System Updated and Secure

Microsoft is “packing in” Windows 2003 features toward the goal of keeping the network up and
running and available to user requests. Windows can go belly up — but usually it doesn’t just
“happen.” For example, frequently damage occurs when bad drivers are installed despite the OS’s
attempts to address the problem. Although loading an imperfect driver doesn’t always mean
curtains for the OS, it can result in the blue screen of death that Microsoft refers to as a bugcheck.
If your network experiences problems, you can send a message to Microsoft in several ways.
One way is through the new error-reporting mechanism, which Figure 1.8 shows.
You can specify that an error report be sent when the Windows OS fails and when other loaded
programs fail. You can select those programs through the Choose Programs button that Figure 1.8
shows. As you can see, the default selection involves all Microsoft programs and Windows
components. In most environments, you might want to keep error reporting enabled. I’m not sure
how Microsoft is going to evolve this feature to offer better support; however, I can see the
company using it to improve the product or link your error reports with your activation ID so that
Microsoft’s support services can better assist you if you call for support. (Those who are paranoid
can disable the error-reporting feature.)

Figure 1.8
Enabling or disabling error reporting in System Properties
Driver Signing
Driver signing isn’t new with Windows 2003, but it’s a highly useful feature. This feature lets you
block drivers that haven’t undergone Windows Hardware Quality Labs (WHQL) testing and signing.
The default sets up Driver Signing to warn you when you’re about to load an unsigned driver, as
Figure 1.9 shows. I recommend that you consider raising the level on all your servers to Block —
Never install unsigned driver software.
Driver Rollback
Even if a driver that shouldn’t have been loaded is loaded, you have another chance to excise it
from your system. You can use the Driver Rollback feature that Figure 1.10 shows to roll back the
current driver to the most recent previously installed driver.
n Note The Driver Rollback feature isn’t designed to keep histories of all the drivers for a device
that you’ve ever loaded. It “remembers” only your most recent previously installed driver.

Figure 1.9
Selecting the Driver Signing level in System Properties
Figure 1.10
Driver Rollback feature in Device Manager

Automatic Updates
Windows 2003 now allows automatic updating when patches become available between service
packs. You can choose between different modes that can help you keep your Windows 2003
servers updated, as Figure 1.11 shows.
Figure 1.11
Configuring Automatic Updates in System Properties
Software Updates with SUS

Despite the capabilities of the Automatic Update feature, the most effective way to manage Microsoft’s
patch updates is to disable the Automatic Update service and set up Microsoft Software Update
Services (SUS), which Figure 1.12 shows. Using SUS helps ensure that new Microsoft patches are
well integrated into your environment. You can test the patches you want to update in a test lab,
then distribute the patches you need to your servers and clients.
You could load SUS on a Windows 2003 or Win2K server or DC, then use group policy to
distribute instructions to target machines about how to download and install the patches. For
more information, see the Windows and .NET Magazine Network Security Administrator article
at http://www.secadministrator.com/articles/index.cfm?articleid=37938 or my article at
http://www.mcpmag.com/features/article.asp?editorialsid=336
j Tip
You can leverage the power of Microsoft’s free SUS to specify which patches you
want to send to your systems. It’s a simple task for an Administrator to test the
proposed patch offline in the test lab, then select which patches will go to servers
and clients. SUS is available for download from Microsoft at
http://www.microsoft.com/windowsxp/64bit/techinfo/planning/techoverview/default.asp

Figure 1.12
Microsoft SUS
IIS Improvements
Microsoft Internet Information (IIS) Services 6.0 is a wholesale IIS overhaul. In a nutshell, IIS 6.0 is
• faster
• more secure
• easier to administer
Did I mention that it’s faster? IIS 6.0 is so much faster than previous IIS versions that its speed
is hard to describe. Why is it faster? Microsoft has moved the HTTP processor from user mode to
kernel mode, a move that makes IIS 6.0 dramatically faster.
Space constraints keep me from delving into and describing all the IIS 6.0 architecture and
security changes. For an in-depth look at the changes, be sure to read Brett Hill’s Windows & .NET
Magazine article “IIS Overhauled in Version 6.0,” which you’ll find at the following URL:
http://www.winnetmag.com/windowsserver2003/index.cfm?articleid=38285

IIS Remote Administration Mode

If you want to set up your servers so you can administer them remotely — from any Web browser
anywhere in the world — you can do so by enabling Remote Administration Mode. You must go
to Add/Remove Windows Components, then traverse to Application Server, Internet Information
Services, World Wide Web Service, and Remote Administration (HTML), as Figure 1.13 shows.
Figure 1.13
Setting Up Remote Administration
When you’re ready to use Remote Administration Mode, go to http://<servername>:8089.

You’ll be prompted for credentials. After you’re in, poke around to see what you can do from a
Web browser. Figure 1.14 indicates some of what you can accomplish after you set up Remote
Administration Mode.

Figure 1.14
Remote Administration Mode
j Tip
You can’t load Remote Administration if the target server is a DC.
Should You Deploy?

Now that Windows 2003 is generally available, it’s certainly worth a look. But how can you decide
whether you’re ready to deploy it? You’ll have to ask yourself some questions about the current
state of your network to see whether, after you commit to Windows 2003, the installation will
remain an uphill battle. You can begin your assessment by asking yourself these questions:
• Am I currently running on older hardware?

If yes, evaluate your hardware to make sure it won’t prohibit the upgrade to Windows 2003.
• Do I have many custom applications or Web applications?
With every new OS release, application incompatibilities can be a problem. With that in mind,
you’ll need to test and retest each custom application if you want it to run on Windows 2003.
Moreover, given the dramatic changes Microsoft has made to IIS 6.0, if you have Web
applications, you need to ensure that they won’t break after you upgrade to IIS 6.0.

• What will deployment cost?

Do you have a Microsoft licensing agreement that lets you upgrade to Windows 2003? If so,
you’ll pay only the labor costs of performing the application tests and the upgrade — not the
software costs.
If you don’t have a licensing agreement that lets you upgrade to Windows 2003, try to
figure out how many licenses you’ll need. Be especially careful after you introduce your first
Windows 2003 DC. I’m not an expert on Microsoft licensing, but my understanding is that after
you introduce your first Windows 2003 DC, you’ll need to get current on all your Client Access
Licenses (CALs). Definitely check with your Microsoft licensing representative to get the full
scoop on the upgrade costs.
j Tip
The article at the following URL provides some information about Microsoft licensing:
http://www.winnetmag.com/Articles/Index.cfm?ArticleID=24033
Onward — to Windows 2003 AD

In terms of Windows 2003 features, I’ve barely scratched the surface. Some of the features I’ve
described are “skin deep” but useful. Others offer dramatic improvements over previous capabilities.
Yet other features kick in when you use Windows 2003 as an AD DC, as I explore in Chapter 2:
What’s New in Windows Server 2003 Active Directory and Chapter 3: What’s New in Windows
Server 2003 Management.

23
Chapter 2:
What’s New in Windows Server 2003

Active Directory
Introduction
“Chapter 1: Windows Server 2003 – What’s New” introduced some of the many compelling features
Windows Server 2003 (Windows 2003) brings to the table. Windows 2003 includes
• a faster, more secure, and re-architected Microsoft Internet Information Services (IIS) 6.0
• remote access quarantine through the Network Access Quarantine Control feature
• server event tracking through Shutdown Event Tracker
• greater scalability with more processors
• greater scalability with more cluster nodes
You can make a strong case for upgrading to Windows 2003 based on those features alone. If
you simply walked around with the Windows 2003 CD-ROM and upgraded all your Windows 2000
member servers, you would have a field day exploring what you can accomplish with the new
features. Of course, you won’t want to walk around with the CD-ROM and perform those upgrades
(you’d be likely to get into trouble). Nevertheless, Figure 2.1 shows the first screen you’ll encounter
when the time to upgrade comes.
Figure 2.1
Windows 2003 CD-ROM initial screen

In my opinion, the real magic of Windows 2003 lies in the new Active Directory (AD)-specific
features you gain after you complete your upgrade. This chapter explores what capabilities those
features provide and discusses how to prepare to use them.
Working with Domain Levels

To prepare for Windows 2003 AD, you must first ask yourself two questions: Which kinds of domain
controllers (DCs) do I have and which kinds of DCs do I want to deploy? The answers to these
questions might include Windows NT 4.0 BDCs, Win2K DCs, and Windows 2003 DCs. You’ll want to
begin by stepping back and analyzing your current network configurations.
Analyzing Your Current Network

Your network might contain
• all NT 4.0 DCs
• some Win2K DCs and some NT 4.0 BDCs
• all Win2K DCs
• no Windows-based domains (i.e., no network or a non-Windows network such as Banyan or
Novell)
Each of these situations gives rise to some specific opportunities and concerns. I explore each
scenario in the following text.
n Note Although it makes sense to list the scenario of having all NT 4.0 DCs first (as I did above), I
discuss that scenario last. Moving from all NT 4.0 DCs to Windows 2003 has some unique
considerations. Nevertheless, those of you who have all NT 4.0 DCs will benefit from reading
through the material that precedes the discussion of that particular upgrade.
If You Have Combined Win2K and NT 4.0 BDCs

If you started out with NT 4.0 DCs and introduced a Win2K DC or two, you might remember the
process. You had to begin with an NT 4.0 PDC and upgrade it directly into your Win2K Server. You
probably made a backup of the PDC, then slipped in the Win2K CD-ROM with your fingers crossed.
For 99 percent of the users who approached the upgrade this way, everything went well. For the
other 1 percent of the users, the process involved sweaty palms as they rolled back the upgrade and
tried to figure out what the problem was. After you completed the PDC upgrade, you had your first
Win2K DC. In addition, Win2K advantageously put you directly into what’s called Mixed Mode.
Now that I’m discussing how to analyze your particular scenario, let me remind you how to
discover or verify your network’s mode. To check your current configuration’s mode, run Active
Directory Domains and Trusts, which Figure 2.2 shows.

Chapter 2 What’s New in Windows Server 2003 Active Directory 25
Figure 2.2
Active Directory Domains and Trusts
In the list of domains that appears, select the name of the domain whose mode you want to
check and right-click Properties. The domain mode should appear. If you have any NT 4.0 BDCs,
you’re probably in Mixed Mode, as is the case with Domain B, which Figure 2.3 shows.

Figure 2.3
Ascertaining a domain’s mode
Mixed Mode supports both Win2K and pre-Win2K DCs, which means that you can still add and
remove NT 4.0 BDCs as needed. This capability is a good thing. You might have legacy applications
that require you to keep NT 4.0 BDCs around until you find a Win2K or Windows 2003 solution.
Of course, much of the capability that you have with all Win2K DCs is missing in Win2K and
NT Mixed Mode. (The next section details which capabilities you add if you make the switch to all
Win2K DCs.) However, with the first Win2K DC, you get
• Group Policy support for Win2K and XP Professional clients
• IntelliMirror support for Win2K and XP Professional clients
• domain management capability through either Active Directory Users and Computers (Win2K) or
User Manager for Domains (NT 4.0)

j Tip
For an in-depth discussion of Group Policy and IntelliMirror, see my book Windows 2000:
Group Policy, Profiles, and IntelliMirror. You can find information about the book at the
URL below.
http://www.sybex.com/sybexbooks.nsf/2604971535a28b098825693d0053081b
/d15f21a26eaeed8588256bca0062a12f!OpenDocument&Highlight=0,moskowitz
The promised land, as far as Win2K is concerned, is to get rid of all your NT 4.0 BDCs and have
homogeneous Win2K DCs. Interestingly, new Windows 2003 domains are “born” into Win2K Mixed
Mode. You can see Domain A’s initial mode – Win2K’s Mixed Mode – in the Windows 2003 domain’s
Active Directory Domains and Trusts screen, which Figure 2.4 shows.
Figure 2.4
A new Windows 2003 domain’s initial mode
Therefore, if you build a new Windows 2003 domain from scratch, you could still, if you wanted
to, introduce additional NT 4.0 BDCs. This capability might be helpful should you have legacy
applications, such as a specialized account lookup program or a specialized piece of remote access
equipment, that must reside on a BDC.

If You Have All Win2K DCs s

After you leave the last NT 4.0 BDC in the dust, you can make the switch toWin2K’s Native Mode,
which introduces additional useful features.
• Universal Group support – This feature lets you assign groups from any domain to any other
domain if the domains are in the same forest.
• Total Win2K-style replication – Without any NT LAN Manager (NTLM)-style replication to BDCs
and with all your Win2K DCs using native AD replication, the replication process will now be
more efficient.
• Additional capacity for security principals – Additional capacity lets you grow the database that
holds users past the SAM’s restriction of about 40MB. (You’re still restricted even with one NT 4.0
BDC.) If you need this greater capacity, you know it!
• SidHistory – This feature lets a single account have multiple SIDs. (This capability is useful if you
perform an NT 4.0-to-Win2K or an NT 4.0-to-Windows 2003 migration. Users might need to show
alternate credentials to access data in their old domain.)
• Advanced Group nesting – You can now use multiple levels of nesting between different group
types. Additionally, you can change the scope of domain local groups to domain global groups
by clicking one button.
To make the switch to Native Mode on a Win2K domain, just click Change Mode, which Figure
2.3 shows. You’ll be asked to confirm that you want to change the mode. If you answer Yes, the
Domain operation mode changes with little fanfare, as Figure 2.5 shows.
Figure 2.5
Changing the domain’s operation mode to Native Mode

Your Win2K domain is now in Win2K Native Mode, which lets you add Windows 2003 as well
as Win2K DCs. Keep in mind, however, that Windows 2003 in Win2K Native Mode doesn’t allow
NT 4.0 BDCs.
d Caution
When you make the switch to Win2K Native Mode, you effectively abandon any remaining
NT 4.0 BDCs. They won’t receive updates from your Win2K domain. If you don’t disconnect
the NT BDCs, they might introduce network errors (e.g., they might validate deleted users’
access to your network).
If You Have All NT 4.0 Domain Controllers

Now we can discuss a unique case: You have all 4.0 NT DCs and you’re considering switching
directly to Windows 2003. You’re not required to first upgrade your NT 4.0 domain (and therefore
your NT 4.0 BDCs) to Win2K DCs before you move to Windows 2003. What do you need to know
as you consider whether to skip the step of having Win2K DCs?
First, if you have all NT 4.0 DCs, you can still upgrade any NT 4.0 member server to either
Win2K or Windows 2003. You might choose an upgrade for servers such as your SQL servers,
Systems Management Server (SMS) servers, IIS servers, and Oracle servers. If you don’t have any
Win2K or Windows 2003 DCs, you’ll encounter NT 4.0’s inherent limitations, which include
• a SAM size restricted to about 40MB
• no Group Policy
• no IntelliMirror capability
• a single point of failure (If the PDC goes down, no users or administrators can update account
information or change passwords.)
• the old replication model (BDCs pull from PDCs at scheduled intervals.)
• the need to reformat a BDC to remove its role as a DC
n Note A third-party tool, such as Algin Technology’s U-Promote, can in most cases help you promote
or remove an NT 4.0 BDC’s DC status, leaving it a plain server. As with any tool, use
U-Promote only if you have current backups on hand.
j Tip
You can upgrade an NT 4.0 Server to either Windows 2003, Standard Edition or Windows
2003, Enterprise Edition. However, you can upgrade NT 4.0 Server, Enterprise Edition only to
Windows 2003, Enterprise Edition.

Decision Point
At this point, if you’re running all NT 4.0 DCs, you’re ready to decide whether to bypass the Win2K
DC step completely. You know that you can jump from NT 4.0 straight into Windows 2003 – but
what else should you consider?
If you know that Win2K DCs won’t ever – and I mean ever – be involved in your journey to
Windows 2003 AD, you can take advantage of a special domain mode, Interim Mode. Interim Mode
is useful in the unique scenario comprised of NT 4.0 BDCs and Windows 2003 DCs – no Win2K DCs
allowed.
d Caution
Interim Mode works only with NT 4.0 BDCs and Windows 2003 DCs.
Getting to Interim Mode

If you currently have 100 percent NT DCs and want to introduce your first Windows 2003 DC, how
do you move into Interim Mode? You select it when you use the Active Directory Installation Wizard
to upgrade an NT 4.0 domain’s PDC. You choose the forest functional level for forests that won’t
contain Win2K DCs, as Figure 2.6 shows.
Why Does Interim Mode Exist?

Interim Mode compensates for a specific limitation of both Win2K Mixed Mode and Win2K Native Mode (one
that doesn’t occur with either NT domains or the Windows 2003 equivalent of Native Mode).
The problem lies in group account memberships. NT 4.0 domains let you maintain more than 5000
members in a security group – for example, in a Domain Global Group. However, after you’ve introduced
Win2K DCs, the group account membership situation changes because Win2K DCs can’t handle more than
5000 members in a group.
Windows 2003, on the other hand, can handle more than 5000 members in a group – just as NT can.
Therefore, you can combine NT 4.0 BDCs and Windows 2003 DCs and use Interim Mode. Interim Mode also
provides better replication – specifically between other Windows 2003 DCs.

Figure 2.6
Choosing Interim Mode
n Note The Active Directory Installation Wizard dialog box is titled Forest Functional Level. I discuss
Forest Functional Levels later in this chapter. If you select Windows Server 2003 interim here,
you’re also changing the domain level to Windows 2003 Interim domain level.
When you upgrade an NT 4.0 PDC (to upgrade your NT 4.0 domain), Dcpromo will run
automatically. As you can see above, the text lets you know that the setting is right for you only if
you’ll never have Win2K DCs. Also, notice the statement in the lower left-hand corner of the dialog
box: Note: both options allow the forest to have Windows NT 4.0 domain controllers. In fact, you can
include NT 4.0 BDCs until you make the switch to Win2K Native Mode or the Windows 2003
equivalent (described below).
After the upgrade is complete, you can see Interim Mode again, in Windows 2003’s Active
Directory Users and Trusts, which Figure 2.7 shows.

Figure 2.7
DOMAINC upgraded to Interim Mode
If You Have No Windows-based Domains

If you have no Windows-based domains whatsoever (i.e., in the case of a fresh Windows 2003
domain installation), you’ll probably start with 100 percent Windows 2003 DCs. In that case, you
would bring up your first Windows 2003 Server, run Dcpromo, and create your first domain.
Assuming you won’t need any NT 4.0 BDCs or Win2K DCs, you can get all the benefits of a
homogeneous domain with Windows 2003 DCs at Windows 2003’s domain functional level. First,
however, because you create a Windows 2003 domain as a Win2K Mixed Mode domain, you’ll need
to “bump up” the domain’s functional level. You raise the level through Active Directory Domains
and Trusts by right-clicking the domain name and selecting Raise Domain Functional Level, which
Figure 2.8 shows.

Figure 2.8
Raising a domain’s functional level
Next, you can select the functional level you want to support, as Figure 2.9 shows. Your choices
are to support a domain with Win2K DCs and Windows 2003 DCs or a domain with 100 percent
Windows 2003 DCs.
Figure 2.9
Selecting an available domain functional level

Select the domain functional level you want, then click Raise. You can bump one level to
Windows 2000 native or two levels to Windows Server 2003.
d Caution
Raising the level is irreversible. That is, if you select Windows 2000 native, you can’t go back to
Windows 2000 mixed. If you select Windows Server 2003, you can’t go back to either
Windows 2000 native or Windows 2000 mixed.
After a domain is at Windows 2003’s domain functional level, you get the following major
additional features.
• InetOrgPerson becomes a user principal (I discuss this feature in Chapter 5: Windows Server 2003
Security Enhancements).
• Update logon timestamp: This feature lets administrators easily determine when a specific user
logged on and to which DC. You’ll find this information helpful for auditing purposes. I discuss
this feature and a tool that helps you examine the attribute involved in Chapter 7: Command
Line, Support Tools, and Resource Kit Tools.
• Domain rename feature (I discuss this feature in Chapter 8: Special Domain Operations).
Domain Level Review

You might find the different domain levels a little confusing. Table 2.1 offers a quick summary of
Win2K and Windows 2003 domain levels.

Table 2.1
Win2K and Windows 2003 domain levels
Mode or
Functional Machines
Level Allowed When useful Features Notes
Win2K Win2K DCs, When you have an Group Policy and Both Win2K and
Mixed Mode Windows 2003 application on an NT IntelliMirror for Win2K Windows 2003
DCs, and NT 4.0 BDC on which your Professional and XP domains are created in
BDCs business depends Professional clients Mixed Mode. NT 4.0
BDCs can participate in
Win2K Mixed Mode.
Win2K Win2K DCs and When you have a new Universal Group NT 4.0 BDCs are
Native Mode Windows 2003 Win2K domain, a new Support, SidHistory, excluded from this
DCs Windows 2003 SAM limit gone – mode.
domain, or a Win2K replaced by 100
domain with new percent Win2K-style
Windows 2003 DCs replication
Windows Windows 2003 When you’re upgrading Group size of 5000+ You can choose this
2003 DCs and NT 4.0 an NT 4.0 domain and users, enhanced mode only if you’re
Interim BDCs have NT 4.0 BDCs Windows 2003 upgrading an NT 4.0
Level replication to other PDC with a Windows
Windows 2003 DCs 2003 CD-ROM. Win2K
DCs are excluded from
this mode.
Windows Windows 2003 When you’re creating See the text below Win2K DCs and NT
2003 DCs 100 percent new 4.0 BDCs are excluded
Functional Windows 2003 from this mode.
Level domains without any
older DC types
Domain Functional Level Diagram

Understanding precisely when you can progress to each domain level can be a bit daunting. The
graphic in Figure 2.10 should help guide you – whether you have an NT 4.0 domain, a Win2K
domain, or a Windows 2003 domain.

Figure 2.10
Upgrading from NT 4.0 or Win2K to Windows 2003
Upgraded
Windows NT 4.0 NT 4.0 to
Domain Windows
2000
domain

New Mixed Native
Windows Mode Domain Mode Domain
2003 domain
Windows Windows
2000 to 2000 to
domain domain
upgrade upgrade
Upgraded
Windows NT 4.0 to
Windows 2003 Windows 2000 Windows 2000 Windows 2003
domain Mixed Native
New Functional
(option 2) Windows Mode Domain Mode Domain Level
2003 domain
Upgraded
Windows 2003
Windows NT 4.0 to
Interim
Windows 2003
Mode Domain
domain
(option 1)
d Caution
Let me remind you once more that domain upgrades aren’t reversible. If you select Win2K’s
Native Mode, you can’t go back to Win2K’s Mixed Mode. If you select Windows 2003’s
Interim Level or Windows 2003’s Functional Level, you can’t go back to either Win2K’s
Native Mode or Win2K’s Mixed Mode.

Working with Forest Levels

In the previous section, you saw that a Win2K domain and a Windows 2003 domain could each have
its own domain-wide level. The same is true for a Windows 2003 forest. You create a new Windows
2003 forest at Win2K’s forest functional level.
j Tip
Interestingly, a Win2K forest just “is” – no distinction is made between particular modes.
Only Windows 2003 forests make a distinction between Win2K’s forest functional level and
Windows 2003’s forest functional level.
However, to get to the best features that Windows 2003 AD offers, you must first reach Windows
2003’s forest functional level. To do so, you must ensure that
• all DCs are Windows 2003
• all domains are switched to Windows 2003’s domain functional level
After you’ve completed that preparation, you can take it one step further. That is, you can throw
the switch to bring the entire forest to Windows 2003’s forest functional level – the Holy Grail of
Windows 2003 AD.
To raise the forest level, right-click the Active Directory Domains and Trusts root and select Raise
Forest Functional Level, which Figure 2.11 shows.
Figure 2.11
Raising the forest functional level
After you’ve selected Raise Forest Functional Level, you’ll see the current functional level of the
forest, which Figure 2.12 shows. That level should be Windows 2000. If you run Win2K, Windows
Server 2003 will be the only functional level available.

Figure 2.12
Selecting Windows 2003’s forest functional level
If you chose to perform an NT 4.0 upgrade into an Interim level domain and forest, you have
two options: Windows 2000 Server and Windows Server 2003. Note, however, that you’ll need to
throw Windows 2003’s domain functional level switch in each domain before Windows 2003’s forest
functional level is valid. Simply click Raise on the domain functional level you want, and you’re done.
d Caution
As is true in raising a domain’s level, after you raise a forest’s level, you can’t reverse the move.
That is, if you start with Win2K’s forest functional level and you select Windows 2003’s forest
functional level, you can’t go back to Win2K’s forest functional level.
Windows 2003 Forest Functional Level Features

After you make the irreversible move to Windows 2003’s forest functional level, you get a gaggle of
new Windows 2003 AD features. Some features are “under-the-hood” enhancements, and others are
features you can deploy to solve specific business problems.
Here are some enhancements you get “under the hood” with Windows 2003’s forest functional
level:
• Linked Value Replication (LVR) improvements – Under Win2K, you encountered a problem in
replicating the membership of group accounts. If Stacey in the USA and Ralph in Great Britain
modified the Nurses group membership at about the same time (a user initiated a second change
before the replication function completed the first change), you could only guess which change
would “win” in AD. Now those changes merge successfully.

• Global Catalog (GC) indexing improvements – Under Win2K, if you wanted to manually add a
value to be contained inside the GC server (e.g., social security number), you could do so.
, each GC would essentially dump its index and start re-indexing, which could cause massive
network traffic among the DCs. Global Catalog servers now retain their indexes when a new
attribute is added; the index adds only the change.
• Intersite Topology Generator (ISTG) improvements – Under Win2K, you faced a practical limit. At
some point between 200 and 250 AD sites, you had to perform some special magic to add more
sites. Oftentimes, adding more sites involved consultants and was expensive. Now, you can have
literally thousands of AD sites without the system even breaking a sweat.
Here are some additional major features that Windows 2003’s forest functional level offers:
• Domain rename feature – This feature sounds straightforward and self-explanatory; however,
using the feature requires some background, as I explore in Chapter 8: Special Domain
Operations.
• Cross-Forest Trust – If your forest is at Windows 2003’s forest functional level and another
company (or an unrelated organizational segment of your company) also has a Windows 2003’s
forest functional level forest, you can minimize the potential number of trusts by creating one
cross-forest trust. I explore cross-forest trusts in Chapter 3: What’s New in Windows Server 2003
Active Directory Management.
• Defunct Schema Object – In Win2K, if you had a schema addition and wanted to make a
change, you had exactly zero options to fix the problem. Windows 2003’s forest functional
level changes the score a bit. I explore this feature in the next chapter as well.
Preparing for the Upgrade

If you currently have a Win2K forest with one or more Win2K domains, you’ll probably want to
upgrade them to Windows 2003 domains in a Windows 2003 forest. I’ve reviewed the domain and
forest levels; now it’s time to discuss preparing for the upgrade.
When you have Win2K domains, you use the Win2K schema. To use Windows 2003 domains,
you must upgrade to the Windows 2003 schema. To upgrade your existing Win2K domains to
Windows 2003 domains, you’ll first need to have the right tool – which you’ll then run several times.
That tool is Active Directory Prep (Adprep). You’ll find Adprep.exe on the \i386 directory of the
Windows 2003 CD-ROM. You can choose to run Adprep directly from the CD-ROM or copy it to a
network share or floppy.
Using Adprep
Adprep’s purpose is to upgrade the schema to Windows 2003 levels and give it a new revision
number. You’ll need to run Adprep multiple times:
• Run Adprep /forestprep – one time on the schema master of the root domain of the Win2K
forest
• Run Adprep /domainprep – one time for each domain on the infrastucture master of each domain
For example, if you have four domains, you’ll run Adprep five times: once for the forest and
once for each domain, as Figure 2.13 shows.

Figure 2.13
Running Adprep
corp.com
europe.corp.com na.corp.com
KEY
Run ADPREP /Domainprep on
infrastructure master of each domain
Run ADPREP /Forestprep on the

schema master of the forest buffalo.na.corp.com
Running Adprep /forestprep

To prepare the Win2K forest, you must run Adprep /forestprep on the schema master of the forest.
Make sure that you have the proper service pack level loaded (see the Caution below).
d Caution
You should have at least Win2K Service Pack 2 (SP2) loaded on all DCs before you continue.
Win2K SP3 is preferred. You can proceed, however, with even SP1 (plus hotfixes).
Pop the Windows 2003 CD-ROM into the schema master, and run Adprep /forestprep. When you
do, you’ll see Adprep update the schema incrementally – from Version 13 of Win2K to Version 30 of
Windows 2003, as the output in Listing 2.1 shows.
j Tip
If your schema starts at a number greater than 14, someone might have already performed this
step with a Windows 2003 beta or release candidate (RC).

Listing 2.1
Output from Adprep schema update
X:\I386>adprep /forestprep
ADPREP WARNING:
Before running adprep, all Windows 2000 domain controllers in the forest
should be upgraded to Windows 2000 Service Pack 1 (SP1) with QFE 265089,
or to Windows 2000 SP2 (or later).
[User Action]
If ALL your existing Windows 2000 domain controllers meet this requirement,
type C and then press ENTER to continue. Otherwise, type any other key
and press ENTER to quit.
Opened Connection to SERVERB

SSPI Bind succeeded
Current Schema Version is 13
Upgrading schema to version 30
Connecting to “SERVERB”
Logging in as current user using SSPI
Importing directory from file “C:\WINNT\System32\sch14.ldf”
Loading entries.................................
111 entries modified successfully.
[some output removed for readability]
The command has completed successfully

Loading entries.................................

Loading entries................

...........................................
Adprep successfully updated the forest-wide information.
X:\I386>
Running Adprep /domainprep

You’re now ready to run Adprep /domainprep. Microsoft recommends that you run the tool on each
domain’s infrastructure master. You should see the output that Figure 2.14 shows.

Figure 2.14
Adprep /domainprep output
You’re now ready to upgrade your Win2K domain to Windows 2003. You can start with the
recommended upgrade method: that is, begin with the PDC of the root domain, then upgrade each
PDC in each domain. On the other hand, you could actually choose a Win2K DC and start your
upgrade there.
Next: Window 2003 AD Management

In this chapter, I’ve reviewed the differences between NT, Win2K, and Windows 2003 – especially
regarding AD domain and forest levels and the functions that each level provides. In Chapter 3:
What’s New in Windows Server 2003 Active Directory Management, you’ll see what you can achieve
after the upgrade. As I continue, I’ll assume that you’re working in Windows 2003’s full forest
functional mode. To prepare, take the steps that this chapter outlined in your test lab.
I’ll introduce the new administration console and administration features, discuss cross-forest
trusts, and begin to explore some of the management features that Windows 2003 AD offers. I hope
you’re riveted to your seat awaiting the next chapter!

43
Chapter 3:
What’s New in Windows 2003 Active

Directory Management
In Chapter 2, I discussed the ins and outs of the compatibilities between Windows NT 4.0, Windows
2000, and Windows Server 2003 (Windows 2003). I explored several domain modes in both Win2K
and Windows 2003 and several forest levels in Windows 2003. In this chapter, I review some of
Windows 2003’s key new features, including the additional functionality in the Active Directory Users
and Computers console, the Group Policy Management Console (GPMC), and the ability to set up
forest trusts. Some features don’t require Windows 2003’s domain functional level or Windows 2003’s
forest functional level; others do. I point out where and when you can use specific features.
New Administration Console Features

As soon as you load your first Windows 2003 domain controller (DC), you’re armed with the latest
set of administration tools. In Win2K, the key management tool for Active Directory (AD) has been
the Active Directory Users and Computers console. Updated with several useful features, the console
remains your main tool.
You can ensure you’re running the Windows 2003 version of the Active Directory Users and
Computers by using Help, About. The About Active Directory Users and Computers dialog box
should display version is 5.2.x, as Figure 3.1 shows. (The version will probably change as Microsoft
introduces Windows 2003 service packs.)
Figure 3.1
Checking the Active Directory Users and Computers version

Drag-and-Drop Function
One of the most requested features for this version of Windows was a drag-and-drop function
within Active Directory Users and Computers. In Win2K’s version of the Active Directory Users and
Computers tool, you could move objects around the AD only by right-clicking them, selecting Move,
and selecting the destination. This option is still available in Windows 2003, as Figure 3.2 shows.
Figure 3.2
Moving objects through Active Directory Users and Computers
However, with Windows 2003, you now have the requested additional option. You can simply
drag a user account or multiple user accounts from one folder or organizational unit (OU) to another
folder or OU.
n Note In Windows 2003’s Active Directory Users and Computers, you can still move items by right-
clicking and selecting Move rather than by using the new drag-and-drop feature.
j Tip
I continue to use the Win2K-style method of right-clicking and moving the objects rather than
dragging them. I fear moving an entire group of users or an OU from one corner of AD to
another inadvertently. Continuing to right-click and move my items is a bit slower, but doing so
reassures me that I’ve made a deliberate move.

Chapter 3 What’s New in Windows 2003 Active Directory Management 45
Multiple Select Function

The next-most-requested feature for Windows 2003 also involves the Active Directory Users and
Computers console. That is, the ability to select multiple items within Active Directory Users and
Computers (e.g., 10 users) and change some element of all the items’ information (e.g., changing all
the users’ business addresses to a different location).
To make such a change in AD previously, you had to either individually plunk the information
into each user’s account or write an AD-enabled script, such as a Visual Basic (VB) script, to zip
through each account you wanted to change and add the data. Neither approach was appealing.
Active Directory Users and Computers’ new functionality makes some formerly difficult tasks,
including this one, easy.
To try this feature, simply hold down the shift key and select multiple accounts, right-click after
you’ve selected the last account, and select Properties. You’ll then see a special Properties On
Multiple Objects dialog box, which Figure 3.3 shows.
Figure 3.3
Selecting multiple users in Active Directory Users and Computers

As Figure 3.3 shows, the Properties On Multiple Objects dialog box reminds you that you have
multiple users selected. You click the tab that contains the information you want to change, then
select the check box for the information you’re modifying (e.g., address, account expiration date).
Figure 3.4 shows the available tabs and the Logon Hours dialog box that appears if you select to
change users’ logon hours.
Figure 3.4
Changing properties for multiple objects at once
When you click OK, you leave intact all the current information each account contains but
replace the information you entered after selecting the appropriate check box. The new multiple-
select capability of Active Directory Users and Computers is a great time-saver.
Saved Queries Function

One common problem with Win2K’s Active Directory Users and Computers has been that the console
wasn’t meant to perform repetitive tasks. For example, you might want to locate all users who met
certain criteria within a specific OU or across the entire domain. In Win2K, if you wanted to locate all
users whose accounts were in the Sales OU who hadn’t logged on in the past 30 days, for example,
you faced a difficult task. Typically, you’d have to hand-craft an Active Directory Service Interfaces
(ADSI) script through VBScript to perform this search. Windows 2003’s Active Directory Users and
Computers makes short work of this once-tedious task with a new feature called Saved Queries.
For this example, let’s find everyone in the Sales OU with “user” in his or her name. You can
create and save new queries by right-clicking the Saved Queries folder and selecting New, then
Query. Name your query and begin to select the criteria for your search by clicking Define Query.

Locate and select the category of AD object category for your search, such as Users or Printers.
Figure 3.5 shows how you create a custom search.
Figure 3.5
Search options for locating objects in AD
When you find the category you want to search, select it, and fill in the matching criteria.
Figure 3.6 displays the query to find all users with the word “user” in the name field.

Figure 3.6
Query to find users with the word “user” in the name
When the search has completed, you can immediately access the results. Figure 3.7 shows the list
of users with the word “user” in the name field.
Figure 3.7
Displayed results of a saved query
You’ll find the ability to create and save new queries useful. With this feature, Windows 2003’s
Active Directory Users and Computers has taken a practical step forward.
Group Policy Management Console

In addition to the enhanced Active Directory Users and Computers console, another major manage-
ment advancement comes as a free download from Microsoft. The GPMC is an add-on for Windows
2003 and Windows XP Professional. The GPMC’s goal is to provide an enhanced view of and better
management features for Group Policy.

n Note You can download the GPMC from Microsoft at

http://www.microsoft.com/downloads/details.aspx?familyid=f39e9d60-7e41-4947-82f5-
3330f37adfeb&displaylang=en
In Win2K (and in Windows 2003 without the GPMC loaded), you need to know where each
Group Policy is maintained in relation to each domain and OU and sometimes in relation to each AD
site. The complexity of what you need to know can make managing Group Policy confusing. The
GPMC strives to provide a “Group Policy-centric” view of the environment – a bird’s-eye view of
Group Policy Objects (GPOs).
Installation and Initial Use

Installation is pretty routine. Simply download the Windows Installer (.msi) file from Microsoft and
place it where you want to perform your Group Policy management. For this example, I’ve loaded it
on my Windows 2003 server.
After you’ve loaded the GPMC, you can start the console a couple of ways. Loading the GPMC
effectively disables the former way of manipulating Group Policy. If you attempt to manipulate GPOs
in the usual Win2K fashion, a dialog box offers you only one choice – to click Open and launch the
console, as Figure 3.8 shows.
Figure 3.8
Manipulating GPOs after the GPMC is loaded
Alternatively, you can use an icon to launch the GPMC. An icon titled Group Policy Management
appears automatically when you select Start, Programs, Administrative Tools.

GPMC Basic Use

One benefit of the GPMC is that you can see all your GPOs at once. Simply expand the tree to find
your forests, domains, and OUs. You’ll also see a special folder called Group Policy Objects, which
Figure 3.9 shows.
Figure 3.9
The GPMC’s Group Policy-centric view
You create new GPOs through the GPMC. After you create a GPO, you can edit it by right-
clicking it and selecting Edit. Doing so launches the Group Policy Editor, which you can then use to
set the policies you want to implement.
The GPMC’s New Functions

You might be asking yourself why you would want to switch to another tool to do things you
already accomplish another way. The GPMC brings a lot more functionality than you’ll find in the
base Windows 2003 product. The new GPMC features you should explore and evaluate include
• backup and recovery of GPOs. This much-needed feature simplifies what was previously a highly
laborious task.
• increased reporting. Now you can get HTML-based reports that show the settings inside a GPO.
• “Resultant Set of Policy” modeling. This modeling feature lets you determine what policies a user
will be assigned if he or she moves, for example, from one OU to another OU. This modeling
capability works only if you're connected to a Windows 2003 DC in the domain in which you're
trying to perform the modeling.
The GPMC is packed with features that you won’t want to miss. I can’t review every feature, so
be sure to download the GPMC and see what it has to offer. I think you’ll be pleasantly surprised.

n Note I’ll fully explore the GPMC in the upcoming revision of Windows 2000: Group Policy, Profiles
and IntelliMirror titled Windows Server: Group Policy, Profiles and IntelliMirror. For
information about the current edition and about the revision as soon as it’s available, go to
http://www.sybex.com/sybexbooks.nsf/2604971535a28b098825693d0053081b
/d15f21a26eaeed8588256bca0062a12f!OpenDocument&Highlight=0,moskowitz
New Forest Options

Win2K has been missing something that our friends in the Novell world have: the ability to prune
and graft portions of the directory service. Although Windows 2003 doesn’t introduce pruning and
grafting, it does offer one new “patch” that solves part of the problem.
Defining the Problem

In Win2K, you could upgrade an NT 4.0 domain into a current Win2K forest. For example, if you
had already established your Win2K forest and wanted to add an NT 4.0 domain, it was quite easy.
Take the example of the Corp.com Win2K tree and the currently “uninvolved” NT 4.0 Sales domain,
Figure 3.10
An NT 4.0 domain not yet in an existing Win2K domain
corp.com
SALES
europe.corp.com
You can upgrade the Sales PDC, instruct it to join an existing forest, and simply choose which
domain you want to be the parent. Figure 3.11 and Figure 3.12 show possible upgrade options.
Figure 3.11 shows the Sales domain becoming Sales.corp.com, a child of Corp.com.

Figure 3.11
Option 1 – Sales becomes Sales.corp.com, a child of Corp.com
corp.com
europe.corp.com sales.corp.com
upgraded NT 4.0 domain; maintains

old NetBIOS name of SALES
Figure 3.12 shows another upgrade option for the NT 4.0 Sales domain. The Sales domain
becomes Sales.europe.corp.com, a child of the Europe.corp.com domain.

Figure 3.12
Option 2 – Sales becomes Sales.europe.corp.com, a child of Europe.corp.com
corp.com
europe.corp.com
sales.europe.corp.com
upgraded NT 4.0 domain; maintains

old NetBIOS name of SALES
These two NT 4.0 domain upgrade options are useful, but they go only so far. Specifically, what
happens if you already have two Win2K domain trees and no longer have any NT 4.0 domains? Such
a scenario is quite prevalent in many corporations (e.g., when a merger has occurred). Someone has
already performed the NT 4.0-to-Win2K upgrade in a domain – without choosing a Win2K parent.
Later, an administrator wants to place that upgraded (now Win2K) domain (or domain tree) in an
existing forest. In Win2K, you can’t just “join” two existing Win2K domains or domain trees together.
Let’s look again at the diagram in Figure 3.10. Imagine that the NT 4.0 Sales domain has been
upgraded to Win2K without a parent domain having been chosen. The resulting situation would
resemble the scenario that Figure 3.13 represents.

Figure 3.13
Two Win2K domains that can’t simply be “joined”
corp.com sales.jeremyco.com
upgraded NT 4.0 domain;
maintains old NetBIOS name
of SALES
europe.corp.com Forest Forest sales.

corp.com jeremyco.com
Win2K’s Solution
The Win2K method for working around the inability to prune and graft isn’t pretty. You set up
external trust relationships between the unrelated domains. The external trusts work exactly like
NT 4.0 trusts. However, like NT 4.0 trusts, the mechanism uses NT LAN Manager (NTLM)
authentication, which means the connection isn’t very secure. Additionally, every time you want a
new domain in either forest to be able to share information with other domains, you must create
another trust relationship manually.
An external trust lets you share basic account information through the trust – in the same way
that NT 4.0 domains let you share such information. For example, after an external trust is put in
place, you can apply NTFS permissions in one domain that also restrict users from another domain.
Windows 2003’s Solution

Windows 2003 brings a new concept to the table: forest trusts. Cross-forest trusts let you loosely tie
together two (or more) unrelated forests. You “tie” the forests together at each forest’s root domain.
Figure 3.14 shows an example of three unrelated forests tied together with cross-forest trusts.

n Note In Windows 2003, forests have names just as domains have names. The forest has the same
name as the root of the domain of that forest, as Figure 3.14 shows.
Figure 3.14
Cross-forest trusts
Cross Forest Cross Forest
Trust #1 Trust #2
corp.com sales.jeremyco.com bigu.edu

of SALES
europe.corp.com Forest Forest sales.

corp.com jeremyco.com science.bigu.edu registrar.bigu.edu
Forest bigu.edu
When you tie multiple forests together with cross-forest trusts, the resulting set of relationships
has a special name. It’s called a “federation” of forests.
What a Federation Does and Doesn’t Offer

Cross-forest trusts bring something to the table that Win2K external trusts can’t offer: Kerberos-based
authentication between forests. Because the trust is 100 percent Kerberos-based, it can leverage how
AD works – in ways that NT 4.0 could not.
With the ability to leverage AD, administrators and users get some big benefits. Administrators no
longer need to worry about manually creating a new trust between established domains and a new
domain – should a new domain pop up. Because the new domain is automatically trusted, no new
trusts are necessary.
Users also get a benefit – that is, they can log on from any domain in any forest. However, users
must know their user principal name (UPN) to log on if they travel to any domain located “beneath”
one of the roots, as the following examples demonstrate. If Fred from Corp.com traveled to the
Domain sales.jeremyco.com, he should be able to see Corp.com in the drop-down box. This option
is available because Fred is logging on from a domain that’s one of the root domains.

However, if a user in Registrar.bigu.edu traveled to Europe and wanted to log in at a machine

in Europe.corp.com, he would have to use his UPN logon name, joe@registrar.bigu.edu, to log on
successfully. He couldn’t use his usual method of picking his home domain from the Ctrl+Alt+Del
drop-down box when he logged on. It simply doesn’t appear. Therefore, I recommend that users
become familiar with their UPN logon names – so they can log on from wherever they are.
d Caution
Training your users to use the UPN-style logon could be an uphill battle if they’re used to the
ease of a drop-down box.
Administrators face a similar situation. That is, if administrators want to set ACL permissions on
users across the cross-forest trust, the administrators must know the full UPN name of any accounts
they want to manipulate. This shortcoming could make cross-forest trusts a bit annoying.
n Note To learn more about UPN logon names, go to

http://support.microsoft.com/default.aspx?scid=kb;EN-US;243280 or to
http://www.winnetmag.com/WindowsServer2003/Index.cfm?ArticleID=38280.
Creating Cross-Forest Trusts

To create cross-forest trusts (and then a federation of forests), you must first make sure that the
forests are at Windows 2003’s forest functional level. As you recall, Windows 2003’s forest functional
level means that
• you have no NT 4.0 or Win2K DCs
• you’ve “pulled the switch” in each domain to ensure that it’s in Windows 2003’s domain
functional mode
• you’ve also “pulled the switch” in the forest to ensure that it’s at Windows 2003’s forest functional
level
If every forest that you want to federate is at Windows 2003’s forest functional level, you’re ready
to continue. In the following example, I create a cross-forest trust between a forest that contains
Domaina.com and a forest that contains Corp.Com.

j Tip
You can perform the work from whichever domain you choose, as long as it’s from the root of
one of the forests.
Begin by running Active Directory Domains and Trusts. Then, for the domain from which you’re
working, select the domain’s Properties, click the Trusts tab, and select New Trust. Selecting New
Trust launches the New Trust Wizard, as Figure 3.15 shows. You use the New Trust Wizard to create
all sorts of trusts, including cross-forest trusts.
Figure 3.15
The New Trust Wizard
You can now design your cross-forest trust, which you can set up as a one-way or two-way trust.
Be prepared for multiple wizard pages. Although I won’t explore all of the pages here, I’ll review
highlights and examine the results of some choices you make.

After the splash screen, the wizard displays the Trust Type page, which Figure 3.16 shows. You
can select to set up a traditional NTLM External trust or a Kerberos Forest trust (i.e., a cross-forest
trust). If you choose the NTLM External trust, the work you do here will be between just two specific
domains and won’t span the entirety of forests. It will be precisely the same as an NT-style trust, and
you won’t have any trust transitivity. (Kerberos supports transitive trusts. That is, if Domain A trusts
Domain B and Domain B trusts Domain C, Domain A trusts Domain C.)
Figure 3.16
Selecting trust type
Next, the wizard displays the Direction of Trust screen, which Figure 3.17 shows. As its title
indicates, on this screen you select the direction of the trust. The trust can be inbound to your forest
or inbound to the other forest – or the trust can work both ways. You might choose to make the
trust one way to share resources in one direction only. For example, you might have file servers in
Forest A that Forest B must be able to access. However, Forest B might not need access to file
servers in Forest A. In those circumstances, a one-way cross-forest trust might be just the ticket.
Typically, however, you’ll be setting up two-way cross-forest trusts.

Figure 3.17
Selecting trust direction
I omit the next screen, Sides of Trust, which lets you create both sides of the trust in one step.
That is, instead of creating one half of the trust, then having the administrator of the other forest
create the other side of the trust, you can simply give the system the other forest’s credentials (if you
have them) and create both sides of the trust at once. This creation option is a handy timesaver, as
long as you have the administrative information you need.
The wizard then displays the Outgoing Trust Authentication Level – Specified Forest screen,
which lets you determine which user accounts can go through the trust. I discuss this selection
option, called the Authentication Firewall, in Chapter 4: Inside Windows Server 2003 Forests
and DNS.
Finally, the wizard displays a summary of your selections on the Trust Selections Complete
screen, which Figure 3.18 shows. On this example screen, you can see that I’m setting up a
cross-forest trust between two root domains: Domaina.com and Corp.com.

Figure 3.18
Trust Selections Complete summary screen
After the trust has been set up, Windows 2003 can automatically validate it. You choose the
validation step on the screen that appears after you click Next on the screen that Figure 3.18 shows.
The validation takes only a minute, and it ensures that after the initial trust is set up, it’s valid and
working properly from both forests.( Occasionally, one side of the trust can be built without the other
side being built properly. This step ensures that the trust works correctly both ways.)
After you’ve finished setting up your trust, you can see the fruits of your labor inside Active
Directory Domains and Trusts on the Properties screen, which Figure 3.19 shows.
Figure 3.19
The new cross-forest trust’s properties

Because you’re looking at Domaina.com’s properties, you can see an inbound and outbound
cross-forest trust to Corp.com.
Administrators in either forest can now choose accounts in the other forest and set permissions
granting or restricting access to resources on the servers each “owns.” Additionally, users can log on
to any forest. Again, users can use the drop-down menu when they log on to any root domain, as
Figure 3.20 shows. (You can see the other root domains from your domain and vice versa.)
Figure 3.20
Drop-down logon menu
n Note You can see both root domains listed in the drop-down menu. However, what you see isn’t the
Fully Qualified Domain Name (FQDN), such as Corp.com. You’ll see only Domaina.com’s and
Corp.com’s NetBIOS names – that is, DOMAINA and DOMAINC respectively. This can be
tricky if users are expecting to find the FQDN name for logon purposes.
d Caution
If users want to log on to computers in domains below any of the root domains (outside of
their own forest), they’ll have to know their UPN name, such as john@child-domainl.com.
I want to add a brief caveat regarding Windows 2003 and cross-forest trusts. The cross-forest trust
goes a long way to “tie together” existing Windows 2003 forests. However, forest trusts don’t tie
together the GCs of disparate forests. Today, you simply have no way to magically tie the GCs
together – and this limitation is bad news for those of you who use Exchange 2000 or who plan to
use the upcoming Exchange 2003. Because the GCs aren’t tied together, Exchange has no unified
Global Account List. Essentially, you must still manage each forest’s Exchange independently.

n Note Microsoft Identity Integration Server 2003 (formerly Metadirectory Services) is an up-and-
coming way to put some magic back into managing Exchange across different forests. Microsoft
Identity Integration Server 2003 looks promising.
Forests, then, are basically still separate, but cross-forest trusts between their roots make them
federations that can share data and other resources.
Next: Delegation and Security in Windows 2003

Although Win2K is truly leaps and bounds beyond NT 4.0, Win2K has some deficiencies that
Windows 2003 addresses. I’ve discussed three advantages that you gain with Windows 2003:
• updates to Active Directory Users and Computers that make AD easier to manage
• the new GPMC
• cross-forest trusts
In Chapter 4, I’ll pick up where I’m leaving off. I’ll explore how you can determine who can use
the new cross-forest trusts – and more.

63
Chapter 4:
Inside Windows Server 2003

Forests and DNS
In Chapter 3, I discussed the management aspects of Windows Server 2003 (Windows 2003). I
explored new Active Directory Users and Computers console functions, including the drag-and-drop
feature, the multiple-select feature, and the saved-queries feature. I introduced the Group Policy
Management Console (GPMC) and forest trusts, including cross-forest trusts. In this chapter, I
continue to delve into cross-forest trusts, and I introduce new DNS features.
Securing Forest Trusts

In Chapter 3, you saw that a cross-forest trust might be required if you had already upgraded various
Windows NT domains or Windows 2000 domains to Windows 2003 and wanted to join them. In the
example that Figure 4.1 shows (also presented in Chapter 3), you can see that I’m tying together
three separate Windows 2003 forests: the Corp.com forest, the Sales.jeremyco.com forest, and the
Bigu.edu forest.
Figure 4.1
An organization’s cross-forest trusts
Cross Forest Cross Forest
Trust #1 Trust #2
corp.com sales.jeremyco.com bigu.edu

of SALES
Forest Forest sales.

corp.com jeremyco.com
Forest bigu.edu
europe.corp.com
science.bigu.edu registrar.bigu.edu
As I noted in Chapter 3, tying the forests together doesn’t magically join the Microsoft Exchange
2000 Server or Exchange Server 2003 account lists. Rather, the cross-forest trust accomplishes one
thing: It gives forest trust member domains easy access to each other’s domain resources. However,
how secure is a cross-forest trust?

Cross-Forest Trust Security

When you create a cross-forest trust, you basically agree to let users in other domains in trusted
forests access your forest’s resources. However, you can probably imagine situations in which you
don’t necessarily trust all the accounts in the other forests equally. Figure 4.1 shows a cross-forest
trust situation in which you might want to restrict access selectively. A university and two corpora-
tions are tied together. Although the cross-forest trust lets any account within any of the trusting
forests attempt to access resources in the other trusted forests, you might want to impose particular
limitations.
For example, let’s assume that you’re the administrator of the Corp.com domain. After the
cross-forest trust has been established, you want to protect your forest from curious students at
Bigu.edu who might want to pry. You’ve properly locked down access to your Corp.com resources,
including file servers, printers, and other entities that leverage your Active Directory (AD) to maintain
user accounts’ rights to various resources. However, unless you’ve spent time analyzing each share
to ensure that it doesn’t have Everyone: Full Control (or even Everyone: Read) access, you might
not be fully protected.
The setup that Figure 4.1 shows lets users in Bigu.edu try to authenticate on your domain
controllers (DCs) and access your resources. What if the results of your efforts to lock down specific
resources haven’t been 100 percent effective? For example, what if another administrator inadvertently
permits the Everyone group access to resources for which access should be restricted? You’d still be
vulnerable to attacks from Bigu.edu.
Authentication Firewall
To protect your resources from attacks that users in other trusted domains might launch, you can
set up selective authentication through what Microsoft calls an authentication firewall. Setting up an
authentication firewall lets you block certain SIDs from authenticating across the cross-forest trust.
The users whose SIDs you block won’t be able to authenticate on your network resources.
In the example in Figure 4.1, you could block all Bigu.edu student SIDs from traversing the
cross-forest trust, but still let the Bigu.edu faculty member SIDs do so. This approach would prevent
students from taking a whack at Corp.com resources, but let the faculty members authenticate to
Corp.com servers and access Corp.com resources.
Selective authentication isn’t turned on by default. That is, if you accept the defaults when you
set up a cross-forest trust, you’ll need to enable selective authentication to establish the authentication
firewall. When you use the New Trust Wizard to create your cross-forest trust, you choose the scope
of authentication through the Outgoing Trust Authentication Level – Local Forest dialog box options,

Chapter 4 Inside Windows Server 2003 Forests and DNS 65
Figure 4.2
Outgoing Trust Authentication Level – Local Forest option
The terminology in the dialog box that Figure 4.2 shows is a bit confusing. The dialog box text
doesn’t state that your choice here indicates whether you’ll be deploying an authentication firewall to
block certain SIDs from other domains from getting inside your forest. If you select Forest-wide
authentication, the default, you let all users in the cross-forest trust traverse all the forests. If you
select Selective authentication, thereby creating an authentication firewall, you can then manually
add access for specific users.
If you accept the default (Forest-wide authentication) when you use the New Trust Wizard,
which Figure 4.2 shows, a user who logs on to a domain in another forest that trusts your forest
through a cross-forest trust can see the resources you have. Figure 4.3 shows that by using the Net
View command, that user can see the shares on a specific machine.
Figure 4.3
The Forest-wide authentication option

If, after your forest trust is built, you decide to further lock down resources and enable an
authentication firewall, you must then use Active Directory Domains and Trusts to change the mode.
After you open Active Directory Domains and Trusts, right-click the domain. Select the Trusts
tab, the name of the trust, and Properties. Then click the Authentication tab and select Selective
authentication as Figure 4.4 shows.
Figure 4.4
Choosing Selective authentication through Active Directory Domains and Trusts
As soon as you choose selective authentication, you can see the immediate consequences for
users who try to gain access through the trust, which Figure 4.5 shows. Access is denied.
Figure 4.5
User access after you choose the Selective authentication option

After your authentication firewall is in place, no one in domains outside your forest (i.e., in
“foreign” domains and forests) can get access to any resources through the trust. To then “open up”
the authentication firewall, you need to selectively poke holes in its security. That way, you can
dictate precisely who’ll be given access to the resources in your forest.
You set up selective access through the Active Directory Users and Computers console. First,
you must enable Advanced Features, which Figure 4.6 shows.
Figure 4.6
Advanced Features in the Active Directory Users and Computers console
j Tip
Turn on the Advanced Features in Active Directory Users and Computers to manipulate who
can pass through the authentication firewall.
After you enable Advanced Features, you can specify security for specific objects. You’ll set
the filtering directly upon the computer resource to which a foreign user needs access. In Figure 4.7,
you can see that I’ve enabled the Administrator account from a foreign domain – DOMAINC –
to access resources on server VMSERVER2.

Figure 4.7
Selecting the cross-forest trust users who can access this server
After you assign the Allowed to Authenticate right to a selected user, that user can see the
resources to which access was denied previously. As Figure 4.8 shows, the user can see resources
across the forest trust.

Figure 4.8
A server available to specific users through the authentication firewall
SID Filtering
Another technique to prevent ne’er-do-wells from accessing your resources is SID filtering. SID
filtering can help prevent potential attacks. Imagine this scenario: A domain administrator in another
domain that your domain trusts wants to attack you. The attacker might be a domain administrator
within the same forest. Although that possibility sounds frightening and might be unlikely, it’s
theoretically possible.
If you wonder how such an attack might occur, recall that Win2K’s Native Mode domains and
Windows 2003 Functional Level domains support the SID history feature. The idea behind SID history
is that a user account can be populated with more than one SID – the SID of the user account plus
other SIDs. The user account is usually populated with additional SIDs when someone migrates
accounts with the SID history feature turned on. SID history is often useful – for example, when you
migrate user accounts from many domains and consolidate them into a few domains. SID history lets
a user present an alternate set of credentials to gain access to network resources. Users might need to
present their old credentials to access resources (e.g., Exchange or Microsoft SQL Server) in their
former domains.
An unscrupulous domain administrator could take an account in his or her domain and use
the account to attack your domain. The administrator would accomplish the attack by hijacking the
SIDs from the trusting domain (the NT domain) and putting them in the SID history attribute of his
or her user object. The administrator then “becomes” the user with the hijacked SID – thereby
impersonating (i.e., spoofing) a user in your domain. If the administrator spoofs the account of a
domain administrator in your domain, he or she could do a lot of damage.

Win2K Service Pack 2 (SP2) introduced SID filtering to protect against this potential attack.
Enabling SID filtering won’t stop an administrator bent on being destructive from trying this attack;
he or she can still hijack the SID. But your domain will ignore any SIDHistory attributes, which
renders such an attack ineffective. Windows 2003 has the same functionality enabled by default.
To disable or re-enable SID filtering in Windows 2003, you use the Netdom command.
For more information, read the Microsoft Knowledge Base article “Forged SID Could Result in
Elevated Privileges in Windows 2000,” available at the following URL:
http://support.microsoft.com/default.aspx?kbid=289243
n Note SID filtering is sometimes complex. To learn more about it, in particular how to use SID
filtering to prevent elevation-of-privilege attacks, go to
http://www.microsoft.com/windows2000/techinfo/administration/security/sidfilter.asp
j Tip
In addition to selective authentication and SID filtering, you can place another level of security
upon a forest trust by using top-level name (TLN) restrictions. Windows 2003 uses domain
name suffix routing to provide name resolution between forests connected by trust
relationships. TLN restrictions let you enable, disable, or exclude suffixes to control cross-forest
routing. For in-depth information about TLN restrictions, read the article “Windows 2003
Forest Trusts” at http://www.winnetmag.com/windowsserver2003/index.cfm?articleid=38436.
Windows 2003 DNS Additions

DNS is essential to the health of Windows networks. What air is to humans, DNS is to Win2K and
Windows 2003. This section isn’t about in-depth DNS troubleshooting, however, but about DNS
features new to Windows 2003. I’ll assume that you’ve already set up your DNS correctly and that
you have a healthy AD that relies on your DNS infrastructure.
DNS Health Checks

You can perform a subzone spot check before you move forward to ensure that under your domain
name, all four automatically generated subzones appear. The four automatically generated subzones
appear preceded by an underscore, as Figure 4.9 shows.

Figure 4.9
A domain’s four automatically generated subzones
Verifying that all four automatically generated subzones ( _msdcs, _sites, _tcp, and _udp) are
present ensures that your domain has the records necessary to locate DCs, which clients must be
able to do.
Windows 2003 DNSLINT

You can take your Windows 2003 DNS testing one step further by running a new tool that Microsoft
makes available: DNSLint. DNSLint helps you make sure that you’re running a “clean” DNS server.
You can start by downloading DNSLint from http://download.microsoft.com/download/win2000srv
/utility/q321045/nt5xp/en-us/dnslint.exe
After you download DNSLint to a Windows 2003 server, you can run myriad commands. Be
sure to read the documentation file included to understand all your options. However, to help
diagnose common AD-related DNS errors, you’ll find it useful to run the DNSLINT command with
the /ad switch, which Figure 4.10 shows.
Figure 4.10
Run DNSLint from the command line with the /ad switch

When you run DNSLint with the /ad switch, you instruct DNSLint to produce an HTML report
about the state of DNS affairs. This file will reveal any trouble spots in your DNS. Figure 4.11 shows a
DNSLint report with a clean bill of health (the report would list any errors that DNSLint found).
Figure 4.11
DNSLint report
Conditional Forwarding
Before I discuss the new Windows 2003 conditional forwarding feature, let me briefly review standard
forwarding. You enable Win2K’s standard forwarding on a server-by-server basis in the DNS applet.
You simply right-click the computer name, select Properties, then select the Forwarders tab, as Figure
4.12 shows.

Figure 4.12
Win2K’s Forwarders tab
n Note Other non-Microsoft implementations of DNS, such as Internet Software Consortium’s (ISC’s)
BIND 9.0, support conditional forwarding.
The forwarders address lets one DNS server ask other (possibly nonrelated) servers for the
answer to a DNS question. For example, let’s imagine that a client in a domain wants to discover
Microsoft.com’s address to get to its Web servers. A local AD domain (e.g., Corp.com) probably
wouldn’t know the answer. However, by leveraging the power of forwarders, this server can ask
other servers that might know the answer – and retrieve the answer for the client.
The standard forwarding approach works well for a limited set of circumstances. However,
standard forwarding doesn’t address some situations. For example, imagine the company structure
that the diagram in Figure 4.13 represents: two separate domains that have little to do with each
other.

Figure 4.13
An example company’s DNS configuration
Internet
Forward Forward
CORPNS1 RESEARCHDNS1
CORPSQL1 RESEARCHFILE1
corp.com research.internal.com
However, let’s suppose that from time to time, users in the separate domains must share
resources. For example, the users in Corp.com occasionally need to connect to a computer named
Researchfile1.research.internal.com. And the users at Research.internal.com occasionally need to
connect to CorpSQL1.corp.com. The diagram in Figure 4.13 indicates that the DNS servers of
Corp.com and Research.internal.com can’t “know about” each other.
If a client in Corp.com asked about locating the Research.internal.com computer in
Research.internal.com, resolving that name wouldn’t be easy. Figure 4.14 shows what happens
when standard forwarding is set up.
Figure 4.14
DNS communications in the example company
Client says “I need Internet

something over at
reasearch.internal.com” Forward Forward
CORPDNS1
IBM Compatible Server says
“Check over here.”

With a standard forwarder, the Corp.com DNS server (CORPDNS1) probably won’t get any
response other than “I can’t find it” from the servers to which it forwards. The reason is that the
servers forward to a common point (the ISP or the Internet). In such a scenario, the two DNS servers
can’t “see” each other.
Under Win2K, you could fix this problem – but in a sloppy way. That is, you could have the
Corp.com DNS server house a secondary-zone copy of Research.internal.com, and the
Research.internal.com DNS server house a secondary-zone copy of Corp.com. However, this solution
is messy because every time a new record is entered into DNS, a copy of that record must be sent
to the other DNS’s secondary-zone copy. Depending on how you have the zones configured, the
updating can take extra administrative effort and more bandwidth.
If you could tell the Corp.com DNS server where to look for Research.internal.com resources,
you could solve this problem. Windows 2003’s conditional forwarding lets you do exactly that, as
Figure 4.15 shows.
Figure 4.15
DNS communications with conditional forwarding
CORPDNS1 Server says

“Check over here.”
Client says “I need

something over at
reasearch.internal.com” Internet
Forward Forward
IBM Compatible
Conditional forwarding eliminates the need to house unnecessary secondary-zone DNS files in
servers that really shouldn’t have them. Conditional forwarders let you keep copies of only the DNS
zone files you want – without any extras.
Setting Up Conditional Forwarding

You need to set up conditional forwarding just as you set up standard forwarding for Win2K – that
is, conditional forwarding is unique to each Windows 2003 DNS server. Right-click the server name,
select Properties, then click the Forwarders tab, as Figure 4.16 shows.

Figure 4.16
Windows 2003’s DNS Forwarders tab
To set up conditional forwarding for a DNS domain, select the domain name, click New,
and type the name of the domain and the IP address. Figure 4.16shows that this server will forward
all requests asking about resources in the Research.internal.com domain to 192.168.2.11.
Stub Zones
Stub zones are another feature new to Windows 2003 DNS. Like conditional forwarding, stub zones
solve a problem. (Also like conditional forwarding, stub zones aren’t new to other non-Microsoft
DNS implementations, such as BIND 9.0.) Figure 4.17 presents a DNS configuration that shows the
need for stub zones.

Figure 4.17
A second example company’s DNS configuration
Internet
rd
wa
For
Forward Forward
CORPNS1 INTERNALROOTDNS RESEARCHDNS1
As Figure 4.17 shows, you have two unrelated domains asking a central Root DNS for
information. Suppose a client request comes in from Corp.com asking about resources in
Research.internal.com. You can read the “conversation” between the client and the DNS servers
in Figure 4.18’s internal captions.

Figure 4.18
A successful lookup with manual delegations
Internet
INTERNALROOTDNS
Server says
“I know where
research.internal.com
is – let me point
rd
you toward a
wa
research.interal.com
For
server that knows
Client says “I need the answer and is
something over at authoritative for the
reasearch.internal.com” zone.”
Forward Forward
INTERNALROOTDNS
CORPDNS1 Server
says “Follow the
forward.”
Client A
In this scenario, ClientA asks CorpDNS1.corp.com for the answer, which forwards to the
InternalrootDNS server. The InternalrootDNS server then looks up in its table the list of servers
that are authoritative for the Research.internal.com domain (i.e., servers that respond to Start of
Authority – SOA – requests). However, what happens if Research.internal.com gets three more
DNS servers – each capable of responding to the SOA request? Such a scenario could evolve if
Research.internal.com introduced three more DCs that run DNS in AD integrated mode.
At this point, the InternalrootDNS server would know about the original ResearchDNS1 server
only – and not about the three newly introduced DNS servers. For the InternalrootDNS server to
know about the new DNS servers in Research.internal.com, someone would have to manually update
the InternalrootDNS server. That design isn’t as responsive to change as you might need it to be.
Stub zones introduce a new technique to help address this situation. Stub zones “learn” about
new DNS servers introduced into other domains. Figure 4.19 shows the different communication that
occurs if you use stub zones after the new DNS servers are introduced in Research.internal.com.

Figure 4.19
Stub zones and DNS changes
Internet
CORPDNS1 Server says
“Let me check my stub-zone for
research.internal.com – a definitive
list of research.internal.com servers
which are SOA for the zone.”
rd
wa
For
Client says “I need
something over at
reasearch.internal.com”
Forward
Forward
INTERNALROOTDNS Forward your RESEARCHDNS1

CORPNS1 request to a RESEARCHDNS2
DNS server
that is SOA
for the zone.
Client A
CORPSQL1 RESEARCHDNS3 RESEARCHFILE1
Creating Stub Zones

You create a stub zone as you would create any DNS zone. That is, you right-click the server and
create a new zone. Then, you select the zone type, as Figure 4.20 shows.
Figure 4.20
Creating new stub zones

At this point, you can choose how widely you want to replicate the stub-zone information.
You specify the zone for which you want to create a stub zone. You should then have a functioning
stub zone.
j Tip
If your stub zone doesn’t activate right away, right-click Reload from Master to jump-start the
stub zone.
Conditional Forwarding vs. Stub-Zones

Conditional forwarding and stub zones accomplish similar results. When should you choose one
over the other? Conditional forwarding gets the job done. But if the servers you list in the Forwarders
tab go down and new ones go up, you must manually update the list. Also, conditional forwarding
must be configured individually on each DNS server you set up. One misconfiguration could cause
problems for a while.
In contrast, if you create a stub zone in the source domain for the target domain, DNS servers
can go up and down at will in the target domain – and the source domain is always updated.
Additionally, you can make a stub zone AD-integrated. That means if you create the stub zone in
the source domain once – all AD integrated DNS servers will be aware that you want to use stub
zones for certain target domains. You perform a one-time configuration – and you’re done.
Next: Windows 2003 Security Enhancements

In this chapter, I examined the security ramifications of cross-forest trusts and how to address
some potential vulnerabilities, including by using selective authentication. I review how you set up
an authentication firewall. After the authentication firewall is in place, you must do some manual
labor to open each specific gate to let users in other forests gain access through cross-forest trusts.
I also discussed some Win 2K DNS limitations and how Windows 2003 works around them with
conditional forwarding and stub zones.
In Chapter 5, I’ll present Windows 2003 security enhancements. If you have older clients that
you can’t get rid of, Chapter 5 will be especially relevant to you. If you have all newer clients, you’ll
learn what makes those clients more secure than ever.

81
Chapter 5:
Windows Server 2003

Security Enhancements
In Chapter 4, I considered what happens when you merge two environments, including how to
create secure forest trusts and deploy new Windows Server 2003 (Windows 2003) DNS features to
make a merged environment workable. Although I discussed some security concerns – particularly,
how to keep all but those you choose from accessing the resources you need to protect – Windows
2003 brings much more to the table for your protection effort.
In this chapter, I cover some of the new security enhancements that you can use to ensure a
more secure environment day to day. I review improvements in securing file shares and in ACL
viewing and editing for better control of file permissions. I discuss the InetOrgPerson object and the
ease of new schema modification functions that can help you take better advantage of AD. I also
include a tip or two about how to shore up different parts of your Active Directory (AD) to make
them a bit more secure.
Securing the Wire

Microsoft has a history of being burned by the vulnerability of its internetworking protocols. The
protocol tradeoff is easy to understand: If you make protocols fast, light, and only cursorily secure,
they’re speedier on the wire – and you can deploy them more quickly and widely. However,
unsecure protocols on your network can compromise your company’s resources.
With that in mind, Windows 2003 introduces both new restrictions and new options for some
familiar scenarios. The changes in Windows 2003 means that you must better understand available
security functions such as Server Message Block (SMB) signing, secure channel signing, Lightweight
Directory Access Protocol (LDAP) signing, and password authentication methods.
Shoring Up with SMB Signing

Not all users can drop their deployed desktops and switch to Windows XP Professional or Windows
2000 Professional. Legacy (aka “downlevel”) clients are all too familiar to IT staff. In fact, some orga-
nizations include clients that have not only different Windows OSs but also different service packs
applied, which can make it especially difficult to ensure a baseline of protection across the network.
Wherever it can, Windows 2003 endeavors to make things more secure than its predecessor. One
way in which it attempts greater security is by using SMB connections. The SMB protocol comes into
play when clients connect to shares. When you performed your first Dcpromo to Windows 2003, you
saw the Active Directory Installation Wizard screen that Figure 5.1 shows.

Figure 5.1
Warnings about downlevel machines
The screen in Figure 5.1 indicates that you might have problems with older downlevel machines.
The good news is that connections to every Windows 2003 share will be “signed” (i.e., authenticated)
each time a client makes a connection. Indeed, each SMB packet carries a unique signature that the
recipient validates. Therefore, malicious users can’t pretend to be what they’re not.
The bad news, however, is twofold. First, older downlevel clients will fail to connect because
they can’t “speak” the revised protocol’s language. Second, when clients can use SMB signing, it will
slow connections down a bit, probably by 10 percent to 15 percent.
The real problem, however, is that because older downlevel clients can’t perform SMB signing,
they can’t log on. To log on to the network, each client must connect to a domain controller’s (DC’s)
Netlogon share. Therefore, each client must be able to perform SMB signing to that Netlogon share to
validate to the network. Clients that can’t perform SMB signing are out of luck. Because Windows 98
can respond to SMB signing, you’ll only need to troubleshoot problems. Also, you can make changes
to address SMB signing for Windows NT 4.0 and Windows 95 clients.
Win98 Clients
Win98 clients, by default, can respond to SMB signing requests. This capability means that you don’t
have to change or set up anything on your Win98 clients for them to participate in domains with
Windows 2003 DCs.
However, if you have one or two Win98 clients that can’t log on to Windows 2003 DCs or
connect to Windows 2003 shares, the client’s ability to respond to SMB signing might be disabled.

Chapter 5 Windows Server 2003 Security Enhancements 83
To turn off a Win98 machine’s ability to respond to SMB signing, someone must manually add a
registry value.
Therefore, if you suspect a Win98 machine isn’t responding to SMB signing requests, you’ll need
to dive into the registry and look for the addition of either of two registry settings.
Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNetsup
subkey and look for an EnableSecuritySignature value of type REG_DWORD. The default is that this
value is absent, which means SMB signing is enabled. To turn off SMB signing, you would create this
value and set it to 0. Therefore, to re-enable SMB signing, set the value to 1 (Enable). The client will
then respond to SMB signing.
Also, look for an RequireSecuritySignature value of type REG_DWORD. The default is 0.
Manually setting the value to 1 (Enable) requires that all SMB traffic be signed.
Again, you’re checking to see whether someone has created these values. If they exist, someone
might well have specifically disabled a machine’s ability to respond to SMB signing.
NT 4.0 Clients
NT 4.0 Service Pack 3 (SP3) clients won’t perform SMB signing by default. You’ll have to enable SMB
signing through the registry, as I discuss below.
If you’ve already loaded your NT 4.0 clients with SP4 or later – the clients can by default respond
to SMB signing requests. Therefore, you won’t need to set up or change anything on your NT 4.0 SP4
clients to have them participate in domains with Windows 2003 DCs.
However, if you have one or two NT 4.0 clients with SP4 that can’t log on to Windows 2003 DCs
or connect to Windows 2003 shares, someone might have disabled the machines’ ability to respond
to SMB signing – in much the same way that I discussed relative to Win98.
Enabling SMB signing on NT 4.0 SP3 machines and troubleshooting NT 4.0 SP4 or later machines
that aren’t responding to SMB signing requests involves the same two registry values. For NT 4.0 SP3
machines, if the values don’t exist, you’ll create them, then set both values to enable SMB signing. If
the values do exist, set them to enable the feature. For NT 4.0 SP4 or later machines, you might
create and set or re-set the values to re-enable the feature.
Navigate to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer
\Parameters subkey and look for an EnableSecuritySignature value of type REG_DWORD. The default
is that the value is absent, which means that the client will respond to SMB signing. A value of 0
means the client won’t respond to SMB signing. To enable or re-enable SMB signing, set the value
to 1 (Enable) – the client will then respond to SMB signing.
Also, look for a RequireSecuritySignature value of type REG_DWORD. The default is 0. Manually
setting the value to 1 (Enable) requires that all SMB traffic be signed.
Win95 Clients
As the Active Directory Installation Wizard screen in Figure 5.1 indicated, Win95 clients can’t log on
to Windows 2003 DCs. If Win95 clients attempt to log on, they get the message that Figure 5.2
shows.

Figure 5.2
Message returned if a Win95 client attempts to log on to a Windows 2003 network
To get your Win95 clients up to speed, you’ll need to load the Active Directory Client Extension
(ADC; aka Directory Service Client – DS Client). The DS Client apparently isn’t on the Windows 2003
CD, but you can find it on any Win2K CD-ROM, in the \CLIENTS\Win9x directory. To run
DSClient.exe, you’ll need to have Internet Explorer (IE) 4.0 or later loaded. Figure 5.3 shows the
Directory Service Client Setup Wizard that you can use to load DS Client onto Win95.
Figure 5.3
Directory Service Client Setup Wizard
After you load the DS Client, Win95 machines won’t need any additional registry settings to
respond to SMB-signed traffic. In other words, just load the DS Client on your Win95 clients, and
you’re “in like Flynn.”

Manipulating the Servers to Not Require SMB Signing

What if you can’t get your clients up to speed? Specifically, what if you can’t reach some client
combination of
• Win98
• NT 4.0 with SP4
• Win95 with ADC
and you still need to have your clients log on to Windows 2003 DCs and connect to Windows 2003
file shares? You have a final option: You can configure the domain to not require SMB signing.
However, this approach is definitely a “last resort” because it really decreases the intended security.
Nevertheless, if you must disable SMB signing, click Start, Programs, Domain Controller Security
Policy. Navigate to Windows Settings\Security Settings\Local Policies\Security Options. Locate
Microsoft network server: Digitally sign communications (always), which Figure 5.4 shows. With the
Define this policy setting check box selected, change the default from Enabled to Disabled.
Figure 5.4
Disabling SMB signing

j Tip
Even if you need to disable SMB signing as described above, you can still leave the sister policy,
Microsoft network server: Digitally sign communications (if client agrees), enabled without
penalty. This setting lets clients and servers that can use SMB signing do so.
Shoring Up with Secure Channel Signing

When Windows 2003 DCs and client workstation and server members communicate about their status
in the domain, they do so over a “secure channel.” Communications about status occur when domain
members join, leave – or their computer passwords are automatically updated between the computer
and the domain.
Windows 2003 DCs require that these secure channel actions be digitally signed. XP, Win2K, and
NT 4.0 with SP4 or later can participate in secure channel signing without any modification. Win9x
machines aren’t strictly “domain members” and therefore don’t use the secure channel or participate
in secure channel signing. For the purposes of secure channel use and secure channel signing, you
can ignore Win9x machines. However, if you have NT 4.0 machines without SP4, you need to either
upgrade those systems to SP4 or disable secure channel signing in the domain.
If you must disable secure channel signing, click Start, Programs, Domain Controller Security
Policy. Navigate to
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. In
the list of policies and policy settings, locate Domain Member: Digitally encrypt or sign secure
channel data (always). With the Define this policy setting check box selected, change the default
from Enabled, which Figure 5.5 shows, to Disabled. The change disables the requirement for secure
channel communications with domain members. Again – only disable secure channel communications
if you can’t upgrade your NT 4.0 machines to SP4 or later.

Figure 5.5
Disabling secure channel signing
Shoring Up with LDAP Signing

After you introduce your first Windows 2003 DC, you’ll want to start using the new Windows 2003
administration tools. The good news is that these tools all enforce another new security feature. That
is, many of the Windows 2003 administrative tools work only when LDAP signing protects the
communication.
LDAP signing guarantees that nothing tampers with the communications and data that flow
between your administrative workstation and DCs. When you use the Windows 2003 administration
tools, all your DCs must be able to perform LDAP signing. To support LDAP signing with Win2K,
you need to load Win2K SP3 on each DC and restart the DC.
Even if you can’t load SP3 on all your Win2K DCs, you might still want to use the Windows
2003 administration tools to manage all your DCs. To do so, you can turn off LDAP signing on your
administrative workstation (usually XP). Doing so will let the communication go over the wire
unsigned, which might leave the traffic vulnerable to sniffing. Do so at your own risk.
After you load the Windows 2003 administration tools on your XP administrative workstation,
you’ll need to modify the registry on your machine. Navigate to the HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\Windows\CurrentVersion\AdminDebug\ADsOpenObjectFlags subkey on
your administrative workstation. Set the ADsOpenObjectFlags value to 0x03. Restart the administrative
tools. You’ve now turned off LDAP signing between your administrative workstation and all DCs.

j Tip
For more information and to see which specific applets inside the Windows 2003
administration tools explicitly use LDAP signing, go to Knowledge Base article Q325465,
“Windows 2000 Domain Controllers Require SP3 or Later When Using Windows Server 2003
Administration Tool,” at the Microsoft Product Support Services (PSS) URL below:
http://support.microsoft.com/?kbid=325465
Shoring Up by Eliminating NTLM and LM

The most vulnerable part of your network is still your users’ passwords. As you know, you need as
strong a password policy as possible without getting too much resistance from your user community.
However, it’s equally important to ensure that the passwords can’t be “stolen” on the wire. First, let
me review the available password authentication methods.
Clients can authenticate their passwords to a DC four ways. Those methods, listed from strongest
to weakest are
• Kerberos – Kerberos is the strongest authentication method. Kerberos ensures that both the client
and the server mutually authenticate each other or the password isn’t accepted. You’ll find
Kerberos authentication in Windows 2003 and Win2K DCs and in Win2K and XP clients.
When it’s available, Kerberos is the default authentication mechanism.
• NT LAN Manager (NTLM)v2 – NTLMv2 is the next strongest authentication method, and no
one’s cracked it yet. NTLMv2 enhances NTLM authentication by strengthening the encryption
mechanism.
• NTLM – NTLM includes password encryption as well as signing. However, inherent elements
make NTLM authentication easy to crack.
• LM – LM is the weakest authentication method. It’s the default authentication method for NT 4.0
without SP4 and for all Win9X machines.
The upshot is that the only two secure mechanisms for password validation are Kerberos and
NTLMv2. If intruders intend to capture traffic on the wire – and the traffic includes NTLM and LM
traffic from NT 4.0 SP3 and earlier or from Win9X – they would soon have the passwords that rely
on the weaker authentication methods.
My suggestion if you have mixed downlevel clients is to accept the default Windows 2003
security – and harden your overall security significantly by eliminating NTLM and LM authentication.
Eliminating the weaker authentication methods could be the most important security step for your
Windows 2003 network.
To eliminate NTLM and LM authentication, follow these steps:
1. Update the client software. For NT 4.0 machines, load SP4. For Win9X machines, load the
AD client, as I described previously.
2. Enable NTLMv2 authentication on the client.

3. At the domain level, refuse NTLM and LM authentication traffic; accept only Kerberos and
NTLMv2 traffic.
Enabling NTLMv2 Authentication at the Client

After you update NT 4.0 machines with SP4 or later and load the ADC on every Win9x client, you
need to take an additional step. The clients must be configured so that they won’t attempt to
authenticate through NTLM or LM, but rather with NTLMv2. Enabling authentication at the client is
slightly different for each client type, as I describe below.
NTLMv2 for NT 4.0 Clients

To set an NT 4.0 with SP4 or later client to use NTLMv2 only, you need to modify each computer’s
registry. In HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA subkey, locate the
LMCompatibilityLevel value and set it to 3 to permit NTLMv2 authentication only.
j Tip
You can set additional registry options at this time. For more information, read the Knowledge
Base article Q147706, “How to Disable LM Authentication on Windows NT,” at the URL
below.
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb
/articles/q147/7/06.asp&NoWebContent=1
NTLMv2 for Win9X Clients

For both Win98 and Win95 clients, you must first load the ADC. However, Win95 also requires
several additional updates before you continue: the Distributed File System (DFS) client (which you
can download from http://microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/default.asp)
along with two updates available in one package: WinSock 2.0 Update and Microsoft Dial Up
Networking (DUN) 1.3 (which you can download together from http://www.microsoft.com
/windows95/downloads/contents/WURecommended/S_WUNetworking/dunwinsky2k/Default.asp).
To set a Win9X client to use NTLMv2 only, you need to modify each computer’s registry. In the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control subkey, create an LSA registry subkey.
Then, add the value LMCompatibility of type REG_DWORD and set the value to 3.
j Tip
You can set additional registry options at this time. For more information, read the Knowledge
Base article Q239869, “How to Enable NTLM 2 Authentication,” at the URL below.
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb
/articles/q239/8/69.asp&nowebcontent=1

Disabling NTLM and LM at the Domain Level

After you’ve set up NTLMv2 support all your clients, you’re ready to disable both LM and NTLM
authentication at the DCs. You’ll perform this action inside the Domain Security policy. Once open,
navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options and locate the policy named Network Security: LAN Manager. With the Define this policy
setting check box selected, define the policy Send NTLMv2 response only\refuse LM & NTLM, from
the drop-down list that Figure 5.6 shows.
Figure 5.6
Defining authentication levels
d Caution
If you disable NTLM and LM responses, you lock out clients that support only those
authentication methods, including Macintosh clients and Services for UNIX (SFU) clients. The
disabling could also be harmful to alternate authentication methods such as Win2K Routing and
Remote Access Service (RRAS); Cisco, Shiva, or Ascend dial-in modems; and other products
that use Windows authentication. Such products might rely on NTLM or LM authentication.
Additionally, although it’s not strictly necessary, it’s also good to expunge the recorded traces of
LM passwords from your DCs. You can do so by selecting the Group Policy Network security: Do

not store LAN Manager hash value on next password change policy, which Figure 5.7 shows. With
the Define this policy setting check box selected, you define and enable the policy.
Figure 5.7
Eliminating LM password hash values from DCs
After you’ve enabled this policy, the AD doesn’t store the LM values when users’ passwords are
changed. If a DC is compromised, no one will be able to use the values to gain access.
ACL Viewing and Editing Improvements

One day-to-day problem that Windows 2003 has overcome involves file permissions. With Win2K,
Microsoft added directory level inheritance; that is, if you had permissions, or rights, explicitly set
upon a folder, folders below the original folder automatically inherited those permissions, as the
diagram in Figure 5.8 shows.

Figure 5.8
Overview of Win2K and Windows 2003 inheritance
Joe’s rights are explicitly

placed upon this folder The rights are simply
calculated via inheritance—
there need not be a specific
ACL on the folder
Inherited
Joe User
Directory1 Joe User
Sales
In
he
Directory2
rit
ed
Joe User
Marketing
Directory3
In Win2K, however, it was difficult to determine the effective permissions in a lower directory.
Effective permissions come into play whenever a user or group might have explicit permissions and
inherited permissions. How can you know what the effective permissions are?
For example, consider Directory 2 in Figure 5.8. What are Joe’s effective permissions if he inherits
rights from Directory1, but is also a member of Sales, which has its own permissions?
You can see that permissions could quickly become confusing. To combat this confusion,
Windows 2003 has added a new ACL editor that lets you easily discover and edit permissions. With
Windows 2003, you’ll find an Effective Permissions tab on every directory and file.
Simply right-click and select Properties for the directory or file whose effective permissions you
want to examine, select the security tab, and click the Advanced button. You can then click the
Effective Permissions tab, which Figure 5.9 shows.

Figure 5.9
Windows 2003’s new ACL editor
Just click Select, select a user or group, and you can see the precise access control placed upon
that object for a specific user or group. The new ACL editor makes knowing “who” has permissions
“where” a lot easier.
Security Principals Update

Win2K has many object types (e.g., users, groups, contacts, organizational units – OUs). Windows
2003 adds a new type of object: InetOrgPerson. In Windows 2003, an InetOrgPerson object has many
of the same features and attributes as a regular user object, including
• Name,
• Phone number,
• Logon account restrictions,
• Password
So why might you need the InetOrgPerson object if user objects already work well in Windows
2003? Because InetOrgPerson objects comply with Request for Comments (RFC) 2798, whereas
regular user objects don’t. This difference is a concern in a limited set of circumstances. You might
need InetOrgPerson objects if you use a third-party metadirectory service (e.g., Sun’s iPlanet) to

update both your AD and your iPlanet directory. iPlanet expects its input and output to be an
RFC-compliant InetOrgPerson object – not a Windows 2003/Win2K user object. You can check out
the InetOrgPerson RFC at http://www.faqs.org/rfcs/rfc2798.html. InetOrgPerson objects are easy to
create, potentially useful, and have few drawbacks.
You can create an InetOrgPerson object as easily as you create a new user object. Figure 5.10
shows how you create an InetOrgPerson object in the Active Directory Users and Computers console.
Figure 5.10
Creating an InetOrgPerson object
You can create your “User” objects the standard way or choose to make them “InetOrgPerson”
objects. You incur no penalty if you make your user objects InetOrgPerson objects rather than User
objects. However, you should continue to use regular User objects unless you know you need
InetOrgPerson objects to be 100 percent compatible with RFC-compliant metadirectory services.
d Caution
You should be aware that InetOrgPerson objects aren’t compatible with Exchange 2000.
That is, you can’t enable an InetOrgPerson mailbox.

Schema Updates and Modifications

Although modifying the schema is always risky, Windows 2003 makes it easier to write applications
that modify the schema and take full advantage of AD. If you upgraded your domain from Win2K to
Windows 2003, you already modified the schema by running Adprep.
Additionally, several Microsoft and third-party applications modify the schema. One Microsoft
application that modifies the schema is the upcoming Systems Management Server (SMS) 2003 (still in
beta), which Figure 5.11 shows.
Figure 5.11
SMS 2003 (not yet released) option to extend the schema
Schema updates have been permanent – until Windows 2003. That fact made many developers
hesitate to write applications that leveraged the advantages of a schema update. Win2K application
developers had a problem if they ever wanted to distribute an update to their application that
changed their use of the schema.
For example, if an application vendor had made a schema modification by adding an attribute
called SHOE SIZE, which accepted a numeric value – that modification might work well at the time.
However, if the vendor then wanted to update the attribute to accept a character (e.g., S, M, L) rather
than a numeric value, the vendor would have to introduce another schema modification attribute to
accept the value types desired. This situation occurred because “under the hood” of the schema, each
attribute is assigned a unique Object Identification Number (OID).

Win2K allows a schema attribute to be considered “defunct.” This ability to change the “status”
works well; however, if you consider the example above, in which the vendor wants to change the
SHOE SIZE attribute from accepting numbers to accepting characters, the vendor would have to get
another OID and code the application to insert yet another permanent schema addition to add the
new attribute.
Windows 2003 also lets a schema attribute be considered defunct. However, you can reuse the
underlying OID with a different name or value. Additionally, you can set attributes to be Defunct or
Active at any time.
n Note At no time is the attribute ever truly deleted. Rather, the attribute is classified as defunct so
that you can reuse its OID.
j Tip
According to rumor, future versions of AD will support “tombstoning” and purging defunct
schema definitions. Tombstoning is similar to deleting except that when you tombstone, you
inform other servers that you’re removing the schema object definitions so that those servers
can update their databases. Again, Windows 2003 doesn’t yet support these features.
If you have an attribute you want to designate as defunct, you’ll need to follow several steps,
as I outline below. First, you’ll need to register the schmmgmt.dll with regsv32.exe, as Figure 5.12
shows.
Figure 5.12
Registering the schmmgmt.dll

d Caution
Any changes you make to the schema are at your own risk. Make changes to the schema only
in a test lab. To modify the schema, you must enter a registry value in the registry upon the
schema master. By default, AD servers don’t let anyone edit the schema.
To modify the schema, navigate to the HKLM\SYSTEM\CurrentControlSet\Services\NTDS

\Parameters subkey. Enter a value named Schema Update Allowed of type REG_DWORD and set it
to 1, as Figure 5.13 shows.
Figure 5.13
Entering a registry value before you modify the schema
Next, add the Active Directory Schema snap-in to the Microsoft Management Console (MMC).
Figure 5.14 shows how you select Active Directory Schema to add it as a standalone snap-in.

Figure 5.14
Adding the Active Directory Schema snap-in
By default, you can’t see defunct objects. If you want to see them, right-click the Active Directory
Schema and select View, Defunct Objects, as Figure 5.15 shows.

Figure 5.15
The view inside the schema
To make an object defunct, locate the attribute, examine its properties, and clear the default
Attribute is active check box, as Figure 5.16 shows.
Figure 5.16
Clearing the Attribute is active check box

At this point, you can create a new attribute with the same OID but a different name and value
type. Windows 2003’s improved schema modification functions make it easier for application vendors
to write applications that modify the schema to get the most from AD.
Next: Backup, Restore, and Recovery

Windows 2003 definitely offers improved security – with SMB signing, secure channel signing, and
LDAP signing as the defaults. However, if you have clients on which you can’t load the service packs
or ADC to let them participate in these security measures, you might need to reduce server-side
security to let your clients function.
As the text makes clear, it might be a good idea to strengthen the fortress a bit by removing all
NTLM and LM communications, but be sure to test the impact of removal before you make your
move. (You don’t need hordes of angry laptop users who can’t connect through your third-party
dialup.)
Finally, the improvements in the ACL viewer and editor, the new InetOrgPerson object, and the
new schema modification functions are useful add-ons. All in all, Windows 2003 makes it a more
secure world.

101
Chapter 6:
Backup, Restore, and Recovery

for Windows Server 2003 and
Active Directory
Performing backups is a system administrator’s single most important task. However, because having
backups sometimes isn’t enough, you need skills that go beyond the ability to back up and restore
files. In this chapter, I describe some common scenarios in which things go wrong – from a server
going belly up to objects in Active Directory (AD) being inadvertently deleted.
Windows Server 2003 (Windows 2003) gives you many ways to get your system back to business
as usual. I’ll show you how to use the techniques and features it offers – before you have to swing
into action to save the day (and your job). I discuss using the Recovery Console (RC), deploying the
new Emergency Management Services (EMS) feature, performing an AD backup and restore, enabling
Automated System Recovery (ASR), and replicating DCs from media with the new Install from Media
(IFM) feature.
Using the RC
When Microsoft released Windows 2000, one of my new favorite features was the Recovery Console
(RC). The RC could help you address a persistent problem that many of you will remember.
Before the advent of the RC, if a server went belly-up and you needed to perform surgery on it,
doing so was difficult if the underlying file system was NTFS. Booting from a floppy disk wouldn’t let
you see or modify NTFS volumes. Given the frustration of working with NTFS in this urgent situation,
thousands of Windows NT 4.0 server administrators kept their OS loaded on FAT partitions – just for
the rare emergency. This approach let the administrators boot to a DOS prompt to edit, rename, or
modify damaged files.
Windows 2003 and Win2K have the RC, a tool whose job is to help when the chips are down.
The RC console lets you load a very small subset of the OS along with a powerful subset of OS func-
tions. Previously, for example, if a service went down while NT 4.0 was running and you needed to
reboot the server, you might be in trouble if the Last Known Good Configuration recovery option
failed to bring your system back. With the RC, you can start and stop services, format disks, and copy
and replace files already on the disk. Basically, the RC contains much of what you’ll need should
things on a particular Windows 2003 or Win2K server go awry.

You can use the RC two ways: preloaded or loaded on the fly. Preloading the RC requires
only about 7MB of disk and adds an additional boot option to the boot.ini file. To preload the RC,
insert the Windows 2003 CD-ROM and open a command prompt. From the CD-ROM, run winnt32
/cmdcons. The RC will contact Microsoft for any last-minute updates, then perform the installation,
as Figure 6.1 shows.
Figure 6.1
Installing the RC
After the files are copied, you can see the fruits of your labor. Simply reboot the server and look
for the new RC line added to the boot.ini file, which Figure 6.2 shows.
Figure 6.2
RC line item in the boot.ini file

Chapter 6 Backup, Restore, and Recovery for Windows Server 2003 and Active Directory 103
After you enable the RC, you’re asked to log on. If this server is a member server or standalone
workstation, you log on with the local Administrator password. If this server is a domain controller
(DC), you log on with the Directory Services Restore Mode password that you input when you
created this DC. (I discuss the Directory Services Restore Mode password in the upcoming AD
Nonauthoritative Restore section.) If you try to log on with the domain Administrator account
password, you won’t be permitted to use the RC, as Figure 6.3 shows.
Figure 6.3
Attempted logon to a DC with RC installed using the domain Administrator password
After you log on to the RC successfully, you have an array of tools at your disposal, as Figure 6.4
shows. I encourage you to familiarize yourself with the tools in the RC, so you’ll be ready to use
them when you encounter a problem.

Figure 6.4
The RC tools
Among the RC’s abundant tools, some of my favorites are

• Listsvc – Helps determine which services are running and the current state of each service
• Enable and Disable – Changes how services start up (e.g., you can disable services that aren’t
working as they should)
• Bootcfg – Aids you in rebuilding broken boot.ini files by helping you locate instances of
Windows 2003 on the computer
• Expand – Lets you take a compressed file – for example, myfile.sy_ – and expand it to
myfile.sys, which you can then place almost anywhere on the hard drive
j Tip
It’s still fairly difficult to do registry repairs inside the RC. If you need tools to repair the
registry while the server is damaged, I encourage you to check out Winternals Software’s tool
ERD Commander at
http://www.winternals.com/products/repairandrecovery/erdcommander2002.asp

Deploying EMS
When a server is unresponsive, Windows 2003’s EMS can display what’s happening over the
computer’s serial port. You can then use a second device to manage the broken server. Before I
discuss EMS further, however, I’ll review the usual options for monitoring server operations and
troubleshooting an unresponsive server.
When a server is running and you want to observe what’s going on, you have several options.
If the machine is running well, you can peek in through the built-in administrative Terminal Services
that I described in Chapter 1 (Windows 2003 by default loads the necessary files for the equivalent
of Windows 2000 Terminal Services), use Telnet to contact the machine, or tap a host of other tools.
These approaches to monitoring your server are often called “in-band” management – that is, you use
the Ethernet cable to cross the network, look into server operations, and possibly work on the server.
Many datacenters I see have clunky cabinets with racks of monitors, keyboards, and mice. Other
datacenters rack-mount their servers and use a keyboard/video/mouse (KVM) switchbox to switch
between the servers in the rack. Still others have KVM switchboxes that run over TCP/IP, the idea
being that – from anywhere in the enterprise – you can monitor what’s happening on the server
console. Some of these setups are complex and expensive, but the real question is whether they
can help if the server reaches the blue screen stage or completely hangs when you’re at another site
or in another country.
Understanding Out-of-Band Management

When you reach an unresponsive server by an alternate route – through the serial port – the
approach is often referred to as “out-of-band” (OOB) management. Because Microsoft wants you
to be able to run a lean datacenter, the company designed Windows 2003 to work in an OOB
“headless” environment.
Headless means that you can set up, build, run, monitor, restart, and repair a Windows 2003
server without a keyboard, a mouse, or even a video card. And you might be able to do so from
anywhere in your enterprise – in fact, from anywhere in the world. (You usually can’t perform all
those actions with a KVM switch or even with a TCP/IP KVM switch.)
n Note To get the kind of support that Windows 2003’s headless environment provides, you would
usually need to install a third-party card, such as Compaq’s Remote Insight Lights-Out
Edition card.
If your server becomes unresponsive over the network and you can’t use Terminal Services or
Telnet to manage it, you now have Windows 2003’s EMS. The principle underlying EMS is simple:
You install a special piece of software on Windows 2003 that displays what’s happening over the
computer’s serial port. Then, through a second device, you can manage a broken Windows 2003
server.
Any of several pieces of hardware can serve as the second device, as Figure 6.5 shows.
• You might attach a handy Windows Tablet PC running Hilgraeve’s HyperTerminal – or another
portable serial device.

• You might attach a password-protected security modem to the server’s serial port and dial in to
see what’s up.
• You might attach all the servers to a device called a serial port concentrator. Then, you can use
character-based Telnet to get direct access to a specific server.
Figure 6.5
Connecting to a broken server’s serial port
Out of Band /
Alternate Network
Windows 2003 Server
via S
erial
Port
Serial Port Concentrator

via
Ser
ial l-in
Po
rt Dia
via Security Modem

Se
ria
l Phone
Po
rt Company
Typically,
Production Network Ethernet you would
use one
device to
connect to
the server’s
serial port
Laptop Computer

j Tip
Cyclades (http://www.cyclades.com) is one manufacturer of serial port concentrators.
You can find the company’s statement of support for EMS at
http://www.cyclades.com/pressroom/?id=1051617600
No matter which serial connection you choose, the concept is the same: The device isn’t con-
nected to the same network as the broken server. That way, you can reach the server through the
serial port.
Configuring the SAC

The Special Administration Console (SAC) is a key component of OOB management. The SAC is the
EMS command-line environment that Windows 2003 provides. This console is separate from the usual
command-line environment and provides different functions. After you’ve enabled EMS, the SAC is
always running unless EMS components don’t load properly.
For an introduction to the SAC, go to the following Microsoft URLs:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003
/proddocs/entserver/ems_components.asp
/proddocs/entserver/ems_sac_commands.asp
However you choose to manage your damaged server, with EMS, you ultimately use the serial
port. To see for yourself what EMS looks like, you must configure your server to output to the serial
port. You do so through the bootcfg command, which changes parameters in the boot.ini file. You’ll
simply run bootcfg /EMS with additional parameters.
d Caution
Your commands might differ depending on which serial and boot options work for your
hardware.
You’ll automatically add an entry to your boot.ini file that, after a reboot, enables EMS. If you
have a device connected to the serial port through a null-modem connection, you’ll see the output of
EMS as soon as the system reboots. Figure 6.6 shows the results of a successful run of the bootcfg
command as well as the output from the newly changed boot.ini file.

Figure 6.6
Enabling EMS
j Tip
Enabling EMS for the next boot is easy; just be sure to use the same speed for the computer and
the receiving device.
When you reboot the server, you might notice almost imperceptible differences on the boot-up
screen – but little else that’s different. In fact, if the server doesn’t encounter problems, it continues to
boot as usual. However, if you have a device connected to the serial port of the server, you’ll see the
SAC, which Figure 6.7 shows. In this example, I have a laptop running HyperTerminal connected
through a null-modem connection.

Figure 6.7
SAC initialization
After the SAC is loaded, you can choose to

• restart the unresponsive server
• shut down the server
• open one or more command prompts
• set a different IP address for the server, which is useful should the server need to be moved to a
different segment
• manually crash the system, which is useful if you want to generate Crashdump data for Microsoft
Product Support Services (PSS – Microsoft might request Crashdump information to troubleshoot
particularly sticky problems)
Figure 6.8 displays SAC commands. Reading through the list gives you a sense of the actions you
can take.

Figure 6.8
SAC commands
d Caution
Usually, you’ll want to avoid Crashdump because it will, as its name implies, crash the system
and create a dump.
What’s amazing about the SAC is that if your server encounters a blue screen (or if you force
one through the SAC’s Crashdump command), you’ll see the blue screen output on your serial-port
connected terminal session, as Figure 6.9 shows.

Figure 6.9
Windows 2003 server crash SAC output
Understanding !SAC
Telnet and Terminal Services work well when the system is running – in which case, you can
use in-band management. The SAC makes the difference when things aren’t going well (e.g.,
misconfigured IP addresses, service problems, blue screens) over the usual network channel.
However, if a machine is completely unresponsive (i.e., the machine might or might not have
displayed the blue screen but is 100 percent hung), you still have !SAC.
!SAC (usually pronounced Bang SAC) is a special Windows 2003 mode. !SAC provides a limited
subset of what you can do through OOB. Basically, you can restart the computer and redirect
onscreen blue screen messages. You can’t choose !SAC mode to perform these functions, however;
the underlying system chooses it for you.
For more information about !SAC, go to the following Microsoft URL:
/proddocs/entserver/ems_!sac_commands.asp

Additional EMS Thoughts

EMS, SAC, and !SAC offer OOB management with terrific benefits. However, you might be able to get
additional benefits depending on which kind of BIOS and hardware you use for your Windows 2003
server. For example, if you need to change the boot order or another BIOS setting, your BIOS might
or might not be capable of redirecting its output to the serial port. You’ll need to check with your
server vendor to ask whether your server BIOS supports redirection to the serial port.
You can do much more with EMS, headless servers, and the SAC, including building machines
from scratch – all through the serial port. For more information about EMS and headless servers,
go to the following Microsoft URL: http://www.microsoft.com/whdc/hwdev/platform/server/headless
/default.mspx
Performing an AD Backup and Restore

If you open up your Windows 2003 and Win2K Active Directory Users and Computers console,
you’re likely to see a sea of organizational units (OUs) full of users. A portion of your directory might
resemble the DomainA.com directory that the diagram in Figure 6.10 represents.
Figure 6.10
DomainA.com AD directory
John
Sally
Sales
Dirk
Jeff
West Coast Sales
Edna
East Coast Sales James
DomainA.com

AD can be a pretty treacherous place, with many administrators performing lots of work at
all times. What happens if an administrator inadvertently deletes Jeff’s account? Or worse, an
administrator deletes East Coast Sales and everyone in it? Or worse yet, an administrator deletes Sales,
all the OUs below it, and everyone in them?
Although a little panic is understandable, if you stay calm, you can get your AD accounts back.
Doing so, however, takes some pre-planning and a little good fortune.
AD Backup Essentials
Backing up AD is relatively straightforward. Simply perform a system state backup of one DC. A
server’s system state is its nucleus. If you back up a DC’s system state, you have the contents of AD.
d Caution
If you must perform a restore of deleted objects, you need to know that the machine on which
you do the backups is the machine on which you do the restores. Also, to perform a restore, as
you’ll see in the following text, you need to reboot and take the DC offline. Therefore, if you
plan to back up one or two DCs in your environment, make sure that you can reboot those
DCs during the day without penalty.
Performing a System State Backup

With the preceding information, you can use the standard backup tool. Navigate to and select System
State, as Figure 6.11 shows.
Figure 6.11
Backing up the system state

You should back up to a location that you’ll be able to access when this machine is
rebooted – either a tape drive or a file. Remember that you can’t take a system state backup from
one DC and restore that system state to another DC.
Creating an AD Map
Next, you need to make a “map” of your AD. If someone deletes an object, you’ll need to know its
distinguished name (DN) to restore it. As you’ll recall, a DN is a list of items separated by commas
that uniquely identifies an object by using the relative DN for the object and the names of the
container objects and domains that contain the object. The DN is a text representation of an entry in
the directory server database. For example, the object selected in Figure 6.12 would have the DN
cn=James,ou=East Coast Sales,ou=Sales,dc=domaina,dc=com
Figure 6.12
Mapping each object shown by DN
Without a map of your AD that tells you explicitly where each object is listed by DN, you’ll have
a difficult time restoring objects, as the following text discusses.
j Tip
In Chapter 7: Command-Line, Support, and Microsoft Windows Server 2003 Resource Kit
Tools, I’ll show you how to use the Dsquery command to display a list of all the users’ DNs
at once.

AD Nonauthoritative Restore
After you’ve performed your backup, if a problem occurs (e.g., someone deletes James’ account or
East Coast Sales), you can start to recover what was deleted by performing a nonauthoritative restore.
To begin a nonauthoritative restore, you need to reboot the DC on which you created the system
state backup. When you do so, press F8 to get to the special boot options that Figure 6.13 shows.
Figure 6.13
Starting an AD restore
Choose the Directory Services Restore Mode (Windows domain controllers only) option. This
choice enables a special mode that lets you start your restore process.
When the logon prompt appears, you log on with the Directory Services Restore Mode password.
You created and entered this password when you ran Dcpromo and made this server a DC.
j Tip
What if you can’t remember your Directory Services Restore Mode password? You’ll need to
reboot, log on as domain Administrator, and type
Ntdsutil
Then type the command

set dsrm password
which lets you reset your forgotten password.
After you log on, run the backup utility again. Perform a full system state restore to the original
location, as Figure 6.14 shows.

Figure 6.14
Restoring AD on top of itself
After you perform the full system state restore, the records you’ve preserved in the system state
backup will be returned to AD and restored. However, your job isn’t complete until you do an
authoritative restore.
AD Authoritative Restore
After the nonauthoritative restore is complete, you’ll be asked to reboot the machine. Do not reboot!
Instead, close NT Backup and proceed.
d Caution
When you’re asked to reboot the machine following a nonauthoritative restore, do not reboot!
If you reboot, other DCs can override information about the objects you’re restoring.
If you reboot, the AD objects wouldn’t be restored. This situation occurs because when an AD
object is deleted, it’s recorded as deleted and “tombstoned.” That information goes to other DCs,
which also record that the object is slated for deletion and tombstoned. As a result, even though this
DC has restored the object to its own local copy of the AD database, other DCs will override the
restoration with their signal indicating that the object is tombstoned and slated for deletion.

You need a way to communicate to the other DCs that – for the specific objects you want
restored – those DCs should accept a signal to override the communication that those objects are
slated for deletion. That signal is the authoritative restore.
n Note Because AD replication would require a chapter in itself, I’ll keep the information brief here.
However, underneath the hood, the authoritative restore raises the update sequence number
(USN) to a very high number – ensuring that other DCs with lower USNs can’t overwrite the
objects you’re restoring. For a comprehensive article about USNs with AD backup and restore,
see my article at http://www.mcpmag.com/features/article.asp?editorialsid=166
and the following Windows and .Net Magazine article at
http://www.winnetmag.com/articles/index.cfm?articleid=15558
Start your authoritative restore by typing

Ntdsutil
at a command line. Then, to reach the authoritative restore menu, type

authoritative restore
Assuming the inadvertently deleted portion of AD was the East Coast Sales OU and everything in it,
following “authoritative restore,” type
restore subtree "ou=East Coast Sales,ou=sales,dc=domaina,dc=com"

Figure 6.15
Performing an authoritative restore

An authoritative restore ensures that other DCs won’t overwrite the objects you’re restoring after
this DC is rebooted. When you reboot this DC after the authoritative restore is complete, the deleted
objects get the signal to “ride above” the tombstoned objects. That way, the objects are restored to
this DC and replicated to all other DCs.
The New Windows 2003 Backup API

Windows 2003 provides a new API, Tombstone Reanimate, which should be useful in restoring
deleted objects in AD. As you just read, it takes a full system state backup of a DC, a reboot, a
nonauthoritative restore, and an authoritative restore – just to get back one user object. The idea of
the new API is straightforward: After an AD object is tombstoned – that is, marked for deletion –
you can have a program “un-tombstone” that object.
I worked with Bill Boswell (http://www.winconsultants.com) and Mark Russinovich
(http://www.sysinternals.com) to test this API. Unfortunately, although we were able to reanimate
tombstones (and get previously deleted objects back from the dead), they resembled the reanimated
animals in Stephen King’s Pet Sematary in that they “weren’t quite right.” Most of their features,
such as group membership and even phone number, weren’t replaced, making the API a lot less
useful than it could be. You can test the code yourself by visiting
http://www.sysinternals.com/files/adrestore.zip.
Enabling ASR
When a major server failure hits, you want to get the server back up and running quickly. Windows
2003’s (and Windows XP’s) Automated System Recovery (ASR) feature lets you recover a system that
won’t start. Before ASR, you had to load the entire OS from CD-ROM, then do a complete restore on
top of the fresh OS installation.
ASR lets you take a snapshot of the system volume and put it on tape or other locally attached
media. Additionally, some information about the backup is preserved to floppy disk. Figure 6.16
shows the Automated System Recovery Preparation Wizard, which lets you enable ASR from within
Windows 2003’s backup utility.

Figure 6.16
The Automated System Recovery Preparation Wizard
n Note ASR lets you take a snapshot of the system volume for later restore.
j Tip
The Automated System Recovery Preparation Wizard backs up the partition the OS uses, but it
doesn’t back up other partitions, such as program and data partitions. Those partitions must be
backed up using standard routines.
When a problem hits, you can simply pop in the most recent set of ASR tapes along with the
floppy disk created for that backup and boot with the Windows 2003 CD-ROM, as Figure 6.17
indicates. While the CD-ROM is booting, press F2 for ASR Recovery, and you’re nearly done.

Figure 6.17
Starting ASR after a disaster
The ASR process will read the floppy disk to determine your disk configuration at the time
you created the backup. After the OS is loaded, the process automatically restores the rest of the
system drive.
ASR can really save time – but the catch is that the backup data must reside in a place that
ASR can reach. ASR can reach only locally attached backup data, such as data stored on tape or disk.
(You can’t access the backup over the network, and you can’t have it waiting for you on specialty
devices such as FireWire – IEEE 1394 – or USB 2.0 drives.)
For more information about ASR, go to
http://www.windows2000faq.com/articles/index.cfm?articleid=37650
/proddocs/entserver/asr_overview.asp
Replicating DCs from Media

Before I wrap up this chapter, I want to discuss one more backup-related issue: the new Windows
2003 option that lets you install from media. IFM solves a serious problem that certain AD
deployments have. Some AD deployments are so large and the pipes between DCs so small that
promoting a new DC becomes painfully slow – or even impossible.
Windows 2003’s IFM option lets you take one DC’s system state and put it on CD-ROM, USB
“thumb drive,” or any other removable media. You can then ship that removable media along with
the server to a destination (or if the server is already at the destination, send just the latest IFM media
set). When you’re ready to promote the target server to DC, run Dcpromo with a special switch (the
Dcpromo /adv switch), and the Active Directory Installation Wizard will prompt for that previously
saved system state, as Figure 6.18 shows.

Figure 6.18
Deploying IFM to copy domain information
The newborn DC gets about 99 percent of the AD information from the removable media it has
locally. You can get the remaining 1 percent of information over the network. Now, deploying DCs
across even pathetically slow links is virtually a guaranteed success.
n Note You start with a system state you already have, put it on removable media, and ship it with (or
to) the DC-to-be. Then, run Dcpromo /adv. When you do, the Active Directory Installation
Wizard offers a special option for promoting a new DC. By using IFM, you can reduce network
traffic and get that DC loaded.
Next: New Tools and Resources

Being able to restore AD is more important than ever; fortunately, doing so is easier than ever. The
Windows 2003 backup and recovery functions I’ve discussed in this chapter take you a long way
toward recovery nirvana.
• RC – Microsoft introduced the RC in Win2K, but the feature has been updated in Windows 2003.
• EMS with SAC and !SAC – EMS, SAC, and !SAC are new in Windows 2003.

• AD backup and restore – Although this function is familiar, it’s good to refresh your knowledge.
Also, I hope that the Tombstone Reanimate API brings forth some goodies from third-party tool
makers.
• ASR – ASR is new in XP and Windows 2003. The tool is handy, but works only if the disk or
tape is locally attached.
• IFM – IFM is a highly useful tool, especially for large AD shops with small pipes and lots of DCs.
Windows 2003 becomes more interesting the closer you look. In Chapter 7, you’ll encounter
Windows 2003’s new built-in tools, support tools, and resource kit tools.

123
Chapter 7:
Command-Line, Support, and

Microsoft Windows Server 2003
Resource Kit Tools
GUI is good. Command-line is better. What’s in the box is tasty. But add-ons are sweeter. Poetry
aside, those lines indicate what this chapter offers. I’ll review how to work with some key Windows
Server 2003 (Windows 2003) tools that offer great benefits – if you know how to use them.
I discuss selected command-line tools, support tools, and resource kit tools. From these tool
sources, you’ll be able to build a custom toolkit tailored to your environment.
Windows 2003 Built-In Command-Line Tools

The advantage of command-line tools is that you can use them without a GUI. This option is helpful
when you use Telnet or, as I discussed in Chapter 6, when you use the Special Administration
Console (SAC) through Windows 2003’s Emergency Management Services (EMS). Additionally, some
tools can run under a normal user context and are therefore useful inside logon or startup scripts.
The downside of command-line tools is the learning curve. The tool names are hard to
remember, and the multiple options that the tools offer can be equally baffling. However, although
command-line tools can be cumbersome, their benefits typically outweigh their drawbacks.
When it comes to Windows 2003, the Microsoft development team got command-line tools right.
Although not all GUI options are scriptable, those that are scriptable are well implemented and
equally well documented.
To get a list of the command-line utilities available in Windows 2003, open the Help and Support
Center and locate the Command-line reference A-Z, which Figure 7.1 shows. (Notice, however, that
the last tool in the alphabet is Xcopy. Perhaps Windows 2006 will have commands that start with
Y and Z.)

Figure 7.1
The Help and Support Center list of command-line tools
j Tip
Typically, to reach the list of command-line utilities, I type
command line reference
in the search window.
You can also immediately locate the Help and Support Center list of command-line utilities by
opening a command prompt and typing
hh ntcmds.chm

Chapter 7 Command-Line, Support, and Microsoft Windows Server 2003 Resource Kit Tools 125
Windows 2003 offers a bevy of command-line tools – almost too many. To keep the command-
line tool section of the chapter manageable, I’ll limit my discussion to those tools that help you
manage the event log and Active Directory (AD).
n Note Don’t let the myriad options that each tool offers befuddle you. Almost every tool has a /?
option that lists the tool’s options. Alternatively, you can click the name of a tool listed in
Figure 7.1 to display that tool’s command-line options.
Built-In Command-Line Event-Log Tools

The event log is perhaps the most underutilized Windows troubleshooting tool. Event logs record
more useful knowledge than almost any other tool. The problem is that you have to keep checking
them. Although third-party tools can help you consolidate and manage your event logs, you can also
improve your event-log experience with some of the built-in tools at your disposal. I’ll examine three
built-in tools that can help you manage your event logs: Eventcreate, Eventquery, and Eventtriggers.
Eventcreate
Eventcreate lets an administrator create a custom event in a specified event log. If you’re a batch file
junky, and you want to have the status of your jobs reported to the event log, you’ll want to use the
Eventcreate tool.
The Eventcreate syntax from the Help file reads
eventcreate [/s Computer [/u Domain\User [/p Password]] {[/l {APPLICATION | SYSTEM}] |
[/so SrcName]} /t {ERROR | WARNING | INFORMATION} /id EventID /d Description
n Note According to Microsoft’s formatting legend, italics indicate information the user must supply;
boldface indicates something the user must type exactly as shown; an ellipsis indicates a
parameter that can be repeated in a command; brackets indicate optional items; braces
indicate choices from which the user must choose one only; and Courier font indicates code or
program output.
Figure 7.2 shows a sample batch file script that, if a flag file is found, reports the finding to
the event log.

Figure 7.2
Deploying Eventcreate
When the script reports the finding to the event log, the result appears in the format that
Figure 7.3 shows.
Figure 7.3
Result of an Eventcreate finding
The Eventcreate tool is handy, but it becomes even handier when you use it with utilities such as
Eventquery and EventCombMT. (I discuss EventCombMT in the Windows 2003 resource kit utilities
section toward the end of the chapter.)

Eventquery
Eventquery’s purpose is to query event logs on Windows 2003 servers for information already in the
logs – including information you set the event logs to capture through Eventcreate. However, if you
try to use the Eventquery tool without preparation, you get the message that Figure 7.4 shows. You
first need to change the default command processor.
Figure 7.4
Changing the default command processor
At the command prompt, type

cscript //H:CSCRIPT //S
which changes the command processor from the interactive GUI script processor to CScript.
The Eventquery syntax from the Help file reads
eventquery[.vbs] [/s Computer [/u Domain\User [/p Password]]] [/fi FilterName] [/fo {TABLE |
LIST | CSV}] [/r EventRange [/nh] [/v] [/l [APPLICATION] [SYSTEM] [SECURITY] ["DNS server"]
[UserDefinedLog] [DirectoryLogName] [*] ]
If I want to query all events that have event ID 106 in the Application log of the server I’m currently
on, for example, I can type
eventquery.vbs /FI “ID eq 106” /l Application
and get the results that Figure 7.5 shows. Note that the response is available because I entered event
ID 106 onto this server with Eventcreate.

Figure 7.5
Querying a server with Eventquery
Eventtriggers
The Eventtriggers tool ties your event-management efforts together. That is, when an event you want
to monitor pops into the event log, you can have Eventtriggers notify you or set a command to
execute automatically. It’s like having someone dedicated to monitoring the server logs and acting
upon them if necessary.
The Eventtriggers tool includes three commands:
• Eventtriggers create
• Eventtriggers query
• Eventtriggers delete
For monitoring and notification to occur, you must first create the Eventtrigger, which will then
monitor and act upon the occurrence of logged events that meet the criteria you set up. After you
create some triggers, you can see them at work by using the Eventtriggers query command. You can
delete Eventtriggers with the Eventtriggers delete command.
As an example, I’ll create an Eventtrigger for event ID 106. That is, if event ID 106 appears in the
Application log, Eventtriggers fires off a batch file in response. In this example, I use the syntax
eventtriggers /create /tr “FilePresent” /l application /eid 106 /tk
\\vmserver2\share\gobatch.cmd
which Figure 7.6 shows. This syntax creates a trigger named FilePresent and checks the Application
log for event ID 106. If Eventtriggers finds event ID 106, it automatically triggers the command
gobatch.cmd
which you can also see in Figure 7.6.

Figure 7.6
Deploying Eventtriggers to trigger actions based on events
n Note You also have available the command Evntcmd, which converts events to SNMP traps, or
notifications. Evntcmd might be useful if you have many SNMP-related devices – and a
management station that’s configured to address SNMP traps. For more information about
SNMP traps, refer to my eBook The Definitive Guide to Enterprise Manageability, which NetIQ
also sponsors. You’ll find the eBook at http://www.netiq.com/offers/ebook/default.asp and the
SNMP information in Chapter 5.
To test my Eventtrigger command syntax, I used the same command that I used when I
experimented with Eventcreate. That is, I created an event with event ID 106, then watched my
trigger react and execute the batch file. (The batch file that Eventtrigger triggers might send an email,
display a pop-up, or perform any number of actions.)
Built-In AD Management Tools

Microsoft has included a suite of command-line AD management tools in Windows 2003’s base
installation. Without your having to write custom scripts, these commands help you perform basic
directory maintenance. I think you’ll find the following built-in AD management tools and their
functions particularly useful.
• Dsadd – Adds objects to the directory
• Dsmove – Moves objects from their current directory location to a new location
• Dsget – Gets information about and displays the properties of directory objects
• Dsmod – Modifies specific attributes of objects already present in the directory
• Dsquery – Locates directory objects that fit specified criteria
• Dsrm – Removes objects or a portion of a directory subtree

Although I lack the space to explore all the built-in tools and their commands in detail, I’ll show
you the essential “ropes” with two of the tools and you can take it from there. I’ll discuss the Dsadd
tool’s Dsadd user command and the Dsquery tool’s Dsquery user command.
Dsadd
Dsadd gives you a simple way to add several kinds of entities to AD quickly. The six Dsadd
commands are
• Dsadd computer
• Dsadd contact
• Dsadd group
• Dsadd OU
• Dsadd user
• Dsadd quota
Dsadd User
The Dsadd user syntax from the Help file looks a little daunting. It reads
dsadd user UserDN [-samid SAMName] [-upn UPN] [-fn FirstName] [-mi Initial] [-ln LastName]
[-display DisplayName] [-empid EmployeeID] [-pwd {Password | *}] [-desc Description]
[-memberof Group;...] [-office Office] [-tel PhoneNumber] [-email Email] [-hometel
HomePhoneNumber] [-pager PagerNumber] [-mobile CellPhoneNumber] [-fax FaxNumber]
[-iptel IPPhoneNumber] [-webpg WebPage] [-title Title] [-dept Department] [-company Company]
[-mgr Manager] [-hmdir HomeDirectory] [-hmdrv DriveLetter:] [-profile ProfilePath] [-loscr
ScriptPath] [-mustchpwd {yes | no}] [-canchpwd {yes | no}] [-reversiblepwd {yes | no}]
[-pwdneverexpires {yes | no}] [-acctexpires NumberOfDays] [-disabled {yes | no}] [{-s Server |
-d Domain}] [-u UserName] [-p {Password | *}] [-q] [{-uc | -uco | -uci}]
Don’t let the extreme set of options deter you from deploying this command. You’ll find that
Dsadd goes well beyond the capabilities of the old Net user command. With Dsadd, you can set
virtually every option typically found in a user object.
For example, you can create a new user object for Jane Martin in DomainA’s marketing
organizational unit (OU). In this example, her first name is Jane, her middle initial is A, and her last
name is Martin. She is a member of the Backup Operators group, and her telephone number is
302-555-1212. You would use the syntax
Dsadd user cn=Jane_Martin,ou=marketing,dc=domaina,dc=com -fn Jane mi A -ln Martin
display “Jane Martin” memberof “cn=Backup Operators,cn=builtin,dc=domaina,dc=com”
tel “302-555-1212”

Figure 7.7
Deploying Dsadd user to add user accounts anywhere in AD
j Tip
Dsadd is particular about its input requirements, especially when you specify the distinguished
name (DN) of the account you want to create and the group or groups to which you want to
add that user account. When you use Dsadd, you’ll need to be precise.
Dsquery
The powerful Dsquery tool lets you search all of AD for specific object types. The Dsquery tool’s
commands are
• Dsquery computer
• Dsquery contact
• Dsquery group
• Dsquery OU
• Dsquery site
• Dsquery server
• Dsquery user
• Dsquery quota
• Dsquery partition
You can also use Dsquery * – which provides a global search through your entire AD.
Again, because I don’t have unlimited space for examples, I’ll restrict my example to one
Dsquery command – Dsquery user.
Dsquery User
You’ll probably use the Dsquery user command often. This useful command helps you locate user
objects in the directory.
The syntax from the Help file reads

dsquery user [{StartNode | forestroot | domainroot}] [-o {dn | rdn | upn | samid}] [-scope
{subtree | onelevel | base}] [-name Name] [-desc Description] [-upn UPN] [-samid SAMName]
[-inactive NumberOfWeeks] [-stalepwd NumberOfDays] [-disabled] [{-s Server | -d Domain}]
[-u UserName] [-p {Password | *}] [-q] [-r] [-gc] [-limit NumberOfObjects] [{-uc | -uco | -uci}]
The best news is that you can keep this syntax very short to get a quick result back. For
example, if you want to check the location of all the users in your domain named Jane, you would
simply type
dsquery user name Jane*
Figure 7.8 shows the results of that query: all the DNs in your domain that include “Jane” in the
name. This kind of DN-related query is particularly handy for backup and recovery purposes should
you need to perform an authoritative restore, which I discussed in the Chapter 6.
Figure 7.8
Deploying Dsquery user to locate users in AD
Windows 2003 Support Tools

The support tools are an important element in maintaining server and AD health. You’ll discover
an excellent set of advanced tools available as an additional install but free on the Windows 2003
CD-ROM.
Support Tools Installation

To locate the support tools, navigate to <cd-rom>:\Support\Tools and launch SUPTOOLS.MSI, which
Figure 7.9 shows.

Figure 7.9
Locate SUPTOOLS.MSI
j Tip
Note that this tools folder also holds automated deployment tools – in Deploy.cab – which you
can explore if you feel adventurous.
After you’ve installed Suptools.msi, you’ll see the results in the Start menu as Windows Support
Tools. You won’t find the specific tools listed. You’ll need to launch the Suptools.msi Help file, which
then displays the list of tools, as Figure 7.10 shows.

Figure 7.10
List of Support Tools in the Help and Support Center
n Note You can get to the screen that Figure 7.10 shows either by starting with Suptools.msi in the
Start menu (then launching Suptools.msi’s Help file) or by going to the Help and Support
Center.

AD Tools
Many of the support tools exist to help you manage AD. You can get a list of AD-related tools by
clicking the Active Directory Management Tools subset, which you can see in Figure 7.10. The tools
listed in the Active Directory Management Tools subset tools are deeply capable; exploring one or
two tools in any depth could fill a chapter.
Some of the tools that I consider AD management tools don’t appear in this tool subset but in
other categories. Dcdiag, the first tool I discuss, is a case in point.
j Tip
You’ll want to examine the Alphabetical List of Tools highlighted in Figure 7.10 to get a feel for
all the tools available.
With your custom toolkit in mind, I’ll discuss a few of the most important tools for day-to-day
AD management. After I discuss Dcdiag, I’ll discuss its Active Directory Management Tools subset
diagnostic counterpart: Active Directory Replication Monitor (Replmon).
Dcdiag
Dcdiag is the Swiss Army knife of AD testing. You carry out most tests by using the syntax
dcdiag /test: <test>
where <test> can be any one of a huge number of options.

For example, you can test whether a domain controller (DC) is healthy (by using the Advertising
switch), whether the topology between DCs is kosher (by using the Topology and Replication
switches), which DCs hold which Flexible Single-Master Operation (FSMO, aka Operations Master)
roles (by using the FSMOCheck switch), and much more.
Dcdiag with Replication
Sometimes, replication between DCs suddenly stops for no apparent reason. You can often find the
cause by checking DNS, but discovering the extent of the problem can be difficult. If you use the
syntax
dcdiag /test:Replication
you get results that resemble those shown in Figure 7.11. Results that indicate individual replication
problems can help you gauge the extent of the overall problem (in this case, no replication problems
exist).

Figure 7.11
Deploying Dcdiag
If you suspect replication problems, you can also carry out the test with the /v switch. This
switch enables verbose output, which can help you see precisely where problems lie.
Dcdiag with Dcpromo
When you bring up new DCs at other sites, you might face a familiar challenge: problems that might
be either on the server that you want to promote or in the domain itself. All you know is that
something is preventing the promotion of the server to DC. Dcdiag with the /test:DCPROMO switch
can help. If you want to create a new replica DC, you use the syntax
dcdiag /test:DCPROMO /DNSDomain:<domainname> /replicadc
from the machine you want to promote to DC. If your DC-to-be passes all tests to be promoted,
you’ll see the results that Figure 7.12 shows. You can then proceed knowing that the promotion is
likely to work.

Figure 7.12
Deploying Dcdiag with the /test:DCPROMO switch
Replmon
If Dcdiag is the Swiss Army knife of command-line AD diagnostics, then Replmon fills a similar role –
but with a GUI. You begin deploying Replmon by loading all the DCs in the domain. You do so by
clicking Edit, clicking Add Monitored Server, and continuing through the Add Monitored Server
Wizard. After you’ve loaded all DCs, you’re prepared to run some tests. For example, you can
right-click a DC and run a test that generates a report, such as Check Replication Topology, which
Figure 7.13 shows.
Figure 7.13
Deploying Replmon for AD diagnostics

You can use Replmon to perform a host of validation tests. One powerful function is Synchronize
Each Directory Partition with All Servers, which you see listed in Figure 7.13. When you select and
initiate this function, the Synchronizing Naming Context with Replication Partners dialog box that you
see in Figure 7.14 will appear and offer three synchronization options.
Figure 7.14
The Synchronize Naming Context with Replication Partners dialog box
AD replication is usually “pull only” – that is, each DC in a site will pull the latest data from its
partners. You can change the replication mode by selecting the Push mode option that Figure 7.14
shows. Additionally, instead of waiting for replication to occur more widely, you can force replication
over site boundaries by selecting the Cross site boundaries option that Figure 7.14 shows.
n Note Replmon lets you perform a one-time “push” replication through the Push mode option that
Figure 7.14 shows.
d Caution
I’ve never encountered a need to use the first option that Figure 7.14 shows, Disables transitive
replication. I typically want replication to occur everywhere, so I don’t select that option.
You’ll want to familiarize yourself with Replmon, which is one of the most useful tools for
troubleshooting AD problems. Be aware, however, that the Help function in Replmon is nonexistent.
You might want to search on the tool name to access some of the many articles about deploying
Replmon.

Windows 2003 Resource Kit Utilities

The Windows resource kits have always offered tools that perform various kinds of “magic.”
Historically, Microsoft made some tools available for download, but you had to purchase the resource
kit and the resource kit documentation to get most of the tools.
With Windows 2003, Microsoft is apparently giving away the bulk of the resource kit utilities and
making others available as they’re produced. To start developing your resource kit, go to
http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe
and download and install the resource kit on your computer.
j Tip
Also available – as a separate download – is the Microsoft Internet Information Services (IIS)
6.0 Resource Kit. For an overview of the resource kit and to download it, go to
http://www.microsoft.com/downloads/details.aspx?familyid=80a1b6e6-829e-49b7-8c02-
333d9c148e69&displaylang=en
Some of the utilities in the resource kit are command-line tools, others are GUI tools, and still
others fall into a different category. I’ll explore tools from the third category first.
Active Directory Users and Computers Enhancement Tools

Two great resource kit tools enhance the capability of the Active Directory Users and Computers
console – the tool you use each and every day. I’ll give you an overview of both Acctinfo.dll and
Rcontrolad.
Acctinfo.dll
Acctinfo.dll isn’t a program you can simply double-click and run. Rather, it attaches itself to the Active
Directory Users and Computers console to extend the console’s capabilities. Acctinfo.dll displays all
sorts of interesting account information about the most recent user logon. Previously, you would have
needed scripting to get this information.
However, to get to these account information properties, you’ll first need to complete the
following steps:
1. Copy Acctinfo.dll to \%systemroot%\system32
2. Then, use the syntax
regsvr32 acctinfo.dll
n Note You’ll need to repeat both steps to add Acctinfo.dll to each individual system.

j Tip
If you want to remove Acctinfo.dll, simply use the syntax
regsvr32 /u acctinfo.dll
After you register Acctinfo.dll, you’ll be able to see the newly available information on the
Additional Account Info tab in the dialog box that Figure 7.15 shows.
Figure 7.15
The Additional Account Info tab
Without needing to use scripting, you can access lots of information (e.g., when the user’s
password next expires, when the user most recently logged on, what the user account’s SID is).
One interesting and useful feature is the Set PW On Site DC button that you can see in Figure
7.15. When you click the Set PW On Site DC button, the dialog box that Figure 7.16 shows will
appear. You can then change the user’s password directly on the DC that the user uses for validation.

Figure 7.16
The Change Password On a DC In the Users Site dialog box
If you use the Set PW On Site DC feature to change passwords, users will be able to access their
newly changed passwords right away. They won’t need to wait for replication from the PDC-Emulator
to this DC.
Rcontrolad
Rcontrolad is a tool that lets you control another useful little tool. When you double-click Rcontrolad,
it expands into several files. First, you run the rcontrol_setup.exe program as a Domain Administrator.
Second, you copy the included rcontrol.exe to the location from which you deploy your Active
Directory Users and Computers console. You’ll then be able to right-click any XP or Windows 2003
computer and select Remote Control, as Figure 7.17 shows.
Figure 7.17
Selecting Remote Control after deploying Rcontrolad

After Rcontrolad is installed, you can control target computers remotely. When you do, you’ll be
connected through Terminal Services to the remote computer, as Figure 7.18 shows.
Figure 7.18
Connecting to the remote computer
Rcontrolad is a handy alternative to manually adding each machine to the Control Panel Remote
Desktop applet.
Event Manipulation Tools

In Chapter 1, I discussed the new Server Event Tracking feature, which lets administrators enter (and
thereby better track) the reasons for restarting or rebooting a server. In this final section of Chapter 7,
I discuss how you can extend that record-keeping capability and also leverage what you learned in
this chapter about the Eventcreate, Eventquery, and Eventtriggers tools.
Custreasonedit
The Custreasonedit tool lets you extend the Server Event Tracking feature’s list of possible reasons for
shutting down and restarting a server. To use Custreasonedit to add to the list of reasons, you must
first introduce sample reasons to this computer. You do so by right-clicking the samplereasons.reg file
in Windows Explorer and selecting Merge, as Figure 7.19 shows.
Figure 7.19
Expanding the samplereason.reg file

Use the syntax

custreasonedit /i
to launch the tool’s GUI, as Figure 7.20 shows.
Figure 7.20
Introducing custom reasons for shutdown
After you’ve run custreasonedit /i, you can see the sample reasons and add your own. Simply
type in the Title and Description, pick the Reason Category, select which check boxes you want to
have shown by default, and click Add. After you’ve tailored the list, click Export to export to a
registry file. Then, merge the resulting registry file back into the system registry – and your reasons
will be customized.
j Tip
The Custreasonedit process I describe customizes the reasons for this machine only. However,
the readme.chm file tells you how to distribute the updated reasons list to multiple machines.

EventCombMT
You’ve learned how to use the Eventcreate tool to capture selected events in the event log. Now,
you might want a centralized way to locate these (and other) events across multiple servers. The
EventCombMT tool lets you perform event searches easily.
After you run EventCombMT, you can right-click in the left window and select the types of
servers on which to query events, as Figure 7.21 shows (highlighted in yellow).
Figure 7.21
Selecting servers to search
As Figure 7.22 shows, you can select the log files to search (highlighted in orange), the event
types (highlighted in green), any specific event IDs or event ID ranges (highlighted in yellow), or text
within an event (highlighted in blue). In this example, I’m checking one DC for event ID 105 and
event ID 106 in the Application, System, and Security logs.

Figure 7.22
Entering the types of events for the search
When you click Search in EventCombMT, the tool will query all the servers specified for the
criteria you established. When the search is finished, the Temp directory will contain several files, and
the Temp directory window will be exposed automatically. Open up a log file, such as the file Figure
7.23 shows, to see the events returned from the search – including those you created with the
Evencreate tool.

Figure 7.23
Logged events that match the criteria you establish
n Note The resource kit tools are downloadable, but Microsoft doesn’t support them 100 percent.
Should you need assistance with them, you’ll get “best-effort” support.
Next: Special Domain Operations

You can perform administrative tasks countless ways. However, familiarizing yourself with the
command-line tools, support tools, and resource kit tools can really be a lifesaver. You can then
better leverage the event logs to figure out what’s happening in your environment. Best of all, all the
commands and tools I’ve discussed in this chapter are free. However, no “centralized storage”
mechanism for events exists yet – for that you’ll still need a third-party tool.
In the final chapter of Windows 2003: Active Directory Administration Essentials, I consider some
operations you’ll probably perform rarely, such as transferring or seizing server roles, addressing DC
promotions that fail partway through, cleaning up the metabase, and renaming DCs and domains. I’ll
discuss how to perform these operations safely.

147
Chapter 8:
Special Domain Operations

In the previous chapters of Windows 2003: Active Directory Administration Essentials, I’ve discussed
many of the Windows Server 2003 (Windows 2003) tasks you might perform regularly or periodically
– although not always daily. Those tasks include working with
• trusts
• authentication firewalls
• security control
• Emergency Management Services (EMS)
• backup and restore
• advanced administration with support tools
In this final chapter, I discuss administrative tasks that involve operations I hope you seldom – if ever
– need to perform. These useful and occasionally necessary operations can be hazardous to the
overall health of Active Directory (AD) if they’re not handled perfectly. However, should you be
called upon, you’ll want to know how to perform these tasks. I recommend that you attempt these
operations first in a test lab – before you’re called to active (directory) duty.
Among the administrative tasks I cover are working with server roles, cleaning up the AD
metabase, renaming domain controllers (DCs), and renaming domains. Because the powerful
operations you’ll use for these tasks involve specific dangers, you need to know how to perform the
operations safely.
FSMO Role Review and Troubleshooting

If you’re a current Windows 2000 administrator, you probably already know about Flexible Single
Master Operation (FSMO, aka Operations Master) roles. FSMO roles control specific Windows 2003
and Win2K domain capabilities, as I describe in the following text.
Each of the five FSMO roles – two for the entire forest, three for each domain – must reside on a
DC. Each role plays a key part in the proper operation of AD.
Each domain role resides in a specific location and controls specific tasks:
• PDC Emulator – Each domain has one PDC Emulator. The PDC Emulator is the sole password
change location for downlevel clients, the central authority for time synchronization, and the
default location for the creation of Group Policy Objects (GPOs).
• Relative Identifier (RID) Master – Each domain has one RID Master. The RID Master helps in the
creation of new accounts in each domain by providing a unique identification number for each
user account. Each user’s SID has a RID. As you read in the previous chapter, Acctinfo.dll can
show you the user’s SID. The last portion of the user’s SID (the block of numbers that follows
the last dash – 1120 in the following screen shot) is the RID, which Figure 8.1 shows.

Figure 8.1
RID – the last part of the user’s SID
• Infrastructure Master – Each domain has one Infrastructure Master. The Infrastructure Master’s job
is to help translate group memberships. This function kicks into gear when accounts from one
domain are members of groups in another domain.
Each forest role also resides in a specific place and controls specific functions:
• Schema Master – Each forest has one Schema Master. The Schema Master, as I discussed in
Chapter 5, controls all access to the schema. If you extend the schema, the entire forest must
comply because the forest has only one schema.
• Domain Naming Master – Each forest has one Domain Naming Master. The Domain Naming
Master ensures that no two domains with the same name become members of the forest.
Knowing Role Holders

Before you address any problem solving that involves FSMO roles, you’ll want to know which DCs
currently hold which roles. I’ll discuss two of the available methods for revealing the role owners.

Chapter 8 Special Domain Operations 149
Dumpfsmos
One way to check role ownership is to use the Dumpfsmos command, which you can find in the
Microsoft Windows Server 2003 Resource Kit. Use the syntax
dumpfsmos <any Domain Controller>
and the results will reveal which roles reside on which DCs, as Figure 8.2 shows.
Figure 8.2
The Dumpfsmos command
Replmon
You can also discover which roles reside on which DCs through Active Directory Replication Monitor
(Replmon), which I discussed in Chapter 7. Simply add any DC to Replmon’s list of DCs, then
examine the DC’s Server Properties. On the FSMO Roles tab, you’ll get the rundown that Figure 8.3
shows.

Figure 8.3
Locating FSMO roles through Replmon
Transferring Roles
If you need to take a server that holds a role down for maintenance, you should be able to transfer
its role to another DC. If the DC’s role is a domain-specific role (e.g., RID Master, PDC Emulator,
Infrastructure Master), you can transfer the role to another DC in the domain. If the DC’s role is a
forest-specific role (e.g., Domain Naming Master, Schema Master), you can transfer the role to another
DC in any domain. You can perform role transfers two ways: through the GUI and through the
command line.
Role Transfer Through the GUI

To perform a transfer graphically, you use tools with which you’re already familiar. Consider the
following list, which pairs tasks with the tool you use to accomplish them.
• To transfer the PDC Emulator role, you use the Active Directory Users and Computers console.
• To transfer the RID Master role, you use the Active Directory Users and Computers console.

• To transfer the Infrastructure Master role, you use the Active Directory Users and Computer
console.
You can transfer the first three roles listed through the Active Directory Users and Computers console,
Figure 8.4
Changing FSMO role owners through the Active Directory Users and Computers console
• To transfer the Schema Master role, you use the Microsoft Management Console (MMC) Active
Directory Schema snap-in.
• To transfer the Domain Naming Master role, you use the Active Directory Domains and Trusts
console.
Role Transfer Through the Command Line

Transferring roles through the command line is tricky. To do so, you must use Ntdsutil – the same
tool you use for AD restoration, which I discussed in Chapter 6.
First, I’ll give you a brief overview of the sequence involved in the process. You would
1. run Ntdsutil
2. use the Connect command to connect to the server you select to receive the transferred role or
roles (i.e., the target server)
3. transfer the role or roles
4. confirm that you want to perform the transfer
5. exit the tool

You perform these steps through commands inside Ntdsutil. For example, if you need to transfer
the RID Master role from VMServer2 to VMServer5, you would type the following sequence of
commands:
ntdsutil
to start the Ntdsutil tool

roles
to go to fsmo maintenance
connections
to enter the connections menu

connect to server <servername>
to bind to the target server

quit
to return to the fsmo maintenance prompt

transfer RID Master
to perform the transfer
You’ll be asked whether you’re sure you want to perform the transfer. After you answer affirmatively,
the RID Master should be transferred to the target server, as Figure 8.5 shows (highlighted in red).
Figure 8.5
Transferring a role

Seizing Roles
Should a server go down while it owns a role, you might have to seize the role. Seizing a role
basically draws a line in the sand that says, “I’ve tried multiple times and can’t get the server back
online. The server from which I’m seizing the role will never come back online again.”
d Caution
Seize a role only if you’re certain that you must.
The procedure for seizing a role involves Ntdsutil and resembles performing a transfer with that
utility. Again, I’ll begin with a brief overview of the sequence involved in the process. You would
1. run the Ntdsutil tool
2. use the Connect command to connect to the server on which you want the role or roles to
finally reside
3. seize the role or roles you need to relocate
4. confirm that you want to perform the seize
5. exit the tool
You perform this sequence through commands inside Ntdsutil. For example, if you must seize
the PDC Emulator role from VMServer5 and relocate the role on VMServer2, you would type the
following sequence of commands:
ntdsutil
to start the tool

roles
to go to fsmo maintenance
connections
to enter the connections menu

to bind to the target server

quit
to return to the fsmo maintenance prompt

seize PDC
to perform the seize

You’ll be asked to verify that you want to perform the seize operation. After you answer
affirmatively, the system first attempts a “safe transfer” (which I described in the Transferring Roles
section) before it performs the seize operation. If the transfer fails (presumably because the server is
dead), you must seize the role – in this case, the PDC Emulator role – and place it on the target
server, as Figure 8.6 shows (highlighted in red).
Figure 8.6
Seizing a role
Cleaning Up the AD Metabase

Sometimes the introduction of new DCs fails partway through. When such a failure occurs, records
could linger in the AD metabase until you manually remove them. You’ll want to remove the records;
otherwise, you’ll see instances of computers that no longer exist, which can cause confusion and
even corruption.
You can use the Active Directory Sites and Services console to see whether you have any
lingering “stale” DC objects. In the example that Figure 8.7 shows, VMServerF is stale (it has failed to
make any connections) and should be removed.

Figure 8.7
A DC that needs to be removed
After you identify a stale object, you need to

• use Ntdsutil to clean up the AD metabase
• remove the DC from the site
• remove the DC from the DC organizational unit (OU)
Metabase Clean-Up Process

The process for cleaning up the metabase is similar to the process for executing other Ntdsutil tasks.
You would
1. run the Ntdsutil tool
2. instruct the tool that you want to clean up the metabase
3. use the Connect command to connect to any currently working DC
4. provide Ntdsutil with the location (site and domain) of the DC you want to remove
5. delete the object directly inside AD
6. exit the tool
Once again, you perform this procedure through commands inside Ntdsutil. In this example, I’m
removing VMServerF. The commands you would type are
ntdsutil
to start the tool

metadata cleanup
to prepare to make a connection to a DC

to bind to any DC that’s working

quit
to return to the metadata cleanup prompt (In the example that Figure 8.8 shows, I abbreviated the
command Quit to the letter “q.”)
select operation target
to get to choose the site, domain, and DC

list domains
to display all the domains to which you have access and automatically assign each of them a number
select domain <number>
where <number> is the domain on which you want to perform maintenance

list sites
to display all the sites in the forest and assign each of them a number
select site <number>
where <number> is the site on which you want to do maintenance

list servers for domain in site
to display all the DCs for the site and assign each of them a number
select server <number>
where <number> is the DC you want to remove

remove selected server
to then remove the server (by pressing Enter)
Figure 8.8 shows the complete series of commands for removing a server. The highlighted
section shows the final removal of VMServerF.

Figure 8.8
Removing VMServerF
After you type

remove selected server
you see the dialog box that Figure 8.9 displays. (Note that this dialog box appears before the final
lines of text in the screen shot that Figure 8.8 shows.)

Figure 8.9
Server Remove Confirmation dialog box
The DC should be successfully removed. You need to return to the Active Directory Sites and
Services console and delete the object. You also need to load the Active Directory Users and
Computers console and delete the object.
j Tip
According to Microsoft, after you delete a DC, you can add a DC that has the same name as
the DC you’ve deleted. However, I recommend that you not do so. I’ve seen directory
corruption occur when names are reintroduced.
Renaming DCs
Renaming a server or DC should be easy. However, to rename a server in Windows NT, you must
remove the server’s computer account from the domain, which adds the server to a workgroup, then
reboot. You then rename the server and reboot again. You then rejoin the server to the domain, and
– oh, yes – reboot again!
With NT DCs, the process is worse. Basically, you can’t rename an NT DC without reformatting
the disk and starting over.
Win2K lets you rename a server from the Computer Name tab in System Properties. As long as
the server is online, the corresponding computer account in AD is changed to reflect the name
change.
To rename a Win2K DC, you run Dcpromo to demote the DC to a garden variety server, reboot,
then rename the server and reboot. You run Dcpromo again to promote the server to DC and – you
guessed it – reboot again.
Windows 2003 changes things a bit. To rename a DC, you no longer begin by undoing its DC
status. That is, you don’t need to run Dcpromo and first demote the DC to server. You can rename a
DC two ways: through the GUI or through the command-line.

DC Rename Through the GUI

To rename a DC, you can go straight to System Properties’ Computer Name tab and click Change.
You’ll then be prompted with the Computer Name Changes warning message that Figure 8.10 shows.
Figure 8.10
Renaming a DC through the GUI
j Tip
Figure 8.10 displays a warning you see when you use the GUI to rename a DC.
After you’ve read the warning and are ready to proceed, click OK to continue. You’ll be
prompted to change the name, enter administrative credentials, and restart the DC. After the records
change in DNS, the DC will be fully renamed and available to service requests.

DC Rename Through the Command Line

When you rename a DC through the graphical interface that Figure 8.10 shows, fully replicating the
name change through DNS to other DNS servers can take time. To avoid replication delays, as well
as to ensure that the DC responds with its old name until you’re ready to remove that name, you can
provide the computer with an alternate name.
With an alternate name, the computer will register DNS (alternate – A) records for both names –
the current name and the new name. The computer provides DNS with the information necessary to
proclaim the “renamed” server a DC and to remove the records that supported the server as a DC by
its original name.
Setting up an alternate name is helpful if you have any applications that use the DC’s original
name. You gain time for application users to stop using the old name and start using the new one.
After everyone stops using the old name, you can remove it – which automatically removes the
records that contain it.
To perform the first step of a rename and provide an alternate name, you use the Netdom tool
from Support Tools. The basic procedure requires that you
1. use Netdom to add the alternate name
2. use Netdom to verify that the alternate name has taken effect
3. use Netdom to change the primary name of the computer from the old name to the new name
4. reboot the computer
5. use Netdom to remove the old name (when you’re ready)
First, you enter the syntax

netdom computername <current computername> /add:<newname>
In the example that Figure 8.11 shows, I’m adding an alternate name (rename5) for the DC
VMServer5.

Figure 8.11
Deploying Netdom to rename a DC
After you reboot the computer, you should start to see new DNS (A) records populate for the new
name in DNS, as Figure 8.12 shows.

Figure 8.12
DNS (A) records for both server names
DNS should now have (A) records for both server names. You should also be able to ping and
perform Nslookups for the computer by either name, as Figure 8.13 shows.

Figure 8.13
Finding both names with Ping and Nslookup
When you’re ready to expunge the old name, you can use the syntax
netdom computername <newname> /remove:<oldname>
Renaming Domains
In the domain arena, Windows 2003 brings a totally radical concept to the table. That is, you can
rename domains as well as perform rudimentary pruning and grafting within AD. However, before I
discuss the new domain rename option, let me set the context by taking you back in time.
Domain Rename – A History

Contrary to popular belief, you could rename domains in NT. In fact, if you look at Microsoft
Knowledge Base article 178009 at
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles
/q178/0/09.asp&NoWebContent=1

you’ll find the steps to do so. However, when you rename NT domains, some serious cautions apply,
and, to some degree, Microsoft has never truly support the renaming.
Win2K offers no real way to rename domains. If you want to rename a domain, you have to
demote every DC in the domain to server, then promote your first server back to DC – and introduce
a new name. In addition, you can rename a server only if the server is at the end of a domain tree –
not if it’s anywhere in the middle. Also, when you rename the domain, you lose all your user
accounts in that domain, and you have to recreate them from scratch.
Figure 8.14 shows an example of a Win2K domain in which – through the process described
above – you can rename some domains but not others. You can’t rename domains at the top of the
tree (or forest) or in the middle. Only the domains on the end are valid candidates for renaming, and
even then, the thought of losing all accounts isn’t appealing.
Figure 8.14
Valid and invalid domains for renaming
corp.com
✓
west.corp.com east.corp.com
✓ ✓
divisiona.corp.com divisionb.corp.com
Windows 2003 offers a new approach to renaming domains. However, don’t jump headlong into a
Windows 2003 domain rename, which is still complex and fraught with peril.

Windows 2003 Domain Rename – An Alternative

Before you decide to rename a domain in Windows 2003, make sure that you must rename it.
Consider, for example, whether an alternate approach might serve your organization’s needs.
In one of the most commonly occurring scenarios, your organization’s name will have changed
from Littlefish to Bigfish. You (and perhaps others in the organization) want to rename your domain
from Littlefish.com to Bigfish.com. If you encounter this situation, I urge you to first consider adding
an alternate User Principal Name (UPN) suffix to the forest, which Figure 8.15 shows.
Figure 8.15
Adding valid UPN names to the forest
After you add an alternate UPN suffix to the forest, you’ll be able to specify user account suffixes
with the new name, as Figure 8.16 shows.

Figure 8.16
Modifying a user account to use a UPN name
You can have users log on with the new name by explicitly spelling out their full UPN name every
time they log on, as Figure 8.17 shows.
Figure 8.17
User logon with a UPN name

Of course, this change is only skin deep. Indeed, the new UPN name (Bigfish.com) doesn’t even
show up on the Log on to: line of the authentication dialog box. However, this adaptation might be
enough to satisfy those who requested the change.
j Tip
Creating a UPN name is much simpler than performing a domain rename – and it might
suffice.
Windows 2003 Domain Rename – How To

A Windows 2003 domain rename is a large undertaking, one that I can’t describe in detail in this text
because of space constraints. However, I can outline the general procedure for performing a domain
rename:
1. Set up a Windows XP Professional workstation to be your “control station.”
2. Download the latest domain rename tools from Microsoft at http://www.microsoft.com
/windowsserver2003/downloads/domainrename.mspx
d Caution
Although you’ll find domain rename tools on the Windows 2003 CD-ROM, the tools are old –
avoid them! Always download the latest Microsoft domain rename tools.
3. Back up all DCs.

4. Design your new forest structure to maintain the overall naming structure. Microsoft calls this
approach maintaining a “well-formed forest.” Put the new forest instruction set on your control
station.
5. Upload the new forest instruction set to every DC in the forest by using the domain rename tools.
6. Perform the rename by using the domain rename tools.
7. Reboot all DCs to accept the new instruction set.
8. Reboot all member computers (servers and workstations) – twice.
9. Fix the external trusts, Dfs, and GPOs.
d Caution
Also, keep in mind that Microsoft doesn’t support the domain rename operation if the forest
contains Microsoft Exchange 2003 or Exchange 2000. Exchange simply can’t handle the
change.
Because of the several steps required, the potential bumps in the road on the way to the goal,
and the restriction that you can’t rename forests that contain Exchange 2003 or Exchange 2000 – the
domain rename operation might be out of reach for many organizations (although rumor has it that
Exchange 2003’s Service Pack 1 – SP1 – might let a domain rename succeed).

j Tip
To read Microsoft’s two white papers on the specific step-by-step procedure for performing
domain renames (one is 30 pages long and the other 80 pages long), go to
http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx, where you’ll
find links to the two documents with all the (gory) details.
d Caution
Be sure to perform the domain rename operation – in fact, all the operations I discuss in this
chapter – first in your test lab, not on your production servers. Also, after a domain rename
operation, as the Microsoft papers discuss, certain other elements of AD (e.g., certificates, Dfs)
might need adjusting before they work again.
Final Thoughts
I hope you won’t need to perform the operations I discuss in this chapter often. From the transfer
and seizing of FSMO roles to renaming DCs and domains, all the operations involve some perils.
However, none of them is impossible, and you should be aware of what’s required to perform them
as safely as possible.
Thank You
I would like to thank NetIQ and Windows and .Net Magazine for providing the opportunity to write
about a topic I love – Windows 2003 and AD.
Special thanks to Dave Bernard at Windows and .Net Magazine for seeing this project off to a
smooth start and landing. Additional thanks to Veronica Patterson, who edited this book and pro-
vided just the right amount of firmness in editing.
I thank Jan De Clercq (Hewlett-Packard – HP) and Dave Peterson (NetIQ) for providing technical
editing. However, if you find any technical errors, they’re mine, not theirs. Please feel free to contact
me to point out technical errors and necessary updates at http://www.moskowitz-inc.com.
I also thank Bill Boswell for additional bits and pieces of technical assistance throughout the
book and for being a solid sounding board for my questions.
Finally, thanks to all of you – the readers who have taken and will take time to download and
read the chapters of this eBook. I’m grateful to you for reading what I have to offer.
Dedication
I dedicate this book to the best friend a guy ever had: Jill Knapp. In a word, you rock. (Okay, that’s
two words.)
Contact Information
If you need AD training, deployment assistance, or a resource to validate your plans for AD deploy-
ment, growth, or renovation, please feel free to contact me at http://www.moskowitz-inc.com. I also
encourage you to visit my free community Group Policy forum at http://www.GPOanswers.com.

Windows-2003 Active Directory Administration Essentials 7

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows-2003 Active Directory Administration Essentials 7

Uploaded by

Copyright:

Available Formats

ii

Windows Server 2003 — What’s New

A Chapter-by-Chapter Roadmap to the Book

Chapter 1: Windows Server 2003 — What’s New

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

Windows 2003 Editions

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

Windows 2003, Standard Edition

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

Features Common to Three Windows 2003 Editions

Active Directory (AD)

Network Load Balancing (NLB)

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

Internet Information Services (IIS) 6.0

Internet Connection Firewall (ICF)

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

Remote Desktop for Administration (Terminal Services in Remote Administration mode)

Server Event Tracking

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

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

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

Manage Your Server Wizard

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

Volume Shadow Copy for Shares

IP Security (IPSec) over NAT

Microsoft .NET Framework

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

Windows 2003, Enterprise Edition

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

Windows 2003, Datacenter Edition

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

Windows 2003, Web Edition

• can’t be a DC (however, it can be a domain member)

Windows 2003 32-Bit and 64-Bit Processing

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

Windows 2003 Hardware Requirements

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

Real-World Windows 2003 Hardware Requirements

Keeping Your System Updated and Secure

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

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

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

Software Updates with SUS

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

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

IIS Remote Administration Mode

When you’re ready to use Remote Administration Mode, go to http://<servername>:8089.

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

Should You Deploy?

• Am I currently running on older hardware?

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

• What will deployment cost?

Onward — to Windows 2003 AD

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

What’s New in Windows Server 2003

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

Working with Domain Levels

Analyzing Your Current Network

If You Have Combined Win2K and NT 4.0 BDCs

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

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

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

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

If You Have All Win2K DCs s