Exchange 2000 Notes From The Field What We Have Learned Kieran McCorry

1. Exchange 2000 Notes From The Field What We Have Learned Kieran McCorry Principal ConsultantTechnology Leadership Group October 7, 2002

2. Agenda? Preparation for deployment Selecting the Right Architecture Migration Approaches Third Party Products Best Practices

3. Preparing For Migration Deploying Windows 2000 • Migrating all users to Windows 2000 first • Sometimes it’s a good idea • Deploying the basic infrastructure is enough • Let the dir synch process take care of creating user objects • Many ways to access your mailbox • NT4 acc/E5.5 mailbox • W2K acc/E5.5 mailbox • NT4 acc/E2K mailbox • WK acc/E2K mailbox

4. Building Windows 2000 Servers Take a Standard Platform Approach Makes rollout and ongoing maintenance simpler Identify server types and appropriate builds Automate as much as possible Use slipstream CDs Automated build tools, etc.

5. Selecting the ‘Right’ Exchange Architecture What are the Types of servers you need to deploy? Do you want to centralize as much as possible? Do you have the appropriate bandwidth? Should you use Datacenter clustering? Is clustering even appropriate? Are there alternatives? How many users should you place on a server?

6. Test Every Aspect Of Your Migration • Build a comprehensive test facility • Mimic your complete environment • Include multiple domains, multiple Exchange 5.5 sites, etc. • Characterize network connections, use WAN emulators • Test migration processes • Migration from NT4 and W2K interoperability • Migration from E5.5 and E2K interoperability • Test your fallback procedures too!

7. Build A Strong Dedicated Team You’ll need a team of experts focused on the deployment and migration Exchange experts Windows experts DNS/Networking Programmers maybe too In Compaq we had 6 central engineering staff Other staff at regional locations Expect to spend months in testing

8. Migration Techniques Plan directory synch carefully Clean up the Exchange 5.5 Directory Avoid using 1-way CAs and changing them later to 2-way CAs Almost always create disabled users Understand exactly how the ADC works Avoid using excessive CAs by some clever planning

9. An Example of ADC Behavior Changes to the Exchange 5.5 Object Continue to be propagated to AD Two-Way Connection Agreement Object Moved Temporary Objects Recipients One-Way Connection Agreement Exchange 5.5 Site Final Objects Active Directory From Windows: Source: Temporary Objects Target: Recipients From Exchange: Source: Recipients Target: Temporary Objects

10. Tokyo Bangkok Recipients DLs Recipients DLs Use Clever OU Designs to Minimize CAs Exchange 5.5 Environment Org ACME Tokyo Windows 2000 Active Directory Site Container One-Way CAs AP.ACME.COM Bangkok Site Container TEMP ACCOUNTS Groups Users Two-Way CAs

11. Standard Approaches For Migration Intra-Org Migrations are most common Works well with a single organization Good when PFs heavily used Larger orgs tend not to upgrade in-place Mailbox data is usually migrated New/replacement hardware is usually deployed

12. Migration Techniques • Mailbox moves can be automated • Private Function MoveMailbox (UserDN As String, TargetMBStore As String) • Dim objPerson As New CDO.Person • Dim objMailbox As CDOEXM.IMailboxStore • objPerson.DataSource.Open “LDAP://” & UserDN • Set objMailbox = objPerson • objMailbox.MoveMailbox “LDAP://” & TargetMBStore • objPerson.DataSource.Save • Set objPerson = Nothing • End Function • Moving large numbers of users • AD Users and Computers is cumbersome • It’s easy and good to script bulk mailbox moves

13. Inter-Org Migrations Useful with multiple separate orgs Brand new start Good when you want to restructure your Admin model Not so good with PFs Straightforward process Can use the ADC for inter-org synch But consider a more heavy duty synch tool in complex environments Use the Exchange Migration Wizard for mailbox moves

14. Partial Organization Migration • A single Exchange 5.5 organization can spin off for its migration • Essentially you break the Exchange 5.5 org into two parts • You’ll need to provide some sort of directory synch • Just make sure PFs and users are segregated by Site • Or, you can start in intra-org migration and split the new E2K org off later…

15. An Initial Approach For Partial Migration 5.5 Srv 5.5 Srv Site A Directory Replication Connector Site A Org ACME Directory Synchronization 5.5 Srv 5.5 Srv Site B Site B Org ACME Org ACME

16. Alternative Approaches For Partial Migration Config CA Recip CA E2K Srv 5.5 Srv E2K Srv E2K Srv Directory Replication Connector Directory Replication Connector Site A Site A Directory Synch Directory Synch 5.5 Srv 5.5 Srv Site B Site B Org ACME Org ACME

17. The Partial Migration Completed E2K Srv E2K Srv Directory Synch Org ACME 5.5 Srv Site B Org ACME

18. End State Third Party Products Can you survive with just Windows and Exchange? Or do you need to evaluate options? Anti-virus best practices Sybari Trend Micro Norton Monitoring and Management HP OpenView MOM NetIQ tools Backup and Restore Commvault Galaxy Veritas Anti-SPAM tools MAPS RBL+ Brightmail Data Archiving KVS

19. What Migration Tools? When? • Understand the different types of tools available • Windows Migration Tools • Exchange Migration Tools • Tools available from • NetIQ • Quest/Fastlane • Bindview • Aelita • Windows tools always useful for intra-org migrations • But you might augment/script with the default tools to simplify mailbox moves • Exchange migration tools VERY useful for inter-org migrations

20. Best PracticesUse Enhancements When Needed Consider, develop, implement possible enhancements to base product SMTP Event Sinks for Logging Customized SMTP Filters (disclaimers, etc.) Event sinks that replace attachments with links Catch-all mail re-routing (even on same server)

21. Best PracticesPlanning and Design Summary Communicate plans to all related teams AND to users Understand your complete environment Especially the network and user patterns Integrate testing of all components Review your plans: get a QA check at least Characterize migration tools Allow up to two weeks testing per migration product Stick with same vendor where possible

22. Best PracticesImplementation Summary Make sure you load test any customizations before deployment Market activities to users Automate processes where possible Server builds Client deployments

23. Questions?