The Expert's Guide for Exchange 2003 Preparing for, Moving to, and Supporting

The Expert's Guide for Exchange 2003 Preparing for, Moving to, and Supporting

The Expert's Guide for

Exchange 2003

Preparing for, Moving to, and Supporting

Exchange Server 2003

by Steve Bryant



Chapter 1 Exchange 2003 and Active Directory . . . . . . . . . . . . . . . . . . . .


Sidebar: The Flood of Electronic Communications and You . . . . . . . . . . . . . .


Exchange Server 2003: New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Sidebar: Exchange Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Mobile and Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Microsoft Outlook Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Sidebar: Outlook 2003 License for Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Other Exchange 2003 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


The Importance of Windows 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Exchange 2003 and AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


AD Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Sidebar: ADSI Edit and the Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . .


Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Sidebar: Manually changing the Directory Access List . . . . . . . . . . . . . . . . . . .


Enabling GC Services on a DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Next: Preparing for Exchange 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .






Chapter 2 Preparing Your Domain Services . . . . . . . . . . . . . . . . . . . . . . . 17

Planning Your AD Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


AD Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


A Single Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Multiple Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


About the GC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Logical Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Site Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Well-Connected Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


AD Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


ForestPrep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


DomainPrep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Trust and Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Next: Consolidating Your Exchange Services . . . . . . . . . . . . . . . . . . . . . . . . . . .




Chapter 3 Consolidating Your Exchange Services . . . . . . . . . . . . . . . . . . . 34

Server Ownership Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Exchange Server Proliferation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Consolidating Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Exchange 2003 and AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Front-End Exchange Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Front-End Servers and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Balancing Front-End and Back-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Consolidating Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Storage Space and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Configuration and Memeory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Mailbox Consolidation Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Creating Server Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Spreading the Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Deploying High- or Continuous-Availability Servers . . . . . . . . . . . . . . . . . . . . . .


Consolidating Mailbox Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Move Mailbox Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Consolidating Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Consolidating Your Exchange Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Consolidating Exchange 2003 and Exchange 2000 Organizations . . . . . . . . . . . . . . . .


Tools for Merging Exchange Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Using the Exchange Migration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Copying Public Folder Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Copying the Organizational Forms Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Copying Contacts from One Organization to Another . . . . . . . . . . . . . . . . . . . . .


Collecting Group Distribution Memebership . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Completing the Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


More Consolidation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Next: Installing Exchange 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .






Chapter 4 Installing Exchange Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . 65

Deployment Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Deployment Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Exchange Server 2003 Installation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . .


New Exchange 2003 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Upgrade from Exchange 2000 Native Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5 . . . . . . . . . . . . . . .


Coexistence and Migration from Exchange 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Coexistence and Migration from Exchange 5.5: Step by Step . . . . . . . . . . . . . . .


Coexistence and Migration, Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Coexistence and Migration, Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Understanding ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


The ADC Tools Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Deploying ADC Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Deploying the Resource Mailbox Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . .


Deploying the Connection Agreements Wizard . . . . . . . . . . . . . . . . . . . . . . .


Coexistance and Migration, Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


ExDeploy Command-Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Next: Multiple Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




Chapter 5 Multiple Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Why Multiple Directories Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


AD as Your Directory Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Forests and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Multiple Directories and Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Single Exchange Organization Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Separate Exchange 2003 and Exchange 5.5 Organizations . . . . . . . . . . . . . . . . . . . .


Separate Exchange 2003 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Exchange 2003 and Foreign Mail Systems — Short Term . . . . . . . . . . . . . . . . . . . . .


Lotus Notes/Domino Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


SMTP for Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Establish Separate Internet Domains for Notes and Exchange . . . . . . . . . . . . .


Establish Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Split the Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Installing and Tweaking the Notes Connector . . . . . . . . . . . . . . . . . . . . . . . . . .


GroupWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


MIIS 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


LDIF Import and Export Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Reviewing Your Multiple Directory Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Next: Outlook Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102





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



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





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

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 probably 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


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


- 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


Chapter 7: Administration Best Practices

Server maintenance

Database maintenance

Redundancy on various levels

Antivirus and spam fighting tools and techniques


- 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.”

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


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

Up to 20 databases

Clustering support

X.400 connector

Database Storage Limit

Database snapshot

Front-end server capability

Outlook Mobile Access

(OMA) and ActiveSync

RPC compression

Recovery Storage Group

Exchange Management Pack (MOM)

Exchange 2003 Standard


Exchange 2003 Enterprise


Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


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,

“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



, 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

64-bit support

Hot Add Memory

Maximum RAM

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


Distributed File System (Dfs)

Encrypted File System (EFS)

Fax Service

.NET Framework

IIS 6.0


Enterprise UDDI P P P

Standard Edition


Enterprise Edition


Datacenter Edition


Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


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

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

Win2K Native mode

Windows 2003

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

Exchange 5.5

Exchange 2000 Service Pack 2 (SP2)

Exchange 2000 SP3

Exchange 2003

NT 4.0


Windows 2003

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

For more information about Exchange support, see “You Cannot Install Exchange 2000 on a

Computer That Is Running Windows Server 2003,” at


Exchange 2003 and AD

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


Figure 1.1


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.”

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


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


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

/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;[LN];302914.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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).

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 1 Exchange 2003 and Active Directory


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:



HostName = REG_SZ



HostName = REG_SZ

The usual warnings apply. Back up the registry key before you make changes and test the changes on a nonproduction server. d


Use the System Manager to force these changes only if you have no other alternative.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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;[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.



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

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


Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


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.


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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


Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003


North America

United States


New York


Team 1










South Asia




Central and South America

Central America


Mexico City


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

New York










Central and South America

Mexico City


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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


Figure 2.2

Logical network topology



200 Users

New York, NY




45 Users

Camberly, UK

200 Users

London, UK


25 Users

Memphis, TN

75 Users

Clearwater, FL

75 Users

Mullhouse, FR

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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 synchronization 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



Site: NY











Site: LD





Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


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: NY




Site: LD












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.)

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


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 AD forest results in an AD name of

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 (, it’s also common for companies to use separate name spaces – such as for external DNS and 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, or even the same namespace, as such

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

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 for your namespace, you can still collect email for,, 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


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



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.



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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services

29 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.



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

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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 timeconsuming, 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


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.


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.


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.


/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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 2 Preparing Your Domain Services


• 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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

• Security server

• Web server




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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 3.1

Site design with multiple protocols


Other Sites





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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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.

Exchange 2003 and AD

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 n


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services




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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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



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 appropriate back-end or mailbox server located within the corporate network. (SMTP is handled a little

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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



Other Sites





Front End



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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


The overall recommendation to provide a good balance is one front-end server to four back-end servers.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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:

• 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

• 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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Active Node A

Chapter 3 Consolidating Your Exchange Services


Figure 3.13

Microsoft Clustering Services configuration

Active Node B Active Node C Passive Node D






C:\ C:\










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 Windows 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 software, antispam software, management tools, and agents for each node.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

• 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;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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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 "displayname,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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


objectClass: person objectClass: organizationalPerson objectClass: contact proxyAddresses: SMTP:[email protected]


X400:c=us;a= ;p=First Organizati;o=Exchange;s=Jason Sherry; targetAddress: SMTP:[email protected]

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:[email protected]


X400:c=us;a= ;p=First Organizati;o=Exchange;s=Jason Sherry; targetAddress: SMTP:[email protected]

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


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:

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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:[email protected]

proxyAddresses: smtp:[email protected]

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:[email protected]

proxyAddresses: smtp:[email protected]

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 3.14

Example .REG File

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles]

"DefaultProfile"="NEWSERVER Profile"

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\0a0d020000000000c000000000000046]




[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\1018e8b4de806342b370f3d513f342ec]
















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\13dbb0c8aa05101a9bb000aa002fc45a]












"001e6750"="NEWSERVER Profile"













Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services






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,\





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,\




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,\














































Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003











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,\



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,\





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,\




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,\

























[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\522121b7579cad4f815965481963977e]









Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services












[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\5254129a867d1e49bf8937208f135a06]



















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\5acf76a3665511cea39a00aa004acafa]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\67d962f70362044d93d9f4aa3ab5c3e3]




















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\7e9c76239d8799459feef1a71dfd133c]





Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003











[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\8503020000000000c000000000000046]


[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\9207f3e0a3b11019908b08002b2a56c2]










[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676]






[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676\00000001]


"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,\


[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\9375CFF0413111d3B88A00104B2A6676\00000002]


"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,\


"Account Name"=hex:4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,20,00,\



[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\a10cb5608742104c853574c1b6642917]



Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 3 Consolidating Your Exchange Services


















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\d89ff04133504346a808966b8aa26668]






















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\dc30434b7a0ef849aa75c37a99b3e7cd]















[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\dca740c8c042101ab4b908002b2fe182]

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\NEWSERVER Profile\f10b187cfe97204387dc7d32bab3d160]

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003


















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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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 –

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003




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 complicated 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 j


You can download the Exchange 2003 Deployment Tools from 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 j


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


have Exchange 5.5 Service Pack 3 (SP3) installed on at least one server in your organization before you deploy Exchange Server 2003.

Coexistence and Migration, Phase 2

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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


Figure 4.4

Microsoft Active Directory Connector Setup



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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).



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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:

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


• 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 singleorganization 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.



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 j


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.



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003




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


Coexistence and Migration, Phase 3

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 homework 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 certain 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 4.8

Exchange Task Wizard progress report



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 Knowledge Base Article 822450, “How to Remove the Last Exchange Server 5.5 Computer from an

Exchange Server 2003 Administrative Group,” at;


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:

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 4 Installing Exchange Server 2003


/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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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, database 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 crosscertify 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

/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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Steve Bryant

Division A Forest

Chapter 5 Multiple Directories


Figure 5.1

Single Exchange forest environment

Steve Bryant



Exchange Forest

Division B 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories


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


Outlook Clients



Brian Veal



Server Running

Identity Integration Feature


Steve Bryant

Outlook Clients

Steve Bryant

Division A Forest

Brian Veal

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

=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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories


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 file on the target Notes server.



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 d


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 messages 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

Site D

Exchange Site

Site C

Exchange Site

Site A

Exchange Site

Site B

Notes Domain


Notes Domain


Mail flow and directory updates between the systems will only use the connector. If the connector is down or inoperative, no email will pass

Notes Domain


Notes Domain


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Exchange Site

Site D

Exchange Site

Site A

Figure 5.5

SMTP message transport

Notes connector

Chapter 5 Multiple Directories



Notes Domain


Notes Domain


Exchange Site

Site C

Exchange Site

Site B

Only directory updates uses the connectors and connector servers. Email flow uses SMTP

Notes Domain


Notes Domain


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 and the Exchange environment can collect email for, as Figure 5.6 shows. The use of separate Internet domains is the safest and easiest solution to configure.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 5.6

Separate Exchange and Notes domains






Establish Subdomains

You can establish subdomains (by using an internal partitioning scheme) to identify each email system. For example, you could use internally to identify the Notes users and (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



Brought to you by Quest Software and Windows & .NET Magazine eBooks



Chapter 5 Multiple Directories


A mapping table on the SMTP mail relay/virus scanner server would receive email messages for [email protected], look up the internal address of [email protected], 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 [email protected] sends an email message, the SMTP relay server would strip exchange from the address so that someone in the outside world would see [email protected] 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



Email relays





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).

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories


Figure 5.9

Changes to the Amap.tbl file


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

S MT Ad r 28 Pr xy Ad es se (S TP ) A d hi li e

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 5.10

Changes to the Mapnotes.tbl file


Alias = ISEQUAL( ShortName, “”, SUBSTR

( FullName, 1, 64 ), ShortName )

F ul Na e I EQ AL S or Na e, “” X5 0

( F ll am , CN ), X5 0

( L st am “ “ Fi st me , CN ) )

T A “ MT :” IS QU L( Ma lA dr “ I SE UA

( S TP dd , ”, Re la e

( S ri ( ul Na e, “; , L” “ ” , “ “ ” “% ” ep ac (

S tr p( Ma lD ma n, “; “ L” “ ” , “ “ ” “@ co an y.

m” ,

S MT Ad r , ai Ad r


FirstName = FirstName

LastName = ISEQUAL( LastName, “”, ISEQUAL(

FirstName, “”, X500( FullName, “CN”), “” ) ,



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 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories


Figure 5.11

Changes to the Amap.tbl file


FULLNAME 220 FullName 1

MAILDOMAIN 31 MailDomain 2

COMPANY 64 CompanyName NULL




LOCATION 128 Location 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




MT ai ai dd dd ys r r

1 8

1 8


M te il ne dd

Ad es re s




4 M ai Sy te Ad Th is in e

T s hi li

l e e

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 5.12

Changes to the Mapmex.tbl file


F ul Na e F rs Na e “ La tN me “/ OM AN ”

MailDomain = Trim( Strip( NotesAddr, “@”, “L” ), “B” )

ShortName = Alias

LastName = ISEQUAL( LastName, “”, FullName, LastName )

FirstName = FirstName

Company = Company

Department = Department

Location = Office


USN = USNCreated


Initials = Initials

CALDOM = Trim( Strip( NotesAddr, “@”, “L” ), “B” )

M ai Do ai = NO ES OM N A d th l in

M ai Ad r T im SM PA dr “ ”) A dd th l in

M ai Sy = 5” Ad t is in e

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories




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.


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:

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

• AD


• 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 5 Multiple Directories


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 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, 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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.



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).

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 connection. A remote worker who uses Outlook might synchronize it over a dial-up or slower WAN connection. 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


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 Service (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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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 Outlook 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 surprising 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



800 1000


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

You don’t need to choose a compression option or make any changes manually; the compression 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

1KB HTML Message with 1MB Attachment

Outlook 2000

Outlook 2003 without cache

Outlook 2003

Cached Mode

0 200 400



800 1000



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.


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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, as Figure 6.5 shows.

Figure 6.5

Outlook 2003 and Outlook 2000 bandwidth use comparison

Address Lookup

Ambiguous Name




0 2000 4000 6000 8000 10,000 12,000 14,000 bps

Outlook 2000

Outlook 2003

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 subsequent 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.


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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 ( 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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.



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:


• “Exchange Server 2003 RPC over HTTP Deployment Scenarios Guide” from

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


Figure 6.7

OWA logon page



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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








OWA 2003 Basic

OWA 2003 Premium

Outlook 2003

0 2000 4000 6000 8000 10,000 12,000 14,000 16,000 18,000


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


Figure 6.9

OWA and Outlook 2003 sending and receiving bandwidth use comparison

1KB HTML Message with 1MB Attachment


OWA Premium -

High Compression

Outlook 2003 without cache




4000 6000 8000 10,000 12,000 14,000 16,000


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.


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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 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 synchronization of the mailbox to the PDA without using a cradle or desktop synchronization software.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.



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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 6 Deploying Microsoft Outlook


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


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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 j


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 and microsoft.public.mobility newsgroups, and

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 consolidation. 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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, as Figure 7.3 shows.

Figure 7.3

Archiving backup disk arrays to tape

Backup Serve Remotely connects 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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” faulttolerance 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 (

/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 circumstances. 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 thirdparty options.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 j


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery




When you want to back up key mailboxes individually, ExMerge is probably much more costeffective and simpler to use and automate. (See the previous section “Restoring Mailboxes and

Items with ExMerge.”)


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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



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 recommend that you use the Generate report only option, which Figure 7.11 shows, to see what would be deleted or moved.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 7 Administrative Best Practices and Disaster Revovery


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


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 exposures 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

/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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.




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 synchronization of email. Microsoft also has improved Outlook Web Access (OWA), which now offers compression features, notifications, and encryption, as well as junk-email management.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Moreover, you can use a single secured configuration for all communications to your environment 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 RPCover-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, 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


Figure 8.1

Layered path into the network


OWA users

Port 110

Invalid HTTP commands

Port 443

Internet SMTP


Port 25

Port 21

Outer firewall blocks unwanted traffic

Invalid SMTP commands

Reverse-proxy server accepts and bridges SSL sessions and drops invalid commands


Server 2003

Inner firewall accepts the bridged,

SSL sessions

Exchange Server

2003 performs the authentication and accepts or declines the session

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


Mailbox servers


OWA users


Mailbox servers

Port 110

Invalid HTTP commands

Port 443

Port 25

Port 21

Internet SMTP


Outer firewall blocks unwanted traffic

Reverse-proxy servers accepts and bridges SSL sessions and drops invalid commands

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Inner firewall accepts the bridged,

SSL sessions

Exchange Server 2003 front-end servers

Exchange Server

2003 performs the authentication and accepts or declines the session


The Expert’s Guide for Exchange 2003

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

Internet SMTP


Outer firewall blocks unwanted traffic

Microsoft Exchange

Edge Services

Inner firewall accepts the bridged,

SSL sessions

A copy or subset of the AD allows the

Edge Device to:

Perform Recipient Filtering

Spam Confidence Level Tagging

Specialized SMTP Routing

Brought to you by Quest Software and Windows & .NET Magazine eBooks


Server 2003


Chapter 8 Exchange Security




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


To download the Outlook Web Access Web Administration utility, go to


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)


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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:

S te , </FONT></DIV><DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV><DIV dir=ltr><FONT face=Arial size=2>J us t l t ou kn w.

yo u av t j ob D n’ te l a ny ne dir=ltr><FONT face=Arial size=2>-S te e</FONT>

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Figure 8.4

IIS Authentication Methods screen

Chapter 8 Exchange Security


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


Figure 8.6

Requiring a secure channel for POP and IMAP sessions



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




MAIL FROM: <[email protected]>

RCPT TO: <[email protected]>



Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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 Communication by Using the Transport Layer Security Protocol in Exchange Server,” at;en-us;829721&product=exch2003, explains the process 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 certificate 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 e hl Hello []

















250 OK s ta tl s

5 54 5.


Un bl t i it al ze se ur ty su sy te e hl Hello []


















250-XEXCH50 250 OK s ta tl s

2 20 2.


SM P er er ea y

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.”

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.


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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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

/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

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 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

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003 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



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

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.)

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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

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 messages 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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, you can easily add that entire domain to your Trusted Senders list. Also, if you want to receive email messages from someone at, you could add 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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

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., for example, is one of several free blacklist servers you can use.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Figure 8.14

Configuring blacklist service use

Chapter 8 Exchange Security


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.


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks


The Expert’s Guide for Exchange 2003

Figure 8.15

Configuring IMF



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


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 antispam tools, I highly recommend deploying IMF.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Chapter 8 Exchange Security


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.

Brought to you by Quest Software and Windows & .NET Magazine eBooks

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF


Table of contents