ExchangeServer FULL

The Expert's Guide for
Exchange 2003
Preparing for, Moving to, and Supporting
Exchange Server 2003
by Steve Bryant
i
Books
Contents
Chapter 1 Exchange 2003 and Active Directory . . . . . . . . . . . . . . . . . . . . 1
Sidebar: The Flood of Electronic Communications and You . . . . . . . . . . . . . . 4
Exchange Server 2003: New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Sidebar: Exchange Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Mobile and Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Microsoft Outlook Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Sidebar: Outlook 2003 License for Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Other Exchange 2003 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
The Importance of Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Exchange 2003 and AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
AD Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sidebar: ADSI Edit and the Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Sidebar: Manually changing the Directory Access List . . . . . . . . . . . . . . . . . . . 15
Enabling GC Services on a DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Next: Preparing for Exchange 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ii
Books
Contents
Chapter 2 Preparing Your Domain Services . . . . . . . . . . . . . . . . . . . . . . . 17
Planning Your AD Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
AD Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A Single Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Multiple Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
About the GC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Logical Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Site Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Well-Connected Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
AD Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Site Links and Site Link Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Naming Your AD Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
AD and DNS Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
AD, DNS, and SMTP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Domain Cleanup and AD Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Consolidating and Collapsing Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Moving File and Print Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Windows 2003 Server Rename Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Prepping AD for Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ForestPrep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DomainPrep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Trust and Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Next: Consolidating Your Exchange Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
iii
Books
Contents
Chapter 3 Consolidating Your Exchange Services . . . . . . . . . . . . . . . . . . . 34
Server Ownership Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Exchange Server Proliferation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Consolidating Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Exchange 2003 and AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Front-End Exchange Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Front-End Servers and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Balancing Front-End and Back-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Consolidating Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Storage Space and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuration and Memeory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Mailbox Consolidation Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Creating Server Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Spreading the Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Deploying High- or Continuous-Availability Servers . . . . . . . . . . . . . . . . . . . . . . 50
Consolidating Mailbox Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Move Mailbox Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Consolidating Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Consolidating Your Exchange Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Consolidating Exchange 2003 and Exchange 2000 Organizations . . . . . . . . . . . . . . . . 52
Tools for Merging Exchange Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Using the Exchange Migration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Copying Public Folder Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Copying the Organizational Forms Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Copying Contacts from One Organization to Another . . . . . . . . . . . . . . . . . . . . . 54
Collecting Group Distribution Memebership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Completing the Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
More Consolidation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Next: Installing Exchange 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iv
Books
Contents
Chapter 4 Installing Exchange Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . 65
Deployment Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Deployment Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Exchange Server 2003 Installation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
New Exchange 2003 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Upgrade from Exchange 2000 Native Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5 . . . . . . . . . . . . . . . 69
Coexistence and Migration from Exchange 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Coexistence and Migration from Exchange 5.5: Step by Step . . . . . . . . . . . . . . . 70
Coexistence and Migration, Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Coexistence and Migration, Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Understanding ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
The ADC Tools Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Deploying ADC Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Deploying the Resource Mailbox Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Deploying the Connection Agreements Wizard . . . . . . . . . . . . . . . . . . . . . . . 76
Coexistance and Migration, Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ExDeploy Command-Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Next: Multiple Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
v
Books
Contents
Chapter 5 Multiple Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Why Multiple Directories Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
AD as Your Directory Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Forests and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Multiple Directories and Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Single Exchange Organization Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Separate Exchange 2003 and Exchange 5.5 Organizations . . . . . . . . . . . . . . . . . . . . 85
Separate Exchange 2003 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Exchange 2003 and Foreign Mail Systems — Short Term . . . . . . . . . . . . . . . . . . . . . 88
Lotus Notes/Domino Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
SMTP for Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Establish Separate Internet Domains for Notes and Exchange . . . . . . . . . . . . . 91
Establish Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Split the Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Installing and Tweaking the Notes Connector . . . . . . . . . . . . . . . . . . . . . . . . . . 94
GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
MIIS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
LDIF Import and Export Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Reviewing Your Multiple Directory Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Next: Outlook Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
vi
Books
Contents
Chapter 6 Deploying Microsoft Outlook . . . . . . . . . . . . . . . . . . . . . . . . . 103
Outlook 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Cached mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Before Outlook 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Enter Outlook 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Synchronization Timer and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Network Adaptor Speed Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
MAPI Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
OAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
RPC-over-HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Outlook 2003: Additional Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
OWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Launching OWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
OWA Address Book Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
OWA Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Enabling OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
ActiveSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Reviewing the Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Next: Administrative Best Practices and Disaster Recovery . . . . . . . . . . . . . . . . . 120
vii
Books
Contents
Chapter 7 Administrative Best Practices and Disaster Recovery . . . . . . . . 121
Disaster-Recovery Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
The Exchange Database: A Brief Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Transaction Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Backing Up Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Full Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Backup Utility for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Centralizing Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
The Devil Is in the Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Exchange Backup Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Restoring Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Restoring Exchange from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Backing Up the IIS Metabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Restoring Mailboxes or Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Retaining Deleted Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Deploying Recovery Storage Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Recovering Your Server with Recovery Storage Groups . . . . . . . . . . . . . . . . . . . 135
Restoring Mailboxes and Items with ExMerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Additional Exchange Recovery Techniques and Tools . . . . . . . . . . . . . . . . . . . . . . . 136
Brick-Level Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
VSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Third-Party Recovery Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Backup and Archival Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Mailbox Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Keeping Up with Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Next: Security Auditing and Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
viii
Books
Contents
Chapter 8 Exchange Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Identifying Security Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Reducing Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Segregating Your Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exchange Server Edge Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Securing Authentication and Controlling Protocol Access . . . . . . . . . . . . . . . . . 147
Pop and IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
SMTP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Securing the Data Stream and the Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Securing the Email Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Digital Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Securing Servers and Dealing with Harmful Email Messages . . . . . . . . . . . . . . . 158
MBSA . . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
MBSA 2.0 . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Hardening the OS . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
URLScan . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
SCM . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Server Patch Management . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Windows Update . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Software Update Services . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
SMS 2003 . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Dealing with Harmful Email Messages ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Managing SMTP Relays . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Preventing Virus Outbreaks . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Preventing Unsolicited Email . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Outlook’s SmartScreen Function ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Exchange Server 2003 Antispam Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
IMF . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Third-Party Solutions . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Protecting the Exchange Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
1
Chapter 1:
Exchange 2003 and Active Directory

Welcome to my world, a thriving terrain of technological wizardry where, for the past 6 years, I’ve
engaged the synergies of Microsoft Exchange Server and Active Directory (AD) as a swash-buckling
infrastructure architect. At least, that’s how I like to imagine it. It’s a world with which you’re prob-
ably familiar, given that you’re reading The Expert’s Guide for Exchange 2003. Or perhaps it’s a world
you want to know better because you’re making the move from another messaging platform. Or
perhaps you’re totally new to Exchange and want to begin learning about it.
Whatever your reasons for reading this book, I believe I can offer some useful information and
examples in the pages that follow. Each chapter will offer a short introduction to its main topics. After
brief background information, I’ll move into more detailed discussions until you and I are swimming
in VBScripts, useful charts, and other forms of techno-bliss. Finally, each chapter will offer references
and links to other materials for your further research.
The Expert’s Guide for Exchange 2003: Preparing for, Moving to, and Supporting Exchange Server
2003 educates email administrators and systems managers about the best methods for migrating to
and managing an Exchange 2003 environment. Core concerns include configuration management,
accounting, and monitoring performance with an eye toward migration, consolidation, security, and
management. The brief chapter notations that follow provide an overview of some of each chapter’s
topics.
Chapter 1: Exchange 2003 and Active Directory

New features drive migration projects
- Single sign-on (SSO), collaboration, mobile and remote access
- New features in the Outlook client
- Free with Exchange 2003 Client Access License (CAL)
- Better performance over slow links
Features introduced with Exchange 2000
Features new with Exchange 2003
The importance of Windows Server 2003 (Windows 2003)
Exchange 2003 and AD
Chapter 2: Preparing Your Domain Services

Prerequisites you know
Requirements you might not know
AD planning
Domain cleanup and consolidation options
Why a cleaner AD gives you more options
Brought to you by Quest Software and Windows & .NET Magazine eBooks
2 The Expert’s Guide for Exchange 2003
Chapter 3: Consolidating Your Exchange Services

Why so many Exchange 5.5 sites exist
Site consolidation
- Site consolidation before Exchange 2003 migration
- Site consolidation after Exchange 2003 migration
- Strategies for and impact of each option
Server placement strategies – remote and small offices
- Outlook performance over slow links
- Remote users
Server sizing
Cluster and fault-tolerance options
Chapter 4: Database Strategies and Server Sizing

Stores – Why you should have more
- Strategies for stores
Archives
- Strategies and options
Load balancing options
Disaster recovery options
- Volume Shadow Copy
- Recovery Storage Group
- Brick-Level Backup – Benefits and Issues
- ExMerge, Offline Recovery and other Backup and Recovery options
- IIS Metabase recovery options
- Backup and Restore Performance
- Best Practices
Chapter 5: Multiple Directories

Why you might need multiple directories
- Need for high security
- Merger, de-merger
Microsoft Identity Integration Server 2003
- Interorg replication
- Collaboration using Internet standards
Co-existence and migration from other messaging environments
- Lotus Notes
- GroupWise
Chapter 6: The Exchange Client

Outlook Deployment
Performance over slow links
Installation scripting and profile management
Mobile Implementation
Collaborative integration with other applications.
Chapter 1 Exchange 2003 and Active Directory 3
Chapter 7: Administration Best Practices

Server maintenance
Database maintenance
Redundancy on various levels
Antivirus and spam fighting tools and techniques
Securing SMTP, POP, IMAP, LDAP
- Securing Outlook client sessions
Tracking tools and benefits of message tracking
Monitoring and tracing SMTP messages
Monitoring queues and verifying message routing
Chapter 8: Security, Auditing, and Logging

Allowing access while maintaining security
- Securing the message stream
- Securing account identity
- Securing the message
Monitoring the server for suspicious behavior
Logging options and alerts
Unlike many available Exchange 2003 books, The Expert’s Guide for Exchange 2003 is new, written
from scratch, not “upgraded” from a previous Exchange book. The subject matter is fresh – you’ll find
no “leftovers.” You already know that Microsoft has made improvements to the Exchange Server
product. I want to get to the particulars, because I know the differences are incredible. My priority is
to sway the remaining Exchange 5.5 shops toward Exchange 2003. In fact, if you are one of those
considering the move, I feel compelled to offer you a little pep rally. You’ll find it in “The Flood of
Electronic Communications and You.”
The Flood of Electronic Communications and You

With our first foray into numbers, I hope you will indulge me a few comments about why your job is so vital. In
September 2000, IDC predicted in report 23011 that by 2005 we would see nearly 35 billion email messages
per day. The report compared the deluge of messages to “heavy rain.” In September 2003, researchers
estimated that 31 billion messages were sent daily. This unexpected surge in volume growth occurred for a
number of reasons: Most businesses quickly accepted email as a primary communication method; people soon
began to send an unprecedented number of unsolicited messages; and, unfortunately, virus outbreaks swelled
the number of messages.
The idea that I can email my kid’s teachers and communicate with local government officials through email
no longer feels strange. And it’s going to get even better (or worse, depending on how you look at it). A newer
report from IDC indicates that we might see 60 billion email messages daily by 2006. From that number, only
31 billion are predicted to be person-to-person, while the balance will be from virus outbreaks, unsolicited
mail and alerts. The IDC Doc #27975 (at http://idc.com/getdoc.jhtml?containerId=27975&pid=35178981) also
describes how email is used – and points out that browser-based access will continue to grow in popularity.
The newer report likened the flow of messages to “water flowing out of a hose” and suggested that
communications such as the Internet Mail Service (IMS), wireless, and alerts, will be used more often to help
sort through the “growing currents of content.”
Exchange Server 2003: New Features

The single most important driving force behind migration is the set of new features that Exchange
Server 2003 offers. They include single sign-on (SSO), collaboration, mobile and remote access, and
the Outlook client.
Single Sign-On
One of the most important advantages you get with Exchange Server 2003 is the capability of single
sign-on (SSO). Exchange Server 2003 doesn’t provide logon accounts or a security database; each
Exchange Server 2003 mailbox is associated with a unique AD user object. Users who authenticate to
the AD for logon scripts and access to files, printers, and the network need not logon again for email.
Exchange mailboxes are stored in a database, and access to that database and access control lists
(ACLs) that reference AD accounts control its folders. In simple terms: 1 Exchange mailbox = 1 AD
user account.
Microsoft has changed Exchange licensing over time, with the price of the Enterprise edition
increasing. Microsoft has also restructured client licensing. “Exchange Licensing” gives you an
overview of current licensing policies.
Exchange Licensing
Exchange licensing has changed over the years. The price of the Standard edition continues to decrease while
the price of the Enterprise edition increases. At the time of this writing, the cost of a Standard Exchange 2003
Server license is $699 and the cost of an Enterprise license is $3999. Both versions offer an “unlimited” number
of mailboxes, Outlook Web Access (OWA), front-end server functionality, support for mobile devices and
connectors for SMTP, GroupWise, and Lotus Notes. The Enterprise edition supports multiple message stores
with limits above 16GB. Moreover, it provides support for clustering and X.400.
Client licensing has also been restructured. An AD Client Access License (CAL) is still required for each
mailbox (because Exchange requires an AD account), but you have a new alternative to User CALs for
Exchange. In the past you had to have an AD CAL and an Exchange 2000 User CAL for each mailbox. This
model is still the best approach if you expect your users to connect to the Exchange Server from their desktops
or from mobile devices.
If, however, your company or solution requires that people access their email from kiosks or centrally
located terminals, you might be better off with the new Device CAL. The Device CAL retails for the same $67
as the User CAL, but you need to buy only one for each device. For example, suppose you run a company that
has only 50 computers but 200 people. Everyone shares machines and OWA is your standard desktop. In this
scenario, you could use one AD account for all 200 people and 50 Device CALs. In some cases, this approach
could save quite a bit of money ($10,050, in this example.)
As you consider Exchange 2003, you’ll need to choose between the Standard and Enterprise editions.
Table 1.1 compares the features of the two editions.
Table 1.1 Exchange Server 2003 versions

Exchange 2003 Standard Exchange 2003 Enterprise
Up to 20 databases ✓
Clustering support ✓
X.400 connector ✓
Database Storage Limit 16GB 16TB
Database snapshot ✓ ✓
Front-end server capability ✓ ✓
Outlook Mobile Access
(OMA) and ActiveSync ✓ ✓
RPC compression ✓ ✓
Recovery Storage Group ✓ ✓
Exchange Management Pack (MOM) ✓ ✓
Collaboration
Collaboration is one of the most broadly applied, if not abused, terms in our industry. I’d like to set
a clear context for what I have to say. First, I think most of you will agree that Microsoft products
generally work well with each other. Microsoft Office products interact well with Exchange Server.
You can easily apply form letters in Microsoft Word to email messages and merge the results with
entries from the contact list in Outlook. Nearly every Office product can “Send to Mail Recipient.”
However, the real power of Microsoft collaboration comes in other, more advanced tools, such as
SharePoint Portal Server 2003, Project Central, Business Contact Manager, and integration with
Information Rights Management.
Microsoft Project takes collaboration a step further with the ability to email updates to project
teams. By implementing Microsoft Project Server 2003 with Exchange and Outlook, project team
members can use the Outlook client to check tasks and report their time.
SharePoint Portal Server 2003 supports Exchange with webparts. Therefore, you can build
SharePoint sites with access to your inbox, calendar, and tasks applications. Even better is the option
to use SPS as the file repository for email attachments. Outlook 2003 has built-in support to leverage
SPS for sending attachments. Files stored by SPS are then indexed, categorized and secured outside
the Exchange environment allowing for faster backup and restoration for the Exchange environment
and better management of your business intelligence.
Integration with CRM applications and Information Rights Management will be detailed later in
the book with specific examples and features list. I will also provide a sample installation diagram
and discuss both the integration and configuration.
Mobile and Remote Access

One of the interesting projections emerging from email trending statistics is that browsers will become
the predominant method of access. Microsoft designed the Exchange 2003 (and Exchange 2000) store
for access directly through WWW Distributed Authoring and Versioning (WebDAV) – to provide
secured access to information without translation processes or message reformatting.
Outlook Web Access (OWA) 2003 provides the same look and feel as Outlook 2003 through
authentic implementation of a long list of familiar Outlook features. Examples include a spell-checker;
calendar, tasks, and contacts access; access to junk email controls; right-click functionality; the ability
to drag and drop email messages; message signature creation and editing; encryption; and even visual
and audio alerts for messages and alarms. The most recent version of Exchange, with all its tools for
mobile access, shows that Microsoft apparently listens to industry analysts’ predictions and customers’
requests.
The subject of mobile access for Exchange will be discussed in detail for those interested in
Smartphone and browser access from phones and PDAs. Microsoft’s Mobile Information Services
have been incorporated into Exchange 2003 Standard and Enterprise editions. If your mobile device
can get an IP address from a wireless network, then chances are good that device will be able to
communicate with your Exchange 2003 server. There are two methods of access in respect to mobile
access; Outlook Mobile Access or OMA provides a browser-based display of your mailbox that is
specially formatted for mobile devices and Exchange Active-Sync or EAS provides synchronization of
your Inbox, Calendar and Contacts folder over wireless network. Each of these configurations has
their own requirements that we will cover in detail in this book.
Microsoft Outlook Client

Not surprisingly, the Outlook client is typically the primary decision factor in moving to Exchange
Server. In fact, many Exchange features, such as offline availability and PDA synchronization, are
available only with the Outlook client. Outlook’s biggest improvements over past versions include
new network optimization methods for communicating with Exchange 2003. Remote procedure call
(RPC) over HTTP, Cached Exchange Mode, and the ability to leverage two-way message and
attachment compression provide Outlook with more options for slow links.
Later in this book, I use detailed network traffic analysis and statistics to demonstrate the benefits
of the new client. This information, which represents many hours of simulation in the lab, also
provides insights as to the number of remote Outlook sessions you can support over various links.
The results of these tests should arm you with the knowledge necessary to design your Exchange
environment and specify server locations.
You should also be aware that you won’t pay an additional fee for Outlook 2003 if you’re
licensed for Exchange 2003. Read “Outlook 2003 License for Free” for details.
Outlook 2003 License for Free

One of the Web pages you’ll discover if you follow the Microsoft Exchange site pricing and licensing links clearly
indicates that you pay no additional fee to run Outlook 2003 – as long as you’re licensed for Exchange 2003.
According to the page, which you’ll find at http://www.microsoft.com/exchange/howtobuy/enterprise.asp,
“Each Exchange 2003 CAL also includes Microsoft Office Outlook® 2003 or Microsoft Entourage® X for Mac
and permits access from Microsoft Office Outlook Web Access, Outlook Mobile Access, Exchange Server
ActiveSync®, or any standard Internet-messaging client.”
Other Exchange 2003 Improvements

In addition to the improvements I’ve discussed, Microsoft has made changes in other areas of
Exchange. For example, Microsoft has removed the rarelyused conferencing services and Instant
Messaging components from Exchange in favor of new native support for mobile devices. This
support is exciting for anyone who has a wireless phone that uses the Wireless Application Protocol
(WAP) and for companies that contemplate deploying BlackBerry messaging PDAs or Smartphones.
(HTML navigation has been virtually impossible with WAP phones accessing typical HTML pages.)
Exchange 2003 supports Wireless Markup Language (WML), XHTML, and Compact HTML (cHTML),
which in turn support presenting Web site text components on phones and PDAs.
Even better is the new support for Exchange ActiveSync (EAS), which supports synchronization
over wireless networks. The Exchange ActiveSync session is secured with Secure Sockets Layer (SSL)
and can synchronize your Smartphone Windows-based PDA device from anywhere, providing that
your device has an IP Address and can communicate with the Exchange 2003 server running EAS.
The Importance of Windows 2003

As business demands continue to increase, the quality, stability, and security of Windows Server
increases as well. Windows Server has always provided the core services for Exchange. Windows
Server 2003 (Windows 2003) packs greater scalability and functionality while supporting Microsoft’s
Secure Connected Infrastructure initiative.
Microsoft has worked to promote robust application development on its systems. The Win32 API,
available since the mid 1990s, permits programmatic access to Windows clients and servers – just as
Collaboration Data Objects (CDO) is well documented and available for Outlook programming. Only
in recent years has the zeal for outside development led to serious compromises in security: More
access equals less security.
The possibility of compromise is why Outlook XP, Outlook 2003, and Windows 2003 install
with many of their advanced programmatic features disabled. For example, Windows 2003, by
default, doesn’t install Microsoft Internet Information Services (IIS). Should you decide to install IIS,
many of the more powerful scripting functions remain disabled until you deem them necessary. The
catch-phrase for this approach is “Secure by Default.”
Installing Exchange 2003 on Windows 2003 offers distinct advantages. Some background
information about the Windows 2003 editions will help set the context for this discussion.
Windows 2003 has four versions, but because Windows 2003 Web Edition doesn’t support
Exchange 2003, Table 1.2 presents the differences among the Standard, Enterprise, and Datacenter
editions only.
Table 1.2 Windows 2003 Standard, Enterprise, and Datacenter editions feature comparison
Standard Edition Enterprise Edition Datacenter Edition
64-bit support ✓ ✓
Hot Add Memory ✓ ✓
Maximum RAM 4GB 32GB 64GB
4-Way SMP ✓ ✓ ✓
8-Way SMP ✓ ✓
64-Way SMP ✓
Internet Connection Firewall (ICF) ✓ ✓
Network Load Balancing (NLB) ✓ ✓ ✓
Cluster Service ✓ ✓
VPN Support ✓ ✓ ✓
Internet Authentication Service (IAS) ✓ ✓ ✓
Network Bridge ✓ ✓ ✓
IPv6 ✓ ✓ ✓
Distributed File System (Dfs) ✓ ✓ ✓
Encrypted File System (EFS) ✓ ✓ ✓
Fax Service ✓ ✓ ✓
.NET Framework ✓ ✓ ✓
IIS 6.0 ✓ ✓ ✓
ASP .NET ✓ ✓ ✓
Enterprise UDDI P P P
Two new modes of AD operation accompany these different versions of Windows 2003.
Windows 2000 Mixed mode lets Windows NT 4.0 Backup Domain Controllers (BDCs) participate
in the directory, but with limitations in functionality. Win2K Native mode provides added functionality
but doesn’t offer the full benefits of Windows 2003’s modes.
By upgrading all of your domain controllers (DCs) to Windows 2003, you can take advantage of
the newest improvements in AD – including improved replication and the ability to rename DCs and
domains. (Keep in mind that each raised level of functionality reduces the compatibility with legacy
directory services.) Table 1.3 presents the features available in Win2K Mixed and Native modes and in
Windows 2003.
Table 1.3 Windows 2003 AD modes and features

Win2K Mixed mode Win2K Native mode Windows 2003
SID history ✓ ✓
Converting Groups ✓ ✓
Universal Security Groups ✓ ✓
Group Nesting ✓ ✓
User password on InetOrgPerson object ✓
Update logon timestamp ✓
DC rename ✓
InetOrgPerson objectClass change ✓
Dynamic auxiliary classes ✓
Improved AD replication ✓
Linked value replication ✓
Defunct schema objects ✓
Global Catalog (GC)
replication improvements ✓
From a design perspective, the advantages of installing Exchange 2003 on a Windows 2003
server are clear. However, other circumstances, such as licensing restraints and hardware or software
compatibility, might render this approach impractical for you. Table 1.4 presents the Exchange
support available for the three Windows server platforms in use today.
Table 1.4 Windows server Exchange support

NT 4.0 Win2K Windows 2003
Exchange 5.5 ✓ ✓
Exchange 2000 Service Pack 2 (SP2) ✓
Exchange 2000 SP3 ✓
Exchange 2003 ✓ ✓
For more information about Exchange support, see “You Cannot Install Exchange 2000 on a
Computer That Is Running Windows Server 2003,” at http://support.microsoft.com/default.aspx?scid
=kb;[LN];321648.

I’ll save many Exchange 2003 features for later discussion. The most important thing to understand
is that to install Exchange 2003 (or Exchange 2000), you must have access to AD. (Microsoft’s
competitors have tried to use this point to convince Exchange 5.5 shops to change platforms.) At
the same time, IBM has acknowledged the importance of AD by making Notes/Domino 6.0 more
compatible with AD. In fact, IBM now makes synchronization tools, such as the Active Directory
Synchronization (Ad Sync) tool, to help Notes and Domino administrators manage users and groups.
You don’t need synchronization tools with Exchange Server, because it uses the AD to store its
information. The following background will clarify the importance of AD.
AD Domains
An AD domain is a collection of security objects that share a common directory database. AD stores,
manages, and secures these objects. When you configure an AD DC, you must create a new AD
forest or install your domain in an existing AD forest.
Domains in the same forest have a fundamental relationship that permits the automatic
replication of specific information – such as Exchange Server settings and mail routing tables. The
general rule is that you have one AD forest for each Exchange organization. I’ll discuss other options
later, but understanding this simple rule is critical to your Exchange design planning.
Within AD domains, you can place objects into logical containers known as organizational units
(OUs). This logical separation of objects helps to establish an administrative boundary within the
domain. You can delegate OUs and their objects to others for administrative and management
purposes. Whereas OUs serve as administrative boundaries, AD domains represent replication
boundaries and, to a limited extent, security boundaries for AD objects. An AD forest represents an
organizational and security boundary for domains.
AD is in essence a database of information. It’s divided into partitions or naming contexts (NCs):
Domain, Configuration, Schema, and RootDSE, which Figure 1.1 shows. Most AD administration
occurs within the Domain NC because it contains the user objects. The Domain NC is replicated to all
DCs within an AD domain. The other NCs are shared with other domains in your organization.
Figure 1.1
AD NCs
If you understand how replication works, you can see why AD can function so well over slow
links. For example, assume that you have a company with five large locations, each on a different
continent. The user objects for your employees in Antarctica probably don’t need to be replicated to
Europe. Moreover, the administration for employees in Antarctica will probably be localized. In other
words, Antarctica should probably have its own AD domain. If you place AD domains in the same
forest, however, users on each continent can have access to servers in other parts of the world.
You can use a single Exchange organization to provide calendar sharing, meeting invitations, and
delegation throughout the company.
In this scenario just discussed, suppose that the company’s locations in North America and South
America have a centralized administrative model and fast network connections. In their case, it makes
sense to use a single domain to permit easier object moves and central administration. Another
advantage is the fact that each DC in this domain serves as a peer or backup for the others in the
same domain. If the server in Mexico fails, the server in the United States can authenticate users and
provide access to the Global Address List (GAL) – assuming network connectivity is still available.
The primary reason to create multiple domains in your organization is to provide replication
boundaries because DCs in the same domain replicate information to each other more often and
require RPC connectivity to replicate logon scripts and directory information. Replication between
domains in the same forest involves far less information and can take place over SMTP.
As I’ve discussed, the most common AD item you deal with is an object. User accounts,
computer accounts, and printers are all examples of objects. Every object in the AD, including user
objects, is categorized. The AD schema provides the class and object descriptions and is stored in the
Schema NC that’s replicated throughout the forest. In this example, the user object Steve Bryant
belongs to the ObjectCategory named Person, which the schema defines, as Figure 1.2 shows.
Figure 1.2
AD ObjectCategory
The importance of these distinctions becomes clear when you begin working with scripts and
custom applications. For now, I want to provide some context for the AD structure as it relates to
Exchange and basic AD design concepts.
Before I proceed to discuss AD in general, however, I want to introduce you to a key tool –
ADSI Edit – to which I’ll refer often throughout this book. For a brief introduction to ADSI Edit, read
“ADSI Edit and the Support Tools.”
ADSI Edit and the Support Tools

It’s a good idea to include the Windows Support Tools on every server you install because the tools are
excellent troubleshooting resources. You can find them in the \support\ directory on the Win2K and Windows
2003 CD-ROMs.
Be sure to install the appropriate version for the OS you run. In this book, I frequently use one of these
tools – the Active Directory Services Interface (ADSI) Edit tool – to illustrate the specific characteristics and
relationships of objects within the AD. ADSI Edit is a low-level administration tool that lets you access the core
components of the AD.
Access to core components means a high level of exposure for AD. At the same time ADSI Edit provides
extensive power, it requires commensurate care and responsibility. An accidental deletion or a modification to
the wrong object could cripple your domain.
Global Catalog
As its name implies, the Global Catalog (GC) contains information about every object in the AD
forest. An AD forest could contain hundreds of domains, and searching those domains would be very
difficult because objects in the Domain NC aren’t fully replicated to other domains. Instead, portions
of the objects are copied to a read-only index, the GC. It’s against this GC that AD searches are
performed. The GC is particularly important to Exchange and Outlook because it provides the GAL.
Although all DCs support the Lightweight Directory Access Protocol (LDAP) protocol for access,
only the Global Catalog Server supports the Name Service Provider Interface (NSPI), which Outlook
2000 and later clients use for the GAL.
Outlook 95 and 98 clients expect their Exchange Server to provide the GAL and don’t
“understand” NSPI. In these instances, Exchange 2003 and Exchange 2000 use a service called
DSProxy (one of the several services that fall under the overall category of Directory Service) to
query the GC on behalf of the client. The results are then proxied back to the client.
Outlook 2000 and later clients use the DSProxy service on the Exchange Server on their first
directory query to locate a GC. After the service locates the GC, the Fully Qualified Domain Name
(FQDN) of the GC is made persistent on the client. Clients with persistent referrals won’t use DSProxy
unless the GC they’re targeting is no longer available and they need a different GC.
n Note In some cases, you might prefer to manually set the GC that an Outlook client would use. For
more information about this approach (because it requires a registry change), go to “How to
Specify the Closest or Specific Global Catalog Server,” at http://support.microsoft.com
/default.aspx?scid=kb;[LN];319206. In other cases, you might choose to keep your Outlook
clients from persisting their connections to the GC by force. Doing so would require the
DSProxy service to perform the directory lookups on behalf of the client, but it could help
alleviate problems associated with unstable GCs or a flux in the network topology. For more
information about this setting, see “How Outlook 2000 Accesses Active Directory,” at
http://support.microsoft.com/default.aspx?scid=kb;[LN];302914.
As you can imagine, it’s important that the Exchange 2003 server “understand” the health and
topology of the GC servers in the environment, so it can make good referrals to clients. Exchange
2003 and Exchange 2000 servers have an internal process – called DSAccess – that collects
information about the AD and stores it for referrals, as well as for the Categorizer and System
Attendant services.
By default, an Exchange 2003 server dynamically detects the DCs, GC servers, and configuration
DC in its topology. The server establishes LDAP sessions to each server in an effort to grade the
connections as up, slow, or down.
By default, the DSAccess process detects and adds GCs in the local AD site to the Directory
Access List. In the event that DSAccess doesn’t find any local GCs, the process will look for GCs
elsewhere in the network by enumerating the NTDS settings for the site, as Figure 1.3 shows.
Figure 1.3
NTDS settings
Servers placed in the Directory Access List are then used as referrals to DSProxy clients in a
round-robin fashion to provide a level of load-balancing among the GCs. This list is dynamically
updated when DCs are added or removed from the network, or when Kerberos tickets expire (by
default, every 10 hours).
Manually changing the Directory Access List

At times, you might need to manually set the Directory Access List to force either the use or exclusion of a
particular GC for your Outlook users. You can select these settings on the clients, as indicated previously, or on
the Exchange servers themselves.
After you access the Exchange System Manager Microsoft Management Console (MMC), right-click on a
server and choose Properties. On the Directory Access tab, you should see a list of DCs that the DSAccess
service found, which Figure A shows. You can’t change the default list of DCs, but you can change the
drop-down list to add or remove specific types of DCs. You can change the detection settings from automatic
to static and ultimately remove or add specific servers to and from the list.
Figure A
Exchange Server Properties Directory Access tab
You can also assign DCs and GCs through the Exchange 2003 server’s registry. To do so, add the following
registry subkeys and values:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\UserDC1
IsGC = REG_DWORD 0x0
HostName = REG_SZ DC_DomainName.CompanyName.com
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\UserGC1
IsGC = REG_DWORD 0x1
HostName = REG_SZ GC_DomainName.CompanyName.com
The usual warnings apply. Back up the registry key before you make changes and test the changes on a non-
production server.
d Caution
Use the System Manager to force these changes only if you have no other alternative.
Manually changing the Directory Access List, continued
The DSAccess dynamic processes are quite clever and should work well in most installations. For more
information about DSAccess, read “Directory Service Server Detection and DSAccess Usage,” at
http://support.microsoft.com/default.aspx?scid=kb;[LN];250570.
Ultimately, the GC is critical to Exchange clients. In addition, Outlook clients access the GC quite
regularly. Therefore, the placement of GCs within your network is especially important. A general rule
is that at least one GC should be located near every Exchange 2003 and Exchange 2000 server in
your organization.
j Tip
Locate at least one GC near every Exchange 2003 and Exchange 2000 server.
Moreover, many people recommend that one GC is required for every four Exchange Server
processors. For example, if you had two quad-processor Exchange Servers, you would need two GCs
in that location.
Enabling GC Services on a DC
Fortunately, you’ll find it simple to enable GC services on a DC. With the Active Directory Sites and
Services console, right-click the NTDS Settings object under the DC you want to change and select
Properties. On the General tab, check the Global Catalog check box to enable GC services on the
GC. You should reboot the DC after you change this setting. Be aware that the GC will be replicated
to this server immediately following the reboot.
Many other aspects of the Global Catalog Server fall outside the scope of this book. For example,
in Windows 2003 AD, you can control the replication of GC information.
You can view the specific object attributes available and even add more attributes as needed. If
you wanted to write an application to query user objects for Social Security Numbers or birthdays,
you could add those attributes to the schema, then instruct the GC to include those values. Your
application could then query any GC for those fields. In the next chapter, I’ll explore AD further in
respect to planning, designing, and deployment.
Next: Preparing for Exchange 2003

The demand for faster access and better “business intelligence” has spurred technology advances.
Exchange 5.5 is a great product that has lasted since the late 1990s. However, evolution in security
threats and the need for greater access, global systems, and better administration and management
tools have necessitated change. In upcoming chapters, you’ll find in-depth discussions about AD that
include the topics of multiple forests, design, administration, and management.
17
Chapter 2:
Preparing Your Domain Services

Having used Chapter 1 to introduce Active Directory (AD) and its relationship to Microsoft Exchange
Server, I’m ready to discuss planning an AD deployment. But before you get out the CD-ROMs, I’d
better remind you about the inevitable: Serious initial planning for AD begins in conference rooms –
in long, detailed meetings that include senior managers and department heads.
Planning Your AD Deployment

The success of your AD deployment will depend on your knowing what the future might bring.
You’ll need to be fully informed about any immediate plans for mergers or department restructurings
within your company. After your company deploys AD, you can’t easily combine or separate AD
forests and trees without compromising security and functionality.
Moreover, you need to know in advance about any potential new locations, network redesigns,
office closings, or personnel moves. Any one of these changes could significantly affect AD design. A
combination of two or more such changes could render the design useless, particularly in the case of
a significant network change or a major relocation.
As you plan, I encourage you to consider a multi-phased deployment in which you roll out the
AD and DNS structures a few weeks or even a month before you deploy Exchange, which gives you
time to ensure that AD is stable. To avoid an unhealthy Exchange environment, it’s best to have a
well-understood AD in place and operating smoothly before Exchange enters the picture.
A directory that doesn’t replicate correctly, for example, can lead to an inconsistent address
book. Also, an Exchange server must talk to a domain controller (DC) to load the stores. If available
DC services are inadequate, users won’t be able to access their mailboxes. Therefore, from an
administrator’s point of view, establishing AD before introducing Exchange gives you the advantage
of familiarizing yourself with one set of new tools before you bring in another set.
After you gather preliminary information, you’ll need to address three key questions in the
planning meetings. First, how closely will AD be tied to the company structure? Second, will AD
management be centralized or occur in remote offices? Third, can the organization as a whole share
the same schema and still maintain a secure AD? The answers to these questions, which I’ll discuss in
more detail later, are key factors in how your company will balance limits on access with the need
for collaboration.
When you plan AD, I recommend starting with the notion of a single forest and single domain
and veering from that concept only when necessary. In other words, plan to keep AD simple.
AD Forests
Before I go into details, let me reiterate some basics from Chapter 1. An AD forest is a collection
of domains and domain trees that share the same schema naming context (NC), configuration NC,
and, in this case, Exchange organization. When you first create an AD domain, you must choose
(among other things) whether to create a new forest or join an existing forest. After you make this
decision, you can’t turn back. If you choose to join an existing forest, you’ll inherit the schema and
configuration NCs from the forest, which will let you participate in forestwide operations.
Companies that plan to deploy AD must choose between 1) waiting for the corporate root AD
to be established or 2) letting departments move to AD as soon as they’re ready. Each choice can
be problematic. Others might perceive the first option (waiting) as a lack of confidence or as a need
to over-plan. They might perceive the second option (letting departments proceed individually) as
promoting the installation of separate forests. This dilemma often causes companies to delay
deploying AD much longer than necessary. If they delay, they risk falling out of support for Exchange
5.5; if they proceed, they face the prospect of consolidating AD at a later time, which can be painful
and expensive.
A Single Forest
If your company can avoid establishing multiple forests, I advise you to do so. Your company might
need strict security measures that require multiple forests – or critical information or accounts you
must protect from other users and administrators. However, in the absence of such factors, think first
about a single forest.
A single forest requires a level of trust that all administrators will do their jobs properly. If both
your design team and your management have full confidence that the following statements are true, a
single forest is probably right for your company.
• Administrators in all domains put the overall organization’s best interests first.
• Administrators in all domains use security practices that meet or exceed basic security
requirements.
• Administrators in all domains secure the DCs in physically and logically secure computer rooms
and behind protective firewalls.
• Administrators in all domains understand that security and procedural guidelines must be adhered
to at all times and can’t be changed without a consensus or an approval process.
Multiple Forests
A company might need to establish multiple forests for a number of reasons. One of the most
common reasons for separate forests is a merger in which a decentralized (and not fully trusted)
administrative model is in place. Strict legal requirements could dictate the use of separate forests.
Also, your domain model might be built as a hosted service that requires a secure barrier between
organizations, or your company might need to manage the schema differently within your
organization.
If senior managers decide that schema and configuration naming classes can’t be shared across
the organization, that decision makes global calendar sharing and mailbox delegation impossible. In
fact, if your company requires separate forests, many of Exchange’s advanced collaborative features
won’t be available without third-party tools.
Whatever the justification, those of you who establish multiple forests will have your work cut
out for you. Chapter 7 will cover the directory and collaborative options that you’ll have with multiple
forests, but it’s important that you understand the limitations during the design stage.
To begin with, you’re likely to add some complexity to AD because additional software,
hardware, and configuration settings might be necessary to provide some level of collaborative
Chapter 2 Preparing Your Domain Services 19
functionality between forests. For example, you’ll probably require some type of directory
synchronization and free/busy replication to support a Global Address List (GAL) and a degree of
collaboration.
Multiple forests also limit delegation. A user from one Exchange organization won’t be able to
see the calendar information of a user in another Exchange organization. No delegation can occur
between mailboxes in different organizations (orgs). Exchange orgs can’t easily share third-party
connectors, and sharing the SMTP namespace can become limited. You can’t use Outlook Web
Access (OWA) front-end servers to cross organizations either. However, if the ability to share an
SMTP namespace and free/busy information are all you’ll ever need, multiple forests might be a
viable alternative.
For most companies, a single AD forest can provide the level of trust and security required.
Company policies and a formal security program will help establish the rules for domain security
and administrative policies. Companies that must establish multiple forests because of mergers or
stricter security requirements will have options available to help them institute a reasonable level of
collaboration among forests while maintaining security borders.
Domains
Although it’s common to think of domains as security boundaries, that notion isn’t entirely accurate.
First and foremost, a domain is a replication boundary. Every DC within the same domain replicates
the domain NC as well as the schema and configuration NCs. This arrangement lets each DC act as a
peer to the others within the domain. In addition to replicating the NCs, DCs use the File Replication
Service to replicate the SYSVOL folder contents among member domains. SYSVOL contains the logon
scripts and group policies for the domain.
But do you need to replicate all of that information to all your locations? If the answer is yes and
you have “permanent” TCP/IP connections between locations, you can probably design a single
domain model for your organization. By configuring AD sites, you can control the frequency of
replication and compress information as it’s replicated between locations. A single domain model lets
you use fewer DCs because each location can fail over to another location. Moreover, by default,
every DC is a Global Catalog (GC) server because it contains all of the information for the forest.
Users who roam from office to office will be guaranteed a quick logon anywhere you place a DC –
and distributed remote access points and VPN connections can validate to the same domain.
If, however, your company is spread over several continents and one location doesn’t necessarily
need all the information from the other locations, you probably need more than one domain.
Moreover, DCs within the same domain use Remote Procedure Call (RPC) to communicate. RPC isn’t
terribly efficient over WAN links and will have trouble establishing a connection over slow or
unstable network connections. Although AD sites can help reduce the impact of replicating domain
information between locations, you need to ask yourself whether you must replicate all that account
information and whether your network connections can support it.
In addition to providing a replication boundary, a domain can provide administrative boundaries.
A domain administrator in one domain inherits no administrative privileges in other domains, even if
those domains are in the same forest or the same domain tree. Remember that the only true security
boundary is a forest boundary. If you can’t trust the other administrators, another domain isn’t your
answer. Only a forest with specific trusts can provided additional security against malicious attacks
(e.g., elevation of privilege attacks) and security breaches.
Nevertheless, you’ll want to secure the service administration accounts in your domain and
forest to protect domain resources and objects from accidents or malicious attacks. Note that the
following groups within the domain – <domain>\Domain Admins, <domain>\Administrators,
<domain>\Server Operators, <domain>\Backup Operators, <domain>\Account Operators, and even
<domain>\Print Operators – have accounts with elevated permissions. The elevated permissions let
administrators
• impersonate users
• read, modify, or delete Windows-secured resources or configuration settings on machines joined
to the domains in the forest
• bypass, disable, or defeat system invariants such as ACLs, auditing, Flexible Single-Master
Operation (FSMO) roles, and read-only partitions
• cause changes to replicate to other DCs
• instigate other malicious breaches
Concerns about administrative permissions, such as those listed above, often persuade companies
to establish domains in their environment based on political and departmental separations instead of
geographical location. In most cases, the best basis for domains is a mixture of geo-political factors.
Fortunately, Windows Server 2003’s (Windows 2003’s) new domain functional level lets
administrators move objects between domains in the same forest. This new functionality – along
with the ability to rename domains – lets you manipulate your design after deployment to better
tune it to the needs of your organization. I’ll discuss these tools later in the chapter.
About the GC Server

A couple of improvements to the GC are worth mentioning at this point. The improvements are
available with Windows 2003, and they help reduce the impact WANs have on GC replication and
lookups.
• GC replication tuning – GC replication tuning is available by default and helps to preserve the
synchronization state of the GC. A partial attribute set extension now requires the transmission of
only added attributes.
• Universal group membership caching – You should enable the Universal group membership
caching option. This option improves logon performance by storing or caching user Universal
group memberships on DCs.
Organizational Units
One of AD’s greatest strengths lies in the ability to delegate administration, which means that you
can assign administrative control where it’s required. Delegation eliminates the need to give several
administrators authority over an entire domain or site. Instead, a manager who has the appropriate
rights can delegate the administration of smaller groups of accounts and resources, as Figure 2.1
shows.
Figure 2.1
Delegating administrative tasks
Delegation can apply to an individual organizational unit (OU) or a tree of OUs. The rights that
you assign apply to the designated OU or OUs only. Delegated rights let trusted users
• assign properties for a particular container
• create and delete specific types of container child objects
• assign specific properties to specific types of container child objects
• perform other administrative tasks
As you set up your OUs, delegate permissions, and deploy Group Policy, you can mirror your
administrative structure. However, be wary of trying to match your administrative model perfectly:
OU depth can also affect performance.
If you have deep OU structures, any processes that identify containers within a tree will take
longer. In the following example OU structure, you need only imagine the lengthy queries that would
result from such a structure to recognize that it’s probably too deep for most situations.
Company
North America Europe Asia Central and South America
United States UK South Asia Central America
DivisionA DivisionB DivisionC DivisionD
New York London Singapore Mexico City
Sales Sales Sales Sales
Team 1
ProductRed
Medical
RegionA
Don’t create a complicated hierarchy just because you can. Try to create a structure that’s wider than
it is deep. In this case, a better approach would be to make shallower OUs:
North America Europe Asia Central and South America

New York London Singapore Mexico City
Sales Sales Sales Sales
Boston
Sales
Many companies continue to delegate permissions and deploy Group Policy while using a single
OU for all users. And, although granular administration and deployment is a little more difficult, it’s
possible. Fortunately, you can rename, move, empty, and recreate OUs at will. You can move objects
throughout the domain at any functional level. (For information about functional levels, see the
discussion in Chapter 1. For additional details, go to http://www.winnetmag.com/article
/articleid/38280/38280.html.)
Logical Network
Your current logical network will have the greatest impact on your AD design. Request or create a
network topology map that describes your connections, their speeds, and, if possible, their available
bandwidth and stability. These factors will significantly affect your AD design definition. For example,
a packet loss of more than 10 percent could dramatically affect AD replication – as would having less
than 128Kbps of available bandwidth.
If you have two offices that will never have a network link, you’re likely to need separate forests.
Further, if you have remote locations that can’t support RPC traffic, you’ll certainly need more than
one domain. As you diagram your network topology, in addition to noting user counts, you’ll find it
helpful to collect and note TCP/IP information for each location, as Figure 2.2 shows. This
information will help as you plan server placement and establish fault tolerance.
Figure 2.2
Logical network topology
Internet
K
64
768K
45 Users
200 Users Camberly, UK
2K New York, NY
256
51
K
32K
200 Users
London, UK
25 Users
Memphis, TN 75 Users
75 Users Mullhouse, FR
Clearwater, FL
Creating a site topology map needn’t be a daunting task. Start small and work your way up.
Someone in your organization might already have a network topology map that details network
connections. The most important things you need – from an AD planning standpoint – are the names
of the sites, the link speeds, and the number of AD accounts (users) you’re likely to have at each
location.
Site Topology
If your design or support experience includes Exchange 5.5, AD’s replication terms and processes will
be familiar. AD’s replication engine is based on the Exchange 5.5 Extensible Storage Engine (ESE)
and works in much the same way – with the Knowledge Consistency Checker (KCC) performing
checks and route calculations based on information within the directory. Servers contained in the
same logical site (a collection of “well-connected” computers, such as a LAN) communicate with each
other by using uncompressed RPC packets. Communication between logical sites uses controlled
schedules and compressed packets to replicate information.
Well-Connected Computers
The idea behind well-connected computers is important because intra-site replication occurs nearly
instantly to provide fast updates for critical object changes, such as account lockout and object
creation. After a change is made on a DC, the DC waits 15 seconds, then begins a process to
replicate the change to the other DCs in the site.
The DC replicating the change establishes intra-site routes to contact each DC in the site in
fewer than three hops. Moreover, the DC calculates a separate route for each of the AD NCs. The
calculation, replication, and topology discovery processes don’t work well across slower WAN links,
so you should avoid such links for spanning sites.
You might wonder just how fast a connection you should have to span a site. Well-connected,
according to Microsoft, generally means a speed of 10Mbps. However, in some cases, you might
choose to span a site over a 1Mbps or even a 512Kbps link, depending on how fast your synchro-
nization must be. Keep in mind that these speeds are critical only if you need updates to replicate to
other physical sites in less than 15 minutes.
AD Efficiency
To ensure that your AD is efficient on the wire, you’ll need to map the physical layout of your
network and draw logical equivalents complete with TCP/IP subnets, as Figure 2.3 shows. This
information will let you design AD so it “understands” the connections and relationships of the DCs
in your forest.
Figure 2.3
AD logical site configuration
Internet
K Site:CA
64
768K IP: 10.10.7.0/2
Site: NY
2K IP: 10.10.1.0/24
256
51 10.10.2.0/24
K
Site: LD 32K
IP: 10.10.3.0/24
10.10.4.0/24
Site:TN
IP: 10.10.5.0/2 Site:FL
IP: 10.10.6.0/2 Site:CA
IP: 10.10.8.0/2
In this step, you take the first logical drawing and add a little more information. Specifically, you
determine the acceptable acronyms for the site names and identify the subnets used in each location.
After you list this information, you should be ready to begin defining the sites in AD.
Although the time it will take depends on the size of your network, the process I’ve described is
relatively simple because you need to collect only the names, IP subnets, and link speeds of the
connecting physical sites. The AD logical site configuration should closely mirror the physical layout.
However, although the AD logical site layout should mirror the physical network, the domain
boundaries follow a different rule, as Figure 2.4 shows. Within a logical site, multiple domains can
exist, and a domain can span multiple sites.
Figure 2.4
Domain boundaries
Site: LD K Site:CA
IP: 10.10.3.0/24 64
768K IP: 10.10.7.0/2
10.10.4.0/24
Site: NY CA.Company.com
2K IP: 10.10.1.0/24
256
51 10.10.2.0/24
K
32K
UK.Company.com
Site:TN
IP: 10.10.5.0/2 Site:FL
IP: 10.10.6.0/2 Site:CA
IP: 10.10.8.0/2
US.Company.com FR.Company.com
In most cases, you’ll want your AD forest to span locations or sites. A separate domain is the
best choice for optimizing replication. A domain boundary is essential if you have slow or unstable
connections. At the same time, you’ll find advantages to having fewer domains in that you require
fewer DCs for redundancy.
You’ll use the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in
to create and link logical sites and subnets. (You can save a few steps if you configure the sites early
in your deployment.)
During installation, Windows 2003 and Windows 2000 automatically assign a server to a specific
site based on the server’s IP address, assuming that the IP network has been identified in the AD and
assigned to a site, as Figure 2.5 shows.
Figure 2.5
Servers automatically assigned to a site
Site Links and Site Link Bridges

In some cases, logical sites could be described more accurately as “islands” rather than as collections
of well-connected computers. To complete a design, you need to establish links between and among
the sites. RPC over TCP/IP is the primary transport for intra-site and inter-site replication, although
you can use SMTP for inter-site, inter-domain replication.
Because this use of SMTP is important, let me say more about it. If you want the AD forest to
span a WAN link that doesn’t support RPC, the two sites must be configured in separate domains and
in separate sites. In this situation, you can use an enterprise Certification Authority (CA) to issue a
certificate to the DCs – then use SMTP as the site link between the sites.
In most cases, you’ll want to create a separate site link for each physical network link. This
approach gives you greater control of replication for each site because the replication schedule and
cost are attributes of the site link and not of the site itself. For example, if you have two remote sites
that connect to a hub site over private WAN links, you need to create two site links. Also, to make
troubleshooting easier, you’ll want to give each site link object a descriptive name that lists the sites it
connects, such as “Atlanta to London – SMTP.” You don’t want to make this name too long, however,
or others using the Active Directory Sites and Services snap-in will find the name difficult to read.
After all your site links are in order, you can add a site link bridge to provide even more
redundancy in the routing topology. A site link bridge is a logical collection of site links that permits
transitive replication between sites using the lowest cost path. In the example, you could create a site
link bridge between the main sites, which would let the secondary sites use alternate routes for AD
replication in the event of a failure. (Because the alternate route costs would be higher for direct
communication, alternate routes would be used only in the event of a failure.)
You could also create a single site link bridge that contains all site links to provide an excellent
backup route for all AD replication in the organization. Granted, you could achieve the same goal by
creating backup site links for each site. However, that approach would involve more work, result in
static routes that aren’t dynamically updated, and require additional modifications should the AD
structure change.
Naming Your AD Environment

Earlier in the chapter, I described the importance of meeting with key people as you plan your AD
environment. In naming your AD environment, you’ll especially need their involvement and buy-in.
The name you choose determines the identity of the domain, the NetBIOS name users will see when
they log on to the domain, and the overall hierarchical structure of AD itself.
This first, root domain is of utmost importance because you can’t easily rename it, and it will be
included as the suffix of all domains that join it. For example, adding an AD domain named ITG to
the Microsoft.com AD forest results in an AD name of ITG.Microsoft.com.
Because the AD namespace requires DNS and uses DNS zones to store directory information,
Microsoft recommends matching your AD namespace to a DNS namespace that your company has
already registered with an Internet registrar. Although Microsoft itself uses the same internal and
external namespace (Microsoft.com), it’s also common for companies to use separate name spaces –
such as Company.com for external DNS and Company.int for the internal AD and DNS namespace.
AD and DNS Name Spaces

The topics of AD and DNS namespaces will probably generate ample debate during the design
phase, given the many available options. The AD naming hierarchy will, for the most part, dictate the
design of your internal DNS hierarchy. The internal DNS namespace can have a relationship with the
external zone, such as Internal.company.com, or even the same namespace, as such Company.com.
In choosing your AD internal DNS namespace, remember that
• your external facing DNS server shouldn’t contain AD objects
• internal clients should be able to resolve external company objects, such as www.company.com
Another aspect of DNS involves the server(s) that internal machines use to resolve addresses.
As I mentioned, the AD stores information in the internal DNS zones that match the AD namespace.
Although Windows 2003 DNS servers perform well and can be better integrated with the AD, you
don’t need to use Windows 2003 or Win2K servers for your internal DNS zones. In fact, you can use
any server that complies with BIND 8.1.2 (or later) and supports the use of SRV records.
Although it’s not a requirement, you should seriously consider using a DNS server that also
supports dynamic updates. Otherwise, you’ll end up manually creating many records for site
definition, GC, Lightweight Directory Access Protocol (LDAP), DC, and Kerberos entries.
AD, DNS, and SMTP Addresses

One final point I want to make about AD and the internal DNS namespace is that they have no
bearing on the SMTP addresses your company might want to use. Should you decide to use
Company.int for your namespace, you can still collect email for Company.com, Company.org, or any
SMTP domain that you set up.
In fact, an external DNS zone that you set up to route email to an Exchange server is no different
from any other SMTP server. Mail Exchanger (MX) records are used to identify the canonicalized
(CNAME) host records that will receive the email. In your external zone, you can add a CNAME
record for the Exchange server or inbound SMTP record you want to use, then configure an MX
record with a value – or “cost” – (default 10) for the exchanger.
n Note Within a DNS zone, you can create a resource record known as an MX resource record. The
MX associates a domain name with a host name and a preference value. This value, also
referred to as “cost,” will determine the order a mailer (server) uses to route email to your MX
hosts. The mailer uses the MX record with the lowest cost. If two or more records have the
same cost, the mailer will try all MXs with that cost before it tries any with a higher cost. See
Request for Comments (RFC) 974 for more details about MX record processing at
http://www.sendmail.org/rfc/0974.txt.
d Caution
I’ll talk much more about fault tolerance, protocol separation, and firewalls later in the book,
but I want to emphasize one aspect of inbound SMTP while I’m on the subject of DNS. You
need to set up a way to collect email if your Internet connection or email server fails. DNS can
play a part in the necessary redundancy by identifying more than one MX record. In general,
when more than one MX record exists, the lowest cost record will be used. One exception to
this rule occurs when the server that the connection identifies can’t establish an SMTP
connection. If the failure persists, the next higher cost record is selected. If multiple records
have the same cost, the servers will be contacted in a round-robin fashion to establish a
connection. When servers are contacted at random rather than by availability, you sacrifice
true load-balancing.
j Tip
A customer taught me an excellent way to provide fault tolerance and security in respect to
SMTP attacks and virus outbreaks. Most ISPs provide a “mailbag” service for a reasonable fee
that will let your company continue to receive email should you experience a server or
network failure. To set up the protection, you need to create an MX record for your email
server with a low cost (e.g., 10) and set your ISP’s email server at a higher cost (e.g., 100).
With this configuration, a failure of your network link or SMTP server would result in your ISP
storing your email. The ISP could configure its server to continue to retry delivery until your
network link or server is restored. In some cases, your server will need to issue an extended
turn (ETRN) or similar command to start delivery of queued email from the ISP. Another
benefit of this approach is that in the case of a malicious SMTP attack, you need to take down
only one inbound server to isolate your network from the attack.
n Note The ETRN command replaces the TURN command, which was found to have serious security
problems because it doesn’t verify the host that issues the command. The concept behind the
ETRN command is that an SMTP server can collect email for a domain and store it until the
proper server connected and issued a command to collect the email. This feature is ideal for
companies that don’t have a permanent IP connection, need to add fault tolerance to their
inbound email flow, or need to change locations. For more details, see RFC 1985 at
http://www.faqs.org/rfcs/rfc1985.html.
Domain Cleanup and AD Migration

Windows domains have been around since 1993 and Microsoft has developed domain capabilities
over the years. Before Win2K, the domain model didn’t work well over WAN links because of the
nature of NetBIOS and RPC. In response, Microsoft established a new domain model that lets you
create administrative and replication boundaries. The administrative domains, resource domains, and
account domains that were part of the original domain model are now superfluous.
You realize the full impact of the new domain model when you remember the fundamental rule
of DC redundancy: A domain must have least two DCs for failover. If you can collapse just one
resource or remote domain, you can save at least two servers. In a larger company with departmental
domains, a Windows 2003 deployment and domain consolidation could save many more servers – as
well as their update and support costs and any additional ancillary annual expenses. The math is
fairly simple: A reduction of 10 domains would result in a reduction of at least 20 servers. Twenty
fewer servers means fewer server and antivirus licenses as well as fewer backup agents and less
administration.
Consolidating and migrating domains has become such a popular administrative process that
several companies have developed tools to smooth the process. Microsoft, for its part, has updated
the Active Directory Migration Tool (ADMT) in Windows 2003. Whatever aids you choose, the
consolidation and migration process always begins with your final design.
If you currently have NT 4.0 domains, the biggest question is whether you’ll inherit one (or
more) of the current domains and upgrade it to AD or migrate to a brand new AD domain. Although
it’s almost always easier and cheaper to upgrade a current Windows NT 4.0 domain, many people
prefer not to inherit “fat” from a legacy domain.
You can also choose to mix the two approaches and upgrade your largest domain while
collapsing the remaining domains into your newly created AD. In other words, you would upgrade
your largest account domain to AD, then migrate some or all of your other account domains into it.
This reduction of domains would result in instant savings and would greatly simplify your
environment.
Consolidating and Collapsing Domains

To consolidate or collapse a domain, you must move or copy the user accounts, the machine
accounts, and the servers from the old domain to the new. You can use ADMT 2.0 or third-party
migration tools to perform that function. In addition, the tools support retaining user passwords and
group memberships – and can even reapply ACLs to file, print, and Exchange servers to point to the
new AD accounts and/or legacy NT 4.0 domain accounts.
Furthermore, the migration tools can automatically move the computer accounts, change the
domain membership of workstations, and reboot the workstations remotely. Wizards and Help
screens smooth the migration by walking you through the process. You can find ADMT 2.0 on the
Windows 2003 CD-ROM in the \I386\ADMT folder.
Moving File and Print Servers

For many administrators, moving file and print servers from one domain to another can be time-
consuming, not to mention frightening. The challenge of such moves is one reason that migration
tools offer the ability to migrate the SID from the legacy domain to the new domain. The ability to
migrate the SID lets file and print servers remain in their legacy domain while workstations and users
move forward to AD.
This migration option is accomplished through the SIDHistory field, which migration tools can
populate. New AD accounts will be given a new SID, but specialized migration tools can copy their
legacy SID into SIDHistory. The new AD accounts can then impersonate their legacy NT 4.0 accounts.
The AD accounts can access resources in the legacy NT 4.0 domain, while also logging on to the
new AD domain.
At the same time, you should install and test Microsoft’s ADMT 2.0 tool. ADMT includes fewer
options and does little to no reporting, but it does offer brute-force utilities to support most domain
migration projects.
Windows 2003 Server Rename Tools

After you’ve migrated to Windows 2003 and have raised the domain functional level to Windows
2003, you can rename DCs or entire domains. You should avoid the domain rename feature,
however, if you run Exchange 2003 or Exchange 2000. If you rename a domain with this feature, the
DSAccess component no longer functions correctly. Because the Exchange System Attendant Service
relies heavily on DSAccess, the System Attendant Service, Information Store Service, and other
Exchange services won’t start. The domain rename functionality should be compatible with Exchange
2003, Service Pack 1 (SP1).
Prepping AD for Exchange

Although this entire chapter is devoted to deploying AD as preparation for Exchange 2003, I haven’t
yet discussed extending the schema. I saved this subject for last to ensure that I had first provided
adequate information about AD. By default, Microsoft doesn’t automatically provide AD with the
necessary information to support Exchange 2003 or Exchange 2000.
The base AD schema includes all the classes and attributes necessary to define the objects for
its purpose, but thousands of additions and modifications to existing classes and attributes are
required for Exchange 2003 and Exchange 2000. The process of adding these schema updates is
called ForestPrep – the name of the command you use during setup to commit theses changes.
ForestPrep
Before you update the schema, you should identify the AD group to which you want to delegate
Exchange full administrative rights. You will be prompted for this choice during the update process.
This group will have permissions to install Exchange Servers and to configure the Exchange
organization.
After you designate the group that will have full administrative rights, you can begin the schema
update process. Even though schema updates are required only once, you can apply them a couple
of different ways. Exchange 2003 Server comes with a new deployment wizard that takes all the
guesswork out of installing Exchange 2003. Exchange Server Deployment Tools, which Figure 2.6
shows, provides a list of dependencies and walks you through the process one step at a time.
Figure 2.6
Exchange Server Deployment Tools
To update the schema manually, log on to the machine with an account that’s part of both the
Enterprise Admins group and the Schema Admins group and run <drive>:\setup\i386\setup.exe
/forestprep. Follow the dialog boxes for confirmation and enter the activation key.
If you’ve performed this deployment process with Exchange 2000, you might notice a difference.
With Exchange 2003, you don’t have to choose an org name or migration options during ForestPrep.
ForestPrep has been scaled down to do nothing more than modify and add classes and attributes.
Because no “branding” occurs during this phase, you can execute ForestPrep safely even if you don’t
know what the org name will be or whether you’ll upgrade from an Exchange 5.5 org.
Note that these schema updates (any schema update) must be replicated to every DC in the
forest. You’ll pay a network penalty during the replication, so plan your update wisely to reduce the
effect on production network access. Also, you might want to update the schema fairly early in your
AD deployment, perhaps before you deploy remote AD DCs, so that you won’t need to perform a
forestwide replication of schema updates.
DomainPrep
Next, you must create the domain groups that will contain the servers and the object that will contain
the public folder proxy information. You can do so by accessing Exchange Server Deployment Tools
and choosing DomainPrep. To run this command, you need to have administrative privileges for the
local machine and domain administrator privileges for the domain you want to prep. You must run
this command on every domain that will contain Exchange 2003 servers.
Trust and Verify

If you’re wondering whether someone has already run the ForestPrep and DomainPrep commands or
you simply want to verify the changes, you can use the OrgPrepCheck tool to get a detailed report.
Because this tool is a feature of the ExDeploy tool set, you need to execute it from the Exchange
2003 installation CD-ROM or DVD. ExDeploy is very flexible in that it provides a GUI that walks you
through the setup steps, but you can also use it from the command-line to set specific switches for
batch or script commands. In this example, I start at the command prompt and navigate to the
ExDeploy folder on the CD-ROM or DVD, then issue a specific command.
\ENGLISH\EXCH2003\STANDARD\SUPPORT\EXDEPLOY>exdeploy.exe /s:<SERVERNAME>
/gc:<SERVERNAME> /t:orgcheck
Although the OrgPrepCheck tool is designed to assist with Exchange 5.5 upgrades, it serves the
purpose of verification. The ExDeploy tool set offers additional tools, such as those listed below,
which you can run to gain useful deployment information.
• DSConfigSum runs Exchange 5.5 Directory Configuration Summary
• DSObjectSum runs Exchange 5.5 Directory Object Summary
• UserCount runs Exchange 5.5 Directory User Count
• VerCheck runs Server Version Check
• ADCUserCheck runs ADC User Replication Check
• NTDSNoMatch runs NTDSNoMatch
• OrgNameCheck runs Organization and Site Names Check
• ADCObjectCheck runs ADC Object Replication Check

• ADUserScan runs Active Directory User Replication Scan
• PolCheck runs Policy Check
• OrgCheck runs Organization Readiness Check
• PubFoldCheck runs Public Folder DS/IS Check
• ADCConfigCheck runs ADC Configuration Replication Check
• ConfigDSInteg runs Exchange Server 2003 Configuration Object Check
• RecipientDSInteg runs Exchange Server 2003 Recipient Object Check
• PrivFoldCheck runs Private Folder DS/IS Check
• OrgReport runs Existing Org Report
• GCVerCheck runs Global Catalog Server Version Check
Next: Consolidating Your Exchange Services

In Chapter 3, I’ll first review why so many Exchange 5.5 sites exist. I’ll then discuss site consolidation,
including concerns you’ll need to address whether you consolidate before or after your Exchange
2003 migration. I’ll explore server placement strategies, especially scenarios that involve remote and
small offices, as well as server sizing. Finally, I’ll consider your cluster and fault-tolerance options.
34
Chapter 3:
Consolidating Your Exchange Services

At the heart of most successful and cost-effective Microsoft Exchange 2003 and Exchange 2000
deployments lies consolidation. Fewer Exchange servers translates to fewer server licenses,
smaller data centers, easier administration, and a reduced cost of doing business. These benefits of
consolidation are often the desired end results that prompt – and justify budgets for – upgrading and
consolidating Exchange deployments. Estimating the savings that your consolidation efforts can realize
will require some intelligent speculation because you’ll derive your overall savings from multiple
sources.
In fact, Microsoft recently performed a consolidation that illustrates the potential for administrative
savings. With Exchange Server 2003, Microsoft reduced its 113 mailbox servers in 75 geographical
locations worldwide to 38 mailbox servers in 7 locations worldwide.
Server Ownership Costs

IDC estimated that 62 percent of 2002 server costs came from the additional staffing required to
support the servers. Another 23.1 percent of the costs came from downtime, with the balance
assigned to training, software, and hardware. IDC broke down its 2002 numbers for the annual cost
of Windows server ownership (per server) into the following server categories:
• File server $19,809
• Networking server $2,357
• Print server $17,369
• Security server $14,099
• Web server $6,461
Although reports about messaging costs offer various figures, I like to use an annual cost of $10,000
per server for most calculations. Whether your specific numbers are higher or lower, you can see
how quickly server-consolidation savings can add up. So the questions you’re probably asking right
now are “How did we get here?” and “Where did all these servers come from?”
In 2003, the Gartner Group noted that independent business units within companies – rather than
the company’s IT department – initiate more than 60 percent of all IT projects. The high proportion
of business units initiating deployments is especially true for Exchange because remote offices and
departments often decide they need more horsepower or an additional server – or worse still (in
terms of additional ports) their own SMTP domain or Microsoft Outlook Web Access (OWA) server.
Exchange Server Proliferation

Although you can certainly blame departmental projects for proliferation, Exchange 5.5 Server’s
limited scalability has also been a key factor. Most of Exchange 5.5’s scalability limits involved the
Chapter 3 Consolidating Your Exchange Services 35
limits of the Extensible Storage Engine (ESE) engine. Administrators didn’t want to scale Exchange 5.5
servers too large because a 500GB database would take more than 15 hours to back up or restore).
Moreover, a single database failure or corruption could mean certain death to the Exchange
administrator who had decided to put all users on the same box (I won’t even mention how the
OWA client performed). In short, many companies needed additional Exchange 5.5 servers to “spread
the load” – both to accommodate users and protocols and to maintain acceptable performance.
Also, although Microsoft Outlook 98 offered a stable offline mode that permitted remote access to
the Exchange server, it wasn’t robust. Most remote offices wanted the same performance they enjoyed
with local Microsoft Mail (MS Mail) and cc:Mail post offices. To achieve that performance, many
remote offices installed a small Exchange 5.5 server. Fortunately, you now have more options.
For this discussion, I’ll divide the subject of consolidation into distinct categories and begin with
the lowest common denominator: protocols. I’ll then cover server consolidation, site consolidation,
and, finally, Exchange organization consolidation.
Consolidating Protocols
Although administrators often consider protocol consolidation only after they’ve deployed or
upgraded Exchange, the security implications involved should make protocols an early priority. As
an Exchange consultant, I work all over the world and I get to hear many instructive stories. One
customer described a security incident that put the virtues of consolidation in sharp perspective. His
company was burglarized one afternoon; apparently the culprit had “tailgated” an employee into the
building through a side door. Thereafter, the security team insisted that everyone come in and out the
main doors so that security personnel needed to watch just one entrance for unauthorized access.
Chances are you need to reduce the number of “entrances” to your network. And, although you
might not be able to control the number of firewalls on your network (whose protection can be
somewhat offset by the monitoring and management challenges that different access rules create),
you probably can control how many and which protocols (and therefore ports) your company uses.
Because business units drive many IT projects, companies often have multiple Internet
connections. One of my client companies has roughly 50 business units and as many Internet
connections. (I won’t discuss the potential problems that come with 50 Internet connections and
possibly 50 firewalls; you understand the risks and administrative nightmares.) However, you no
longer need all those connections. Instead, you can place a couple of inbound servers for the mail
protocols centrally to provide a redundant inbound path for email and OWA.
As you know, the more inbound ports you have open on your network, the less secure your
network will be. Although I’ll discuss security in more depth in Chapter 7, I want to emphasize here
some key points about the vulnerabilities that multiple protocols can create. Figure 3.1 shows a
three-site design with multiple protocols in use.
Figure 3.1
Site design with multiple protocols
SUv.com
Internet
Other Sites
SMTP
POP
Trucks.com IMAP
HTTPS
SportsCar.com
Other Sites
You can see several points of vulnerability in this design:

1. A new virus or network attack could bring down all three sites because they’re all exposed to the
Internet.
2. From an SMTP perspective, a server or network failure stops inbound mail for that entire SMTP
domain.
3. Virus and antispam updates might not be in sync, so different locations might have different
protection levels.
4. Three firewalls and their access rules are much more difficult to manage and monitor than one
or two.
In Figure 3.1, you can see that many inbound ports must be enabled to support each business unit. A
better design would establish a clear boundary between the Internet and the email servers (i.e., a
Demilitarized Zone or DMZ) and consolidate the Internet email services to better secure and stabilize
the environment.
You can establish a protective boundary for your organization in various ways. You can
configure Microsoft IIS to provide a boundary or configure Linux with Sendmail to accomplish the
same purpose. Other products and more sophisticated solutions also exist. Microsoft has recently
announced a new product, Exchange Edge Services, which will eventually play this role for SMTP
and provide additional features as well. The current Microsoft solution is to place Microsoft ISA
Servers or Exchange 2003 front-end servers at the boundary.

Before I discuss front-end server deployment, I want to point out that Exchange 2003 is smarter than
I once thought. Because its folders and mailboxes are published to Active Directory (AD), Exchange
2003 knows to look in AD for Exchange resources.
In your Exchange organization, you have mailboxes on servers. AD keeps mailbox information
under several Exchange attributes in the Class object USER for each person who has a mailbox. But if
you look at the Exchange objects in the Microsoft Management Console (MMC) Users and Computers
snap-in, you see that the public folder proxies (in the default top-level hierarchy) are also added to
AD, as Figure 3.2 shows.
Figure 3.2
Exchange System Objects and Exchange Mailbox Store
Each Exchange server in the routing group is notified of a hierarchy change, and information about
the folder structure is replicated. This notification lets each mailbox server (within the routing group)
report the folder hierarchy as well. And therein lay the magic.
Although the public folder exists on only one server in the routing group, other Exchange 2003
servers can automatically redirect to the appropriate server. If I use OWA to access a public folder
that exists on a different server, the server to which I’m connected will perform a quick directory
lookup and send me to the server that contains the data. All Exchange 2003 and Exchange 2000
servers can automatically redirect the OWA client, as Figure 3.3 shows, to the appropriate mailbox or
public folder server.
Figure 3.3
Using OWA to find a public folder
In this case, I’m attempting to connect to a public folder that exists only on Server2. When ServerA
realizes it doesn’t have the folder I’m requesting, it performs a directory lookup to find the server that
holds the data. The Exchange 2003 server then redirects my request to the appropriate server that
stores the data. As Figure 3.4 shows, Exchange 2003 has redirected the request to the server that
holds a replica of the OWATEST folder.
Figure 3.4
Exchange 2003 redirected request
Mailboxes work similarly. By default, Exchange 2003 and IIS servers make a quick check to see
which server holds the data, and then redirects the client. It doesn’t matter how you create the folder.
n Note The preceding paragraphs describe default behavior for Exchange 2003 and Exchange 2000,
none of which depends upon Front-End Services or any special functionality.
An interesting aspect of this functionality is that you can have a single internal namespace for
email and route users to their mail server automatically. In other words, an internal DNS alias of MAIL
can route to a single Exchange 2003 server – and that server will automatically redirect the user to his
or her appropriate mail server. In an environment with fast links, you could even consider DNS
round-robin or some other way to provide DNS lookup for the server. Again, this approach is default
behavior for Exchange 2003 and Exchange 2000.
Front-End Exchange Servers

Now let’s talk about front-end servers. After you’ve installed your second Exchange 2003 server in the
organization, you can choose to turn it into a front-end server. No additional settings are involved for
a front-end server. An Exchange 2003 server is either a front-end server or a “regular” server – usually
referred to as a back-end server when a front-end server is present. Making an Exchange 2003 server
a front-end server is one of the easiest things you’ll ever do.
Open the MMC Exchange System Manager snap-in and expand the Servers node under your
Exchange organization’s name. Right-click the server you want to convert to a front-end server and
select This is a front-end server, as Figure 3.5 shows. Click OK and reboot the server to complete the
transition. In this case, I right-clicked Server1 and selected This is a front-end server.
Figure 3.5
Converting an Exchange server to a front-end server
n Note Making a server a front-end server prohibits that server’s access to the local stores for mailbox
or public folder information. Fortunately, it’s easy to change the server role back.
So what have I done? By designating a server as a front-end server, I’ve instructed that server to
no longer refer me to a server that holds requested information. The front-end server performs the
same lookups as before, but now it also handles authentication and all communications with the
back-end server. Let me demonstrate. First, I try to open the OWA session from the front-end server,
as Figure 3.6 shows.
Figure 3.6
Using the front-end server
In a front-end server test, the front-end server doesn’t redirect me to the appropriate back-end server.
Instead, I’m “proxied” to the appropriate mailbox or public folder server. I enter the same information
as before. However, this time, I’m prompted for a password, as the dialog box in Figure 3.7 shows.
Figure 3.7
Front-end server password prompt
n Note Front-end servers understand only basic authentication and always prompt for a password –
even if you already have a token in memory. So if you have an in-house application and don’t
want to prompt the user for authentication, don’t use front-end servers.
Next, instead of redirecting me to the appropriate Exchange Server, the front-end server acts like
the back-end server it found. Notice in Figure 3.8 that the Address bar shows an Exchange directory
on Server1.
Figure 3.8
OWA session appearing to come from the front-end server
As you see in the Address bar, the OWA session appears to come from the front-end server, Server1
– although the mailbox is actually on another Exchange 2003 server.
As I mentioned before, Exchange servers search AD to find Exchange objects. In a typical
situation, the server that actually holds the data instructs the referring server to redirect the client.
However, front-end servers are directed to respond as if they held the data.
To illustrate, I’ve included a packet trace I performed in the lab while a client requested an
OWA session from the front-end server. I started the process that Figure 3.9 shows by accessing
http://server1/exchange from Internet Explorer (IE).
Figure 3.9
OWA session request packet trace
In this case, the client’s mailbox was on ServerA. First, the client performs a DNS lookup for
Server1.bryant.com. The response arrives, and the client then performs a GET request for an OWA
session. (Remember that Server1 is the front-end server.)
The front-end server uses DNS to find the Global Catalog (GC) server. After the front-end server
finds the GC server, it queries the AD to determine the mailbox server for the request.
After the front-end server finds the appropriate back-end server, the front-end server begins to
echo the client requests verbatim to the back-end server. The mailbox back-end server responds with
information for the client, as Figure 3.10 shows.
Figure 3.10
Front-end and back-end servers responding to a client request
n Note Another key component that lies at the heart of Exchange 2003 is Web-based Distributed
Authoring and Versioning (WebDAV). WebDAV, a series of extensions of HTTP, is a protocol
standard for performing basic file system operations across the Web. Because WebDAV is
based on HTTP, it’s an excellent way to code through firewalls. When used in conjunction with
XMLHTTP, WebDAV can also define the XML post data structure. OWA for Exchange 2003 is a
prime example of this combination.
A front-end server is designed to reroute Internet protocols to the appropriate back-end servers.
HTTP, POP, and IMAP sessions are directed to the front-end server(s), then proxied to the appro-
priate back-end or mailbox server located within the corporate network. (SMTP is handled a little
differently in that the messages are spooled locally on the front-end server, then routed internally.)
This layer of protection helps isolate the production mail servers and their data from the Internet, as
Figure 3.11 shows.
Figure 3.11
Front-end server protection layer
Internet
Exchange
Trucks.com
SportsCar.com
SUV.com Other Sites
SMTP
POP
IMAP
HTTPS
Front End
Servers
Exchange Exchange
Other Sites Main Site
A front-end server doesn’t “care” where a request originates. Its sole task is to proxy the requests.
The front-end server will look in AD to find the source you’re requesting and proxy the request
to that server on your behalf. Essentially, the front-end server has no inherent load-balancing
characteristics nor can it provide your mail if your mail server is unavailable.
In short, front-end servers let you consolidate your inbound Internet protocols and help simplify
and secure your Internet messaging. By reducing the number of inbound ports, you make your
environment more secure and easier to manage. Moreover, you can leverage these central servers on
behalf of other corporate-wide features such as Outlook Mobile Access and even remote procedure
call (RPC) over HTTP.
Front-End Servers and Performance

Interestingly, front-end servers offer little performance gain apart from offloading Secure Sockets Layer
(SSL) from the back-end servers. As you saw in the protocol traces, the front-end server must be able
to find your internal DNS Server, an AD domain controller (DC), and a GC for your domain. The
front-end server uses these tools to locate and communicate with the back-end servers.
So, what exactly does a front-end server offload from back-end servers?
• Authentication – As I mentioned previously, front-end servers support only basic authentication. If
you use SSL, the front-end server will handle SSL. SSL adds overhead to transactions. In most
cases, SSL doubles or more than doubles the processor use on the server and the amount of data
sent over the wire, so offloading this overhead is helpful.
• Controls – Your custom applications will use a set of tools or controls for the client. The
front-end server acts as an IIS server and provides the controls you specify to the HTTP client.
Although a front-end server doesn’t hugely lighten the load on back-end servers, it lessens the
load somewhat. You can see the degree to which the back-end server’s load is lightened in the
performance comparison snapshot that Figure 3.12 shows.
Figure 3.12
Back-end server performance with and without front-end servers
The peak on the left in Figure 3.12 was generated when a client entered http://server2/exchange
directly to access mail. The peak on the right was generated when the client entered
http://server1/exchange and accessed data on Server2 through the front-end server. As you can see,
the load on the back-end server is slightly lower when access occurs through the front-end server.
Balancing Front-End and Back-End Servers

Based on this data, routing clients through a front-end server doesn’t dramatically reduce the load on
the back-end servers. In most cases, the bottleneck continues to be the back-end servers.
j Tip
The overall recommendation to provide a good balance is one front-end server to four
back-end servers.
As a general rule, add back-end servers as you typically would to overcome capacity issues on
the mail servers. Add front-end servers to provide redundancy to the browser clients and to add a
single namespace. Keep in mind the following six points about Exchange 2003 front-end servers:
• Front-end servers use basic authentication, so users will always be prompted for a password.
• Front-end servers do nothing with Messaging API (MAPI). Your Outlook clients gain nothing
from the introduction of a front-end server
• Front-end servers require quite a bit of network access, including access to the internal DNS and
GC servers and the ability to communicate directly with the Exchange back-end servers.
• Microsoft and security professionals highly recommend (many consider it a requirement) that you
require HTTP Secure (HTTPS) for POP, IMAP, and HTTP traffic to protect not only the data, but
most importantly the logon credentials. I’ll cover such security topics in more detail in later
chapters.
• By default, Kerberos secures the channel between the front-end and back-end servers. If you’ve
installed Microsoft SharePoint Portal Server or another program that might have disabled Kerberos
support, you should look at the following Web page, which shows you how to correct the
situation: http://www.microsoft.com/exchange/support/e2k3owa.asp
• You can implement Windows Network Load Balancing (NLB also formerly known as WLBS) to
help balance the load on front-end servers. With Windows NLB, you can put a collection of
front-end servers into place to centralize all the inbound Internet protocols for a division or entire
company.
Consolidating Servers
How many mailboxes can you put on a single Exchange 2003 server? That question is at the heart of
any Exchange project, and the answer depends on your service level agreements (SLAs) and uptime
requirements explicitly defined or implied. If your current backup and restore procedures can handle
50GB per hour and you have a maximum downtime window of 8 hours, each Exchange server
should hold no more than 400GB of data. When the server load gets beyond that point, you can
reduce mailbox sizes, increase the allowed downtime in your SLA, or allocate a new server.
Storage Space and Recovery

More than anything else, storage space and recovery determine the number of servers you need.
Outlook clients (including Outlook Express and OWA) don’t create heavy CPU use on servers.
LoadSim is an excellent tool you can download to stress-test your servers with Outlook traffic. You’ll
see rather quickly that a single Exchange server (even Exchange 5.5) can handle thousands of users.
Be careful that you consider both current capacity and capacity trends so that your environment can
handle anticipated growth rates in messaging quantity, messaging volume and message sizes for a
given period of time into the future. If you plan to increase quota limits in the near future make sure
you take that into consideration, as well.
On quite modest equipment with dual processors, you can successfully simulate thousands of
users with ease. HP and Dell both have some excellent hardware guides for Exchange that can help
you identify the type of hardware you need for specific server types and numbers of Outlook users.
I/O is much more important to Exchange, so that will likely be your primary concern.
Configuration and Memory

For configuration and memory, you need to specify enough disk space to handle the data you plan
to store or spool. To begin with, avoid placing different types of programs and their data on the
same set of disk-drive spindles as Exchange components. Exchange database reads are random, so a
RAID array constantly moves the drive heads to seemingly random spots on the platters to find data.
At the same time, the database transaction logs (not to be confused with the message tracking logs)
are being written sequentially. Different applications place different requirements on the drives and
thus contend for them, which creates potential delays for all the programs that share the drive.
Given the way the overall process works, you face two concerns. First, because transaction logs
are deleted every night, drive fragmentation occurs. If your database is on the same drive (which is a
very bad practice and not recommended), you’ll probably experience a very fragmented Exchange
Store. Second, because the spindles in the arrays can spin only so fast and the drive heads can
occupy only one position at a time, a heavily accessed database will contend with transaction log
writes.
The result could be a slower operating environment, with Outlook users experiencing pauses
while Outlook opens folders or individual items. If you expect heavy or frequent database access
(e.g., if you have 500 to 1000 users), consider locating your Exchange databases and their transaction
logs on completely different (and dedicated) arrays.
Moreover, if your consolidation plan shows that you need to run multiple databases and storage
groups on your server, consider a mirrored array for each set of storage group transaction logs and a
striped array for the databases in one storage group. Depending on the size of your Exchange
databases and expected activity, you might even want to consider placing each database on a
dedicated array.
Memory and processor specifications are easy to define and plan for. Exchange Server will use as
much memory as you install. By caching as much data and as many processes as possible, Exchange
Server can reliably service thousands of simultaneous users on a server with as few as two Pentium II
(or better) processors.
j Tip
You’ll find two exceptions to the preceding rule of thumb for Exchange Server service ratios:
OWA servers that support SSL and Exchange application servers that regularly initiate
complicated events might need more processing power.
Mailbox Consolidation Concerns

The next question you need to answer is whether you want to run all of the mailboxes from one
server (or a few servers). Although you probably could reduce your entire Exchange organization to
a few servers, you might not want to. The following factors affect this decision:
• Foreign mail connectors – The Lotus Notes Connector, for example, should be run on a separate
server because you’ll need to install a Notes client and will probably need to reboot the server
more often than an ordinary mailbox server.
• Remote offices – Companies with slow WAN links to remote offices will probably require an
additional server – at least for the larger remote locations. Later in this book, we'll describe the
savings gained by using Outlook 2003 in cached mode with Exchange 2003 mailbox servers.
While this will certainly affect the decision to place servers in smaller locations, the larger remote
locations will likely still need a local server to expedite the delivery of local messages with large
attachments and to help reduce the impact to the WAN link for large populations of mailbox
users.
• “Putting-all-your-eggs-in-one-basket” concerns – IT Managers (and administrators) are sometimes
skeptical about placing all resources on one or just a few servers.
Creating Server Redundancy

Although this chapter is about consolidation, the need for redundancy sometimes outweighs the need
for consolidation. So how can you create redundancy in an Exchange network and still keep it as
consolidated and cost-effective as possible? Let’s consider three widely used options: spreading the
load, clustering, and deploying high-availability servers.
Spreading the Load

By placing your connector servers on dedicated equipment and placing the mailbox databases on
separate Exchange 2003 servers, you can mitigate some of the risk associated with server failure or
database corruption. Should a server fail because of hardware or software issues, the services on that
machine alone would be affected. Although such a configuration lets you use cheaper servers
because capacity is kept low, licensing and administration costs often make this configuration less
desirable.
Clustering
Clustering is often initially considered the “silver-bullet” for protection and redundancy in a design
that has fewer servers. Microsoft Clustering Services requires that similar machines share a common
data storage device, such as a Storage Area Network (SAN) or external drive array. Each server runs a
local set of drives for the OS and uses the external device for the database stores and transaction
logs, as Figure 3.13 shows.
Figure 3.13
Microsoft Clustering Services configuration
Active Node A Active Node B Active Node C Passive Node D
C:\ C:\ C:\ C:\
G:\ H:\ I:\ J:\ K:\ L:\
DB1 LOGS1 DB2 LOGS2 DB3 LOGS3
Shared storage clusters rely on shared drives to store the Exchange log files and the databases. Many
External SCSI and Fibre Channel arrays support this configuration, as do many SANs. In March 2004,
Microsoft announced support for the iSCSI interface, which might eventually support clusters as well.
If one server should fail, the other server can load the databases and continue to service clients
as the failed server. The switchover from one node to another could take several minutes depending
on the size and fragmentation of the Exchange databases. An active/active configuration (in which
both servers are typically live and sharing the load) has a practical limit of roughly 3000 active MAPI
sessions. In an active/passive configuration (in which only one server at a time is live), the number of
concurrent sessions has no practical limit.
Exchange 2003 also offers you the ability to mix the configurations: Options such as
active/active/active/passive are available. In fact, Exchange 2003 has added support for up to 8-node
active/passive clusters if you use Windows Server 2003 (Windows 2003) Enterprise Edition or Win-
dows 2003 Datacenter Edition.
Clustering for Exchange lets you load databases from one node onto another node in case of
failure. Some Exchange features (e.g., the foreign-mail connectors) and many third-party Exchange
add-ons are not cluster-aware or only active/ passive aware. In addition, because a clustered server
runs its own OS and applications, it’s subject to separate licensing. You must license both Windows
2003 Advanced Server and Exchange 2003 Enterprise. Furthermore, you must purchase antivirus soft-
ware, antispam software, management tools, and agents for each node.
Deploying High- or Continuous-Availability Servers

The concept of fault-tolerant servers isn’t new. Digital Equipment (DEC) and the inheritors of that
fault-tolerance knowledge, then Compaq and now Hewlett Packard (HP), as well as IBM, have been
building fault-tolerant solutions for more than a decade. Many companies still run critical business
applications on dedicated IBM, Hitachi, and other non-Intel-based server equipment. These platforms
use redundant I/O modules, processor and memory modules, and other redundant hardware within
the same system. Failed components are taken offline; their processes are re-routed before anyone is
aware of a problem.
The same level of protection is now available on the Windows platform. You may want to
explore fault-tolerant options in your research. For example, when I first encountered a Stratus FT
Server in 2001, I was surprised how well it worked. NEC has purchased and improved upon the
Stratus technology, which makes the company’s high-availability servers well worth a look.
Consolidating Mailbox Servers

Regardless of the approach you take to fault tolerance, you’ll be able to reduce your server count
with Exchange 2003. You’ll also find the consolidation process has improved. For years, Exchange
management tools have let you move mailboxes from server to server, but Exchange 2003 offers
some advanced features that make the job faster and more reliable. Moreover, you can now script
moving mailboxes.
Move Mailbox Tool

The new Move Mailbox tool is multi-threaded, so you can move multiple mailboxes at the same time.
The number of threads is based on the number of mailboxes you move, so don’t be disappointed if
you see only a single migration thread when you move small batches of mailboxes. You can
expect performance of roughly 1GB per hour, depending on what your underlying infrastructure
will support.
In addition to its performance improvements, you’ll notice that the migration tool offers support
for error logging and automatically leaves the old mailbox intact should corruption or other errors
occur during the migration. Initial screens give you the option of instructing the tool to skip corrupted
items and continue or skip the mailbox in which corrupted items occur entirely. The tool generates a
report at the end of the migration to detail which mailboxes it moved and to identify any errors it
encountered. Because of its “roll-back” support, you can now let the tool run on a schedule or let a
script initiate it.
Let’s say that you decide to balance the load on two servers manually, but you don’t want to
move mailboxes to accomplish that purpose during the day. You can schedule the move to occur at
night, while the users (and you) are asleep. Any errors that occur during the migration would result
in problematic mailboxes not being moved or moved with any corrupted items skipped.
When you move mailboxes, keep the following factors in mind:
• You’ll lose the single instance store. Moving mailboxes results in items being copied, so be
prepared for the data stores to grow larger than the size of the Exchange database .edb file. You
can easily estimate the necessary space by looking at the Mailbox resources of the source
mailboxes before the move. Exchange System Manager (ESM) lets you export the Mailbox
resources page so you can bring the numbers into Microsoft Excel and calculate totals.
• You can move mailboxes while users are logged on. The Move Mailbox tool is pretty clever in
that it runs two passes. The first pass copies email items from the source server and begins
populating the target server. The migration tool then collects the deltas before it deletes the
mailbox on the source. Although you can move email messages while users are connected to
Outlook, they’ll have to re-launch Outlook to get their email messages.
• Outlook clients will automatically correct the Outlook profile upon launch. After mailboxes are
moved, users need only launch Outlook to find the new server. All other mailbox settings are
retained. (Note that this is dependent on the original mailbox server remaining online until
Outlook has connected once.)
• The Move Mailbox tool works for certain moves only. To move from server to server in the same
Admin Group, you need only to use the ESM console to make the moves. Outlook clients will
automatically be redirected to the correct server. If you need to move the mailbox across admin
groups and the source server is Exchange 2000 or Exchange 2003, then the organization must be
set to Native mode. If you're moving from one admin group to another and the source server is
Exchange 5.5, you'll need to use the ESM from Exchange Server 2003, SP1 and use the Outlook
profile modification tool to change the Outlook profile to the new server.
• Streaming content will be promoted to the Rich Text Store as part of the migration. As mailboxes
are moved from Exchange 2000 or Exchange 2003, any content in the streaming store (.STM file)
will be promoted to the rich text store (.EDB) of the Exchange database prior to being moved.
This means that native storage is “lost” as part of the move mailbox process, and your resulting
.EDB files will be much larger on the target server than they were on the source server.
Consolidating Sites
Most remote Exchange servers exist to meet performance requirements. Outlook clients and even
OWA clients haven’t been terribly efficient on the wire. In other words, they put a lot of information
on the network. Some lab testing I did in 1999 showed that just launching Outlook 97 created
more than 100KB of network traffic. The numbers associated with Outlook 2003 – when used in
conjunction with Exchange 2003 – are substantially better due to compression and the new cached
mode.
I’ll discuss client-server performance numbers in detail in Chapter 6, but the bottom line is that
you can retire many of those remote servers. Outlook 2003 and Exchange 2003 now offer better
options for slow networks, and Microsoft has made dramatic improvements in compression, caching
directory lookups, and Outlook client performance.
If you deploy Exchange 2003, you can take either of the following approaches to collapsing your
remote sites. You can
• collapse remote sites before you deploy Exchange 2003. This scenario closely resembles the
organizational move described in the following text because you’ll have to “brute force” copy the
mailboxes over with ExMerge, the Exchange Migration Wizard, or third-party tools. Because the
mailboxes you move will basically be new mailboxes, you’ll lose distribution list membership
along with delegate information. In addition, rules probably won’t function, and you’ll need to
create a new Outlook profile for the client machine and configure it to point to the new server.
The mobile users will be affected the most as the OST files will need to be rebuilt and the offline
address books will need to be downloaded new.
• collapse remote sites after you deploy Exchange 2003. In this scenario, the migration will be
more like the mailbox moves I’ve already discussed except for the latency associated with the
slow link. You’ll probably need several nights of moving mailboxes to get remote users onto the
central server.
• you could also decide to collapse the sites as you move. This would not result in a “double”
migration. Personally, I have found it best to break these steps up into separate small projects in
order to ensure focus on the moves.
ExMerge is an efficient, multi-threaded migration tool that can access mailboxes on a source
server and import the data into personal folder store (PST) files and ultimately onto a target Exchange
server. Before you can use ExMerge on Exchange 2003 and Exchange 2000 systems, however, you’ll
need to create an account that has permissions to the mailboxes you intend to populate. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;823143&product=exch2003 for detailed
information about the necessary configuration settings.
You need to get to know ExMerge because you’ll use it more and more with Exchange Server.
In fact, it’s the tool you’ll use to extract a single mailbox or item from an Exchange database restore.
You’ll find the tool on the Exchange 2000 Service Pack 2 (SP2) CD-ROM, but I recommend that you
get the most current version directly from Microsoft’s Exchange site.
As you collapse your remote sites, you would use ExMerge to connect to the source server,
select the mailboxes you want to copy, and select the target server. ExMerge can then migrate items
– Mail folders, Drafts, Sent Items, Calendar, Tasks, Contacts, and every folder created in the mailbox –
from the source mailbox to the target server.
You’ll need to rebuild any connector information on the central server. For example, you would
need to replace a fax gateway, voicemail connector, or Blackberry service. For most remote locations,
you could conduct the migration overnight by preloading the redundant gateways, public folders,
distribution groups, and contacts before moving the mailboxes.
Consolidating Your Exchange Organization

Merging Exchange organizations has, unfortunately, become more complex since Exchange 2000,
because you now must deal with AD and the security accounts, as well as email and public folders.
(In an Exchange 5.5 environment, you can use Microsoft’s InterOrg synchronization tool from the
Microsoft BackOffice Resource Kit, Second Edition.) As you consolidate fairly current Exchange
organizations, such as those that involve Exchange 2003 or Exchange 2000 (or a mix of the two), no
single wizard helps you perform all the necessary changes and additions, so you must use several or
look for third-party tools that offer an all-in-one solution.
The rest of this chapter describes a process for consolidating Exchange 2003 and Exchange 2000
organizations. The process lets you keep your old and new systems running until the final merging.
Because you can roll back if necessary, you don’t have to worry about a “point of no return” in the
process of moving hundreds of users at once.
Consolidating Exchange 2003 and Exchange 2000 Organizations

First, you need to understand the nature, scope, and risks of the task you’re tackling as you collapse
one Exchange organization into another. You’ll be copying mailboxes, Public Folders, Distribution
Lists, and Contacts from one Exchange organization into the other. You’ll need to change Outlook
profiles manually or through a script to direct the users to the new server.
Several functions won’t work correctly after the merge. For example, all offline users will need to
create a new offline folder store (OST) file and download a new copy of the Offline Address
Book(s). Delegate information won’t carry over smoothly – if at all. Mailbox rules probably won’t
function correctly. Also, replies to existing messages might fail if you don’t exercise great caution
during the migration. It is very important that the old mail proxy addresses for the users are migrated
from the old organization to the new organization. When a person replies to a message, the old
X.400 or X.500 and, in some cases, the SMTP address will be used to address the message. The
Exchange Migration Wizard will bring these over, as will third-party tools. Finally, you’ll probably
need to delete the nickname files that the Outlook client keeps. For most companies I work with, the
migration is worth the risk because a single organization is much more flexible and offers better
collaborative functions than two organizations.
Tools for Merging Exchange Organizations

The easiest way to merge two Exchange organizations is to purchase migration tools from such
vendors as Quest Software (including migration solutions from recent acquisitions of Aelita Software
and Discus Data Solutions) or NetIQ. The capable tools these companies offer are all-in-one, and they
let you perform the migration with few manual steps. Moreover, these third-party tools let you
handily undo tasks, and they offer detailed reports about the migration. You can migrate accounts
and change Outlook profiles with ease.
For those who lack the budget for a third-party tool, the following text provides a step-by-step
walk-through with Microsoft tools and some light scripting. Administrators who are considering
purchasing a third-party tool will also benefit from a better understanding of the tasks involved.
Using the Exchange Migration Wizard

If you plan to merge Exchange organizations without third-party tools, you’ll probably use the
Microsoft Exchange Migration Wizard. With this most recent version of one of my favorite tools, you
can migrate Exchange 2003 and Exchange 2000 mailboxes to Exchange 2003 servers in different
organizations. The wizard also creates any necessary AD accounts in the target directory, including
most of the old attributes, such as the SMTP addresses. However, the wizard doesn’t address
everything. For example, because the wizard is single-threaded, no matter how many mailboxes you
migrate (e.g., 100), they’ll move one at a time until the migration is complete.
To get the mail moved over, I run the Exchange Migration Wizard and copy the mailboxes. One
strength of the Exchange Migration Wizard is its ability to match up the accounts before committing
to migrating any email messages. One of the final screens in the wizard lets you view the account
matches and change the mapping if necessary. If you have few mailboxes to move and have already
created the accounts, follow the wizard’s screens and move the mail.
Copying Public Folder Data

The next step – copying public folder data – involves a combination of several tools as well as a few
custom applications. First, you need to capture the current public folders. To do so, put together a
workstation (or two) with the following configuration: Windows 2000 or Windows NT, Outlook 97 or
later, network access to your public folder server, and access to the public stores on the source and
target servers.
In addition, install on the workstations the PFAdmin tool from the
\exreskit\tools\pftools\pfadmin directory on the Microsoft Exchange 2000 Resource Kit CD-ROM or
download it from the Exchange 2003 site at Microsoft. In a nutshell, you need to create a text file that
lists the ACLs on each folder. You’ll use this information later to restore the permission settings. Refer
to the exchtool.chm file located in the Help folder on the CD-ROM for detailed instructions about the
PFAdmin tool.
After you run the Listacl command to generate the list, you can begin copying the public folder
data. Use an Outlook client and your administrator account to systematically copy each of the folders
in the public folder tree to a local PST file. I recommend that you keep the PST file size less than 1
GB for stability and performance reasons. Depending on the size of your public store, you might
need to use Outlook sessions on several machines to copy the data in a timely fashion. In large
migrations, I’ve used as many as 20 computers to capture the public folder store among several
PST files.
Copying the Organizational Forms Library

Now, back up the organizational forms library – if such a library exists – on the server. With one of
the Outlook sessions, create a new folder in the PST named Backup Forms. Right-click the folder,
select Properties, then select the Forms tab. Select Manage to open the Forms Manager screen.
If you have permissions to the organizational forms libraries, you should be able to select it from
the left pane and view the available forms. Select all the forms on the left and click Copy in the
center of the window to copy the forms to the PST. After the copying process is complete, close any
open PST files and close Outlook.
Upload the PSTs into the target public folder system. After the upload is complete, use the
PFAdmin information to reset the folder permissions on the newly created folders. If you follow the
instructions in the exchtool.chm Help file, you can export the ACLs into a text file, manipulate the
file, and then import the ACLs into the new structure. Finally, make sure you have permissions to the
new organizational forms library and upload the forms you copied to the PST as before.
Copying Contacts from One Organization to Another

To collect the distribution group membership on the source domain, we can use the LDIF export
function to collect the SMTP address and names from the source AD. Launch the following
command from a batch file:
ldifde -m -f collect.txt -r "(&(objectClass=contact)(mailnickname=*))" -l "display-
name,objectclass,mailnickname,proxyaddresses,targetaddress"
The result of this command will be a file named collect.txt that contains the field specified in the
command:
dn: CN=Jason Sherry,OU=USERS,DC=oldcompany,DC=com
changetype: add
displayName: Jason Sherry
mailNickname: JSherry
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: contact
proxyAddresses: SMTP:jsherry@hotmail.com
proxyAddresses:
X400:c=us;a= ;p=First Organizati;o=Exchange;s=Jason Sherry;
targetAddress: SMTP:jsherry@hotmail.com
You'll need to change this file so that all references to the old forest are replaced with references to
the new forest. Actually, there should be only one change per entry:
dn: CN=Jason Sherry,OU=USERS,DC=newcompany,DC=com
changetype: add
displayName: Jason Sherry
mailNickname: JSherry
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: contact
proxyAddresses: SMTP:jsherry@hotmail.com
proxyAddresses:
X400:c=us;a= ;p=First Organizati;o=Exchange;s=Jason Sherry;
targetAddress: SMTP:jsherry@hotmail.com
After your change is complete, execute the following command to import these contacts into the
new AD:
ldifde -i -f collect.txt
Pretty easy, huh? Be sure to watch the status of the import because LDIF does not work well
with duplicates. If the contact already exists, or if the import fails on an entry, the whole import
stops. At that point, you can either delete the successful entries from the collect.txt file and start again
or remove all the entries and re-run the import phase. Also, if you need more fields than I have
provided in this example, use ADSI Edit to see the name of the field you wish to add, and then
make the change to the export command.
Collecting Group Distribution Membership

To collect the distribution group membership on the source domain, use the LDIF export function to
collect the SMTP address, group name, and members from all mail-enabled groups in the source AD.
To collect this information, launch the following command from a batch file:
ldifde -m -f collect.txt -r "(&(objectClass=group)(mailnickname=*))" -l
"displayname,objectclass,member,mailnickname,proxyaddresses,targetaddress"
You can then modify the resulting file to import the information into the new AD structure. First,
you'll need to change all references to the old AD information:
Before:
dn: CN=Sales Team,OU=USERS,DC=oldcompany,DC=com
changetype: add
displayName: Sales
mailNickname: All-Sales
objectClass: top
objectClass: group
proxyAddresses:
X500:/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=All-
Sales
proxyAddresses: SMTP:All-Sales@oldcompany.com
proxyAddresses: smtp:Sales@oldcompany.com
proxyAddresses: X400:c=us;a= ;p=First Organizati;o=Exchange;s=All-Sales;
After:
dn: CN=Sales Team,OU=USERS,DC=newcompany,DC=com
changetype: add
displayName: Sales
mailNickname: All-Sales
objectClass: top
objectClass: group
proxyAddresses:
X500:/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=All-
Sales
proxyAddresses: SMTP:All-Sales@oldcompany.com
proxyAddresses: smtp:Sales@oldcompany.com
proxyAddresses: X400:c=us;a= ;p=First Organizati;o=Exchange;s=All-Sales;
Later, the import file will contain the actual member list that is added after the initial list is imported.
The same changes will be needed in those entries as well:
Before:
dn: CN=Sales,OU=USERS,DC=oldcompany,DC=com
changetype: modify
add: member
member: CN=Phil George,OU=USERS,DC=oldcompany,DC=com
After:
dn: CN=Sales,OU=USERS,DC=newcompany,DC=com
changetype: modify
add: member
member: CN=Phil George,OU=USERS,DC=newcompany,DC=com
A good search and replace should knock all these out in one step. It is also important to
understand that my references here are with all the users in the default USERS OU for both the
source and target AD structures. The collect scripts will find the entries no matter the OU, but the
target scripts will work much better if you can place all the entries in a single OU. If not, you'll need
to make sure the import text file has the correct target OU listed for each account or contact.
Completing the Consolidation

At this point, it might seem as if the most difficult parts of a large project are behind you. However,
the fun has just begun. In many cases, the server parts of consolidation are the easiest because you
can plan for most contingencies and work on the weekends or late at night. However, other key
aspects of the project are user acceptance and the overall smoothness of the transition from the users’
perspective.
For example, when you move Exchange mailboxes from one organization to another (or site to
site in an Exchange 5.5 environment), you’ll lose several functions, including Folder Agents, Folder
Assistants, and Rules (you can copy server-based Inbox Rules by using ExMerge 2000 to move the
mailboxes, but not client-based rules), Delegate Rights and Settings (both client and host), and OST.
The migration will affect Notebook users the most because they’ll need to recreate all previous OST
and Outlook profile settings. This recreation process could mean some pain for Notebook users who
need to resynchronize over a slow link. When you plan your consolidation, keep the impact on users
in mind.
You should create a new Outlook profile for every user you move. You might be tempted to
reuse the old Outlook profiles and just change the server name. However, if you take this route,
you’ll experience problems later on because reminders will often break and links to the contacts
folder as an address book often do not work properly. Bite the bullet and create new profiles. You
should probably leave the old ones intact to manually copy any settings the profiles might contain,
such as PST file use.
You can create the new profiles with an assortment of tools (e.g., the Office Profile Wizard). You
can also script the creation of an Outlook profile by adding just a few registry keys to the client’s
machine. And you can find third-party tools to help you create profiles programmatically.
Here is the .REG file (Figure 3.14) you need to create if you wish to programmatically create new
ones for the clients. You'll need to change the NEWSERVER name to match the name of your target
server and replace newserver.company.com with the DNS name of your server. This registry file will
work on Windows NT, Windows 2000, Windows XP, and Windows Server 2003 machines – and it
will work for any version of Outlook.
Figure 3.14
Example .REG File
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Pro-
files]
"DefaultProfile"="NEWSERVER Profile"

files\NEWSERVER Profile]

files\NEWSERVER Profile\0a0d020000000000c000000000000046]
"000b0340"=hex:00,00
"000b0413"=hex:01,00
"000b0412"=hex:01,00

files\NEWSERVER Profile\1018e8b4de806342b370f3d513f342ec]
"001f300a"=hex:63,00,6f,00,6e,00,74,00,61,00,62,00,2e,00,64,00,6c,00,6c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,36,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:23,00,00,00
"001f3006"=hex:4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,41,00,64,00,64,\
00,72,00,65,00,73,00,73,00,20,00,42,00,6f,00,6f,00,6b,00,00,00
"01023d0c"=hex:7e,9c,76,23,9d,87,99,45,9f,ee,f1,a7,1d,fd,13,3c
"001f3d09"=hex:43,00,4f,00,4e,00,54,00,41,00,42,00,00,00
"001f3001"=hex:4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,41,00,64,00,64,\
00,72,00,65,00,73,00,73,00,20,00,42,00,6f,00,6f,00,6b,00,00,00
"00033009"=hex:00,00,00,00
"01026601"=hex:40,d7,e9,2a,74,ea,74,4b,95,c6,3b,db,ba,84,1d,9e

files\NEWSERVER Profile\13dbb0c8aa05101a9bb000aa002fc45a]
"00036661"=hex:00,00,00,00
"00036600"=hex:01,05,00,00
"00036601"=hex:84,01,00,00
"00036605"=hex:03,00,00,00
"00036604"=hex:02,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"01023d01"=hex:a1,0c,b5,60,87,42,10,4c,85,35,74,c1,b6,64,29,17
"01023d00"=hex:52,54,12,9a,86,7d,1e,49,bf,89,37,20,8f,13,5a,06,52,21,21,b7,57,\
9c,ad,4f,81,59,65,48,19,63,97,7e
"01023d02"=hex:67,d9,62,f7,03,62,04,4d,93,d9,f4,aa,3a,b5,c3,e3,f1,0b,18,7c,fe,\
97,20,43,87,dc,7d,32,ba,b3,d1,60
"001e6750"="NEWSERVER Profile"
"001e6608"="NEWSERVER.company.com"
"001f662a"=hex:6e,00,73,00,31,00,30,00,31,00,37,00,2e,00,73,00,73,00,73,00,69,\
00,2e,00,73,00,65,00,61,00,67,00,75,00,6c,00,6c,00,2e,00,6e,00,6c,00,00,00
"00036606"=hex:00,00,00,00
"00036619"=hex:09,00,00,00
"110265e0"=hex:0f,00,00,00,1e,00,00,00,7c,00,00,00,43,00,00,00,9c,00,00,00,43,\
00,00,00,e0,00,00,00,43,00,00,00,24,01,00,00,43,00,00,00,68,01,00,00,43,00,\
00,00,ac,01,00,00,43,00,00,00,f0,01,00,00,43,00,00,00,34,02,00,00,43,00,00,\
00,78,02,00,00,43,00,00,00,bc,02,00,00,43,00,00,00,00,03,00,00,43,00,00,00,\
44,03,00,00,43,00,00,00,88,03,00,00,43,00,00,00,cc,03,00,00,43,00,00,00,10,\
04,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,\
00,00,00,01,00,00,2f,00,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,\
00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,\
38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,\
32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,\
00,00,00,01,00,00,2f,67,75,69,64,3d,30,45,37,46,46,31,38,32,31,43,37,30,41,\
30,34,41,39,34,46,42,44,43,45,45,39,34,41,30,41,39,37,46,00,00,00,00,00,00,\
dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,\
67,75,69,64,3d,42,45,42,45,31,31,34,31,38,46,41,31,35,35,34,35,38,38,32,45,\
44,42,39,38,32,34,41,33,30,44,42,36,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,\
1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,42,35,\
45,42,45,37,34,30,43,34,43,46,30,39,34,32,39,45,45,39,45,34,41,42,37,39,38,\
33,38,38,37,31,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,\
e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,37,44,38,46,41,41,46,35,42,\
37,32,36,43,33,34,43,39,31,46,41,43,33,41,42,39,34,34,35,41,43,42,46,00,00,\
00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,\
01,00,00,2f,67,75,69,64,3d,42,31,38,43,41,41,33,34,32,31,30,44,38,32,34,43,\
42,44,45,38,43,46,38,32,43,36,35,31,35,32,30,45,00,00,00,00,00,00,dc,a7,40,\
c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,\
64,3d,42,37,46,45,38,44,32,31,38,43,38,43,31,32,34,34,41,38,38,36,34,46,37,\
30,41,30,41,36,38,39,42,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,\
08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,37,31,38,42,45,\
33,38,30,35,37,43,30,34,38,34,31,38,33,45,43,41,41,30,35,41,42,39,33,31,30,\
34,33,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,\
00,00,00,00,01,00,00,2f,67,75,69,64,3d,46,39,43,38,41,31,30,31,32,45,31,43,\
31,41,34,39,41,39,30,32,33,32,39,30,34,42,44,33,43,32,31,32,00,00,00,00,00,\
00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,\
2f,67,75,69,64,3d,44,36,42,41,33,46,43,37,38,30,42,43,38,39,34,45,41,44,35,\
46,45,46,35,41,30,39,42,44,44,35,45,31,00,00,00,00,00,00,dc,a7,40,c8,c0,42,\
10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,31,\
43,37,37,42,43,31,46,43,42,30,39,46,31,34,42,38,46,36,43,30,39,34,36,32,45,\
38,41,39,36,39,45,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,\
2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,39,37,42,39,32,33,45,30,\
35,44,41,32,38,44,34,39,41,38,46,32,39,45,42,35,37,32,35,36,41,36,31,46,00,\
00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,\
00,01,00,00,2f,67,75,69,64,3d,42,41,45,39,43,43,41,45,46,45,30,38,39,39,34,\
34,38,41,39,35,38,35,41,42,46,30,35,37,38,31,38,33,00,00,00,00,00,00,dc,a7,\
40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,\
69,64,3d,44,44,35,46,35,43,36,38,35,38,34,45,33,36,34,37,42,37,33,35,44,36,\
30,30,32,37,42,39,33,45,33,43,00,00
"100365e1"=hex:09,00,00,00,0b,00,00,00,09,00,00,00,09,00,00,00,09,00,00,00,09,\
00,00,00,09,00,00,00,09,00,00,00,09,00,00,00,09,00,00,00,09,00,00,00,09,00,\
00,00,09,00,00,00,09,00,00,00,09,00,00,00
"100365e2"=hex:00,00,00,00,00,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,\
00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,\
00,00,01,00,00,00,01,00,00,00,01,00,00,00
"100365e3"=hex:00,00,00,00,27,14,00,00,38,14,00,00,37,14,00,00,05,15,00,00,0e,\
15,00,00,36,14,00,00,5a,14,00,00,0f,15,00,00,11,15,00,00,10,15,00,00,12,15,\
00,00,13,15,00,00,14,15,00,00,15,15,00,00
"101f65e4"=hex:0f,00,00,00,40,00,00,00,42,00,00,00,66,00,00,00,80,00,00,00,96,\
00,00,00,b2,00,00,00,ce,00,00,00,e2,00,00,00,00,01,00,00,24,01,00,00,42,01,\
00,00,62,01,00,00,82,01,00,00,aa,01,00,00,c0,01,00,00,00,00,41,00,6c,00,6c,\
00,20,00,41,00,64,00,64,00,72,00,65,00,73,00,73,00,20,00,4c,00,69,00,73,00,\
74,00,73,00,00,00,41,00,6c,00,6c,00,20,00,43,00,6f,00,6e,00,74,00,61,00,63,\
00,74,00,73,00,00,00,41,00,6c,00,6c,00,20,00,47,00,72,00,6f,00,75,00,70,00,\
73,00,00,00,41,00,6c,00,6c,00,20,00,52,00,65,00,6c,00,61,00,74,00,69,00,6f,\
00,6e,00,73,00,00,00,41,00,6c,00,6c,00,20,00,52,00,65,00,73,00,6f,00,75,00,\
72,00,63,00,65,00,73,00,00,00,41,00,6c,00,6c,00,20,00,55,00,73,00,65,00,72,\
00,73,00,00,00,50,00,75,00,62,00,6c,00,69,00,63,00,20,00,46,00,6f,00,6c,00,\
64,00,65,00,72,00,73,00,00,00,53,00,45,00,41,00,47,00,55,00,4c,00,4c,00,20,\
00,41,00,75,00,73,00,74,00,72,00,61,00,6c,00,69,00,61,00,00,00,53,00,45,00,\
41,00,47,00,55,00,4c,00,4c,00,20,00,46,00,72,00,61,00,6e,00,63,00,65,00,00,\
00,53,00,45,00,41,00,47,00,55,00,4c,00,4c,00,20,00,47,00,65,00,72,00,6d,00,\
61,00,6e,00,79,00,00,00,53,00,45,00,41,00,47,00,55,00,4c,00,4c,00,20,00,49,\
00,72,00,65,00,6c,00,61,00,6e,00,64,00,00,00,53,00,45,00,41,00,47,00,55,00,\
4c,00,4c,00,20,00,4e,00,65,00,74,00,68,00,65,00,72,00,6c,00,61,00,6e,00,64,\
00,73,00,00,00,53,00,45,00,41,00,47,00,55,00,4c,00,4c,00,20,00,55,00,4b,00,\
00,00,53,00,45,00,41,00,47,00,55,00,4c,00,4c,00,20,00,55,00,53,00,00,00
"100365e5"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00
"110265e6"=hex:0f,00,00,00,00,00,00,00,7c,00,00,00,00,00,00,00,7c,00,00,00,43,\
00,00,00,7c,00,00,00,43,00,00,00,c0,00,00,00,43,00,00,00,04,01,00,00,43,00,\
00,00,48,01,00,00,43,00,00,00,8c,01,00,00,43,00,00,00,d0,01,00,00,43,00,00,\
00,14,02,00,00,43,00,00,00,58,02,00,00,43,00,00,00,9c,02,00,00,43,00,00,00,\
e0,02,00,00,43,00,00,00,24,03,00,00,43,00,00,00,68,03,00,00,43,00,00,00,ac,\
03,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,\
00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,\
31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,\
dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,\
67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,\
41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,\
1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,\
32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,\
33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,\
e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,\
30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,\
00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,\
01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,\
42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,\
c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,\
64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,\
34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,\
08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,\
34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,\
30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,\
00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,\
42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,\
00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,\
2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,\
36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,\
10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,\
46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,\
36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,\
2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,\
38,30,41,39,42,31,34,35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,\
00,00,00,00,00,dc,a7,40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,\
00,01,00,00,2f,67,75,69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,\
35,42,37,31,36,41,31,43,34,37,42,36,33,33,45,30,32,00,00,00,00,00,00,dc,a7,\
40,c8,c0,42,10,1a,b4,b9,08,00,2b,2f,e1,82,01,00,00,00,00,01,00,00,2f,67,75,\
69,64,3d,32,46,32,41,45,34,38,30,38,30,41,39,42,31,34,35,42,37,31,36,41,31,\
43,34,37,42,36,33,33,45,30,32,00,00
"000b65ea"=hex:01,00
"000365eb"=hex:01,00,00,00
"010265ec"=hex:69,09,1c,c0,bd,84,ae,47,a9,17,4a,05,26,ac,b4,c4

files\NEWSERVER Profile\522121b7579cad4f815965481963977e]
"001f300a"=hex:45,00,4d,00,53,00,4d,00,44,00,42,00,2e,00,44,00,4c,00,4c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:21,00,00,00
"00033009"=hex:06,18,00,00
"00036609"=hex:0c,00,00,00
"0003660a"=hex:01,00,00,00
"01023414"=hex:54,94,a1,c0,29,7f,10,1b,a5,87,08,00,2b,2a,25,17
"001f3001"=hex:50,00,72,00,69,00,76,00,61,00,74,00,65,00,20,00,46,00,6f,00,6c,\
00,64,00,65,00,72,00,73,00,00,00
"001f3006"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,4d,00,65,00,73,00,73,00,\
61,00,67,00,65,00,20,00,53,00,74,00,6f,00,72,00,65,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00

files\NEWSERVER Profile\5254129a867d1e49bf8937208f135a06]
"00033e03"=hex:21,00,00,00
"001f300a"=hex:45,00,4d,00,53,00,4d,00,44,00,42,00,2e,00,44,00,4c,00,4c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033009"=hex:40,08,00,00
"00036609"=hex:06,00,00,00
"0003660a"=hex:03,00,00,00
"01023414"=hex:78,b2,fa,70,af,f7,11,cd,9b,c8,00,aa,00,2f,c4,5a
"001f3001"=hex:50,00,75,00,62,00,6c,00,69,00,63,00,20,00,46,00,6f,00,6c,00,64,\
00,65,00,72,00,73,00,00,00
"001f3006"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,4d,00,65,00,73,00,73,00,\
61,00,67,00,65,00,20,00,53,00,74,00,6f,00,72,00,65,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00

files\NEWSERVER Profile\5acf76a3665511cea39a00aa004acafa]

files\NEWSERVER Profile\67d962f70362044d93d9f4aa3ab5c3e3]
"001f3001"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,52,00,65,00,6d,00,6f,00,\
74,00,65,00,20,00,54,00,72,00,61,00,6e,00,73,00,70,00,6f,00,72,00,74,00,00,\
00
"001f3006"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,52,00,65,00,6d,00,6f,00,\
74,00,65,00,20,00,54,00,72,00,61,00,6e,00,73,00,70,00,6f,00,72,00,74,00,00,\
00
"001f300a"=hex:45,00,4d,00,53,00,55,00,49,00,2e,00,44,00,4c,00,4c,00,00,00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:24,00,00,00
"00036609"=hex:40,00,00,00
"0003660a"=hex:0a,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00
"00033009"=hex:00,00,00,00

files\NEWSERVER Profile\7e9c76239d8799459feef1a71dfd133c]
"001f3d0a"=hex:63,00,6f,00,6e,00,74,00,61,00,62,00,2e,00,64,00,6c,00,6c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,36,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"101e3d0f"=hex:01,00,00,00,08,00,00,00,63,6f,6e,74,61,62,2e,64,6c,6c,00
"001f3d0b"=hex:53,00,65,00,72,00,76,00,69,00,63,00,65,00,45,00,6e,00,74,00,72,\
00,79,00,00,00
"00033009"=hex:22,00,00,00
"001f3d09"=hex:43,00,4f,00,4e,00,54,00,41,00,42,00,00,00
"001f3001"=hex:4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,41,00,64,00,64,\
00,72,00,65,00,73,00,73,00,20,00,42,00,6f,00,6f,00,6b,00,00,00
"01023d01"=hex:10,18,e8,b4,de,80,63,42,b3,70,f3,d5,13,f3,42,ec

files\NEWSERVER Profile\8503020000000000c000000000000046]
"0102300b"=hex:b1,d7,8e,2b,85,00,cc,47,97,a7,8e,df,c8,d0,40,89

files\NEWSERVER Profile\9207f3e0a3b11019908b08002b2a56c2]
"01023d01"=hex:10,18,e8,b4,de,80,63,42,b3,70,f3,d5,13,f3,42,ec,a1,0c,b5,60,87,\
42,10,4c,85,35,74,c1,b6,64,29,17
"01023d0e"=hex:7e,9c,76,23,9d,87,99,45,9f,ee,f1,a7,1d,fd,13,3c,d8,9f,f0,41,33,\
50,43,46,a8,08,96,6b,8a,a2,66,68
"01023d00"=hex:52,54,12,9a,86,7d,1e,49,bf,89,37,20,8f,13,5a,06,52,21,21,b7,57,\
9c,ad,4f,81,59,65,48,19,63,97,7e
97,20,43,87,dc,7d,32,ba,b3,d1,60
"01023d08"=hex:dc,30,43,4b,7a,0e,f8,49,aa,75,c3,7a,99,b3,e7,cd

files\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676]
"{ED475418-B0D6-11D2-8C3B-00104B2A6676}"=hex:02,00,00,00
"LastChangeVer"=hex:08,00,00,00,00,00,00,00
"{ED475419-B0D6-11D2-8C3B-00104B2A6676}"=hex:01,00,00,00
"{ED475420-B0D6-11D2-8C3B-00104B2A6676}"=hex:02,00,00,00
"NextAccountID"=dword:00000003

files\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676\00000001]
"clsid"="{ED475414-B0D6-11D2-8C3B-00104B2A6676}"
"Mini UID"=dword:56742a89
"Service Name"=hex:43,00,4f,00,4e,00,54,00,41,00,42,00,00,00
"Service UID"=hex:7e,9c,76,23,9d,87,99,45,9f,ee,f1,a7,1d,fd,13,3c
"MAPI Provider"=dword:00000002
"Account Name"=hex:4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,41,00,64,00,\
64,00,72,00,65,00,73,00,73,00,20,00,42,00,6f,00,6f,00,6b,00,00,00

files\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676\00000002]
"clsid"="{ED475414-B0D6-11D2-8C3B-00104B2A6676}"
"Mini UID"=dword:2460e6dd
"Service Name"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00
"Service UID"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"MAPI Provider"=dword:00000005
"Identity Eid"=hex:
"XP Provider UID"=hex:67,d9,62,f7,03,62,04,4d,93,d9,f4,aa,3a,b5,c3,e3,f1,0b,18,\
7c,fe,97,20,43,87,dc,7d,32,ba,b3,d1,60
"Account Name"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,\
45,00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,53,00,65,00,72,00,76,\
00,65,00,72,00,00,00

files\NEWSERVER Profile\a10cb5608742104c853574c1b6642917]
"001f3001"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,44,00,69,00,72,00,65,00,\
63,00,74,00,6f,00,72,00,79,00,20,00,53,00,65,00,72,00,76,00,69,00,63,00,65,\
00,00,00
"001f3006"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,44,00,69,00,72,00,65,00,\
63,00,74,00,6f,00,72,00,79,00,20,00,53,00,65,00,72,00,76,00,69,00,63,00,65,\
00,00,00
"001f300a"=hex:45,00,4d,00,53,00,41,00,42,00,50,00,2e,00,44,00,4c,00,4c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:23,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00
"00033009"=hex:00,00,00,00

files\NEWSERVER Profile\d89ff04133504346a808966b8aa26668]
"001f3001"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,53,00,65,00,72,00,76,00,\
65,00,72,00,00,00
"001f3d0a"=hex:65,00,6d,00,73,00,75,00,69,00,2e,00,64,00,6c,00,6c,00,00,00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"001f3d0b"=hex:45,00,4d,00,53,00,43,00,66,00,67,00,00,00
"00033009"=hex:02,00,00,00
"101e3d0f"=hex:03,00,00,00,10,00,00,00,1a,00,00,00,25,00,00,00,65,6d,73,75,69,\
2e,64,6c,6c,00,65,6d,73,61,62,70,2e,64,6c,6c,00,65,6d,73,6d,64,62,2e,64,6c,\
6c,00
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00
"01023d01"=hex:a1,0c,b5,60,87,42,10,4c,85,35,74,c1,b6,64,29,17
"01023d00"=hex:52,54,12,9a,86,7d,1e,49,bf,89,37,20,8f,13,5a,06,52,21,21,b7,57,\
9c,ad,4f,81,59,65,48,19,63,97,7e
97,20,43,87,dc,7d,32,ba,b3,d1,60
"01023d08"=hex:dc,30,43,4b,7a,0e,f8,49,aa,75,c3,7a,99,b3,e7,cd
"01023d0d"=hex:13,db,b0,c8,aa,05,10,1a,9b,b0,00,aa,00,2f,c4,5a

files\NEWSERVER Profile\dc30434b7a0ef849aa75c37a99b3e7cd]
"001f3001"=hex:4d,00,53,00,20,00,45,00,78,00,63,00,68,00,61,00,6e,00,67,00,65,\
00,20,00,48,00,6f,00,6f,00,6b,00,00,00
"001f3006"=hex:4d,00,53,00,20,00,45,00,78,00,63,00,68,00,61,00,6e,00,67,00,65,\
00,20,00,48,00,6f,00,6f,00,6b,00,00,00
"001f300a"=hex:45,00,4d,00,53,00,4d,00,44,00,42,00,2e,00,44,00,4c,00,4c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:28,00,00,00
"00033009"=hex:00,02,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00

files\NEWSERVER Profile\dca740c8c042101ab4b908002b2fe182]

files\NEWSERVER Profile\f10b187cfe97204387dc7d32bab3d160]
"001f3001"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,54,00,72,00,61,00,6e,00,\
73,00,70,00,6f,00,72,00,74,00,00,00
"001f3006"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,45,\
00,78,00,63,00,68,00,61,00,6e,00,67,00,65,00,20,00,54,00,72,00,61,00,6e,00,\
73,00,70,00,6f,00,72,00,74,00,00,00
"001f300a"=hex:45,00,4d,00,53,00,4d,00,44,00,42,00,2e,00,44,00,4c,00,4c,00,00,\
00
"001f3d13"=hex:7b,00,36,00,34,00,38,00,35,00,44,00,32,00,36,00,41,00,2d,00,43,\
00,32,00,41,00,43,00,2d,00,31,00,31,00,44,00,31,00,2d,00,41,00,44,00,33,00,\
45,00,2d,00,31,00,30,00,41,00,30,00,43,00,39,00,31,00,31,00,43,00,39,00,43,\
00,30,00,7d,00,00,00
"00033e03"=hex:24,00,00,00
"00036609"=hex:00,00,00,00
"01023d0c"=hex:d8,9f,f0,41,33,50,43,46,a8,08,96,6b,8a,a2,66,68
"001f3d09"=hex:4d,00,53,00,45,00,4d,00,53,00,00,00
"00033009"=hex:00,00,00,00
More Consolidation Details

Also, remember that the new AD account is associated with the new mailboxes, not the old ones.
Your users need to know that they must log on to the new domain (they might require no more
than some basic instructions).
I prefer to copy the computer accounts and do the domain-migration work over a weekend and
use Systems Management Server (SMS) or Office Wizards during the week to automate the necessary
changes to the Outlook profiles. Larger deployments will obviously take much more planning and
many helping hands.
Later (but as soon as possible), you can provide a clean break by removing the trusts and
unplugging the old domain and old Exchange server from the network. In a smaller deployment
(e.g., 150 users), you should be able to move the computer and user accounts in an hour, followed
by about 8 hours to move the machines from the old domain into the new domain.
As with site consolidations, you’ll need to rebuild any connector information in the source
organization. For example, you’ll need to replace a fax gateway, voicemail connector, or Blackberry
service. In addition, a reorganization such as this Exchange consolidation usually includes migrating
an SMTP domain. You’ll need to plan for DNS and SMTP changes before you migrate mailboxes.
Consolidation is one of the key aspects of efficient Exchange deployments. Having said that,
remember that Exchange site and organizational consolidation projects will affect end users and their
current configurations and data. To assist with more complicated consolidation efforts, you can use
tools available on the server CD-ROMs, tools that you can download from the Microsoft Exchange
Server site, or third-party tools available from vendors.
Next: Installing Exchange 2003

The next chapter will discuss installing Exchange Server 2003, including preparing the server and
migrating to Exchange 2003. Those who move to Exchange 2003 from Exchange 5.5 will need
extensive information (e.g., Did you know that an Exchange 5.5 server can’t be upgraded to
Exchange Server 2003?). I’ll also cover in detail the requirements of the Active Directory Connector
(ADC), how to create connection agreements manually, and how to use the Exchange Server
deployment wizards to prepare the systems for you.
65
Chapter 4:
Installing Exchange Server 2003

You might have noticed that I’ve covered nearly everything you need to know about installing
Microsoft Exchange Server 2003 except for the installation itself. After you meet the requirements
discussed in the first three chapters, the installation is just a few mouse clicks away. In fact, installing
Exchange has always been that easy – and therein lies a problem.
Many people don’t see the importance of a planning process and so don’t go through the
planning stages I describe in this book. However, if you prepare for Exchange Server 2003 and know
why you’re doing what you’re doing, you’re more likely to understand and be able to solve any
problems that arise. Lack of planning can lead to problems. For example, if you don’t place your
Global Catalog (GC) servers properly, Outlook will perform poorly. Also, failure to consider Exchange
server placement can negatively affect both performance and collaboration.
In this chapter, I discuss the new set of deployment tools for Exchange Server 2003 as well as
ways to install Exchange Server 2003 programmatically. To reflect the range of deployment options,
I cover deploying Exchange Server 2003 in several scenarios – including a new (“greenfield”)
installation and a migration from Exchange 5.5.
Having covered upgrading one Exchange organization to another in Chapter 3, in this chapter, I
emphasize migrating an existing Exchange 5.5 organization to Exchange Server 2003. I discuss in
some detail how to use the Active Directory Connector (ADC) to establish coexistence with Exchange
5.5 and, ultimately, to migrate mailboxes.
Deployment Tools
Initially, I wasn’t too excited about the new deployment tools Microsoft ships with Exchange Server
2003. Documentation about deployment is available online, and I felt that another wizard-like tool
was unnecessary. With Exchange Server 2000, users quickly learned about the required installation
of SMTP, Network News Transfer Protocol (NNTP), and Microsoft IIS on the server. Administrators
diagnosed problem installations with tools such as Dcdiag – and sometimes used ADSI Edit to inspect
Active Directory (AD). Although I thought these requirements and tools were common knowledge,
I’ve learned that they aren’t. The new tools make preparation and installation easier.
Most importantly, the new deployment tools introduce an important paradigm to installation: that
administrators check the domain for errors before they introduce Exchange Server 2003. Microsoft
Product Support Services (PSS) has used many of these tools to analyze Exchange Server installations,
but now the tools are included in the deployment toolset to let you inspect your domain, DNS, and
current Exchange systems. You can predict problems rather than having to react to them. I’ve come
to really appreciate the deployment tools and recommend them to even the most seasoned Exchange
administrators.
The Exchange Server 2003 deployment toolset, ExDeploy, resembles a wizard in that it walks you
through all the requirements and provides links to multiple tools, including Dcdiag and ADSI Edit –
to preemptively troubleshoot problems with AD, the ForestPrep process, and more. Systematically
using ExDeploy’s preparation tools can add 20 minutes to the deployment phase, but those
minutescan save you hours spent troubleshooting. Even as a seasoned consultant, I make it a habit to
run ExDeploy instead of manually running the setup from the \i386 directory. Doing so lets me
double-check myself on specific steps and provides quick access to diagnostic tools.
When you insert the Exchange Server 2003 media (e.g., CD-ROM, DVD) autorun launches a
setup file that displays a CD-ROM menu. From the list on this screen, select and click Exchange
Deployment Tools to launch ExDeploy. Later in the chapter, I discuss ExDeploy’s options.
Deployment Tasks
Deploying Exchange Server 2003 includes the following six phases:
• Phase 1: Planning the deployment and checking the infrastructure
• Phase 2: Checking and cleaning the Exchange 5.5 directory (if it exists)
• Phase 3: Replicating the Exchange 5.5 directory data
• Phase 4: Provisioning the AD for Exchange
• Phase 5: Installing the Exchange Server directory components
• Phase 6: Moving mailboxes and removing legacy Exchange 5.5 servers
The overall purpose of the deployment toolset is to give you the tools and wizards you need to walk
you through the installation – so you don’t have to call Microsoft Product Support Services (PSS). No
joke! Of course, other benefits include knowing that your AD is clean and functioning well and that
the Exchange environment is provisioned correctly.
The Exchange deployment tools provide a walkthrough that lets you mark off phases as you
complete them. The tools also let you check your current environment before and immediately after
the installation. Tools in the set
• check the Exchange 5.5 Directory Configuration and Directory Objects
• provide a Exchange 5.5 Directory User Count
• check Exchange and GC server versions
• check ADC replication
• run the NTDSNoMatch utility
• check Organization and Site Names
• run the Active Directory User Replication Scan
• check policies
• run the Organization Readiness Check
• run the Public and Private Folder DS/IS checks
• check the Exchange Server 2003 Configuration and Recipient Objects
• run an Org Report
Chapter 4 Installing Exchange Server 2003 67
n Note For those of you who enjoy knowing the details, ExDeploy is actually exdeploy.hta, and it runs
from within your browser. Exdeploy.exe is the command-line tool ExDeploy uses to perform
the checks and create the logs.
Exchange Server 2003 Installation Scenarios

As I mentioned previously, I’ll discuss new installations of Exchange Server 2003 as well as migrations
from Exchange 5.5. However, I’ll spend more time on the migration scenario because it’s more com-
plicated and requires additional tools and procedures.
Because I lack space to cover an entire deployment, I’ll devote most of the discussion for each
scenario to deploying the first Exchange 2003 server. Initially, however, I want to emphasize two key
points:
• You can’t upgrade Exchange 5.5 Servers directly to Exchange Server 2003.
• Exchange Server Deployment Tools aren’t designed for inter-organization migration. If you have
two Exchange organizations, these tools aren’t for you. You might want to explore third-party
migration tools.
After you select the Exchange Deployment Tools option from the CD-ROM autorun screen, you’ll see
the Exchange Server Deployment Tools screen, which Figure 4.1 shows.
Figure 4.1
Exchange Server Deployment Tools
j Tip
You can download the Exchange 2003 Deployment Tools from
http://www.microsoft.com/downloads/details.aspx?FamilyID=271e51fd-fe7d-42ad-b621-45
f974ed34c0&DisplayLang=en. You should use the latest version of the installation tools.
After you select Deploy the first Exchange 2003 server, you’ll be prompted to choose whether you
plan to migrate from and coexist with Exchange 5.5, upgrade from Exchange 2000, or perform a new
installation. After you make your selection, the appropriate screen will appear and list specific
deployment tasks. I’ll discuss the scenarios in reverse order, saving the most complicated scenario
for last.
New Exchange 2003 Installation

The simplest Exchange Server 2003 installation is a new one. If you select Deploy the first Exchange
2003 server, then, when prompted, select New Exchange 2003 installation, you’ll see a new
installation page that contains eight steps.
The steps are designed to walk you through verifying that the target server has the appropriate
services installed. They offer instructions for deploying the Netdiag and Dcdiag tools to check
network and domain health.
Next, you’ll deploy ForestPrep and DomainPrep, then install the server. If you’re installing
Exchange Server 2003 into your production network, I recommend that you make sure the first server
is a permanent, non-clustered server. Some roles, such as the Recipient Update Service (RUS),
Routing Group Master, and system public folder server are assumed for the first server and don’t
work correctly in a clustered environment.
Upgrade from Exchange 2000 Native Mode

The next easiest installation is an upgrade from Exchange 2000 Native Mode. In fact, the installation
process is the same as the process for a new installation – except that you must address several
components shipped with Exchange 2000 that Exchange Server 2003 no longer supports.
Before you can upgrade an Exchange 2000 server to Exchange Server 2003, you must remove
the following components:
• Instant Messaging Server
• Chat
• Key Management Service (KMS)
• Lotus cc:Mail connector
• Microsoft Mail (MS Mail) connector
• Microsoft Mobile Information Server Event Sink
• Any third-party email connector that’s not compatible with Exchange Server 2003
If your situation requires the use of one or more of these components, you might choose to install a
new Exchange Server 2003 server in your environment alongside your Exchange 2000 server or
servers. Keep in mind, however, that Exchange 2000 can’t act as a front-end to Exchange Server 2003.
In a mixed environment, you must upgrade your front-end servers before you upgrade the mailbox
servers.
Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5

Technically, the difference between this scenario and the previous one is that this scenario uses the
ADC. Because the Exchange 2000 Native Mode installation contained no Exchange 5.5 servers, you
didn’t need to synchronize information in an Exchange 5.5 directory with information in AD.
In a Mixed Mode Exchange 2000 and Exchange 5.5 scenario, however, you have Exchange 2000
and Exchange 5.5 servers. And, although you’ll already have configured ADC, the Exchange 2000
version of ADC isn’t compatible with Exchange 2003.
Therefore, in this scenario, your main task is to upgrade the ADC servers, as Figure 4.2 indicates,
then verify the connection agreements (CAs), which control synchronization between Exchange 5.5
and AD.
Figure 4.2
Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5
j Tip
I’ll discuss the ADC service and CAs in much more detail shortly, but you should know that the
ADC servers must run the Exchange Server 2003 version of ADC before you deploy Exchange
Server 2003 on any servers.
Because of the necessary integration with AD, deploying the first Exchange 2003 or Exchange
2000 server in an Exchange 5.5 organization is the largest step in moving toward these later versions
of Exchange. After this step is complete, subsequent installations of Exchange 2003 or Exchange 2000
are fairly simple.
The deployment tools walk you through this scenario in detail. When you select Upgrade Active
Directory Connector Servers, which Figure 4.2 shows, you’ll see a new task list that contains six steps
designed to walk you through extending the schema, prepping the domain, and running ADC Setup
to upgrade the ADC servers. (You’ll need to run ADC Setup for each of your ADC servers.)
All existing CAs will remain in place because they and their settings are still required. After
you’ve upgraded the ADCs, you should run the ADC tools (which I’ll cover in detail later in the
chapter), to verify that the CAs are configured correctly and that nothing else is required for Exchange
5.5 coexistence. The ADC tools will analyze the Exchange 5.5 organization and can automatically
create additional CAs as needed. After you’ve upgraded the ADCs, you can upgrade existing
Exchange 2000 servers to Exchange Server 2003 and install new Exchange 2003 servers into your
environment.
Coexistence and Migration from Exchange 5.5

I’ve saved the “best” scenario for last – and devote the remainder of the chapter to it. Exchange 5.5
migrations underscore the importance of AD to Exchange 2003 and Exchange 2000. Note that
Microsoft terms this process a “migration,” not an upgrade. (If you think back to early Exchange 2000
documentation, you’ll recall that Microsoft always termed the move to Exchange 2000 a migration.)
Coexistence and Migration from Exchange 5.5: Step by Step

The term migration is correct because directory information isn’t upgraded from Exchange 5.5. The
information is copied and the data is migrated. Because Exchange 5.5 has its own directory, to make
its contents available in Exchange 2000, you must migrate the configuration and mailbox directory
information to AD. The ADC service performs this directory migration. The ADC and its settings
differentiate this scenario from the previous one. The deployment tools divide the migration scenario
into three phases.
Coexistence and Migration, Phase 1

Much as you would in the Exchange 2000 coexistence scenario, you run Dcdiag and Netdiag.
However, you also run a group of tools known collectively as DSScopeScan. DSScopeScan uses
Lightweight Directory Access Protocol (LDAP) and credentials that you specify to connect to an
Exchange 5.5 server in your organization and determine its configuration, the number and types of
objects, the user count, and the version of Exchange 5.5 currently installed on the servers. You must
have Exchange 5.5 Service Pack 3 (SP3) installed on at least one server in your organization before
you deploy Exchange Server 2003.

In phase two of the migration to an Exchange 5.5 coexistence scenario, you deploy ForestPrep and
DomainPrep to provision AD, and you launch OrgPrepcheck to check the results. You can find those
results in the ExDeploy.log file under the “+ Preparing Active Directory for Exchange Server 2003
(OrgPrepCheck)” section.
The ForestPrep procedure will take about 20 minutes depending on the number of items in the
domain and the performance of your server(s). During the procedure, you’re prompted to enter the
name of the account or group to use for subsequent installs. The account or group that you list will
have Exchange Full Admin permissions to the organization. Initially, only this account or group will
have permission to install Exchange Server 2003.
Before I discuss Phase 3 of the migration process, I’ll describe the ADC service and its function in
some detail. I’ll then resume the migration discussion with Phase 3. I think you’ll soon see why a
thorough understanding of ADC is essential.
Understanding ADC [3]

As I mentioned previously, the Exchange Directory Service (DS) contains objects: mailbox objects,
custom recipients, distribution lists (DLs), and configuration settings for the entire organization. For
Exchange 2003 to take advantage of those objects and settings, the objects must first be replicated to
the AD. Moreover, for Exchange 5.5 users to see and use Exchange 2003 mailboxes, contacts, and
groups, those objects must be replicated to the Exchange 5.5 DS.
ADC is a service that runs on a Windows 2003 or Windows 2000 server to perform directory
synchronization. From among the several versions of ADC, I’ll discuss the version that comes on the
Exchange 2003 CD-ROM or DVD in the \ADC\I386 folder.
n Note You can install the ADC service only after you’ve executed ForestPrep and DomainPrep
because the configuration settings for ADC are maintained within the Microsoft Exchange
object that ForestPrep creates.
ADSI Edit is a handy tool for verifying AD changes, as Figure 4.3 shows. In this case, you can easily
see where Exchange stores its settings within the Configuration Naming Context of the AD.
Figure 4.3
Exchange settings in ADSI Edit
During ADC installation, you’re prompted to install the Active Directory Connector Service and the
Active Directory Connector Management components, as Figure 4.4 shows. For the initial installation,
it’s best to install both. Installing the ADC requires a reboot, so plan accordingly.
Figure 4.4
Microsoft Active Directory Connector Setup
j Tip
You don’t have to install the management tools on the ADC server. You might prefer to install
the management tools on your administrative terminal, so you can administer the connection
locally.
The ADC Tools Applet

Those of you who’ve used the Exchange 2000 Microsoft Management Console (MMC) Active
Directory Connector Services snap-in will find a new addition with Exchange Server 2003: the ADC
Tools applet, which Figure 4.5 shows.
Figure 4.5
ADC Tools applet
ADC Tools will help you collect information about the Exchange 5.5 environment, find resource
mailboxes (through the Resource Mailbox Wizard), and automatically create CAs based on the
discovered information (through the Connection Agreement Wizard).
n Note With the inclusion of ADC Tools in the Active Directory Connector Services snap-in, you no
longer need to download NTDSNoMatch or run queries against the Exchange organization.
Both functions are included in this tool.
Deploying ADC Tools

In ADC Tools Step 1, you set the server and the path for the log files. In Step 2, ADC Tools connects
to the target server and begins collecting information about the Exchange 5.5 organization. This
information is used in Step 3 as the Resource Mailbox Wizard, which Figure 4.6 shows, identifies
domain accounts associated with more than one mailbox.
Figure 4.6
Resource Mailbox Wizard displaying two Exchange mailbox associations
Deploying the Resource Mailbox Wizard

Discovering these domain accounts is important: ADC Tools will find each Windows NT 4.0 account
that’s associated with more than one mailbox and let you match the appropriate account with one of
the mailboxes. In other words, one AD domain account must equal one Exchange mailbox.
In Exchange 5.5 multiple mailboxes could be associated with a single domain account. AD
makes that impossible because of the nature of the objects and the number of values possible within
the attributes.
j Tip
Each AD domain account can have only one primary associated mailbox.
Although you can add another account to the ACL of a mailbox later, each AD domain account is
limited to one primary mailbox account. In the example that Figure 4.6 shows, Daniel Malloy is the
primary NT 4.0 account on two Exchange 5.5 mailboxes.
Using ADC Tools, I selected the Malloy, Daniel (dmalloy) account as the primary account for his
mailbox and identified the other mailbox as a resource mailbox. Although the resource mailbox will
then be primarily associated with another domain account, Daniel Malloy will retain permissions to it.
With Exchange 5.5, the primary object was a mailbox and the associated NT 4.0 account was an
attribute you could change at will. Remember that the field for NT Account allowed a single reference
only. With AD, the domain account is the primary object and the Exchange settings are attributes of
that object, as Figure 4.7 shows.
Figure 4.7
Exchange settings in an AD account
Each Exchange 5.5 mailbox must be associated with a unique domain account before you
deploy the ADC – or the wrong domain account might be associated with the mailbox. The risk of
an incorrect association is quite real, especially with resource mailboxes such as mailboxes in
conference rooms – which is why ADC Tools includes the Resource Mailbox Wizard.
Depending on the number of resources in your organization, this association process could take
a few minutes or many hours. Therefore, you should run the Mailbox Resource Wizard as early in the
migration process as possible – and export and view the results so you can delegate the changes.
You can run the wizard again at a later time, after you or your staff members make the changes in
the DS.
Deploying the Connection Agreements Wizard
In ADC Tools Step 4, you’ll use the most longed-for tool for Exchange 5.5 migration projects: the
Connection Agreements Wizard, an automated tool for creating CAs. As with most technical
processes, the devil is in the details. With Exchange migration projects, those details involve CA
configurations, which contain the settings that the ADC service uses to keep the directories
synchronized. The ADC uses three types of CAs:
• configuration CAs
• recipient CAs
• public folder CAs
Configuration CA. The first time you install Exchange Server 2003 into your Exchange 5.5
organization, a CA is created automatically. During this installation, you’ll be asked whether you want
to create a new Exchange organization or upgrade an existing Exchange 5.5 organization.
If you choose to upgrade an existing Exchange 5.5 organization, the installation program asks for
connection settings, then leverages the ADC to create the configuration CA and begin replicating the
configuration settings of the Exchange 5.5 organization into the AD configuration container.
You can move the configuration CA to other ADC servers and change the Windows connectivity
settings, but otherwise the configuration CA is read-only. Moreover, you can’t create this CA manually.
Therefore, if you attempted to install Exchange Server 2003 and don’t see the configuration CA, your
Exchange 5.5 organization hasn’t been upgraded.
Recipient CA. The recipient CA is the primary emphasis for this section. It controls synchronizing
mailbox objects to the AD. The recipient CA lets Exchange 5.5 objects appear in AD and adds
Exchange 2003 mailboxes to the Exchange 5.5 Global Address List (GAL).
Without the correct recipient CAs in place, you lack a single address book – even in a single-
organization scenario. The number of recipient CAs you need depends on the degree of granularity
your synchronization requires. By default, ADC Tools attempts to create a single recipient CA for each
site that synchronizes all of the recipients, contacts, and DLs for that site.
This default behavior means that
• you must make sure that each site has a network connection and proper credentials before ADC
Tools can complete all its steps. Although ADC Tools will launch regardless, you won’t get past
the authentication screen unless it can communicate with and authenticate to all sites in your
organization.
• synchronization to and from each site will occur on the same schedule using the same settings.
For example, if you want to synchronize DLs and mailboxes on different schedules or into
different containers, you’ll need to manually create separate CAs for the different settings.
n Note If you pay close attention to the ADC during the setup phases, you might notice how
accurately it matches accounts to mailboxes. The “magic” behind its ability to do so lies in the
fields the ADC uses during the search. In Exchange 5.5, the associated NT 4.0 account
(sometimes incorrectly referred to as the SID) is the only field that’s truly matched between
Exchange 5.5 and NT 4.0 directories. When you associate an NT 4.0 account with an Exchange
5.5 mailbox, the SID is copied into the mailbox object as an attribute. Assuming that an NT 4.0
domain is upgraded or the accounts migrated to a clean AD using SIDHistory, the SID value
will probably remain intact. Because the SID is unique and is an attribute for both systems, this
value is then the perfect field for the ADC to use to match objects between AD and the
Exchange DS.
j Tip
An interesting aspect of the recipient CA is that you can select root objects for the source. For
example, on the From Exchange tab from within the CA details, you can select the Exchange
5.5 organization name instead of a specific site to replicate every Exchange 5.5 object to AD
with a single CA. Although this might seem to be an effective way to minimize the complexity
of your ADC configuration, it isn’t ideal for two-way synchronization because any AD changes
made to objects in other Exchange 5.5 sites won’t replicate.
Public folder CA. The public folder CA’s purpose is to create public folder proxies in AD for
Exchange 5.5 public folders. After you’ve added the public folder proxy addresses, replication can
occur between Exchange 5.5 and Exchange Server 2003 servers – including the system folders. To
make replication changes easier during migration, ExDeploy now includes the Microsoft Exchange
Public Folder Migration Tool (pfMigrate.wsf) to help automate the process of adding Exchange Server
2003 to the replication list of the Exchange 5.5 public folders.
In addition to choosing the source and target servers and containers, you’ll need to select a
direction for your agreements. You have three choices for each agreement:
• Two-Way – The preferred and most common method of synchronization is a two-way
agreement.
• Windows to Exchange – If you want to establish a single Exchange 5.5 GAL, you might choose
not to replicate any changes to AD.
• Exchange to Windows – If you’re planning a quick move or want to avoid making changes to
the existing Exchange 5.5 environment, you can choose to synchronize with AD only those
attributes that exist in the DS.
n Note When you use the MMC Active Directory Connector Management snap-in, you might notice
that the first CA you create becomes the primary CA for that Exchange organization. You can
have just one primary CA, and only that CA that can create accounts in the target
environment. Secondary CAs can only append or modify existing objects.
The ADC is a powerful tool. Its mapping rules are flexible, and you can configure the CAs it
contains to be quite specific and granular. It can handle deletions and find matches within the target
systems without creating duplicates. The number of CAs you can run on an ADC server has no
published limit, but administrators in complex environments often choose to deploy multiple ADC
servers. As with any directory replication, a hub-and-spoke configuration is typical to centralize the
updates.
j Tip
Without a direct upgrade path from Exchange 5.5 to Exchange Server 2003, you have to decide
what to do about a complex Exchange 5.5 environment. Such environments often have a hub
site that handles the complex mail routing topology by using a mix of site connectors, X.400
connectors, and specific SMTP settings. One solution is to first upgrade the hub-site servers to
Exchange 2000, which retains their mail settings, then upgrade the servers to Exchange Server
2003.

Phase 3 of the Coexistence with Exchange 5.5 scenario involves installing Exchange 2003 Server, and
this phase contains five steps. The first is to execute Setupprep to examine and verify that the
directories are synchronized. After you evaluate the results, you can install the first Exchange 2003
server into your organization.
During the Exchange Server 2003 setup, you’re prompted to select whether you’ll create a new
organization or upgrade an existing Exchange 5.5 organization. You’ll see this prompt only once –
and failure to make the right choice results in considerable cleanup work. Therefore, do your home-
work before you make this choice.
To move mailboxes from the Exchange 5.5 servers to the Exchange Server 2003 servers, you
need to add one Exchange 2003 server to the existing Exchange 5.5 site or sites. With the release of
Exchange Server 2003 SP1, you can now move mailboxes from Exchange 5.5 servers to Exchange
Server 2003 machines in other sites (admin groups), but you’ll need to manually modify the Outlook
profiles or run the Profile Migration script to reset the Outlook profiles to the new target server.
Moving mailboxes has been greatly improved with the Exchange Server 2003 MMC Active
Directory Users and Computers snap-in. Select one or more user objects in the snap-in and right-click
to bring up the Exchange Tasks. From this selection, select Move Mailbox, then select the target
Exchange 2003 server and the appropriate storage group.
You’re then asked to choose how to handle errors that occur during the process. You can
choose to have the mailbox move aborted in the event of any error, or you can choose to log a cer-
tain number of errors after which the attempt is considered failed.
The Mailbox Move Wizard can now migrate multiple accounts at once. You can choose to
migrate the accounts after hours or watch the migration live and monitor the progress with the new
onscreen reporting information, which Figure 4.8 shows.
Figure 4.8
Exchange Task Wizard progress report
n Note The Mailbox Move Wizard now moves multiple mailboxes (up to four) at once and displays the
status and progress of each move live.
After you’ve moved the information you need from Exchange 5.5, you can begin to think about
retiring the old servers. Microsoft maintains current information about this procedure in the Knowl-
edge Base Article 822450, “How to Remove the Last Exchange Server 5.5 Computer from an
Exchange Server 2003 Administrative Group,” at http://support.microsoft.com/default.aspx?scid=kb;
EN-US;822450.
In brief, you need to make sure the system folders are replicated, then verify and use the ADC
to replicate the changes. Finally, you stop the Exchange 5.5 services and use the Exchange 5.5
administrative tools from the Exchange Server 2003 console to remove the Exchange 5.5 server from
the site.
ExDeploy Command-Line Options

As I mentioned previously, ExDeploy is the brains behind the deployment tools. Immediately below
you see what the Help screen displays when you use exdeploy.exe /? to find the syntax for the tools:
/s:<Exchange 5.5 server>[:port]

/gc:<Global Catalog server>|? Use <Global Catalog server> as target server
/p:<Log File Path> Redirects progress output to <Log File Path>
/h, /? Display this Help text
/c (Comprehensive) Runs all tools
/skip:<Tool1> [/skip:<Tool2>] ... ] Skips specified tools or tool groups
/t:<Tool1> [/t:<Tool2>] ... ] Runs all specified tools or tool groups
/site Runs PrivFoldCheck on all servers in the same site
Also, ExDeploy tools that help you gain information include the following:
• DSConfigSum runs Exchange 5.5 Directory Configuration Summary.
• DSObjectSum runs Exchange 5.5 Directory Object Summary.
• UserCount runs Exchange 5.5 Directory User Count.
• VerCheck runs Server Version Check.
• ADCUserCheck runs ADC User Replication Check.
• NTDSNoMatch runs NTDSNoMatch.
• OrgNameCheck runs Organization and Site Names Check.
• ADCObjectCheck runs ADC Object Replication Check.
• ADUserScan runs Active Directory User Replication Scan.
• PolCheck runs Policy Check.
• OrgCheck runs Organization Readiness Check.
• PubFoldCheck runs Public Folder DS/IS Check.
• ADCConfigCheck runs ADC Configuration Replication Check.
• ConfigDSInteg runs Exchange Server 2003 Configuration Object Check.
• RecipientDSInteg runs Exchange Server 2003 Recipient Object Check.
• PrivFoldCheck runs Private Folder DS/IS Check.
• OrgReport runs Existing Org Report.
• GCVerCheck runs Global Catalog Server Version Check.
Planning for your Exchange Server 2003 deployment can seem more daunting than the actual
installation. Determining AD design, setting goals for the migration, and determining the
administrative structure of the target system often involves non-technical decisions that require input
from non-technical teams.
However, after the planning stages are complete, you can take off your gloves and get to work.
As you know from this chapter, Exchange Server 2003 deployment tools will help you walk through
the installation process from start to finish.
Next: Multiple Directories

In the next chapter, I’ll cover the need for multiple directories and the methods you can use to keep
them in sync. I’ll discuss the Microsoft Identify Integration Server in depth, as well as migrations from
other directories (e.g., Notes), and, finally, the Interorg ADC agreement.
83
Chapter 5:
Multiple Directories
Pure homogeneous environments exist in the dreams of network designers but not usually in the
real world. Even if your environment is pure Microsoft and the latest in Active Directory (AD)
technologies, you might have chosen to configure your domains in separate forests for security and
partitioning reasons. If you use Lotus Notes/Domino or GroupWise – or expect to run multiple
Exchange organizations for any length of time – this chapter is certainly for you. And, although
understanding the underlying connections between directories can certainly aid in migration projects,
I won’t discuss migration in this chapter. Instead, I explore the options available for running separate
directories for extended periods of time.
Why Multiple Directories Exist

It’s not uncommon for organizations, particularly larger ones, to have more than one directory.
Customer Relationship Management (CRM) systems, sales automation tools, messaging systems, data-
base applications, and authentication systems rarely use the same directory. This situation creates
additional administrative overhead in contact management, group calendaring, and task management.
The good news is that AD can provide a directory foundation you can leverage for other
systems. Both hardware and software vendors have aligned themselves with Microsoft to leverage
AD as their directory structure. You too can leverage AD for your specific application – whether it’s
creating Lightweight Directory Access Protocol (LDAP) queries to look up information or writing ADSI
scripts to either populate or extract data from AD.
AD as Your Directory Foundation

Suppose you’ve decided that AD is the right structure for you, and your company has integrated your
applications and systems into AD. Now, let’s complicate that idea with the notion that your company
has merged with another, and your counterparts have done the same thing. The good news is that
you can connect AD forests as federated forests with cross-forest trusts. In addition, you can cross-
certify Microsoft Certification Authorities (CAs) so that you can use certificates universally for
encryption and smartcard use. In fact, running multiple forests within a company shouldn’t disrupt
authentication, file and printer sharing, development projects, or systems management.
Forests and Security

One of the most important areas to address is security. You can’t obtain true security if the domain
you need to secure is part of a single forest. Although I discussed this principle in Chapter 2, I
mention it again because my Microsoft peers and the company’s product groups continue to
broadcast that message. If you’re concerned that administrators in your organization have different
administrative approaches or could disrupt your business through an intentional or accidental act, you
should consider designing your AD with multiple forests.
If you’re concerned about how to physically and logically protect your domain controllers (DCs),
you should also consider multiple forests. Within a single forest, for example, a domain administrator
could potentially run a script that creates a million mailboxes on his or her local server. This massive
import would affect the performance and stability of your network, your Global Catalog (GC) server,
your DCs, and your Outlook clients. It would also affect client machines’ ability to log on to the
system and remote Outlook users’ ability to download the address book.
Needless to say, a more blatant intentional attack could do even more damage. To share the
same forest, you must trust the other administrators and their security practices. To begin your
consideration of multiple forests, download and read the Microsoft white paper “Multiple Forest
Considerations.” This extensive document provides much more information than I can offer in a
single chapter. To download the white paper, go to http://www.microsoft.com/downloads
/details.aspx?FamilyID=b717bfcd-6c1c-4af6-8b2c-b604e60067ba&DisplayLang=en. For additional
reading, Quest Software has published a whitepaper on multi-forest configurations that is available at
http://wm.quest.com/products/collaborationservicesexchange/. Choose the “Best Practices for
Designing a Secure Active Directory: Multi-org Exchange Edition” whitepaper. Although this
whitepaper is free, you’ll need to register to download it.
Multiple Directories and Exchange

Now that I’ve created the context for multiple directories, let’s discuss their impact on Exchange.
Because AD forests can’t be truly merged – and share configuration and schema containers – they
can’t share the same Exchange organization. This inability to share the same Exchange organization is
highly significant because Exchange collaboration features require the same forest.
The Outlook client pulls the address book from the GC servers, and because the GC is specific
to a given forest, the GC can’t and won’t contain detailed mail information for another forest. To
open another user’s calendar using Outlook, the calendar owner must be listed in your Global
Address List (GAL), and both mailboxes must be in the same Exchange organization. In truth, a
separate Exchange organization provides about as much collaborative functionality as a foreign mail
system such as Notes or GroupWise. To “connect” the systems, you need a connector – and that
connector will somewhat limit functionality.
Single Exchange Organization Scenario

Suppose that your company indicates that multiple forests are required for security and autonomy
reasons, but the company also requires full functionality from Outlook and Exchange Server. One
solution is to have multiple forests “share” the same Exchange organization. (In this scenario, the
forests aren’t truly sharing the Exchange organization because Exchange information isn’t replicated to
them, and they don’t provide address book lookups.)
Here’s how this approach works: You establish a forest to house the Exchange environment.
You can create this “Exchange forest” with a single-domain, single-forest configuration. You create
an AD user in this organization for every mailbox your company requires. Moreover, you create all
mailboxes in this organization. By using trusts, you can delegate each mailbox in this forest to an AD
account in another forest. You can then disable the actual AD accounts in the Exchange forest, as
Figure 5.1 shows.
Chapter 5 Multiple Directories 85
Figure 5.1
Single Exchange forest environment
Steve Bryant
Steve Bryant
Division A Forest Division B Forest
Exchange
Servers
Exchange Forest
Although the design of this scenario seems fairly simple, this approach requires that DNS be
replicated among the forests because the Outlook clients will need to locate GCs in the Exchange
forest. Moreover, it requires that you locate the GC servers for the Exchange forest near the users to
provide efficient access to the address book.
These requirements give the Exchange forest scenario a higher initial cost than other solutions.
However, the ongoing cost of this design is less than the ongoing cost of some other scenarios
because you don’t need to license or manage any third-party connectors for synchronization. The end
result of this configuration is full and complete functionality of Outlook and Exchange because all
mailboxes and Exchange servers are in the same forest and all share the same GC.
Separate Exchange 2003 and Exchange 5.5 Organizations

Microsoft has extended support for Exchange 5.5 until December 31, 2005. Many companies
will probably continue to wait until the last moment to migrate from that environment. I have several
customers who suggest they’ll hold out because Exchange 5.5 currently meets their needs and/or
they currently can’t budget for AD and Exchange Server 2003 client licenses. For them, I include the
following scenario, which relies on the Active Directory Connector (ADC) beyond its designed
purpose, but satisfies this scenario’s need for inter-organizational support nicely.
The ADC that ships with Exchange Server 2003 provides directory synchronization between
Exchange 2003/Exchange 2000 and Exchange 5.5 environments. The connection’s purpose is to
provide directory synchronization during a migration to populate the AD with mailbox information
from Exchange 5.5, but you can use it for long-term connection purposes, as I’ll discuss in some
detail.
The ADC functionality is useful for Exchange 5.5 upgrades, as I discussed in the previous
chapter, and it supports a reorganization as well – if you’re moving to a brand new Exchange 2003
organization. It’s this functionality that provides inter-organizational support. In this scenario,
configuration is much like what I covered in the previous chapter except for the selections you
make in the Inter-Org Agreement Properties dialog box, which Figure 5.2 shows.
Figure 5.2
Inter-Org Properties dialog box
The ADC recipient agreement is the mechanism that synchronizes Exchange 5.5 and Exchange
2003 objects. The agreement lets you perform this synchronization across organizations. Although the
ADC was designed to support migrations from Exchange 5.5 environments, you can (though it isn’t
fully recommended) use the ADC for long-term connectivity between the two organizations. Through
the connection agreements (CAs) you gain a single address book with no implications for DNS. The
only requirement is that the ADC server has the necessary network connection with both the
Exchange 5.5 and the Exchange 2003 environments.
The net result of this configuration is simply a single address list. Mailboxes in one organization
are copied into the other organization to “combine” the different address books. Calendar information
can’t be delegated nor can Outlook Web Access (OWA) servers be shared. Message routing doesn’t
involve any site connection or formal mail connector. Instead, each system considers users on the
other systems to be on “foreign” systems. You must configure the users accordingly. SMTP is the
most commonly used transport for multi-organizational configurations – with separate SMTP domains
used for each organization.
Separate Exchange 2003 Organizations

Although the ADC is great for connecting to Exchange 5.5 systems, it can’t combine two ADs. To
make that connection, you need more than the ADC. You can find third-party tools that connect ADs
by creating entries from one system in the other.
Technically, you could accomplish the connection manually by creating SMTP contacts in each
system to represent mailboxes in the other. The problem with a manual process lies in the necessary
updates and deletions. Therefore, administrators prefer an automated method.
Microsoft has provided the necessary connection functionality in a product called the Identity
Integration Feature Pack (IIFP) for Microsoft Windows Server Active Directory, which is subset of the
Microsoft Identity Integration Server (MIIS) 2003. If you need to “combine” the global addresses for
multiple forests, IIFP is your solution, as Figure 5.3 illustrates.
Figure 5.3
IIFP
Exchange Exchange
Servers Servers
Server Running
Identity Integration Feature
Outlook Clients Pack Outlook Clients
Steve Bryant
Brian Veal
Steve Bryant Brian Veal
Division A Forest Division B Forest
A single server running IIFP can create contacts for multiple organizations in either a meshed or
a hub-and-spoke configuration. IIFP creates contacts to represent mailboxes in other organizations.
You can use either SMTP or X.400 to route the mail, but that configuration is within Exchange Server
2003. IIFP and MIIS 2003 perform the directory synchronization only – they don’t handle the mail
flow.
To install and run IIFP, you must run Windows Server 2003 Enterprise Edition and Microsoft
SQL Server 2000 with Service Pack 3 (SP3). The installation process itself is fairly simple, and most
people can usually complete it in a few hours. As with all network changes, you should read the
documentation that you get when you download IIFP, and test it thoroughly in a lab. The process
includes setting up IIFP and installing management agents in each forest. When you configure IIFP,
keep in mind that
• you must have management agents for both forests
• you should always encrypt LDAP traffic
In addition to the setup steps I mention above, you’ll need to identify the connection filters,
including their projection rules, attribute flow, and provisioning and de-provisioning options. The
process might seem daunting at first, but some great walkthroughs are included with the product.
Read IIFP_2003_GAL_synchronization.doc to get a thorough background knowledge of the
product, then use IIFP_2003_GAL_synchronization_Step_By_Step.doc, which comes with the IIFP
when you download the package from http://www.microsoft.com/downloads/details.aspx?FamilyID
=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=e, to perform a trial connection in the lab.
After that, you should be ready to begin a pilot in your own environment.
The benefits of using IIFP include the following:
• You get a “free” solution for merging two AD forests to provide GAL synchronization.
• Microsoft fully supports this approach as a long-term solution for GAL synchronization.
• You can leverage the knowledge you gain about this tool when you use MIIS 2003.
IIFP does not include free/busy or calendar synchronization so users will still have difficulty
scheduling meetings. However, third-party solutions are available that provide free/busy
synchronization.
Keep in mind that IIFP is designed to manage identities across ADs. It will work for Exchange
Server 2003 and Exchange 2000 with both the AD and Active Directory Application Mode (ADAM).
Exchange 2003 and Foreign Mail Systems – Short Term

Users have learned over the years that a single email system probably won’t emerge from the many
that are available. At the Microsoft Tech-Ed and LotusSphere conferences, you’ll hear different
opinions about which of the two mail system dominates and why. However, organizations use many
other systems, including Novell’s returning heavyweight GroupWise, OpenMail, TAO, and other POP
and IMAP systems. Microsoft has created tools to assist with migration and short-term coexistence
with Lotus and GroupWise and tools to assist with the migration from POP and IMAP servers.
Some companies that have used these connectors to migrate email have noticed the technical
advantages of connecting directories with these tools. However, the rich collaboration the companies
gain is tainted by the fact that because the tools weren’t designed for long-term use, their stability and
redundancy sometimes comes into question. I’ll cover the Notes and GroupWise connectors to
illustrate their strengths and weakness.
Lotus Notes/Domino Connector

As I mentioned before, Lotus Notes/Domino isn’t going away anytime soon. In fact, the strength of
Notes/Domino as a development platform has helped it establish a foothold in companies as their
business practices become linked with the technology. Having said that, many faithful Notes shops
have decided that the Outlook collaborative client and the Exchange messaging environment are ideal
for their organizations.
These shops want to keep their applications on Notes/Domino, at least until their developers
have been retrained and the applications ported. Their challenge is to maintain both directories
during and after the move and to maintain a synchronized directory for the collaborative applications
that will be left behind.
Exchange 2003, Exchange 2000, and Exchange 5.5 all ship with the Notes connector tools. The
Notes connector contains both a directory synchronization feature and a message conversion tool.
The administrator creates an Exchange 2003 server to act as the “connector server,” then installs the
Notes client on the server to provide the necessary APIs required to connect to the Lotus
Notes/Domino server. These APIs let the Exchange 2003 server use a predetermined Lotus Notes ID
to connect to the Notes environment. The Exchange 2003 server can then pull and push directory
updates and deliver and receive email by monitoring a specific Mail.box file on the target Notes
server.
n Note Exchange Server 2003 SP1 now supports connections to Domino 6.x servers, including the
latest Domino 6.51 server.
From a directory standpoint, the Notes connector server creates AD accounts or contacts to
represent the Notes users in the Names and Address book. From the Notes side, the Exchange users
appear to be on another Notes server within the Notes enterprise. The result is that each set of email
users appears in the other server’s mail directory. This configuration has some additional benefits as
well:
• Rich-text messages are supported, including meeting requests, message formatting, and stationery.
• You can install the calendar connector, which is part of the Notes connector, to add a
calendaring component that will provide free/busy information across systems.
• Although group entries are created in the opposite system, the membership isn’t. In other words,
you’ll have an entry for the group in each directory, but the entry is a contact, not an actual
group.
Keep in mind, however, that this tool’s purpose is to create a directory link so that you can
migrate users from one system to another. The assumption is that you’ll use the connector less and
less as you move users – and finally not at all. Because the connector not only synchronizes the
directory but also routes the email between the systems, it represents both a potential bottleneck and
a single point of failure.
d Caution
If you consider using the Notes connector long term, remember that it represents both a
potential bottleneck and a single point of failure.
Messages bound for the Exchange environment are stored in Notes format on the Notes server in
a special routing mailbox. The Exchange Server that runs the Notes connector then collects the mes-
sages at set intervals and converts the messages from Notes format to Outlook rich text. If the Notes
connector server goes down, loses the connection, or otherwise fails, you have no mail routes
between the two environments, as Figure 5.4 shows. That potential failure makes the Notes connector
not the best long-term solution for directory synchronization.
Figure 5.4
Notes connector
Notes connector
Exchange Site Exchange Site Notes Domain Notes Domain

Site D Site A Notes Notes
Mail flow and

directory updates between
the systems will only use the
connector. If the connector
is down or inoperative, no
Exchange Site Exchange Site email will pass Notes Domain Notes Domain
Site C Site B Notes Notes
SMTP for Message Transport

By contrast, SMTP is a great message transport in a heterogeneous environment. Major software
and service vendors, including Microsoft and Lotus/IBM support SMTP. If you offload the message
transportation to SMTP, the system can separate directory updates and mail flow, as the diagram in
Figure 5.5 shows.
Figure 5.5
SMTP message transport
Notes connector
Exchange Site Notes Domain

Site A Notes

Site D Notes
SMTP
Exchange Site Only directory updates uses Notes Domain

Site C the connectors and Notes
connector servers. Email flow
uses SMTP
Site B Notes
By using SMTP as your message transport, you can potentially set up each server to route email
independently. Doing so eliminates the single point of failure that using the Notes connector creates.
Fortunately, you have multiple options for this task. I’ve tested the following options and used
them in production environments. The first option is to use one Internet domain for Notes and
another for Exchange.
Establish Separate Internet Domains for Notes and Exchange
Perhaps your company is comprised of individual companies. In such a case, the Notes environment
can collect Internet email for Company1.com and the Exchange environment can collect email for
Company2.com, as Figure 5.6 shows. The use of separate Internet domains is the safest and easiest
solution to configure.
Figure 5.6
Separate Exchange and Notes domains
Internet
Company2.com Company1.com
Exchange Notes
Environment Environment
Establish Subdomains
You can establish subdomains (by using an internal partitioning scheme) to identify each email
system. For example, you could use Notes.company.com internally to identify the Notes users and
Exchange.company.com (also internally) to identify the Exchange users. If you take this approach, the
areas of concern you’ll encounter are (1) the internal naming structure and (2) the processing of
inbound email. Many companies that use this strategy have a virus scanner or other SMTP server that
scans and relays inbound email, as Figure 5.7 shows.
Figure 5.7
Internal subdomains for the Exchange and Notes environments
SMTP Mail Relay/ Virus Scanner

Internet
exchange.company.com notes.company.com
Exchange Notes
A mapping table on the SMTP mail relay/virus scanner server would receive email messages for
steve@company.com, look up the internal address of steve@exchange.company.com, and route the
email messages to the Exchange servers for processing.
You can also set up a relay server to modify outbound email messages. If steve@exchange
.company.com sends an email message, the SMTP relay server would strip exchange from the address
so that someone in the outside world would see steve@company.com as the reply address.
One drawback of this approach is that the necessary mapping tables often require manual
updates. The primary benefit of the approach is the ease with which multiple internal servers can
share the domain name. I’ve worked with customers who have Exchange, Notes, GroupWise, and
various SMTP servers sharing the same domain by creating an internal partitioning scheme such as
the one just described.
Split the Domain
Splitting the domain is tricky, but it provides a seamless border between multiple systems. In essence,
the Exchange server will forward unresolved email messages to the Notes system and vice versa, as
Figure 5.8 shows.
Figure 5.8
Splitting the domain
Internet
Company.com Company.com
Unresolved
Email relays
Exchange Notes
Several Microsoft TechNet articles describe this process from the Exchange perspective, and
similar documents on IBM’s Web site help you configure the process for Notes. The routing process
works as follows:
1. Either system might receive an inbound email message that isn’t resolved to a local mailbox or
person document.
2. The server forwards the unresolved message to the IP address on the other mail system that you
specify in the configuration document or SMTP settings.
3. The message is either delivered or the system creates a non-delivery report (NDR).
The drawback of this option is that the alternate system will create NDRs. Many NDRs burden
systems, allow administrators less control, and “announce” the server name and the email system in
use. Also, this configuration is slightly more difficult to set up and support. This option also doesn’t
support as many internal system types as the use of subdomains. The benefit is that everyone in the
company can share the same Company.com address for internal and external messages.
Installing and Tweaking the Notes Connector

Because the process is involved, the next few pages give you the details you need to modify the
Notes connector. However, before you modify it, you need to install it. Begin by installing the Notes
connector on a server using the default settings. Even if you have a very small server, don’t fret. I
have Pentium-class machines with less than 128MB running the connector for address books with
more than 6000 names.
Because you won’t use the connector for mail routing, a server failure means only that the
directories aren’t current. Keep this factor in mind when you specify hardware for your connector,
but do use a separate server. Don’t put the connector on a mailbox server or any other server that
you can’t reboot during the day.
Next, verify that mail and directory updates can use the connector without problems. Then, stop
the Notes connector and navigate to the Dxanotes and Dxamex folders. (You can find these folders
under Exchsrvr/Connect or Conndata on your Exchange Server/Notes Connector server.)
These folders contain the configuration files for the connector. Copy the folders to a safe place
somewhere else on the system. Next, open the Dxamex folder and look at the files that handle
imports into Exchange.
In the Amap.tbl file, which Figure 5.9 shows, add an entry for the SMTP addresses. The entry to
be added is shown in boldface type. As noted in the figure, if you aren’t using SNADS, you also
should delete the SNADS line.
Figure 5.9
Changes to the Amap.tbl file
AMAP.TBL
DN 256 Obj-Dist-Name
TA 256 Target-Address
ACCOUNT 32 Assoc-NT-Account
COMPANY 64 Company
DEPARTMENT 64 Department
FULLNAME 128 Display-Name
FIRSTNAME 64 Given-Name
ALIAS 64 Mail-nickname
OFFICE 64 Physical-Delivery-Office-Name
LASTNAME 64 Surname
NOTESADDR 128 Proxy-Addresses(NOTES:)
USNCreated 12 USN-Created
Initials 6 Initials
Title 32 Title
Phone 20 Telephone-Office1
MobilePhn 20 Telephone-Mobile
Fax 20 Telephone-Fax
ZIP 16 Postal-Code
Pager 20 Telephone-Pager
SNADSADDR 20 Proxy-Addresses(SNADS:) Delete This line
SMTPAddr 128 Proxy-Addresses(SMTP:) Add This line
In the Mapnotes.tbl file, which Figure 5.10 shows, replace the Fullname= and TA= lines with the
code in boldface type that follows each.
Figure 5.10
Changes to the Mapnotes.tbl file
MAPNOTES.TBL
Alias = ISEQUAL( ShortName, “”, SUBSTR
( FullName, 1, 64 ), ShortName )
FullName = ISEQUAL( ShortName, “”, X500
( FullName, “CN” ), X500
( LastName “, “ FirstName, “CN” ) )
TA = “SMTP:” ISEQUAL( MailAddr, “”, ISEQUAL
( SMTPAddr, “”, Replace
( Strip( FullName, “;”, “L”, “R” ), “ “, “_” ) “%” Replace(
Strip( MailDomain, “;”, “L”, “R” ), “ “, “_” ) “@company.com”,
SMTPAddr ), MailAddr )
DN = UNID
FirstName = FirstName
LastName = ISEQUAL( LastName, “”, ISEQUAL(
FirstName, “”, X500( FullName, “CN”), “” ) ,
LastName)
Company=Company
Department = Department
Office = Location
Initials = Initials
The new Fullname= line places the Notes entries into the Exchange environment as Last Name,
First Name. If you want to leave the setting as First Name Last Name, replace the TA= line only and
leave the Fullname= entry unchanged.
The TA= line is the most important component because it replaces the Notes information with
SMTP-specific information. This line builds the Internet address that will be used for each entry. The
TA= line pulls this information from the Notes address field that already exists. In the Mapnotes.tbl
file, change the company.com address to the address you want to use for the Notes environment.
Next, you modify the files that control moving data from the Exchange environment into the
Notes environment. Navigate to the Dxanotes folder and open the Amap.tbl and Mapmex.tbl files.
In the Amap.tbl file, which Figure 5.11 shows, add the single SMTPAddr line to include the use
of an SMTP address as well as the additional lines shown in boldface type.
Figure 5.11
Changes to the Amap.tbl file
AMAP.TBL
FULLNAME 220 FullName 1
MAILDOMAIN 31 MailDomain 2
COMPANY 64 CompanyName NULL
DEPARTMENT 64 Department NULL
FIRSTNAME 64 FirstName NULL
LASTNAME 64 LastName NULL
LOCATION 128 Location NULL
SHORTNAME 64 ShortName NULL
UNID 64 $$UNID NULL
DN 256 $$DN NULL
USNCreated 16 $$USN
Initials 6 MiddleInitial NULL
Title 32 JobTitle NULL
Phone 20 OfficePhoneNumber
MobilePhn 20 CellPhoneNumber
Fax 20 OfficeFAXPhoneNumber
Resource 20 ResourceFlag
CALDOM 32 CalendarDomain
MAILSRV 32 MailServer
SMTPAddr 128 InternetAddress Add This line
MailAddr 128 MailAddress Add This line
MailSys 4 MailSystem Add This line
Finally, in the Mapmex.tbl file, you make one modification in the FullName= line and add the
three additional entries in boldface type. By default, the Exchange users will appear to be in a
separate domain from the Notes users. To make the directories appear as one, you can modify the
FullName (i.e., distinguished name – DN) to match others in the environment. In this environment,
the DN is in the format Steve Bryant/Company, so I modified the connector to use the same format
for imported users, as Figure 5.12 shows.
Figure 5.12
Changes to the Mapmex.tbl file
MAPMEX.TBL
FullName = FirstName “ “ LastName “/COMPANY”
MailDomain = Trim( Strip( NotesAddr, “@”, “L” ), “B” )
ShortName = Alias
LastName = ISEQUAL( LastName, “”, FullName, LastName )
FirstName = FirstName
Company = Company
Department = Department
Location = Office
UNID = HASH( DN )
USN = USNCreated
DN = DN
Initials = Initials
CALDOM = Trim( Strip( NotesAddr, “@”, “L” ), “B” )
MailDomain = NOTESDOMAIN Add this line
MailAddr = Trim(SMTPAddr, “B”) Add this line
MailSys = “5” Add this line
In the example that Figure 5.12 shows, I added fields to make the directory appear seamless. The
line beginning with MailDomain= ensures that SMTP is used and that no external Notes domain is
involved. Replace NOTESDOMAIN with the Notes domain name you use in your environment.
Because you’re forcing an entry in the mail domain field, the Exchange sites don’t need to install or
run the Notes Addressing DLL on their servers.
You add the required lines MailAddr and MailSys to identify the type of Notes person document
to create and indicate how the address will be created. The result is a person document with an
SMTP address for routing only. After you modify the settings, restart the Notes connector service.
Because the mapping fields load during the service startup, you’ll need to stop and start the service
after each change.
I won’t pretend this process is a cakewalk. It takes me a couple of days to create a new
connection this way, but it’s easy to test, and you learn the results of your work fairly quickly. Be
prepared to stop and start the service often. Change the event logging on the service to Medium –
so you can watch the event logs for errors. (By default, event logging is set to “off.”)
Also, be prepared to delete all entries and resync. To make the delete-and-resync process easier,
create a local recipient container in the Exchange system for the imported Notes accounts and use a
separate Names and Addresses file in Notes for the imported Exchange addresses. I encourage you to
build your mapping files in a test environment because if you make a mistake with the mapping
fields, a directory sync will litter the event log with errors and potentially delete entries that the
connector has already created.
n Note As cool as this tweaking is, Microsoft Product Support Services (PSS) won’t provide much
support for this configuration. In fact, should directory synchronization fail, PSS will probably
ask that you reinstall the connector or overwrite the mapping files. If support is important to
you, you should take a serious look at MIIS 2003, which I cover in more detail at the end of
this chapter. MIIS 2003 supports the same level of field mapping and manipulation, but it
Microsoft designed it to work in that capacity and PSS supports it fully. Finally, be aware that
the Notes connector doesn’t support rich text in this, but it does support HTML-formatted
messages. Calendar invitations, free/busy, encryption, and any other features that would
provide rich text or formatting won’t work. What you gain, however, is stability.
GroupWise
The technologies and procedures for GroupWise directory synchronization and message formatting
are nearly identical to the Notes/Domino processes. The connector for Novell GroupWise
synchronizes specific Novell GroupWise mailbox information to the AD and visa versa. As with the
Notes connector, you should create a separate Exchange Server 2003 server to run the connection.
Also as with the Notes connector, mapping tables control which fields in the Novell directory
map to corresponding fields in AD. Because of this structure, you can also manipulate the way the
entries are created and maintained in the systems.
To install the GroupWise connector, you must first verify connectivity to the Novell network by
installing the Novell NetWare Client for Windows (or the Novell Directory Services – NDS – client,
depending on the version of NetWare you use) on the Exchange connector server.
On the Novell side, you must install the Novell GroupWise API Gateway on one of the Novell
servers and configure a foreign GroupWise domain for your Exchange 2003 organization using the
NetWare Administrator program. Using the recipient policies, you can configure different proxy
addresses for different groups of people and install separate GroupWise connectors to spread the
load and reduce the impact of a connector failure.
MIIS 2003
In the scenarios I’ve described in this chapter, I’ve identified the specific directory synchronization
options for the various versions of Exchange as well as foreign directories. You’ve probably noticed
that each process I mentioned is specific to that task and that none of the scenarios I’ve mentioned
thus far has abilities beyond the predefined task.
In other words, until now, I haven’t described the “silver bullet.” Microsoft began to consider the
connection concerns in the late 1990s and worked on a metadirectory project that would support
connections with multiple disparate directories for address list synchronization, account management
and provisioning, and even password synchronization.
Microsoft Identity Integration Server 2003 (MIIS 2003, formerly Microsoft Metadirectory Services
(MMS)) is Microsoft’s newest and most powerful metadirectory offering. MIIS 2003 supports far more
than the few directories mentioned so far. The following list indicates the range of MIIS 2003’s
support:
• AD
• ADAM
• Attribute value pair text files
• Delimited text files
• Directory Services Markup Language (DSML)
• Fixed-width text files
• GALs (Exchange)
• LDAP Directory Interchange Format (LDIF)
• Lotus Notes/Domino 4.6 and 5.0
• Microsoft Windows NT 4.0 domains
• Microsoft Exchange 5.5 Bridgeheads
• Exchange 2003, Exchange 2000, Exchange 5.5
• SQL 2000 and SQL 7 and databases
• Novell eDirectory v8.6.2 and eDirectory v8.7
• Oracle 8i and Oracle 9i databases
• SunONE/iPlanet/Netscape Directory
• IBM Informix, DB2, dBase, Microsoft Access, Microsoft Excel, OLE DB through SQL Data
Transformation Services (DTS)
If you want to synchronize address lists from Exchange 2003, Exchange 2000 and Exchange 5.5
organizations, and Notes/Domino, multiple and/or LDAP directories – MIIS 2003 offers a better
solution than running all the connectors I’ve mentioned previously.
MIIS 2003 is a powerful metaverse product – and it isn’t free. It’s a production-quality, heavy-duty
server product that supports very granular replication of directory objects. MIIS 2003 requires SQL
Server 2000 Enterprise SP3 on the back end, and you’re encouraged to install Visual Studio .NET for
any custom extension work you might need. By using management agents, you can control which
fields of which objects are replicated to the metaverse. And, once within the metaverse, you can
control which fields and objects are copied back to the individual directories.
MIIS 2003 is a complicated product that requires some knowledge of AD and the directories
you want to synchronize – and some development skills in compiling specific management agents.
Moreover, the terminology used to describe MIIS 2003’s setup and management will be foreign to
many administrators and will take some getting used to. For more detailed information about MIIS
2003, go to http://www.microsoft.com/miis.
LDIF Import and Export Scripts

Finally, I’d like to mention that you can script the management of objects within AD. You can use
LDIF scripts as well as comma separated value (CSV) files to export information from the AD. In
addition, you can use specifically formatted files either in LDIF or CSV formats to import information
into AD. I covered the syntax for LDIF scripting in the previous chapter, but I wanted to mention it in
this one as well.
Reviewing Your Multiple Directory Options

Many tools are available to help you maintain a single address list for your company. Non-Exchange
systems can also share the address book and provide collaboration with users whose mailboxes are
located on Exchange servers.
When you design a long-term coexistence solution, you should understand the protocol
implications as well as the “moving parts” necessary for directory synchronization. Manual directory
updates probably don’t provide the best long-term solution. Even LDIF scripts could become
cumbersome after some time, especially if you must deal with deletions and edits to existing records.
As we mentioned before, different “flavors” of MIIS can help you solve your directory
synchronization needs, but MIIS is not the only choice available.
1. Custom Code – Nothing is stopping you from writing your own directory synchronization tool.
AD allows both reading and writing with LDAP. Do a quick search for LDAP and ADSI at
http://msdn.microsoft.com and you will find many code samples to do just that. Moreover, LDIF
and even CSV files can be exported and imported on regular schedules to establish and maintain
the single global address list.
2. IIFP is available from Microsoft as a free download. It does a good job of “merging” two AD
forests to provide GAL synchronization. Moreover, it is fully supported as a long-term solution for
GAL synchronization
3. SimpleSync, a product available from CPS Systems at http://www.cps-systems.com/, has been
around for several years and also provides an excellent tool for synchronizing LDAP directories
(e.g., AD, Notes, Exchange, and iPlanet.
4. HP (formally Compaq, formally DEC) also has an enterprise-level synchronization tool called
LDAP Directory Synchronization Utility (LDSU). This tool was originally written to support the
company’s large in-house move to Exchange 2000 and has a large customer base.
5. MIIS, discussed MIIS in detail earlier in this chapter, is fully supported by Microsoft and provides
a great deal of functionality, but with complexity.
6. Aelita Collaboration Services for Exchange, from Aelita now part of Quest Software, is the one
tool that offers the most for Exchange collaboration among different forests and Exchange
organizations. The two largest advantages of this product are its ability to synchronize over SMTP
and to provide free/busy information across Exchange organizations.
Next: Outlook Deployment

In Chapter 6, I’ll discuss Outlook deployment, including performance over slow links, installation
scripting, and profile management. I’ll also cover mobile implementations of Outlook and
collaborative integration with other applications.
One of the strongest new features of Outlook is its ability to work over slow links. Outlook’s
new level of compression and synchronization dramatically affects both performance over slow links
and overall server load. By understanding the improvements in Outlook 2003, you can better design
systems that span slow links.
Outlook 2003 also offers improved privacy, antivirus capability, junk email filtering, compression,
synchronization, overall performance, and stability. In addition, Outlook 2003 is closely matched
with the new OWA versions. In Chapter 6, I’ll discuss the new features and their impact on your
enterprise – including the newly added support for smart phones and mobile devices.
103
Chapter 6:
Deploying Microsoft Outlook

By the end of this chapter, I think you’ll understand why the Microsoft Exchange client information
I discuss is essential to you. The Exchange client is, in fact, the most important aspect of Exchange.
I’ll discuss your several client options, including their different functionality and their impact on the
network. This information will help you determine how clients can connect from the Internet to
receive information, how many servers your organization requires, and how mobile access can work
most effectively.
In Outlook 2003, Microsoft has finally created an Outlook client that’s smart on the network. And
with the new methods you have for connection, end users have more options for getting to their
data. I’ll explore the strengths of the new Microsoft Office Outlook 2003 client, the new Outlook Web
Access (OWA) client, the Outlook Mobile Access (OMA) client, and ActiveSync.
I’ll also discuss the specific settings available for each Outlook client because those settings
affect the client’s performance, the network, and the organization’s security. Choosing to use remote
procedure call (RPC)-over-HTTP or to use premium rather than basic OWA will have implications for
security, network performance, and functionality that you should understand. One of the goals of this
chapter is to provide you with the information you need to determine the best configuration for your
Outlook clients and their connectivity to the Exchange server.
n Note I won’t discuss Outlook Express, POP, and IMAP because those access methods and protocols
haven’t changed much over the past 10 years.
Outlook 2003
Outlook 2003 is the newest version of Outlook. It’s available for the McIntosh and for i386 systems
running Windows Server 2003, Windows XP, and Windows 2000. Outlook 2003 represents the largest
change to the code base and the most significant set of improvements since the first Exchange client.
(The first Exchange client was simply called “Exchange” – just as cc:Mail and MS Mail identified both
the client and server components.)
As companies continue to rely on messaging for communications, the Microsoft Office Product
Group and Microsoft Research teams spend considerable time trying to keep up with feature requests
and fine-tuning the interface so that menus become increasingly natural and even predictive.
Microsoft has improved existing features and introduced new looks, layouts, and advanced features.
The many added features are both reactive, such as the junk email filters, and user-requested, such as
office automation features (e.g., Smart Tags, SharePoint services integration).
Cached mode
Probably the most important change in Outlook will be invisible to most users. Outlook 2003’s
Cached mode option is intended to be seamless, simple, and invisible – and it meets those goals
completely. If you feel that this new function doesn’t apply to your organization and serve its needs,
you need to read this section thoroughly. Don’t tune out!
Cached mode dramatically affects not only the number of users your servers can support but also
the placement and configuration of your servers. Understanding this is important because of the
benefits and implications of its use. A brief history of Outlook will set this option in context.
Before Outlook 2003

Outlook 97 introduced the concept of offline mail storage. Don’t confuse offline mail storage with
personal folder store (PST) used as an offline folder store (OST). Microsoft designed offline mode
(Cached mode) to contain a copy of what was in a user’s mailbox on the Exchange server. End users
decided how much they wanted to “cache” locally in their OST file.
This approach to offline mail storage was a great improvement because it let users access
their contacts and even create email messages while they were on planes – or were otherwise
disconnected from the corporate network. The problem with Outlook 97 was that the offline file
wasn’t stable. Outlook 98 included some hotfixes that improved many areas of concern – among
them the stability of the offline store.
Although Outlook 2003 (XP) and Outlook 2000 further stabilized the OST, they suffered from
the offline/online problem (the Outlook client had to be in one state or the other). You could
synchronize with a server while you worked offline, but you couldn’t use features such as delegation
and Inbox rules. In addition, you had to restart Outlook to switch from one mode to another.
Even with this limitation, many companies began deploying Outlook clients configured for offline
use in remote locations. Users who worked offline gained a quick response by using a local cache of
the mailbox and a local copy of the Global Address List (GAL). A user in a remote office would
consume roughly the same bandwidth in either mode, but the offline client would respond faster and
network connectivity problems would affect it less than its online counterpart working from the same
location.
Even in previous versions of Outlook, the impact of offline use went beyond mobile users.
Desktop machines could access their mailboxes over a WAN link with surprising speed. In fact, the
only time users would notice the slow link would be during the mail synchronization – especially
when email messages with large attachments were involved.
Before Outlook 2003, remote synchronization monopolized not only the Outlook client, but also
the desktop itself, which might become unresponsive during the transfer. Moreover, as I mentioned
previously, working offline has some limitations. Users can’t access mail or public folders that aren’t
cached locally nor can they delegate tasks or work with rules.
Enter Outlook 2003

With Outlook 2003 and Cached mode, the client can switch between online and offline automatically
without announcing an error or disrupting the user. Imagine an office with perhaps 100 users, all
running Outlook 2003 in Cached mode. The users are working online when an administrator
accidentally reboots the Exchange Server. Bad news indeed, but not catastrophic because the Outlook
2003 client detects that the server isn’t available and automatically goes into offline mode.
Chapter 6 Deploying Microsoft Outlook 105
When the users create new email messages, Outlook 2003 automatically puts the email messages
into the Outbox without even hinting that a problem exists. A status bar in the lower right of the
Outlook client indicates that Outlook is “Disconnected” and trying to connect, as Figure 6.1 shows.
Figure 6.1
Outlook 2003 in Cached mode
By default, Outlook 2003 will notify the user of a status change through a dialog box and from
within the status bar itself. A “Disconnected,” “Connected,” or “Trying to Connect” indicator is
displayed automatically – depending on the current state of connectivity to the server. “Offline” is a
manual setting that you can select to prohibit the client from attempting a connection to the server.
Without the status bar’s indication, however, the user would have little way of knowing that
anything was amiss. When the server boots and the Exchange Services are running again, the client
automatically senses its return, switches to online mode, and synchronizes the deltas. Mobile users
experience a similar scenario when they launch Outlook. They needn’t worry about which mode to
choose or whether they’re connected to the network. The Outlook client handles the decisions.
Synchronization Timer and Priority

As Microsoft developed Office 2000, the company began working on the predictive functions by
which the menu systems learn how you work and offer the menu items that you use frequently first.
This predictive functionality has spilled over in subtle ways into other aspects of Office. Outlook 2003
synchronization is a case in point, as Figure 6.2 shows.
Figure 6.2
Predictive menus
Microsoft first introduced this approach to menus with Office 2000. It has now become standard
for Office and OS menu systems. Although this predictive menu system is rather primitive, it
represents one of the ways Microsoft’s software works to learn users’ habits.
Another predictive function of Outlook 2003 is its ability to automatically control the order in
which items are synchronized in Cached mode. When you launch Outlook 2003 for the first time in
Cached mode, Outlook begins to track which folders and types of items are most often synchronized.
As you continue to use Outlook 2003 in Cached mode, the system begins to learn which folders
you use most and prioritize those folders so that they are synchronized first. Eventually, the system is
trained – without user intervention. Outlook will always start by synchronizing the user’s most
frequently used folders and end by synchronizing the user’s least frequently used folders.
In addition to this intelligent prioritization process, Outlook determines the frequency of
replication based loosely upon the frequency at which an Outlook 2003 user creates new items in
the local cache. The idea is to try to batch the communication requests and synchronization tasks
whenever possible. In addition to item synchronization, various alerts are communicated between the
client and server (e.g., server alerts that tell the Outlook client newer items have arrived on the
server). To conserve bandwidth, these alerts are batched, which reduces the number of times the
server and client establish new communication channels.
The Outlook 2003 client working in Cached mode begins synchronization within 15 seconds
of your creating a new item (e.g., an email message). If you create another new item before the
15-second timer expires, the timer resets for another 15 seconds. The process will repeat until a
minute has elapsed – then all queued items will be synchronized in one batch. A similar process
occurs when the server receives new items and needs to send alerts to the client.
Network Adaptor Speed Awareness

Outlook 2000 could determine whether a server was available, but it could do so only at startup.
Outlook 2003’s ability to monitor connectivity continually is indeed a huge improvement, but the
ability to adjust functionality based on connectivity speed is something entirely new to Outlook.
Outlook can now change synchronization options based upon the speed of your network con-
nection. A remote worker who uses Outlook might synchronize it over a dial-up or slower WAN con-
nection. When Outlook determines that the local network connection is less than 128Kbps, it will
download headers only and skip updates to the Offline Address Book (OAB). A remote worker can
simply double-click the header (or synchronize with a PDA) to synchronize the message body and
attachment locally.
n Note You should understand that Outlook’s ability to detect network speed doesn’t determine the
connection speed of the session with the server but the identified connection speed of the
interface you use for the connection.
The Headers-only mode is especially handy for dial-up sessions and General Packet Radio Ser-
vice (GPRS) network connections. Because I travel a lot, I often use my smart phone to connect my
notebook computer to the Internet and synchronize Outlook. The Headers-only function is fast. But
better yet, Outlook 2003 synchronization now downloads the newest items first, so you have the
most relevant information immediately. (This approach is also new in Outlook 2003. Previous Out-
look versions would synchronize the oldest items first, so you had the wait the longest for newer
items.)
MAPI Compression
My first comment about Messaging API (MAPI) compression is – it’s about time! Microsoft has
extended the MAPI protocol to the Outlook 2003 client and to Exchange Server 2003 to support
EcDoRpcExt calls. Microsoft has used the Lempel-Ziv algorithm before – for Active Directory (AD)
replication – and has now implemented it in Outlook 2003 and Exchange Server 2003 to provide sur-
prising results.
To begin with, this compression feature applies not only to the attachments but also to the body
of the message itself – including HTML messages. In fact, HTML messages compress by 60 percent to
80 percent. For the most part, you should see a 20 percent to 40 percent savings in bandwidth when
you compress documents such as Word files and Visio files, as Figure 6.3 shows.
Figure 6.3
Outlook 2003 MAPI compression bandwidth savings
1KB HTML Message with 1MB Attachment
Outlook 2000
Outlook 2003
without cache
Outlook 2003
Cached Mode
0 200 400 600 800 1000 1200
Kbps
Outlook 2003 and the XPRESS compression technology offer substantial network and
performance savings over the previous versions of Outlook. Remember that you can obtain this
two-way compression only with Exchange 2003 Server and an Outlook 2003 client running on
Windows XP.
You don’t need to choose a compression option or make any changes manually; the compres-
sion takes place seamlessly and the function is transparent to users. Each communication is more
efficient because MAPI compresses it during the session. If compression is particularly important to
you, consider the following two points:
HTML-formatted messages benefit from compression more than do Rich-Text Format (RTF)
messages. This change to HTML will reduce network bandwidth use if Outlook is heavily used and
most messages don’t have attachments. If your system meets those conditions and you need to
reduce traffic on your network, consider setting all of your Outlook clients to use HTML as the
standard email message format.
If most of your outbound email messages contain large files, consider disabling Cached mode
on your Outlook 2003 machines because items synchronized in the Sent Items folder receive no
synchronization advantage, as Figure 6.4 shows.
Figure 6.4
Outlook 2003 message-sending bandwidth use comparison
Outlook 2000
Outlook 2003
without cache
Outlook 2003
Cached Mode
0 200 400 600 800 1000 1200 1400
Kbps
Outlook 2003 is extremely efficient for opening attachments and sending email messages.
However, when you use Outlook 2003 in Cached mode, it offers no real advantage for outbound
attachments – because of the way sent items are synchronized and because the entire item must be
sent to the server.
OAB
Cached mode offers more than just smart synchronization of the mailbox. It provides smart
synchronization of the OAB as well. In fact, turning on the cached mode automatically enables the
use of OABs. The ability to use OABs lets you resolve names locally if the Global Catalog (GC)
becomes unavailable during the Outlook session.
Keep in mind that Outlook 2003 doesn’t offer any network improvements for GAL lookups. Tests
that Microsoft conducted and published indicate that Outlook 2003 consumes more bandwidth than
earlier versions of Outlook for address resolution, ambiguous name resolution, and address lookups,
Figure 6.5
Outlook 2003 and Outlook 2000 bandwidth use comparison
Address Lookup
Outlook 2000
Ambiguous Name
Resolution Outlook 2003
Address
Resolution
0 2000 4000 6000 8000 10,000 12,000 14,000
bps
Outlook 2003 comes with many improvements and some of them are at the slight expense of the
network. In the case of the address book, Outlook 2003 can put as much as 12KB on the network
for an address lookup whereas Outlook 2000 uses less than 4KB for the same task. Although subse-
quent lookups are cached and faster, the initial unresolved names will require some bandwidth to
resolve. The Outlook 2003 machine used in the test was in Cached mode.
RPC-over-HTTP
If you can connect to your Exchange environment with OWA (I cover OWA in detail in an upcoming
section of this chapter), you can connect with an Outlook 2003 client using RPC-over-HTTP. That’s a
broad statement, but one that’s true most of the time.
As usual, however, the devil is in the details – and for RPC-over-HTTP, that’s particularly true. To
begin with, the Exchange Server 2003 machine that you use as the RPC-over-HTTP proxy server must
be running Windows Server 2003 and have the optional RPC Proxy Service installed.
A Secure Sockets Layer (SSL) certificate must be installed on the server, authentication for the
RPC Virtual Directory in Microsoft IIS must be set to Basic (with SSL), and Anonymous Access must
be cleared. If you use a front-end/back-end configuration in your Exchange environment, the RPC
Service should be installed on the front-end server(s). You can use the Exchange System Manager
(ESM – updated with Service Pack 1 – SP1) to specify the RPC-HTTP front-end server option. For the
mailbox servers, you need only specify that they’re RPC-HTTP back-end servers using the same ESM
console. Remember that you need to reboot to put these changes into effect.
For smaller shops that use a single server for Exchange and AD, you can install RPC-over-HTTP
as you would a front-end server by installing the RPC Proxy Service, installing a certificate, and
changing the authentication settings as noted previously. However, in ESM, you’ll need to select the
RPC-HTTP setting to specify that the server is a RPC-HTTP back-end server. In addition, you must
make a registry change to hard-code the port used for GC access.
To make the registry change, locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\NTDS\ Parameters subkey and create a new multistring value named NSPI interface
protocol sequences. Edit the data field, adding ncacn_http:6004 to the value. You must restart the
machine for this setting to take effect.
Next, you must configure the Outlook 2003 client to use RPC-over-HTTP. The Outlook 2003
client does most of the work. It begins the process by encapsulating the MAPI calls into an HTTP
packet. SSL sessions are established between the client and the Exchange 2003 Server that runs the
RPC Proxy Service. The front-end server establishes a MAPI session to the mailbox server (or to itself
in the case of a single-server configuration) on behalf of the client.
To make this magic happen on the client side, you must be running Windows XP SP1 patched
with the RPC Update 331320 (http://go.microsoft.com/fwlink/?linkid=16687) or Windows XP SP2.
Obviously, you must have Outlook 2003 installed and you must configure the Outlook profile to use
HTTP to communicate. Although you use few settings on the client (or on the server for that matter),
the settings must be exact and correct or connectivity will be impossible. Figure 6.6 shows the
necessary connectivity settings.
Figure 6.6
Outlook 2003 communicates with Exchange over the Internet using RPC-over-HTTP
Keep in mind that for RPC-over-HTTP to work, the Outlook client must be able to resolve the
Fully Qualified Domain Name (FQDN) of the server. Moreover, the client machine must trust the
Certificate Authority (CA) that issued the server its SSL certificate.
n Note The RPC-over-HTTP function isn’t limited to synchronization but allows total mailbox and
public folder access from the Internet.
For more information about RPC-over-HTTP, see the following articles:
• http://www.winnetmag.com/article/articleid/40018/40018.html
• “Exchange Server 2003 RPC over HTTP Deployment Scenarios Guide” from
http://www.microsoft.com/exchange/library
Outlook 2003: Additional Improvements

Additional improvements to Outlook 2003 include buffer packing, Smart Change Synchronization, and
Incremental Change Synchronization. Microsoft added support for buffer packing to further aid in
replication and general efficiency. The buffer-packing function lets the server continue to load the
buffer with compressed data until it’s full. Buffer packing lets Outlook synchronize more data at once,
which results in fewer session requests because a single session can be leveraged to synchronize
multiple items.
Smart Change Synchronization reduces replication traffic by synchronizing message attributes
(e.g., flags, message forward, reply headers) instead of entire messages. Incremental Change
Synchronization lets Outlook track the synchronization and establish a checkpoint so that if a
connectivity error occurs during synchronization, Outlook won’t have to perform another complete
synchronization. Instead, the process will begin where the previous synchronization ended.
OWA
If you’ve paid attention to the evolution of OWA, you’ll notice specific changes – and not just in
OWA’s “look and feel.” With OWA 2003, the development effort came primarily from the Microsoft
Office team rather than from the Exchange team. Knowing that helps you understand why the OWA
and Outlook 2003 interfaces look so similar.
Moreover, you should know that the Office team is now in charge of Microsoft Office SharePoint
Portal Server. I wouldn’t be surprised if SharePoint Portal Server and OWA began to look more
similar. OWA has needed an overhaul, and recent changes affect not just appearance but core
structure as well.
Launching OWA
When you enable forms-based authentication on Exchange’s HTTP Virtual Server, you’ll have access
to the OWA logon page. The OWA logon page lets you launch OWA with several options that
determine the network performance of the client and the security options, as Figure 6.7 shows.
Figure 6.7
OWA logon page
n Note
You’ll need to enable Forms-based Authentication to see this screen and select alternatives for
client interface and security options. Forms-based Authentication is much more secure because
it lets the administrator define timeout thresholds and better secure the session.
After reading Microsoft’s 336-page document about Exchange 2003 client traffic and completing
my own testing, I don’t see a significant difference in bandwidth consumption between OWA basic
and OWA premium. Unless you have a compelling reason to use OWA basic, OWA premium should
probably be your OWA client of choice.
OWA Address Book Access

I’m among the many who’ve long assumed that HTML-based applications created less traffic on the
network than full clients. And if you read the descriptions of OWA premium versus OWA basic,
you’d think that OWA basic would have a smaller network footprint. For the different clients,
however, various functions simply work faster and more efficiently than others, as Figure 6.8 shows.
Figure 6.8
Network bandwidth use comparison by function
Address
Lookup
OWA 2003 Basic

Ambiguous OWA 2003 Premium
Name
Resolution Outlook 2003
Address
Resolution
0 2000 4000 6000 8000 10,000 12,000 14,000 16,000 18,000
Kbps
OWA Network Performance

To further prove my point about Outlook 2003’s efficiency, note that even without caching, the
Outlook client provides a considerably smaller footprint than its OWA counterpart using high
compression, as Figure 6.9 shows.
Figure 6.9
OWA and Outlook 2003 sending and receiving bandwidth use comparison
Send
OWA Premium -
High Compression
Outlook 2003
without cache
Read
0 2000 4000 6000 8000 10,000 12,000 14,000 16,000
Kbps
Figure 6.9 compares the Outlook 2003 client without cache with OWA premium running SSL
with the high-compression option selected. As you can see, OWA takes almost twice the bandwidth
to send the same attachment.
OMA
During the past year, the wireless industry has improved its offerings, and organizations can now
offer wireless email, calendar, and address book services to PDAs – and even to phones. Microsoft
elected to roll its Microsoft Mobile Information Server (MMIS) into Exchange 2003. In addition, you
can now find technology that lets mobile users with Wireless Access Protocol (WAP) phones not only
read their email messages from a specially designed Web page, but also synchronize their Inbox and
calendar information over the air directly to your Exchange Server 2003 server.
If OWA is considered a thin client, OMA can be considered the thinnest client. OMA is a Web
interface that provides a simple yet navigable view of the user’s mailbox. OMA will display a different
screen depending on whether your device uses Wireless Markup Language (WML), HTML, Extensible
HTML (XHTML), or Compact HTML (cHTML) – but in all cases, OWA is extremely light on the wire
and can fit on even the smallest screens.
Microsoft originally designed OMA for WAP devices. Nevertheless, you can leverage OMA from
non-WAP devices (e.g., remote machines) when network bandwidth is severely limited.
Enabling OMA
OMA isn’t enabled by default, but you can enable it for the entire Exchange organization by selecting
a single check box on the Mobile Services Properties dialog box in ESM, which Figure 6.10 shows.
Figure 6.10
OMA configuration
n Note In respect to OMA on the server, you need to configure very little. If you have an OWA
environment in place, you need only select one check box to enable OMA. However, make
sure you permit the OMA protocol for the mailboxes that will need it.
After you’ve enabled the setting, you just point your browser to https://fullyqualifiedname/oma to
start the session – assuming that you have connectivity and that an SSL certificate is installed on the
server. If you want to let non-WAP devices connect, you need to select Enabled unsupported devices
on the configuration screen that Figure 6.10 shows.
Although the interface seems bare, OMA offers some excellent features and support for mail
users. First, you can access the Inbox (and other mail folders), calendar, contacts, and tasks. Second,
you have access to the Global Address List (GAL) for creating email messages or looking up phone
numbers and other information.
Third, in addition to the usual calendar, contacts, tasks, and message tasks, you can enable or
disable out-of-office notifications and change your language settings and time zone options, as you
can with OWA. If you’ve enabled the ability to change passwords from OWA, you can also use that
feature from within OMA.
Instead of showing what OMA looks like from a regular Internet Explorer (IE) session, Figure
6.11 shows what OMA looks like on a phone.
Figure 6.11
OMA on a Motorola MPX 200
You can navigate by using the number keys on the phone or by moving up and down by whatever
method your phone offers (mine has an arrow-like feature) to select the item you want.
ActiveSync
ActiveSync isn’t new. For years, you’ve been able to synchronize your Pocket PC device with your
desktop, including calendar items and messages. Although Palm users have used programs such as
Pocket Mirror to keep Outlook and the PDA synchronized, only ActiveSync allows direct synchroniza-
tion of the mailbox to the PDA without using a cradle or desktop synchronization software.
This direct synchronization is accomplished through the server component of ActiveSync that
runs in IIS and supports synchronization with an HTTP Secure (HTTPS) session. In other words, a
client agent runs on Pocket PCs and smart phones and a server agent is loaded on either an MMIS or
an Exchange Server 2003 machine, as Figure 6.12 shows.
n Note The MMIS product has been discontinued. About 99 percent of the features have been rolled
into Exchange Server 2003. The primary item that didn’t carry over is support for Exchange 5.5
organizations. In other words, if you upgrade your Exchange 5.5 organizations to Exchange
Server 2003, you’ll still be in business.
Figure 6.12
Smart phone screen
The display screen on your Pocket PC or smart phone will vary depending on brand and OS
version, but in each case you’ll have a Pocket Outlook that contains your Inbox, calendar, and
contacts folder. ActiveSync can synchronize these functions with the cradle or through the wireless
network.
ActiveSync is enabled by default on an Exchange Server 2003 machine, but getting it to work
could be a little tricky. You should start with the white papers and Help screens for configuring the
client and server components.
The biggest concern is connectivity because the mobile device will connect to your ActiveSync
server to resolve the FQDN in DNS, then establish a network connection through HTTPS to the
server. The implication, of course, is connectivity – because your mobile device will need to have
either a wireless network connection or a mobile wireless connection, such as the GPRS network, to
the Internet.
n Note Even though I’m connecting to Exchange Server 2003, the status screen says “Mobile
Information Server,” as Figure 6.13 shows. Don’t be alarmed; this designation is normal!
Figure 6.13
ActiveSync
You can use several ActiveSync settings, including one that lets you set the types of objects you
want to synchronize and the frequency of synchronization. If you’re concerned about data charges on
your mobile phone, you might elect to synchronize mail items only over-the-air and calendar and
contact items with the cradle.
j Tip
If you have problems getting the ActiveSync client to synchronize with Exchange Server 2003,
check the following:
• Recipient Policy – The primary SMTP address for your mailbox must match the rule used for
the Global Recipient Policy.
• SSL Certificate – The certificate used on the server should be from a recognized CA.
• Authentication – The Microsoft-Server-ActiveSync Virtual Directory on your server should
use Basic Authentication only.
Check online resources such as Microsoft’s support pages for Exchange Server 2003, Microsoft’s
support pages for MMIS, Microsoft’s microsoft.public.exchange and microsoft.public.mobility news-
groups, and http://www.cewindows.net/faqs/activesync/mis.htm.
Reviewing the Improvements

Microsoft has made dramatic improvements to both the Outlook and the Exchange products. Because
of the new efficiency of Outlook 2003 and OWA, you can now realize the promise of server consoli-
dation. Compression and intelligent synchronization provide better efficiency, and OMA ActiveSync
offers support for more devices.
The question of clients ultimately boils down to feature requirements. For example, Palm and
cradle synchronization as well as offline access require the Outlook client. For slow or unstable
network links, the Outlook client working in Cached mode offers uninterrupted support for end users
with fast response time for accessing mailbox items.
Next: Administrative Best Practices and Disaster Recovery

In Chapter 7, I return to the subject of Exchange Server 2003 and discuss administrative best practices
as well as disaster recovery. With recovery storage groups, you can now restore individual mailboxes
without disrupting the live database. In addition, new third-party tools can restore mailboxes or even
individual items with the backup files only. I’ll also consider how you can build redundancy into
your Exchange Server environment and which techniques you can use to monitor your Exchange
environment.
121
Chapter 7:
Administrative Best Practices

and Disaster Recovery
At the heart of Microsoft Exchange best practices lie proper disaster-recovery procedures, but the
ability to recover a server is not the only thing you need to know. You must perform multiple
administrative tasks to maintain a healthy Exchange environment. You need to set up and follow
through upon daily, weekly, monthly, and less frequently performed tasks – not only to protect the
Exchange data but also to protect you and your sanity.
As an Exchange MVP, an active Exchange consultant, and a contributor to various magazines,
online industry sites, and newsgroups, I’m exposed to many Exchange shops. The problem about
which I’m most frequently asked is how to restore an Exchange server with no backups and with
corrupt or missing log files. Let me give you the text of a typical email message:
“Steve, last night our Exchange server crashed because the drive was full. I found a bunch of
5MB log files on the hard drive and deleted them, but the store wouldn’t start. The event log
indicated that database had a problem, so I ran Eseutil, but after 19 hours, I still can’t get the system
up. We tried to perform a restore, but found out that the backups haven’t been running properly for
3 months. What can I do?”
I hope this scenario doesn’t sound familiar to you. If it does, please don’t think I’m making light
of this catastrophic failure. I’m not. I simply want to point out that you can avoid the most common
problem I hear about by following some basic steps regularly. A casual glance at the hard drive, the
event logs, and test restores would not only have prevented this disaster but also have given the
administrator important knowledge about the system – and helped develop the skills to perform
restores in the event of an emergency.
After I review the Exchange database and discuss disaster recovery best practices, I’ll cover
backing up Exchange Server, restoring Exchange Server (including using Recovery Storage Groups),
and backup and archiving policies.
Disaster-Recovery Best Practices

Disaster recovery is by far the single most important administrative subject – and, not surprisingly, the
most discussed. In respect to disaster recovery, knowledge is more powerful than technology. Your
understanding of the message stores, the backup and restore procedures, and performance, and, most
importantly, the recovery process will help you more than any wizard.
The Exchange Database: A Brief Review

Exchange Server 2003 contains several database files. Each message store is comprised of two such
files: a rich-text Exchange database (EDB) file and a streaming (STM) file that contains Multipurpose
Internet Mail Extensions (MIME) content. The system stores email messages that you send or receive
by using the Outlook client in the EDB file; it keeps email messages that you send or receive in
native Internet format in the STM file until a MAPI client opens them. Exchange delivers incoming
SMTP, for example, to the STM file, and places a pointer to the email message in the EDB file. The
rich-text database contains the mailbox structure, the mailbox rules, and the MAPI messages. (Some
portions of the data are saved in memory and other portions are written to disk.)
To improve performance, maintain a consistent state, and ensure the data’s autonomy,
consistency, integrity, and durability, Exchange Server (as well as SQL, Active Directory and many
other databases) employs transaction log files. Exchange Server 2003 dedicates a separate set of
transaction logs for each storage group.
When new items are delivered to your Inbox, the changes aren’t immediately written to the
EDB and STM files. If they were, the disk drive that contains the EDB and STM files would need
to perform random reads and random writes constantly, which would seriously affect disk-drive
performance. Moreover, if either EDB or STM files became corrupt and had to be recovered from
tape, any transaction performed after the previous backup would be lost forever.
Use of transaction logs gives Exchange added performance and data integrity. Instead of making
changes directly to the database files, Exchange writes changes simultaneously to transaction log files
and to memory. Until the system commits the data in the transaction logs to the database files, the
system works from memory. This approach is the primary reason that Exchange’s store.exe process
consumes so much memory.
Changes are made to transaction logs and to memory, and then committed to database files
when the load on the system permits. When users access their mailboxes, data might be drawn either
from memory or from disk. Because the data is stored dynamically, users might read an item whose
data is at one point drawn from memory. However, if they read the same item at a later point, its
data might have been committed to (and have to be retrieved from) disk. The drawback to this
design is in understanding how the system works. Few Exchange administrators (and system
designers) really understand how the database “lives” in memory, in transaction logs and within the
database itself. The benefit to this complex design is increased performance with the most recent
items being stored in memory while older items sit in the database files on the drives.
Disk I/O is the most important factor in Exchange server performance – followed closely by
memory capacity. Placing each set of transaction logs on a dedicated set of hard disks is important
because it mitigates the risk of competition for the disk heads, and it provides another level of fault
tolerance for the database. In addition, should a database failure occur, you can restore the EDB and
STM files from your backup, then replay the transaction logs to bring the databases up to the
moment of failure.
d Caution
While these matters are fresh in your mind, I want to warn you that enabling write-cache on
your RAID arrays is dangerous to Exchange Server. The uncommitted changes to the
transaction logs and partial updates to the databases could present additional problems should
the computer turn off suddenly (e.g., if a power outage occurs). Battery backups on RAID
controllers can certainly help as can UPS systems and monitoring software, but it’s still
considered a best practice to remove write-cache for most installations. Consult your hardware
vendor for the procedure to use to disable this option.
Chapter 7 Administrative Best Practices and Disaster Revovery 123
Transaction Logs
I want to cover another important aspect of Exchange that’s also true for most databases that use
transaction logs and “lazy writes.” Even though the data is eventually committed to the EDB and
STM files, the transaction log itself isn’t deleted until a typical Exchange backup occurs. Deleting the
transaction log is part of the backup process; if you haven’t performed a regular backup, you’ll need
those logs if a problem occurs in the current database.
Remember, if you restore a database that you backed up two days previously, you need the past
two days’ worth of log files to make the database current. What happens if the backup fails for a
month? You’ll have a month’s worth of log files, or a full hard drive – whichever comes first. When
the hard drive is full, no more transactions can be written – and the store shuts down.
The moral of this story is that backups are extremely important and that if you don’t monitor
them, trouble will soon rear its ugly head. Backups are also essential if you’re performing a migration.
Keep in mind that 10GB added to the target database will result in a 10GB EDB file and at least
10GB of log files. Exchange also supports an option called “circular logging,” a setting on a storage
group that lets the transaction logs overwrite themselves as needed. Although this option is useful
during a migration, it’s dangerous for typical operations. The last thing a normal Exchange backup
job does after backing up the database is to flush the log files and change the checkpoint file.
Without a successful backup, the log files will continue to grow until the drive becomes full. Circular
logging is the setting used to control the growth of log files on the server by deleting older log files
whether or not a backup has occurred. While this function does let you manage log file growth, it
will negate your ability to maintain information in the event of a failure. With circular logging
enabled, you probably wouldn’t be able to roll back your changes should a failure occur and a
restore be required, so be careful when changing this setting.
Backing Up Exchange Server

As you know, Exchange Server has several components, including an OS, a file system, the registry,
Exchange Server software, fax and other ancillary software, databases, transaction logs, and other
important files, services, and information sources. Many of these entities are services or databases and
aren’t represented as simple files that batch programs, file-copy procedures, or imaging software can
back up.
Exchange Server databases are great examples of open files (potentially large open files) that you
can’t copy. Technically, if you could stop every service and close every file on an Exchange Server,
you could perform a basic file copy or even image the server and clone it. The problem is that such
a process is difficult to automate and requires downtime. Some vendors have created services to
work around or overcome the open-file concern and to permit replication or duplication, but their
products are often costly. Therefore, I’ll confine most of the chapter text to the backup features and
procedures available to Exchange natively.
Full Backup
First, let’s discuss the idea of a full backup. In reference to Exchange, this term usually refers to a
physical copy of all the Exchange files. If you stop the Exchange services, you could manually copy
the entire Exchange directory structure to another drive or even another server for the purpose of
recovery. I have many customers who perform this task and have even automated the procedure
nightly. They schedule a task that stops the services, copies the files, then restarts the services. It’s
inexpensive and provides relatively fast restorations, but it requires downtime and can be tricky in
respect to handling the transaction logs. As I mentioned earlier, part of Exchange backup process is
the management of transaction logs. If you do not use an Exchange-aware backup process, the
transaction logs will not be deleted automatically. Moreover, recoveries will be problematic if you
need to rollback transactions because the checkpoint files will not be accurate. I have worked with
several companies that purposefully shut down the server and use imaging or cloning software to
create a duplicate of the Exchange server every night. This approach also results in an effective full
backup, but again, it requires downtime and will complicate the management of your transaction logs
and checkpoint file.
Backup Utility for Windows

The backup utility for Windows, often referred to as NTBackup (for the name of the executable,
ntbackup.exe), is the staple for most shops. The Backup Utility for Windows provides many features
common to third-party backup tools in that it lets you schedule backups, use hard disks as target
devices, and remotely back up the Exchange databases, transaction logs, and the Site Replication
Service (SRS).
Don’t fall into the trap of thinking that this fully supported utility isn’t a worthy backup program
because it comes bundled with Windows Server. This utility takes advantage of the Exchange API
and of support for the Volume Shadow Copy Service (VSS) and Recovery Storage Groups. It lets
you schedule and monitor backups (through the event log) and performs in the range of 32GB per
hour to 50GB per hour depending on the hardware. Moreover, you can script this particular backup
program and fire it off from the command line. The Windows Server Backup Utility, which Figure 7.1
shows, scans your hardware at launch and lets you use any storage device the scan finds.
Figure 7.1
Windows Server Backup Utility
Tape isn’t the only medium the backup utility supports. You can choose to save the backup file
to a local or network drive. Storing the backup file on hard disk mitigates the delays that tape-drive
systems encounter, so the backup utility should be able to run at a much faster pace.
Centralizing Backups
The Windows backup utility supports Exchange Server 2003 stores on Exchange Server 2003
machines. This capability lets you centralize your backups. A single Exchange Server 2003 machine
can back up the other Exchange machines in your organization.
Moreover, you can set up the same type of configuration from a non-Exchange server by
installing the Exchange Server 2003 administrative tools. You see, NTBackup supports the use of
additional APIs through the registry setting HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Control\BackupRestore\DLLPaths.
You can back up an Exchange Server 2003 store remotely by using a Windows 2003, Windows
XP, or Windows 2000 machine as long as you’ve installed the Exchange 2003 administrative tools.
When planning such a configuration, keep in mind the amount of network traffic required and the
impact to the rest of the devices on the segment. Expect roughly 50GB per hour to stream across the
network for remote backups. A fast or segmented network is best for this type of configuration. In
fact, a single backup server could be placed on an entirely different network segment that is shared
with each Exchange server that uses a separate NIC for backup operations. In the example that
Figure 7.2 shows, I used an XP machine to back up a remote Exchange Server.
Figure 7.2
Backing up Exchange Server 2003 store remotely
Installing the Exchange System Manager (ESM) tools will install esebcli2.dll on the computer
(along with other files) and add the DLL to the system registry. This DLL lets you use the Remote
Store option in NTBackup. Of course, the account you use to back up the server must have backup
operator rights, and the NTBackup GUI is friendlier when the backup server is an Exchange server.
However, you can perform the backup with a standard Windows Server 2003 machine by selecting
the Remote Store option under the Tools menu.
Tape systems aren’t terribly efficient at recovering systems after a failure. The speed of the drives
alone has caused many array manufacturers to design tape-arrays that hold multiple drives to speed
up the recovery process. Because array designs of this kind can easily cost hundreds of thousands of
dollars, companies often look to other types of data-warehousing equipment. Available options
include optical drives and, now that their cost has decreased, Network Attached Storage (NAS)
devices.
When properly configured, two or more disk arrays can create large volume sets that several
servers can share instead of running separate arrays on each machine. By mirroring the data on a
storage array with another array and separating types of data on separate arrays, you can create
redundant, fault-tolerant recovery solutions two or three layers deep. In short, the Exchange stores are
backed up to a disk array instead of tape, and the disk arrays are then archived to tape periodically,
Figure 7.3
Archiving backup disk arrays to tape
Backup Serve Remotely con-

nects to Exchange stores and
backs up the data to a RAID
array
During the day, the backup

server can then archive the
backup files to tape
One benefit of centralizing the backup is centralized logging. Veritas wrote much of the Windows
backup utility, so those who’ve used BackupExec for Windows Servers will find the operation and
functionality familiar.
Besides the backup of the Exchange database stores and the IIS metabase, you need to ensure
that you have a working copy of the Exchange server’s registry. This information is collectively
called System State and can be backed up using most backup applications. The System State contains
specific information about the Exchange server as well as the configuration of IIS, device drivers,
installed applications and overall system configuration.
d Caution
Don’t back up the system state and the Exchange stores in the same job. Microsoft doesn’t
support doing so, and the backup will fail. See PSS ID Number: 820272 for more information.
The Devil Is in the Details

Now that we have an understanding of the backup process, there are a couple additional things to
think about before you can begin scheduling the job. For starters, do you have enough time to back
up the server completely every night? Most of us would prefer to get a normal (full) backup every
night. If your server has more data than can be backed up within the allotted backup window, you
may need to look at backup options such as differential and incremental backups. Here are the
options available to you:
• Normal Backup – Normal is the slowest to backup, but the fastest to restore. With normal,
the databases are backed up completely and thus restored completely with a low degree of
complexity. If your goal is to speed up and simplify the recovery process and you are not overly
concerned with the performance of backup process then Normal Backups are your choice.
• Differential Backup – A differential backup relies on a normal backup for restoration and
thus adds complexity to the restoration. The primary benefit of a differential backup is the
performance of the backup. Because a differential only backs up the data that has changed,
the backup job can run much faster. For example, a weekly backup that occurs on the weekend
could be followed by differential backups each night during the week. The bulk of the data
would be captured over the weekend while only the deltas are backed up each night.
Remember, though, that the backup job will be larger each night as the differences are
compared against the last normal backup. This is an important distinction because it means
that a restoration requires the latest normal backup as well as the latest differential backup.
• Incremental Backup – Incremental backups also rely on normal backups for restoration, but
unlike differentials, an incremental backup captures only changes that occurred since the last
incremental backup. Because of this difference, incremental backups are the fastest for backups
and the most complex to restore. For example, let’s say that the last normal backup occurred
Saturday morning and incremental backups occur every night. A database or server failure on
Thursday would require a restoration of the last normal backup (on Saturday morning), as well
as every incremental that had occurred since then. Several backup jobs and tapes would be
required to bring the server back to a current state. This additional level of complexity usually
discourages most shops from using incremental backups even though it is the fastest method of
backing up the environment..
These terms and procedures are not new nor were they invented by Microsoft or myself.
Strategies for backing up and restoring data on any server are similar in that the price of backing up
and restored must be weighed with the operating budget and the cost associated with a database or
server failure. Tape rotation, for example, and the goals for archiving are based on the requirements
of your company and are not specific to Exchange server. Where you store your backup tapes or
whether you engage a storage company to take tapes to an offsite location is completely up to you
and your company. As I mentioned before, laws change and SLAs are negotiated, so take some time
to develop a plan that makes sense for your organization. Things to discuss with your operations
manager and legal groups include archiving policies, the time allowed to restore a server to service
after a failure and the implications and benefits to sending tapes offsite for storage. Moreover, your
specific requirements may necessitate a “hot site” to be fitted out in case you have a catastrophic
failure at a specific office. Neither the Active Directory nor Exchange Server supports such an
option by default, so you may need third-party tools and additional equipment to provide “site” fault-
tolerance to your environment.
Exchange Backup Details

Before we move on to recovery there are a few more things you should understand about the
backup process and how it can be optimized.
• Schedule the backup to run when server load is low. Even 24-hour shops have some time during
the day when activity is not at its peak. Needless to say, backing up the Exchange server will
affect its performance and clients could feel the effect. It is best to run the backups at such a
time where user connections are low.
• Schedule the backup around the database maintenance windows or change the maintenance
settings. By default, a series of routines run at night to check defrayment and optimize the
databases. To ensure a fast backup, it is best to schedule the backups around these windows
or to change the windows themselves. Background cleanup, item expiration, tombstone
maintenance, database compaction, generation of storage warnings and other procedures such as
reading quota values and flushing out various caches. See PSS articles 159196, 314214 for more
information about setting maintenance schedules and overriding default schedules for some of
the maintenance tasks.
Restoring Exchange Server

The detailed Exchange Server 2003 Disaster Recovery Operations Guide (http://www.microsoft.com
/exchange/library) walks you through various scenarios of backing up and restoring Exchange
servers, the OS, domain controllers (DCs), and AD (if necessary).
In addition, you’ll learn how to determine which steps are necessary under various circum-
stances. For example, if the database becomes unavailable and you need to remount it, you probably
don’t need to format the drives and rebuild the server. The 139-page operations guide covers many
scenarios – and in each case indicates exactly how to restore access to the databases.
If you use the Backup Utility for Windows, consider the operations guide your blueprint for
success. If you use another vendor’s backup utility, consult the vendor’s documentation because the
procedures for restoring the Exchange environment as well as the OS will be different. In almost all
cases, a complete server failure will require that you install the OS on a spare server using the same
name and network settings.
You’ll need to update and patch the server and verify its settings. After you’ve patched the server,
you can install Exchange Server 2003 by using the /disaster recovery switch. The storage groups will
be added with the appropriate stores, but the databases will be empty.
After you mount the databases, you can dismount and restore them by using the backup
software. You can then replay the transactions. (These sentences are, of course, the abridged
version of the restoration process. You need to study, test, and document the actual process in your
environment.)
Regarding restoration, I want to briefly address practice, documentation, and change control.
As I mentioned previously, the technology isn’t as important as the process. Most critical is your
understanding of your backup software, the size and location of the backups, and the process of
restoring your server. In addition, you must verify your backups by implementing a regular
change-control process (e.g., once a month), so you can test your backups.
Recovery Storage Groups, which I discuss in detail later in this chapter, are great for single-item
restoration and validating backups because you can use them without affecting the live databases.
Recently, while performing a restore to a Recovery Storage Group, I discovered that the backup to
my server was corrupt. I changed the backup and tested a new one. You can imagine how glad I am
to have discovered the corruption before rather than after a failure.
Restoring Exchange from the Command Line

Traditionally, you use the command setup.exe /disasterrecovery to restore an Exchange server. This
tool now has a couple of additional, less invasive restoration options. In one case, I faced a situation
in which the registry on an Exchange Server 2003 machine had become damaged. Rather than trying
to recover the registry settings by restoring the System State from a backup, I launched the Exchange
Server 2003 Setup program with the /disasterrecovery switch to restore the registry only. In addition,
you can use the /disasterrecovery switch to restore only the bin folder should one of the files become
damaged or corrupt.
Backing Up the IIS Metabase

Those of you who run Exchange Server 2003 and support Active-Sync, Outlook Web Access (OWA),
Outlook Mobile Access (OMA), or RPC-over-HTTP will certainly appreciate all the work put into
configuring and tweaking the Microsoft IIS virtual directories and applications. The customization
that’s required to get these applications working correctly isn’t something you want to rebuild
manually – especially if, like me, you’ve included some custom configuration settings and redirects.
Fortunately, the configuration settings you use in Microsoft IIS (for Exchange and for other Web
applications) are stored in the Internet Information Services (IIS) metabase that you can back up and
restore.
To back up the metabase, use the Internet Services Manager (ISM) to select the server and
choose All Tasks, Configuration Backup/Restore. As Figure 7.4 shows, you can then create a new
backup of the metabase or restore from a previously saved one.
Figure 7.4
ISM Configuration Backup/Restore
IIS 6.0 automatically backs up the metabase when you make a change to the Web server. This
backup lets you recover quickly from a mistake or from a configuration change that doesn’t achieve
the desired effect.
While I’m on the subject, remember that IIS lets you quickly copy virtual directory settings from
one Web server to another. You can right-click an individual virtual directory or application and
choose All tasks, Save Configuration to file. From another Web server, select the option of creating a
new virtual directory from file and choose the file you saved in the previous process. All previous
settings for that virtual directory will be added to the target Web server. This process gives you an
effective means of “moving” OWA, OMA, and the RPC-over-HTTP and ActiveSync directories to
another Web site on the same server.
Restoring Mailboxes or Items

Recently, I reiterated to the Exchange team in Redmond that the backup utility should have more
granular options. Specifically, administrators don’t have a way to back up a single mailbox or mailbox
item with the default tools and standard API. Unfortunately, you must restore the entire database to
bring back one item. Few other mail systems suffer from this problem, but the capability to bring
back a single entity isn’t currently (nor has it ever been) available with Microsoft’s Exchange Server
product.
Fortunately, you can address this need for granular restoration several ways. I’ll start with the
simplest alternative for restoring the items, discuss new features, and then cover a couple of third-
party options.
Retaining Deleted Items

Outlook and OWA provide the tools necessary to protect your users from themselves. By default,
anything users delete with these clients is moved to the Deleted Items folder. This folder works much
the same way that the OS’s deletion function works: Items are categorized differently but not actually
deleted right away. Should you need to recover the items, you’re a right-click away from restoring the
items to their original location.
If users delete items and folders, then delete them from the Deleted Items folder, how can you
retrieve those deleted-deleted items? Unless you’ve specifically told the Exchange Server 2003 machine
how to handle deleted items, you’ll need to perform a restore to retrieve them.
However, if you want to avoid restoring a database just to retrieve a deleted email message, I
recommend changing the deletion settings on your Exchange stores right away. Use the ESM to open
the store properties. Change the Keep deleted items for (days) setting, which Figure 7.5 shows, to
something other than zero.
Figure 7.5
ESM Mailbox Store Properties
Because deleted items retention is a store setting, you must remember to change the setting for
each store on each server. However, be careful with this setting because even 1 day’s worth of
unsolicited mailbox items could amount to many megabytes or even gigabytes of storage. Start by
changing the setting to a couple of days, then increase the setting as needed to meet your goals.
j Tip
Savvy administrators often use the Keep deleted mailboxes for (days) setting to protect
themselves from administrative slipups. Should an administrator accidentally delete a mailbox
or an AD account (which in turn deletes a mailbox), this setting will save the mailbox in the
store for the number of days indicated. Administrators need only reassociate this mailbox with
an AD account to restore access – as long as they make the change within the specified
number of days.
Of course, you must be careful when you use the deleted items setting because it can cause your
Exchange stores to grow quickly. Periodically, you should use Performance Monitor and the Total
Size of Recoverable Items counter, which Figure 7.6 shows, to see how much of your store the deleted
items are using.
Figure 7.6
Performance Monitor’s Total Size of Recoverable Items counter
After you change the deleted items setting and collect deleted email messages, the end user must
manage the email. In Outlook, users can select the Deleted Items folder, then choose Tools, Recover
Deleted Items From to see a list of the items available for restoration. The user can choose whether to
permanently delete items or recover them, as Figure 7.7 shows.
Figure 7.7
Restoring Deleted Items in Outlook
Recovered items return to the Deleted Items folder – where users can read, forward, or move
them to another mail folder. With deleted item retention, it’s the end user’s responsibility to restore
individual items or folders. Users can restore Deleted Items by using the Outlook client or the new
OWA client.
Deploying Recovery Storage Groups

Microsoft added the Recovery Storage Group to Exchange Server 2003 and improved upon the new
feature with Service Pack 1 (SP1). Before Exchange Server 2003, an Exchange administrator had to
perform a full recovery of the database onto a lab server and export items first to PST files then to
the production server – just to restore a single email message.
Recovery Storage Groups let administrators restore a database on a production server without
affecting the original database or the restoration server. After you select the backup software’s
restoration option, the ensuing process places the restored database in a temporary storage group that
doesn’t affect the original database. The administrator can then copy the items or even mailboxes
from the restored database to the live database without affecting users.
To use a Recovery Storage Group, you must first use the ESM tools to create one. You can
right-click the server and add a new Recovery Storage Group, as Figure 7.8 shows.
Figure 7.8
Creating a Recovery Storage Group
You then right-click the new group and select Add Database to Recover to configure the storage
group for use with the database that contains the items you want to retrieve. To make sure the
database is in a clean shutdown state, mount it, accept the warning, and dismount the store. You
must set the database to permit the This Database can be overwritten by a restore option. Otherwise,
the data won’t be restored. (This option is turned off by default to protect the database during typical
operations.) You can then restore the database and mount it.
n Note You can use a Recovery Storage Group on Exchange Server 2003 Standard or Enterprise
editions.
You should delete Recovery Storage Groups when they’re not in use because backup programs
will automatically use them if they’re present. When you need to recover an individual item or
mailbox, create the Recovery Storage Group and associate a mailbox store with it.
To restore an individual item to an existing mailbox, use the ExMerge utility to connect to the
store in the Recovery Storage Group and export that item to a PST file. You can then use Outlook or
ExMerge to copy the item from a PST file back into the mailbox.
If you need to recover an entire mailbox, perhaps one that was deleted or orphaned, you can
use the new ESM tool – Mailbox Recovery Center – to restore it quickly. This tool is designed to
restore the entire mailbox, and it restores only mailboxes that have been deleted or orphaned. (Such
items, in fact, are the only ones the tool displays.)
Recovering Your Server with Recovery Storage Groups

Recovery Storage Groups also support instant server recovery. In the event of a catastrophic
Exchange failure, you can create an empty database to give end users instant access to outbound
and new email messages. Instead of a complete tape recovery, which can take hours, this type of
restoration is possible in minutes. While the users are connected and the new empty database is
online, you can use the Recovery Storage Group to restore the production database from tape. You
can then merge recovered items into the empty, live database throughout the day. The result is fast
access to email with older email messages trickling in throughout the day.
Restoring Mailboxes and Items with ExMerge

As I mentioned previously, ExMerge is a terrific tool that can help with many messaging concerns.
To begin with, ExMerge lets you export mailboxes and even export certain items within mailboxes.
Moreover, you can script ExMerge to export on a schedule. You use ExMerge through the Microsoft
Exchange Mailbox Merge Wizard, which Figure 7.9 shows.
Figure 7.9
Microsoft Exchange Mailbox Merge Wizard
ExMerge exports data to PST files, which can then be imported into another Exchange server or
simply archived for disaster-recovery purposes. Because ExMerge doesn’t operate as quickly as the
Exchange backup API, it isn’t a good alternative for backups. However, it’s an excellent tool to use to
capture specific mailboxes for a migration or as a second level of backup.
ExMerge is multithreaded and can perform mail exports at several gigabytes per hour. You can
run it from scripts and use it in batch files to perform daily backups of key mailboxes. The exported
data is contained in PST files that you can easily transport to other Exchange systems and Outlook
clients.
The best way to acquire ExMerge is to download the ExAllTools file from the Microsoft
download site for Exchange Server. Place the exmerge.exe and exmerge.ini files in the Exchsrve\Bin
folder – and you’re ready to transport mail!
Additional Exchange Recovery Techniques and Tools

Within the past few years, many vendors have worked to provide even more options for backing up
and restoring Exchange Servers. Some of the techniques, such as brick-level backups, have provided
marginal success. Newer tools, such as Ontrack’s PowerControls and Quest Software’s Aelita Recovery
Manager for Exchange can snap into most backup solutions to provide very granular recovery options
from standard backups.
Brick-Level Backups
In the past year, I saw a T-shirt that says, “Friends don’t let friends do brick-level backups.” I’ve used
and even recommended this technique for backing up Exchange Servers, but I wouldn’t wear such a
shirt – nor do I currently recommend brick-level backups (for several reasons). Let me explain.
By using brick-level backups, you can back up individual mailboxes rather than have to restore
an entire database. The technique is simple, but a little background will establish why I no longer
recommend this approach.
The brick-level backup technique evolved because of Exchange’s limitations. The API used to
back up an Exchange server does so at the database level, not at the mailbox level. Therefore, the
API doesn’t “understand” how to back up a single mailbox.
Third-party tool vendors have used the brick-level backup technique to add the option of
restoring single mailboxes. The tools add a function to their programs that let the backup process
connect to each mailbox individually. By bypassing the Exchange backup API and using a
Collaboration Data Objects (CDO) call to the store, backup applications can select specific mailboxes
to back up and restore. The tradeoff for this capability is twofold: added complexity and much slower
performance.
When you use brick-level backups, performance is definitely a concern. I’ve seen performance as
slow as 1GB per hour for brick-level backups. Because of the slow performance, many administrators
who were initially excited about the technique now use third-party agents to perform brick-level
backups for key mailboxes only instead of for every mailbox on the server.
j Tip
When you want to back up key mailboxes individually, ExMerge is probably much more cost-
effective and simpler to use and automate. (See the previous section “Restoring Mailboxes and
Items with ExMerge.”)
VSS
The Windows Server 2003 VSS lets you mirror a volume or set of files. VSS provides the means for
file versioning and restoring a volume shadow copy very quickly. This feature offers “out of the box”
support for files and user data, but to use VSS for Exchange Server 2003, you need to have much
more sophisticated hardware, such as a Storage Area Network (SAN) for the volume. You also need
to use more sophisticated backup software that can work with Exchange Server, the hardware, and
VSS. Hardware manufacturers Hewlett Packard (HP) and Dell provide turn-key solutions for
implementing VSS with Exchange Server 2003.
The complexity of VSS stems from its use of various services and processes to copy information
while data is live – and to do it without affecting end users. When the backup utility runs, it
instigates VSS to take a copy of the specific Exchange stores. Existing transactions complete and new
transactions are paused to temporarily “lock changes.”
At this point, VSS can update or create the shadow copy. After the update or copy is complete,
transactions can commence and the stores are returned to their usual state. During this cycle, the
Exchange stores can become unresponsive and updates cause the hourglass to appear until the
transactions can begin again. Outlook 2003 in Cached Exchange mode can mitigate these drawbacks,
but other clients will certainly be affected.
As support for other devices continues to grow, I expect that VSS will be supported on much
less expensive hardware, such as NAS devices that use iSCSI. The next year should be exciting as VSS
for Exchange becomes available to smaller Exchange organizations.
Third-Party Recovery Tools

I’ve learned over the years that Exchange’s native backup is pretty good the way it is. The
performance is adequate and rather simple to automate. It’s the recovery that’s the challenge. For
example, even with Recovery Storage Groups, you must restore the entire database just to bring back
a single item. Moreover, you must make sure that the backup program you use is compatible with
Recovery Storage Groups.
Quest Software and Ontrack have developed the two most capable third-party tools I’m aware of.
A few years ago, Ontrack developed a tool that let an administrator mount an offline EDB file and
extract the contents to PST files or send the items directly to an Exchange Server – any Exchange
server. With this tool, you could often mount even databases that appeared corrupt and extract their
contents. I was dumbfounded by such power. I’ve recommended the tool for years as an alternate
recovery method – and, in some cases, as the only way to extract data from corrupt databases.
Quest Software has taken the idea of granular recovery and added support for various backup
formats and media. In other words, the administrator has the ability to open a backup of an
Exchange Server and extract the information needed to restore individual items or an entire mailbox.
The benefits of this new technique surpass any other option I’ve seen for restoring an Exchange item.
Whereas before you had to have an offline store, Quest Software’s Aelita Recovery Manager for
Exchange can connect to backups, mount them, and extract their contents to the live database
without disrupting connected users. In addition, Aelita Recovery Manager for Exchange can search
both email messages and attachments stored within your backup tapes (the Ontrack solution can
only search within email messages). Aelita Recovery Manager for Exchange supports
• Windows backup
• Veritas BackupExec for Windows Servers and NetBackup
• Legato Networker
• HP OpenView Storage Data Protector
• Computer Associates (CA) BrightStor ARCserve Backup and Enterprise Backup
• IBM Tivoli Storage Manager
The type of recovery that Aelita Recovery Manager for Exchange provides doesn’t require the use
of Recovery Storage Groups, transaction logs, or ESM. You don’t need to change your current backup
routine, and the software is compatible with Exchange 2003, Exchange 2000, and Exchange 5.5. Aelita
Recovery Manager for Exchange is also compatible for use with Recovery Storage Groups (instead of
using ExMerge), and it supports snapshots from VSS.
Backup and Archival Policies

Many companies have decided to limit the scope of their backups to recovery procedures only,
similar to the way many companies back up their voicemail systems. In some companies, the legal
department might decide that email messages shouldn’t be archived. Tapes that back up mail stores
are overwritten every 2 weeks. Tapes that back up the mail server configuration and directory data
are archived in the same manner as file servers.
In any case, before you develop an extensive backup design, you should consult your legal
team. I’m not qualified to answer legal questions surrounding email message backup and archiving,
and interpretations of both privacy laws and protection for publicly traded companies can differ.
Publicly held companies face strict compliance regulations. Other companies’ legal teams insist
that their companies not back up email messages. (The theory is that having backups could invite
subpoenas.) Also, many companies are moving forward with policies that automatically purge email
messages after the email messages reach a certain age.
Mailbox Manager
Controlling the size of mailboxes is a hot topic for most Exchange administrators. Setting mailbox
limits will certainly keep the mailboxes below a certain size, but the responsibility for managing the
items must fall on the mailbox owner. The company email policy should state the mailbox-size limits
and offer any instructions that users need to properly manage their mailboxes.
Available since Exchange 5.5, Mailbox Manager offers a centralized way to automate deleting and
archiving items. Enabling and scheduling mailbox management occurs at the server level.
The ESM lets you determine how often the management program runs on a specific server and
what action the program takes when email messages are too old, too large, or both. You determine
the schedule, the frequency, and the reporting of the mailbox management process for each server
through the server’s Properties, which Figure 7.10 shows.
Figure 7.10
Mailbox management process
n Note You can choose to send a summary report to the mailbox owner or to the administrator.
In the recipient policies for the organization, you can define the rules that the program uses to
determine how the mailbox management process checks email messages. You use the ESM to create
Mailbox Manager recipient policies as email recipient policies. When you first create a policy, I rec-
ommend that you use the Generate report only option, which Figure 7.11 shows, to see what would
be deleted or moved.
Figure 7.11
Mailbox Manager Settings (Policy)
In this example, I’ve selected the default options that limit to 30 days the age of items whose size
is greater than 1024KB. You can be selective with this policy by changing the types of items, size,
and age independently. After you’ve properly “tweaked” the size/data formula, you can be more
aggressive in handling items that match your criteria.
Keeping Up with Exchange

As I mentioned previously, the most important aspect of backup and recovery isn’t the tools
themselves but your understanding of the process and the tools. If left unattended, an automated
backup process can fail or produce corrupt backups. Moreover, a backup is of limited value if no
one understands the recovery process. You must understand the options and develop a formal,
well-documented process that includes regular testing of the backups and test recoveries. If you set
up and follow through upon tasks involved, you’ll keep your Exchange system healthy and protect
its data.
Next: Security Auditing and Logging

In the final chapter of The Expert’s Guide for Exchange 2003, I’ll examine securing the Exchange
environment. In the past, Microsoft has chosen functionality over security, but times have changed –
and so has the company’s position regarding security. Systems are now secure by default, but that in
of itself doesn’t eliminate security threats to and vulnerabilities within the system. I’ll explore the
procedures you need to have in place and the Microsoft tools you can use to address security
concerns. Excellent third-party tools also support Exchange security.
I’ll list specific procedures for securing your environment and prioritize them based upon current
security threats. I’ll cover topics that include securing account identity, securing the message stream,
and securing the email message itself. Moreover, I’ll discuss strategies for protecting your Exchange
environment from unsolicited email messages (UCEs) and dangerous attachments. You must fight on
both of these fronts to protect your Exchange environment and support network stability within the
intranet.
You must have good monitoring procedures in place to watch for suspicious behavior and
reduce the effects of a system error by predicting problems in advance. I’ll review the new Exchange
Server message-tracking tools that let you monitor and trace SMTP email messages in addition to
email messages within the system. These tools and others can help you monitor queues and verify
email message routing. I’ll discuss Microsoft Operations Manager (MOM) in detail and show you ways
to monitor and manage your environment by using custom-built tools that leverage Windows
Management Instrumentation (WMI) and the Exchange APIs.
142
Chapter 8:
Exchange Security
Welcome to the final chapter of The Expert’s Guide for Exchange 2003. I’ll complete this book with
probably the most important topic for today’s Microsoft Exchange administrator (except for disaster
recovery): security. I’ve designed this chapter to provide the information you need to protect your
Exchange environment from malicious attacks and security breaches – and to offer some ideas and
strategies that can help you secure your environment before vulnerabilities become problems.
My goal is to discuss potential security concerns – along with solutions that design or redesign
your Exchange environment to protect your company’s assets. Exchange security is a large topic that
many books and white papers address. Although space limitations keep me from covering overall OS
hardening strategies and detailed scenarios for every situation, I’ll discuss some of the major expo-
sures of unsecured systems. I’ll then cover five key areas, illustrating approaches you can take and
offering configurations you can use to secure your Exchange system.
I’ll first address reducing the number of protocols you use, then cover how to partition your
environment to significantly reduce your exposure. I’ll discuss how to protect authentication
credentials and control protocol access. Next, I’ll consider ways to secure data transmission for
privacy and data integrity. Finally, I’ll review the essential tasks of locking down your servers and
dealing with harmful email messages (e.g., unsolicited email messages, email messages infected with
harmful attachments). All of these strategies will help protect your environment as you face the
challenge of balancing access and security.
Over the years, various vendors, other authors, and I have collected most of the information and
many of the tips you’ll find in this chapter. Some of the information comes directly from Microsoft
books and white papers. I especially recommend two Microsoft white papers, one specifically about
Secure MIME (S/MIME) – Quick Start Guide for S/MIME in Exchange Server 2003 – and the other
about securing Exchange Server 2003 through security policies – Exchange Server 2003 Security
Hardening Guide. I also recommend Paul Robichaux’s books Secure Messaging with Microsoft
Exchange Server 2003 and Secure Messaging with Microsoft Exchange Server 2000. You should also
review the following Microsoft white papers about Exchange security:
• Exchange Server 2003 Message Security Guide
• Slowing and Stopping E-Mail Transmitted Viruses in an Exchange 2003 Environment
• Exchange Server 2003 Transport and Routing Guide
You can reach many of these and related documents through http://www.microsoft.com/technet
/prodtechnol/exchange/2003/library/default.mspx. You’ll find that each of the white papers listed is
very specific in nature. I’ll use this chapter to paint a larger security picture on a broader canvas.
Chapter 8 Exchange Security 143
Identifying Security Problems

As you know, security threats are real and the results of successful attacks can be catastrophic.
Keeping your environment secure is an ongoing process that requires time, effort, and current
knowledge about tools and risks. Few businesses assign much time or money for security until it’s
too late and a productivity outage occurs.
Companies that have started a security program should understand that help is available and
that administrators can ask for it when needed. For example, you should check out the Microsoft
newsgroups. You can watch the posts for security concerns and updates and submit your questions.
In addition, check the Microsoft Exchange Web site and the Microsoft Security Web site for update
notifications and alerts.
• http://www.microsoft.com/security
• http://www.microsoft.com/exchange/techinfo/security
• http://www.microsoft.com/exchange/library
Many security threats and concerns can affect your messaging environment’s stability and your
users’ productivity. Any of you who’ve watched the logs on your company’s firewall or even at home
understand what’s out there. The Internet has always been risky for unprotected systems, but now it’s
lethal – and the days of dual-homing an Exchange server on an unprotected link are gone.
Doing so would expose your systems to port sniffers, Denial of Service (DoS) attacks, Internet
Control Message Protocol (ICMP) and Universal Database (UDB) flood and SYN attacks, and address
spoofing. To make matters worse, even if you’re protected by a good firewall, you’ll need to put
processes in place to protect your systems from virus outbreaks, spam, beacons, phishers, and
unauthorized access – as well as from new attacks and vulnerabilities. Lastly, you’ll need to figure out
what to do about security for offline folder store (OST) and personal folder store (PST) files on
mobile equipment, telephones, and PDAs.
Reducing Functionality
As simple as the concept of reducing functionality is, administrators rarely implement this approach.
In some cases, software vendors don’t encourage the reduction. The trend has been to increase
access and to provide more connection options for users. The truth is that increased access and
functionality is counterproductive for security. Reducing functionality reduces exposure.
You need to list your organization’s specific connectivity requirements and make an effort to
reduce the number of protocols you use. By disabling unused protocols, you can dramatically
reduce your exposure to various types of attacks and vulnerabilities. New Exchange Server 2003
environments are more secure than upgraded systems (the same is true for new OSs as well) because
environments inherit protocol settings during upgrade processes. If you upgrade from Exchange 2000
or Exchange 5.5, you should pay particular attention to this section of the chapter.
Let’s start with a couple of simple questions: Can you limit your Internet access to HTTP Secure
(HTTPS)? Can your company can get away with a single port for remote and Internet access to email?
I ask because you can now use HTTPS over TCP (port 443) for online access and offline synchro-
nization of email. Microsoft also has improved Outlook Web Access (OWA), which now offers
compression features, notifications, and encryption, as well as junk-email management.
Moreover, you can use a single secured configuration for all communications to your environ-
ment and run all HTTPS packets through a reverse-proxy server or a router that uses stateful packet
inspection. With HTTPS, you have multiple access methods – including OWA, Outlook with RPC-
over-HTTP, Outlook Mobile Access (OMA), and synchronization (e.g., ActiveSync) with PDAs. The
result is a much simpler design that uses fewer protocols and is therefore easier to monitor and
troubleshoot. Moreover, when you put such a system into place behind equipment and software that
performs stateful packet inspection, you can better monitor and track access. You require a total of
just two inbound ports for mail: port 443 for HTTPS and port 25 for SMTP.
Segregating Your Network

Let me discuss Internet connectivity a little further. One point about security that I’ll emphasize is that
you never want to allow any type of connection directly to your production servers. Instead, layer
your communications and segregate traffic wherever you can.
For example, Microsoft Internet Security and Acceleration (ISA) Server and Novell’s
BorderManager products can act as buffers between the Internet and your mailbox or front-end
Exchange servers. Other reverse-proxy servers – including open-source servers and hardware
appliances – can provide screening, monitoring, forwarding, and proxy services for inbound requests.
In addition, outsourcing companies such as Postini and MessageLabs can accept email messages on
your behalf, clean them, then forward them to your servers. You can set up basic IP rules from your
environment to accept email messages from the email processing company only. No more Directory
Harvest Attacks (DHAs) or port scans on port 25. No more worries about mail relays or sacrificial
servers placed to process inbound SMTP messages. Of course, those services have a price, but I’m
sure you get my point: Protection from the Internet means no direct communications.
Exchange front-end servers are great for providing a single namespace for your environment. If
you have five mailbox servers and you want to channel all of your HTTP, SMTP, and POP traffic to a
single server or use a single namespace such as Email.company.com, you need a front-end server to
proxy your requests. (Keep in mind, however, that a front-end server offers little in the way of
security and nothing at all for Outlook clients.)
Some companies I’ve worked with allow connectivity only through VPNs. VPNs offer security in
that they’re usually proprietary and require specialized client software. Unless you link your VPN
solution to Active Directory (AD) or manage it carefully with complex passwords and localized key
devices such as smart cards or SecurID, terminated employees could potentially continue to connect
and gain access to systems. Moreover, you shouldn’t introduce unprotected remote systems into the
production environment without careful consideration of virus signature updates and OS patch
updates. VPNs for Exchange email alone probably aren’t the best solution for your network or for
security.
Instead, consider a layered path into your network, such as the path Figure 8.1 shows. It includes
an intelligent firewall system such as Microsoft’s ISA server to detect suspicious network traffic before
it hits your Exchange environment.
Figure 8.1
Layered path into the network
Por Exchange
t 11 Inva
0 comlid HT
Server 2003
man TP
ds
Port 443
Port 25
Internet
21 TP
OWA users Port SM
lid ands
va
In omm
c Exchange Server
Outer firewall Reverse-proxy Inner firewall 2003 performs the
blocks unwanted server accepts and accepts the authentication and
Internet SMTP traffic bridges SSL bridged, accepts or declines
Servers sessions and drops SSL sessions the session
invalid commands
You have several choices for stateful inspection tools, including Microsoft ISA Server and tools
from CheckPoint Software Technologies, Cisco Systems, and Novell. These tools can detect suspicious
or malformed packets and drop sessions before any communication with the Exchange environment
begins.
You can add a layer between the Internet and the production servers in several ways. Unless you
have more than one mailbox server, the border server in the DMZ can communicate directly with
Exchange Server 2003. Otherwise, the border server must communicate with an Exchange Server
2003 front-end server, as Figure 8.2 shows.
Figure 8.2
Deploying an Exchange Server 2003 front-end server Exchange
Mailbox servers
Exchange
Mailbox servers
Por Inva
t 11
0 comlid HT
man TP
ds
Port 443
Port 25
Internet
21 TP
OWA users Port SM
lid ands
va
In omm Exchange Server 2003
c
Outer firewall Reverse-proxy Inner firewall front-end servers
blocks unwanted servers accepts and accepts the Exchange Server
Internet SMTP traffic bridges SSL bridged, 2003 performs the
Servers sessions and drops SSL sessions authentication and
invalid commands accepts or declines
the session
If you have multiple internal servers, you’ll need to take advantage of at least one Exchange
Server 2003 front-end server to handle and proxy the requests to the appropriate back-end or
mailbox server.
For each of the protocols you must allow from the Internet, you’ll need a border device or server
to handle the traffic. If you need to allow POP, IMAP, SMTP, and HTTP, you might need to establish
multiple border servers or a firewall that can intelligently monitor each of the protocol streams for
improper traffic. Moreover, the solution you put into place must be able to drop the session and
handle floods, port scans, and other attacks. If you can reduce your communications protocols to
HTML only, you have more options because more devices are available to screen mail and proxy
HTML requests.
Exchange Server Edge Services

One of the strengths and limitations of Exchange Server is its reliance on AD. And SMTP traffic
particularly relies on AD. With Exchange 2003, Exchange 2000, and Exchange 5.5, Exchange servers
(even front-end servers) must have a stable, reliable connection to the Directory Service (DS). Placing
an Exchange server in the DMZ to handle inbound mail flow is both risky and tricky because you
must establish direct access to AD from devices in your DMZ.
For inbound SMTP traffic, many companies currently use Message Transfer Agent (MTA) products
(e.g., Sendmail, Qmail) and antivirus screening products (e.g., from Symantec, McAfee) to shield
Exchange. Many diehard Exchange shops I work with implement fault-tolerant Sendmail servers in
the DMZ to collect, scan, and forward email messages into their environment, as Figure 8.3 shows.
Microsoft is currently developing an edge product to bring some AD routing and logic into the DMZ
– without exposing your production Exchange systems and AD.
Figure 8.3
Deploying edge devices and services
Port 25
Exchange
Outer firewall Microsoft Exchange Inner firewall Server 2003
Internet SMTP blocks unwanted Edge Services accepts the
Servers traffic bridged,
SSL sessions
A copy or subset of the AD allows the

Edge Device to: AD DC
Perform Recipient Filtering
Spam Confidence Level Tagging
Specialized SMTP Routing
n Note Microsoft Exchange Server Edge Services, expected in 2005, will provide autonomy and
intelligence in the DMZ for inbound email message routing. The product will let you place a
specialized server in the DMZ that’s designed specifically to handle email protection, email
security, and email message hygiene. The server will be limited to SMTP email message
handling, but it will hold enough logic and controls to use antivirus and antispam technologies
to screen email messages and process routing rules. It will handle any necessary relaying,
address rewrites, masquerading, and format conversion. Microsoft Exchange Server Edge
Services will be a limited function server with all the SMTP tools and not much more.
Securing Authentication and Controlling Protocol Access

After you’ve defined the protocols and network path, you must secure the transmission of
authentication information. Although most administrators understand the reasons for adding a Secure
Sockets Layer (SSL) certificate to the OWA server, few implement similar protection for POP, IMAP,
and SMTP relay functions. In this section, I’ll show exactly what’s transmitted over the wire when
various clients authenticate to collect email messages. Moreover, I’ll show you various methods you
can use to enforce security – including Microsoft IIS virtual directory settings and IP restrictions – and
how to protect your SMTP traffic between domains. I’ll also cover the Outlook Web Access Web
Administration utility and the specific security settings available that reduce the risk of OWA access
through kiosks and remote systems.
j Tip
To download the Outlook Web Access Web Administration utility, go to
http://www.microsoft.com/downloads/details.aspx?familyid=4bbe7065-a04e-43ca-8220-
859212411e10&displaylang=en.
Let’s examine a typical OWA authentication stream without SSL that someone collected by using
a basic protocol analyzer (i.e., a sniffer).
GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=5606&STRMVER=4&CAPREQ=0 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 10.10.10.1
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Basic c3RldmU6Q29NcExlWFBhU3NXb1JkIQ==
The authorization string base64 decodes to steve:CoMpLeXPaSsWoRd, which clearly

identifies the username and password. If you’ve read about OWA security, you know that you should
always use SSL with Basic authentication. Because Basic authentication uses no hash, the user’s
credentials are encoded with base64, then sent over the wire. Most sniffer programs can collect these
authentication packets and most can also trigger on the word authenticate or negotiate to collect only
those packets that contain logon information. In addition, the email message itself is sent as clear text
with the HTML stream:
Steve, </FONT></DIV><DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV><DIV
Just to let you know...you have the job! Don’t tell
dir=ltr><FONT face=Arial size=2>J
anyone.</FONT></DIV><DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV><DIV
Steve</FONT>
dir=ltr><FONT face=Arial size=2>-S
The first thing you need to do is change the method IIS uses to authenticate the session. Open
the IIS virtual directories for Exchange and check two directories. Both the Exchange directory and
the public virtual directory must be set to permit Integrated Windows authentication (unless your
servers are front-end servers, in which case Basic authentication is the only method available). You
should also make sure that you disable Anonymous access. You shouldn’t use Basic authentication
unless Integrated Windows authentication experiences problems with some browsers – or you’ve
configured your servers to function as front-end servers.
Use the IIS Manager console to set these virtual directories. With Exchange 2000, you made the
changes in Exchange System Manager (ESM), but now you make them in IIS.
Integrated Windows authentication better protects passwords by hashing them before encoding.
Passwords are then sent in a secured manner. When you enable both Integrated Windows and Basic
authentication, as Figure 8.4 shows, Basic will be used only if Integrated fails.
Figure 8.4
IIS Authentication Methods screen
While you have the virtual directory Property screens available, enable the ability to force the use
of SSL for OWA sessions. You can reach the operative screen only after you’ve installed a certificate
on the Web site. If you haven’t yet installed the certificate, use the IIS tools to create a certificate
request. Be sure to get the certificate from a registered trusted authority, especially if you plan to use
smart phones or synchronize PDAs with Exchange Server 2003. (Smart phones and PDAs often lack
the ability to trust a CA.)
Requiring SSL use for OWA sessions, which Figure 8.5 shows, is a clever way to ensure that you
don’t permit password transmission without some type of encryption or protection. Although this
approach can help protect the HTML data stream, it isn’t the correct procedure to protect the SMTP
data, as I’ll discuss later in the chapter.
Figure 8.5
Requiring SSL for OWA sessions
Finally, to better protect the OWA session, you can now use forms-based authentication.
You can enable this option by using the ESM to modify the HTTP Virtual Server properties to gain
the following benefits:
• You can define whether and how cookies are used.
• You can use compression options.
• You can time out a session.
• You can use logon with user principle name (UPN).
Pop and IMAP

OK, now that I’ve addressed the HTML environment, let’s look at other protocols. POP is by far the
worst: The username and password are sent in clear text and no encoding takes place. (Of course,
you need to remember that POP is 20 years old. ) If you can get rid of anything, get rid of POP and
disable the protocol.
IMAP isn’t much better in respect to security. If you must use either protocol, force it to use a
secured channel. You can set the secure channel requirement in the ESM under the Protocols menu
for each server, as Figure 8.6 shows. You must first install a certificate on the server.
Figure 8.6
Requiring a secure channel for POP and IMAP sessions
j Tip
Requiring SSL for both POP and IMAP is the only way to protect passwords and data during
transmission.
For Internet access, run the secured POP and IMAP ports through an intelligent firewall (i.e., a
firewall that understands stateful packet inspection), then into your Exchange environment. If you
permit use of the standard ports, make sure your firewall allows port 993 for IMAP (SSL) and 995 for
POP3 (SSL). You’ll need to configure the clients to use these ports and SSL to communicate with your
servers.
SMTP Security
I’ll discuss two security issues relative to SMTP. The first is authentication. If you have POP and/or
IMAP users, you’re probably letting your servers relay outbound email messages on behalf of those
users. Antispam doctrine insists that you not let servers relay. Therefore, many administrators allow
relays only if a user authenticates. This approach, however, creates a new problem in that the
credentials passed probably aren’t encrypted, as the following data stream indicates.
EHLO bryant1
AUTH LOGIN
ZG9tYWlubmFtZVxtaWtl
UGFTc1dvUmQh
MAIL FROM: <mike@windowsitpro.com>
RCPT TO: <sbryant@windowsitpro.com>
DATA
QUIT
In this data stream, the lines under AUTH LOGON base64 decode to domainname\mike and the
password: PaSsWoRd! If you take this approach to protecting your environment against relays, you
jeopardize the usernames and passwords of your POP and IMAP users. (If these past few paragraphs
haven’t dissuaded you from permitting those protocols, I’ll be truly surprised.)
Outlook Express (or just about any POP client) supports the use of secured channels for SMTP
traffic. You don’t need to open any additional ports to use secured channels, but you must create a
new SMTP virtual server to force the setting. An excellent article, “How to Protect SMTP Communica-
tion by Using the Transport Layer Security Protocol in Exchange Server,” at
http://support.microsoft.com/default.aspx?scid=kb;en-us;829721&product=exch2003, explains the pro-
cess in detail. In short, the steps of the process are as follows:
1. Add another IP address to the server’s network adapter card.
2. Create a new SMTP virtual server.
3. Configure IP access restrictions if possible.
4. Configure access control to require authentication.
5. Configure the security setting of the virtual server to require secured channels.
6. Configure the relay settings as needed.
7. Configure a DNS name for the virtual server.
8. Point the POP and IMAP clients to the new server and configure them to use SSL.
You should create a new SMTP virtual server, using a different IP address and DNS name,
specifically for the clients to talk to. Don’t require SSL on your default SMTP virtual servers or you
probably won’t send or receive many email messages. Few SMTP servers on the Internet are
configured to use or allow SSL – and fewer still require it. Also, don’t require authentication to your
default SMTP virtual servers – or you won’t receive Internet email messages.
Finally, don’t require that clients authenticate to your SMTP servers unless you’ve added a certifi-
cate to the virtual server and configured the clients to require SSL. Otherwise, they’ll be sending their
usernames and passwords over the wire. Should a spammer intercept these credentials, you’ll become
the equivalent of an open relay.
Securing the Data Stream and the Message

Because I’ve been discussing the SMTP, I’ll consider it first in this section. SMTP email messages
aren’t secure, not by a long shot. The first thing you know about Internet email messages (i.e., SMTP
email messages) is that the email message information is sent as clear text, as is the subject line and
the sender and receiver information. Any and all information sent through standard SMTP connectors
(in any email system) not specifically designed to use SSL (from both servers) will be sent as clear
text. Expense reports, meeting notes, application information, and medical records are just a few of
the things that someone can detect, intercept, read, and redistribute without your knowledge. In fact,
I bet that those activities are taking place right now for many of you.
So let’s review what it takes to lockdown such activity. In the previous section, I discussed how
to enable SSL for SMTP virtual servers. However, just because your SMTP virtual connector has an SSL
certificate installed, the server doesn’t necessarily use it for outbound mail. That is, even if the
installed certificate is used to receive inbound secured mail, having the certificate doesn’t mean that
you’re sending secure outbound mail. Because the sending server must force a secured session, you
need to focus your efforts there to ensure that email messages are transported securely to the target
servers.
Microsoft Exchange Server supports the use of Transport Layer Security (TLS) as prescribed in
Request for Comments (RFC) 3207 and its predecessor, RFC 2487. The benefit of this support is that
all other mail systems that follow these RFCs can communicate over TLS and thus provide greater
security for message transport. The RFCs define how the starttls verb is used and at which point the
communication is encrypted.
You should understand, however, that TLS doesn’t offer an end-to-end solution. The email
message itself isn’t encrypted – only the communications channel between the two SMTP MTAs is
encrypted. TLS encrypts both the authentication and the transport of the email message for your
SMTP clients who need to relay and for SMTP email messages sent to and received from other
servers and domains when you need a higher level of security.
The TLS RFCs discourage several practices, including requiring TLS on your SMTP transport stack.
Exchange Server 2003 lets you force TLS on the SMTP virtual server, but you shouldn’t do so. If you
do, you can communicate only with servers that
• are configured to use TLS
• accept your certificate
• use a certificate that your server recognizes
• can establish a secured channel with your server
To secure the communications between your company and another, you need to first make sure
the receiving server can accept the secured channel. If you follow the recommendations I discussed
previously (for securing the message relay by allowing authentication and adding a certificate to
encrypt the session), you’ll already have a certificate installed on your SMTP virtual servers.
To see whether your company or your partner companies have implemented TLS on their SMTP
servers, telnet to the servers over port 25 and issue a starttls command after ehlo or helo. (This
check works for your servers as well.) If you can’t establish a connection, you might want to call the
administrator at the other company to see whether the company is set up to use SSL over SMTP.
Because the RFCs list only a few replies, the answer you get should be yes or no, as in the two
examples that follow. In the first case, the reply is negative, and in the second case, affirmative.
ehlo
250-message1.ProExchange.com Hello [10.10.10.35]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
starttls
554 5.7.3 Unable to initialize security subsystem
ehlo
250-email.theproexchange.com Hello [10.10.10.35]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50 250 OK
starttls
220 2.0.0 SMTP server ready
After you know that you can establish a secured channel with the target domain, you must create
a connector in Exchange to use SSL. You can use Exchange Server 2003 ESM to create a new SMTP
connector for specific domains or email addresses. Use the Address Space tab on the connector’s
Properties pages to select the domains that should require TLS. You can then use the Advanced tab
to configure outbound security to require TLS encryption, as Figure 8.7 shows.
Figure 8.7
Configuring outbound security to require TLS encryption
Fortunately, you can use the same connector to identify all domains that should use SSL. You
need only add subsequent domains to the Address Space tab.
After you’ve selected the correct settings, you should be ready to test the transport. Be sure to
increase logging on the SMTP virtual server to monitor communications.
Securing the Email Message

Although SSL helps to protect authentication and email message transport, it does nothing to protect
the email message itself. For end-to-end security and data integrity, you need to scramble (encrypt)
email messages from the senders’ machines and unscramble (decrypt) them for readers on their
machines. Moreover, the data must remain scrambled not just during transport but also during storage
of the email message.
Scrambling the email message is important when you need to protect information from access
by others, even by network administrators. Moreover, you need to put a mechanism into place that
lets users validate the author of a particular email message. How can you know whether the email
message you received really came from the person identified in the email message?
The answer lies in encryption and the use of keys to protect the data. In this section, I’ll cover
the options for email message encryption and digital signatures, discuss how to choose a method,
and along the way, offer some insight as to the types of CAs from which you can choose.
Encryption
Several methods of encryption are available for Outlook (and other applications). Most are based on
the notion of public/private encryption keys. Microsoft Certificate Services supports this configuration,
which is called public key infrastructure (PKI). The private key is protected and kept on the user’s
computer or a secured data card. The public key is distributed to others and in most cases published
to the Global Address List (GAL).
Microsoft chose the PKI approach for many reasons, including scalability and improved security.
PKI works well with AD and can support deploying smart cards for authentication, encrypting files,
and signing and encrypting email messages. PKI is flexible in that it also supports IP Security (IPSec)
security, code signing, and even Web-server authentication. Before you decide on a CA or structure,
you should first take your total requirements into consideration – given that certificates have uses
beyond email messages.
Let’s run through a scenario from the beginning. Your company decides that you need the ability
to send and receive encrypted email from partners and other companies. (The implication is that
these entities must know and trust the CA that issues the certificates or some confusion will ensue.)
Authority trusts exist to “link” CAs together in one harmonious environment, but because of the
security implications, this type of communication usually dictates that users’ get their certificates from
VeriSign, Thawte, or another recognized issuer of CAs. After entities receive certificates, they can
install the certificates into any Windows XP or Windows 2000 machine. Doing so lets Outlook and
OWA recognize and use the certificates.
Does completing this process mean that you can now send encrypted email messages? Not really,
because the most important component is missing. To encrypt an email message to a specific person,
you must use that person’s public key to encode the message.
As I mentioned earlier, in this scenario, each user has two keys: The private key is protected and
the public key isn’t (at least not as much). If you want someone to send you an email message that
only you (and your private key) can open, that person must use a subset of your private key to
encrypt the email message. After the sender does so, only your private key has the proper algorithm
to decrypt the email message. Cool, right?
The problem with this design is that you need to get your key to the sender. If you’re all in the
same AD and Microsoft Certificate Servers are involved, the recipient’s key is in the GAL. If certificates
aren’t published in the GAL, you must find a way to share your public key with those who want to
send you encrypted email messages. The easiest way to share the key is to digitally sign the email
message.
Digital Signing
Digital signing is different from encryption in that the email message is sent with your public
certificate as an attachment. Technically, the email message is still encrypted, but the encryption is
performed in a different order and isn’t really secure. Let me explain.
When you sign an email message, it’s encrypted (behind the scenes) with your private key, using
information from your public key. Your public key is sent with the email message so the reader can
open the email message directly. Why? Because the information needed to decrypt the email message
is contained within the public key. As a result, recipients get a copy of your public key and can
associate your name, email address, and that key in their address book. After you’re in their address
book, senders can use your private key to encrypt an email message. Although this information
sounds complicated, the process of signing an email message, for which Figure 8.8 shows the
Security Properties screen, is actually fairly simple (and not something that you’ll need to worry about
very often).
Figure 8.8
Adding a digital signature to a an email message
After you install a certificate on the Outlook client, you can add a digital signature as easily as
you can request a delivery receipt. Sending an encrypted email message is just as easy, but you need
the recipient’s public key to encrypt the message “for their eyes only.”
Opening an encrypted or digitally signed email message involves little fanfare. In Outlook, the
recipient simply sees an icon that indicates the email message is encrypted or identifies an attachment
as a digital signature. Other email clients will acknowledge the email message differently, but the
work that goes on “under the covers” is the same. For example, the same features are available in
OWA and Lotus Notes though the menu choices differ. The process works well because the
mechanisms for secured Internet email messaging are defined in the S/MIME RFCs – and most
messaging vendors, including Microsoft, follow them closely.
Securing Servers and Dealing with Harmful Email Messages

Although Microsoft designed Windows Server 2003 to have fewer security vulnerabilities than
previous OSs, you must still plug some holes. I’ll cover tools available from Microsoft to detect weak
spots on your server and third-party tools you can use to perform more thorough scans. In addition
to discussing securing your messaging servers, I’ll cover methods for maintaining patches on the
system.
Patch management plays an increasingly important role in the security of corporate networks,
particularly for network OSs. Firewalls, mail servers, database servers, desktops, and Web servers
from all major vendors are regularly patched to protect the systems from newly created or discovered
exploits and to provide additional stability through code improvements. Microsoft and Sun are leading
the race to automate these updates by providing a Web-based mechanism to identify and download
the most critical patches automatically to close potential exploits before they’re exposed.
Automating patch application, particularly for critical security patches, is increasingly important
because the “time to exploit” is decreasing rapidly. The patch that closed the Nimda exploit was
available 331 days before the outbreak occurred. The patches that stopped the SQL Slammer and
Nachi exploits were available more than 150 days before the viruses were released. With the more
recent Blaster worm, the time to exploit was roughly 30 days. You can see that it’s increasingly
important to apply updates as soon as they’re available and ensure complete deployment across the
enterprise.
MBSA
The first thing that you need to do after installing and configuring a server is scan it for known
vulnerabilities. Microsoft has updated its Microsoft Baseline Security Analyzer (MBSA) to include
support for Windows 2003 as well as support for previous OSs. Actually, MBSA can run on almost
any current Microsoft OS. With just a few clicks, you can run MBSA against a single computer, an
entire domain, or a range of IP addresses. A central scanning machine can process up to 10,000
machines at a time. The IP scanning option works quite well because MBSA will ignore all non-
Windows–based machines within the range. Administrator access is required, so be sure to run MBSA
as a domain administrator or as another account that has local administrative permissions on the
desktops and servers.
MBSA runs many Windows, IIS, Microsoft SQL Server, and desktop checks and places the results
in a report. MSBA checks an impressive list of options and settings, including Administrators Group
Membership, auditing settings, Auto Logon, Automatic Updates settings, unnecessary services, whether
the machine is a domain controller (DC), Guest Account status, file system types, Internet Connection
Firewall (ICF) settings, and Local Account Passwords (e.g., blank, matching user names). MBSA
notifies you about any disabled or currently locked out accounts.
For IIS, MBSA identifies scripts virtual directories, IIS logging options, the IISADMPWD virtual
directory, and IIS installations on DCs. MBSA also catalogs parent paths and inventories unnecessary
services. MBSA ships with a services.txt file containing a list of services that are often installed, but
seldom used – including FTP, Telnet, the World Wide Web (WWW) Publishing Service, and SMTP.
SQL checks are equally intense. MBSA scrutinizes the security mode and local account passwords
and the roles. MBSA runs even more checks against the OS and Internet Explorer (IE) for patches,
Microsoft Data Access Components (MDAC), Exchange Server, Microsoft SNA (Systems Network
Architecture) Server, Content Manager, Microsoft Office, Microsoft BizTalk Server 2000, and many
other applications. In fact, running MSBA in your environment should be a requirement for servers
and desktops alike. MBSA reports give you a list of possible concerns as well as instructions for
resolving them.
MBSA 2.0
In the first half of 2005, Microsoft should release the next version of MBSA. This new version will
provide even better capabilities to detect, analyze, and address security concerns. The reports will
continue to show common security problems and missing updates, but the new analysis engine will
become the base scanning engine for all software that Windows Update Services supports.
Hardening the OS
Although OS hardening is important to securing your Exchange environment, I lack space to cover
the subject completely. However, I’ll note several things you can do to greatly reduce your exposure
to unauthorized server access. You should uninstall unnecessary services, lockdown key IIS and
Exchange directories, apply specific changes to the registry and file system, and change how services
execute. To get started, go to http://www.microsoft.com/technet/security/prodtech/win2003
/w2003hg/sgch01.mspx, where you’ll find the Windows Server 2003 Security Guide.
In the guide, you’ll find specific information about how to lockdown both AD and Windows
2003. To make things a little quicker, you can download Exchange Group Policy Security Templates
from http://www.microsoft.com/downloads/details.aspx?familyid=6a80711f-e5c9-4aef-9a44-
504db09b9065&displaylang=en. You’ll receive not only a white paper about how to lockdown your
Exchange servers (Exchange Server 2003 Security Hardening Guide) but also eight Group Policy
templates to automate the process. Each of the eight templates is designed for a specific Exchange
server role: HTTP, back end, front end, SMTP, POP, IMAP, Network News Transfer Protocol (NNTP),
and Exchange Servers that are also DCs (an incremental policy).
URLScan
URLScan is a powerful control tool that lets the server monitor incoming HTTP requests and filter out
requests you don’t permit. URLScan is especially important on Win2K servers because they lack the
built-in security that Windows 2003 includes. The rules upon which you can base URLScan filters
include several factors (e.g., content, length). If you use Windows 2003 machines, you can probably
skip installing and configuring URLScan (unless you want to incorporate such features as verb control
filters). If you use an older version of IIS, you should download the latest version (URLScan 2.5, as of
this writing) from the URLScan Web site at http://www.microsoft.com/technet/security/tools
/urlscan.mspx.
SCM
The release of Windows 2003 Service Pack 1 (SP1) is on the horizon. With it will come a new tool to
help simplify the lockdown procedures used with the security templates. The Security Configuration
Manager (SCM) will provide a wizard to walk you through disabling unnecessary services (including
IIS Web extensions), blocking unused ports, and securing open ports through IPSec. The ability to
configure audit settings and multihomed network settings and the support for security templates will
let administrators not only apply specific lockdown settings but also better understand the effects of
applying them (and understand how to remove them if necessary).
Server Patch Management

As I mentioned previously, patch management plays an increasingly important role in the security
of corporate networks, particularly for network OSs. The automation of patch application, particularly
for critical security patches, has become increasingly important. You will need to make sure both the
clients and servers are current with all the known security updates. I’ll discuss some methods you can
use to keep your OS up-to-date.
Windows Update
Microsoft Windows Update is the online resource for fixes, updates, and enhancements to Windows
OSs ranging from 64-bit versions of the Windows 2003 family to Win98. The Windows Update
Catalog is the online database that indexes and categorizes the updates and provides the core index
for all of Microsoft’s patching solutions including the built-in Windows Update components installed
in Windows 2003, XP, and Win2K systems. Because Windows Update is built into Win2K and later
OSs, it’s an ideal solution for consumers and small businesses that don’t have a server or an IT
administrator.
Software Update Services

For companies with servers and IT administrators, Microsoft Software Update Services (SUS) provides
a more complete patch management solution. By deploying SUS, administrators can download the
latest updates to an intranet server, test the updates, select updates to deploy to specific computers,
then deploy the updates in a timely and efficient manner. SUS provides dynamic notification of
critical updates to Windows-based computers, whether or not they have Internet access, and it
provides a simple, automatic solution for distributing updates to networked clients and servers.
SMS 2003
Microsoft Systems Management Server (SMS) 2003 extends the core server patching capabilities of
Windows Update Services by adding even more control for patch management as well as complete
software distribution. Compared to Windows Update Services, SMS 2003 offers more advanced control
of content targeting, distribution control, scheduling, and reporting. It also adds full compliance
checking. SMS completes the update management solution with extended levels of control for
software updates of all types combined with an integrated asset management solution.
Of the Microsoft patching tools that you can use for Exchange Server, only SMS 2003 currently
offers a patching mechanism that can monitor and keep your Exchange systems up-to-date. To be
honest, monitoring shouldn’t concern you much – as long as you check the Exchange product pages
every week or so to monitor for new patches and hotfixes specific to Exchange.
Because Exchange updates don’t come out as often as other product updates, automating patches
for Exchange isn’t as critical as for the OSs. If you’re interested in automatically scanning for and
applying patches to your Exchange services, you can always consider SMS 2003 or products available
from third parties such as Quest or Configuresoft.
Quest’s Patch Management for Microsoft doesn’t require the use of agents as does SMS and it
can be up and running in 15 minutes or less. In addition to the ease of deployment, Quest’s Patch
Management for Microsoft provides detailed progress tracking and reporting, the ability to roll back
service packs or patches that cause issues, and the ability to deploy custom patches.
ConfigureSoft’s Enterprise Configuration Manager (ECM) provides centralized security patch
management and a Web-based console for administration. ConfigureSoft’s Enterprise Configuration
Manager also provides extensive reports and the ability to set up compliance rules to monitor key
settings and optionally auto-enforce or auto-change settings to bring them into compliance.
Dealing with Harmful Email Messages

Email messages are the leading distributor of infected files. No matter how good your firewall is, an
infected file can get into the system. If you really think about it, infection begins at the client level. To
make things worse, email virus scanners might pick up infected files, but will they scan HTML links?
An embedded HTML link to a graphic or a Web page can be as dangerous as a virus. From the
server side, the wrong SMTP configurations not only permit incoming infected email messages but
also let spammers and malicious users use your mail servers to harm others.
Managing SMTP Relays

By default, Exchange Server 2003 doesn’t permit relaying on the servers. You should check this
setting periodically on your front-end and back-end servers as well as on the server in your DMZ
that routes email. The best way to control relays on your Exchange 2003 and Exchange 2000 servers
is through IP addresses. By default, no machine should be allowed to relay. With Exchange, this
restriction means that the target SMTP address must be someone within your SMTP domain, as
Figure 8.9 shows.
Figure 8.9
Setting up relay restrictions
Within Exchange, SMTP configurations are in the ESM under a server’s protocols menu. You’ll
need to check each SMTP virtual server you have under each server.
Preventing Virus Outbreaks

Too many folks believe that a simple gateway messaging scanner will protect the enterprise.
However, you need to cover several fronts in the battle against infected email messages. Client
machines offer the greatest risk to the environment. You should require each machine to be security
compliant, then monitor for that compliance. Of course, protecting the border is important, and
performing a periodic scan against the Exchange stores helps prevent infected files from “living” in
the databases.
Gateway servers get the most attention and rightly so because they reside where a virus usually
enters a network. You should take steps to scan and clean email messages as they enter your
environment from the Internet. In fact, cleaning them before they enter the Exchange environment is
even better. Many companies offer SMTP scanning engines that automatically update their virus
signatures on a schedule, thereby ensuring that the virus-scanning signatures are always up-to-date.
Some of the more sophisticated tools use multiple brands of scanning engines in case one vendor is
late in updating its signatures for a new virus.
Assuming that you can block every incoming infected file, you’re still at great risk of an outbreak
because you have clients. (Without them, however, you and I probably wouldn’t have jobs!)
Someone who uses OWA from the Web or uses an Outlook, POP, or IMAP client can easily attach
an infected file to an email message and send it to someone within the company.
Because the email message never crosses your gateway scanner, it will go unnoticed, potentially
right into a user’s Inbox. To mitigate the risk of an internal infection, you should invest in an
Exchange-aware virus-scanning engine that you can install on your messaging servers. Many brands
of such scanners are available, and they let you scan the Exchange stores live or on a schedule –
and also scan MTAs. The net result is an internal scanning configuration that prevents intracompany
outbreaks.
Last and most important is the client itself. The most dangerous outbreaks typically begin when
some malicious code or mechanism infects a client and leverages that client’s email program to
propagate the virus. As of Outlook 2000 Service Release 1 (SR1), this problem hasn’t recurred because
of a new security feature: the Object Model Guard. When the feature first came out, many users
complained because it interrupted PDA synchronization software. It prevents programmatic access to
the address book and the functions that send email messages. Because of this feature, a program
that tries to infect email messages can succeed only if the client clicks a button to permit it or an
administrator has disabled the Object Model Guard.
In addition to protecting the object model, Outlook also controls access to certain types of files.
Administrators can centrally control files and the Object Model Guard by downloading and installing
the Outlook Administrator Pack from http://www.microsoft.com/office/ork/2003/tools/boxa10.htm.
With this tool, you can create an Outlook form in a public folder to better control the security
settings on the Outlook client. For example, you can create a profile that lets administrators but not
the sales team get to executable files within email messages. The files are still in the email message,
but the Outlook client won’t be able to access them. You can extend this level of protection to any
file type you want to control. By eliminating attachments or limiting the types of attachments that
users can open, as Figure 8.10 shows, you greatly reduce your exposure to email-borne outbreaks.
Figure 8.10
Outlook default security settings
The Outlook Administrator Pack offers the best way to centrally control the behavior of the
Outlook client. This control is especially helpful when certain groups of users need access to specific
types of files or need additional programmatic access to their Outlook sessions, as is the case with
PDA users.
So what do you do with Outlook clients earlier than Outlook 2000 SR1? Although security
updates and some protections are available through third-party antivirus products, I recommend
eliminating those clients altogether. Outlook 2003 can run on any XP or Win2K machine and
Outlook XP (2003) can run on Win98 machines. Therefore, your best bet is to get rid of the old
clients. (You’re entitled to a license for Outlook 2003 for every Exchange 2003 Client Access License –
CAL – you purchase, which leaves you with no excuse to not install Outlook 2003 on every client
machine that has a valid Exchange 2003 CAL – unless of course those machines run Windows 9x.)
For those of you who want to protect yourself from being victims of infected Outlook 98 or
Outlook 97 machines, you can leverage an Exchange feature that blocks access from those clients
specifically. Exchange Server 2003 detects the version of the Outlook client connecting and can block
access based on the version number of the requesting client. To learn more about this feature, see
“XADM: Feature to Disable MAPI Client Access” at http://support.microsoft.com/?kbid=288894.
Preventing Unsolicited Email

For those of you who wonder whether you should upgrade to Outlook 2003, let me help you make
up your mind. To begin with, Outlook 2003 includes a feature that blocks HTML-embedded messages
from automatically retrieving pictures from the Internet, as Figure 8.11 shows.
Figure 8.11
Outlook 2003 External Content Settings
This feature alone should help reduce much of the pornography that comes across in unsolicited
email messages. Spammers pay ISP costs, and they use HTML-embedded messages because they can’t
afford to send millions of large email messages and thereby limit the number of people they can
reach. By using this blocking feature (which is enabled by default), you ensure that the email mes-
sages that do get through probably won’t contain graphics.
When you connect to a graphic link embedded in an email message, you’re often connecting to
an untrusted source. In addition, the HTML link you use is probably designed to identify you. When
a client downloads external embedded graphics, you could be confirming that your email address is
authentic. Confirmed email addresses are very valuable to spammers.
Outlook’s SmartScreen Function

The previous two versions of Outlook shipped with a junk-mail filter, but Outlook 2003 ships with an
improved technology known as SmartScreen. Outlook’s SmartScreen function comes with four settings
that individual users can set within their own Outlook profiles. Outlook’s SmartScreen Junk E-Mail
options let you choose among various levels of protection, as Figure 8.12 shows.
Figure 8.12
Outlook SmartScreen’s Junk E-mail options
The default setting of No Protection offers very little in respect to email message filtering. With
this setting, Outlook will only block email messages based on specific domains or senders that the
client has already determined to be junk-email senders. In other words, if John gets email messages
from a questionable address and adds a filter to block them, he’ll no longer get messages from that
address. The effectiveness of this feature is low because most spammers change their sending domain
names regularly or spoof sites and use fake return addresses. The second level, Low, scans email
messages against the lists you’ve provided and searches the subject and body fields for specific words
and phrases hard-coded into Outlook.
Outlook’s SmartScreen has two drawbacks. First, you can’t add or remove key words from the
filter list. Second, as an administrator, you have no central way to manage the settings for the Junk
E-mail Options. With SmartScreen, the responsibility for blocking unsolicited email messages fails on
the users’ shoulders. For some organizations, this scenario is acceptable, but I prefer to have some
leverage over the settings from a central console.
You probably shouldn’t use Outlook SmartScreen’s highest scanning option often. The Trusted
Lists Only option filters out every email message whose sender isn’t in your address book or in a
Trusted Senders or Trusted Recipients list. Of course, if you do business with Company.com, you
can easily add that entire domain to your Trusted Senders list. Also, if you want to receive email
messages from someone at Aol.com, you could add Aol.com or the individual email address to the
Trusted Senders list.
However, the drawbacks of this setting are obvious. Unless you have specifically opened a
domain or user account within Outlook, SmartScreen will filter out an email message. Moreover, the
setting is likely to create some confusion and add work for end users because they’re responsible for
identifying junk email messages, handling filtered email messages, and managing their own false
positives.
Exchange Server 2003 Antispam Tools
Exchange 2000 lets you block email messages based on the sending domain and sending IP address.
A diligent Exchange 2000 administrator could inspect incoming email messages, collect the sending
server’s IP and domain, and build a block list in Exchange 2000. As administrators used these settings,
they began to learn how spammers operate.
Spammers often operate out of small or home offices and in countries with fast network links.
The most prolific spamming companies must constantly change server IP addresses to confuse spam
filters. The IP address you blocked last week will probably never be used again. Spammers acquire a
DSL or network link with banks of IP addresses. In theory, 32 IP addresses should provide a month’s
worth of spam if spammers change the IP address, server name, sending domain, and email
messages every day.
Exchange 2003 not only blocks domains and IP addresses, but also supports basic antispam tools
such as whitelists, blacklists, and third-party blacklist servers. By using the Sender Filtering page,
which Figure 8.13 shows, you’ll be able to filter email messages from particular domains as well as
email messages with blank sender fields.
Figure 8.13
Deploying sender filtering
Exchange Server 2003 now supports the use of blacklist servers, as Figure 8.14 shows. Exchange
Server 2003 can compare the sender’s domain against a list of known spam domains located on
third-party servers on the Internet. Relays.visi.com, for example, is one of several free blacklist servers
you can use.
Figure 8.14
Configuring blacklist service use
You’ll need to check out the block list services you choose; many are free and some are
unreliable. In the past year, the industry lost several well-known Real-Time Block Lists (RBLs), and
one in particular became so compromised that all senders were confirmed as blacklisted!
You can create an Exception list, as Figure 8.14 also shows, to identify the mailboxes that should
never be filtered. Perhaps you have a couple of executives who want to handle spam filtering on
their own by using the Outlook 2003 filters. You can add their SMTP addresses through this screen to
ensure that no server-based rule ever filters their email messages.
IMF
For me, the Intelligent Message Filter (IMF), a new add-on for Exchange Server 2003, is the most
exciting improvement since the release of SP1. Based on the SmartScreen technology, the IMF, which
Figure 8.15 shows, works by scanning an email message at the (Exchange) gateway and at the
mailbox store itself.
Figure 8.15
Configuring IMF
n Note The configuration screen for the IMF might make you think the tool is simplistic or less than
functional, but it has useful capabilities. Microsoft offers a 39-page white paper that describes
the IMF and its various configuration scenarios. To access “Exchange Server Intelligent Message
Server Overview,” go to http://www.microsoft.com/exchange/downloads/2003/imf/imf
_wp.asp.
One benefit of IMF is that unsolicited email messages are moved or deleted before the client ever
connects to the server. This benefit is key for PDA, OWA, POP, and smart phone environments
because these clients don’t always have their own antispam filters.
IMF still needs some improvement. For example, you can’t change the Simple Object Access
Protocol (SOAP) Contract Language (SCL) rating per user or group or manually edit or augment the
logic that filters the email messages. Instead, Microsoft is keeping the code and the logic behind the
IMF very quiet. Aside from the drawbacks just mentioned, IMF works very well. If you have no anti-
spam tools, I highly recommend deploying IMF.
Third-Party Solutions
Many other hardware and software products can help you fight spam. Service companies such as
MessageLabs and Postini can intercept your incoming email message (by redirecting the MX records),
scan the email messages for infected attachments and spam, and send the clean email messages on to
your environment. Your best approach to finding the right solution for your environment is to contact
other companies to see what has worked well for them, then arrange for a vendor trial.
Protecting the Exchange Environment

In this final chapter, I’ve discussed Exchange security and how you can work to achieve it. I hope
the chapter’s information and references offer information and approaches you can use to keep your
Exchange system and your company’s assets secure.

ExchangeServer FULL

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ExchangeServer FULL

Încărcat de

Drepturi de autor:

Formate disponibile

The Expert's Guide for

Exchange 2003 and Active Directory

Chapter 1: Exchange 2003 and Active Directory

Chapter 2: Preparing Your Domain Services

Chapter 3: Consolidating Your Exchange Services

Chapter 4: Database Strategies and Server Sizing

Chapter 5: Multiple Directories

Chapter 6: The Exchange Client

Chapter 7: Administration Best Practices

Chapter 8: Security, Auditing, and Logging

The Flood of Electronic Communications and You

Exchange Server 2003: New Features

Table 1.1 Exchange Server 2003 versions

Mobile and Remote Access

Microsoft Outlook Client

Outlook 2003 License for Free

Other Exchange 2003 Improvements

The Importance of Windows 2003

Table 1.3 Windows 2003 AD modes and features

Table 1.4 Windows server Exchange support

Exchange 2003 and AD

ADSI Edit and the Support Tools

Manually changing the Directory Access List

Manually changing the Directory Access List, continued

Next: Preparing for Exchange 2003

Preparing Your Domain Services

Planning Your AD Deployment

About the GC Server

North America Europe Asia Central and South America

Site Links and Site Link Bridges

Naming Your AD Environment

AD and DNS Name Spaces

AD, DNS, and SMTP Addresses

Domain Cleanup and AD Migration

Consolidating and Collapsing Domains

Moving File and Print Servers

Windows 2003 Server Rename Tools

Prepping AD for Exchange

Trust and Verify

• ADCObjectCheck runs ADC Object Replication Check

Next: Consolidating Your Exchange Services

Consolidating Your Exchange Services

Server Ownership Costs

Exchange Server Proliferation

You can see several points of vulnerability in this design:

Exchange 2003 and AD

Front-End Exchange Servers

Front-End Servers and Performance

Balancing Front-End and Back-End Servers

Storage Space and Recovery

Configuration and Memory

Mailbox Consolidation Concerns

Creating Server Redundancy

Spreading the Load

Active Node A Active Node B Active Node C Passive Node D

C:\ C:\ C:\ C:\

G:\ H:\ I:\ J:\ K:\ L:\

DB1 LOGS1 DB2 LOGS2 DB3 LOGS3

Deploying High- or Continuous-Availability Servers

Consolidating Mailbox Servers

Move Mailbox Tool

Consolidating Your Exchange Organization