Best practices for Exchange Server 2007 migration

Best Practices for Exchange Server 2007

Written by
Ron Robbins
Product Manager
Exchange Migration Solutions
Quest Software, Inc.

White Paper

© Copyright Quest® Software, Inc. 2007. All rights reserved.
This guide contains proprietary information, which is protected by copyright. The
software described in this guide is furnished under a software license or
nondisclosure agreement. This software may be used or copied only in accordance
with the terms of the applicable agreement. No part of this guide may be reproduced
or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording for any purpose other than the purchaser's personal use
without the written permission of Quest Software, Inc.

WARRANTY

The information contained in this document is subject to change without notice.
Quest Software makes no warranty of any kind with respect to this information.
QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software
shall not be liable for any direct, indirect, incidental, consequential, or other damage
alleged in connection with the furnishing or use of this information.

TRADEMARKS

All trademarks and registered trademarks used in this guide are property of their
respective owners.

World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
e-mail: info@quest.com
U.S. and Canada: 949.754.8000

Please refer to our Web site for regional and international office information.

Updated—February 28, 2007

CONTENTS
INTRODUCTION ................................................................................. 3
WHAT’S NEW IN EXCHANGE SERVER 2007 ...................................................3
BEST PRACTICES IN DEPLOYMENT ..............................................................4
PRE-MIGRATION ASSESSMENT .......................................................... 5
INTRODUCTION ....................................................................................5
EXCHANGE ENVIRONMENTS CAN BE COMPLEX ................................................5
PLANNING A MIGRATION TO EXCHANGE SERVER 2007 ......................................6
SAMPLE EXCHANGE ASSESSMENT QUESTIONS ................................................8
WINDOWS ENVIRONMENT ........................................................................8
INFRASTRUCTURE ENVIRONMENT................................................................9
EXCHANGE ENVIRONMENT .......................................................................9
PRE-MIGRATION ASSESSMENT WITH QUEST MESSAGESTATS ............................ 21
SUMMARY ......................................................................................... 22
ARCHIVE BEFORE YOU MIGRATE ..................................................... 23
INTRODUCTION .................................................................................. 23
DEFINING THE PROBLEM........................................................................ 23
ARCHIVING BEFORE MIGRATION .............................................................. 25
SUMMARY ......................................................................................... 28
MIGRATING TO EXCHANGE SERVER 2007 ........................................ 29
INTRODUCTION .................................................................................. 29
TRANSITION OR MIGRATION?.................................................................. 29
THE MIGRATION PROCESS ..................................................................... 31
DEPLOYING EXCHANGE SERVER 2007 ....................................................... 31
DEPLOYING OUTLOOK .......................................................................... 32
CONNECT FOREIGN SYSTEMS .................................................................. 32
ESTABLISH COEXISTENCE ...................................................................... 33
DIRECTORY SYNCHRONIZATION ............................................................... 33
PUBLIC FOLDER SYNCHRONIZATION .......................................................... 35
CALENDAR AND FREE/BUSY SYNCHRONIZATION ............................................ 36
MAILBOX MIGRATION ........................................................................... 36
PROFILE UPDATING ............................................................................. 37
DECOMMISSION SOURCE SYSTEM............................................................. 37
MIGRATING WITH QUEST SOFTWARE ......................................................... 38
SUMMARY ......................................................................................... 39
MANAGING EXCHANGE SERVER 2007 .............................................. 40
INTRODUCTION .................................................................................. 40
MESSAGING AVAILABILITY ..................................................................... 40
MESSAGING INFORMATION MANAGEMENT ................................................... 41
QUEST MANAGEMENT SOLUTIONS ............................................................ 42
SUMMARY ......................................................................................... 43

REFERENCES.................................................................................... 44
APPENDIX A: MIGRATING PUBLIC FOLDERS TO SHAREPOINT......... 45
APPENDIX B: EXCHANGE SERVER 2007 AVAILABILITY APPROACHES
........................................................................................................ 46
APPENDIX C: UNDERSTAND YOUR EXCHANGE ENVIRONMENT BETTER
........................................................................................................ 47

INTRODUCTION
An Exchange migration is one of the most complex, labor-intensive projects
an organization can undertake. However, it does not have to be. With the
proper planning and execution, you can successfully migrate to Exchange
Server 2007 and minimize the impact on your users and your help desk.
This white paper discusses best practices to assist you with some of the
challenges that come with an Exchange migration.

What’s New in Exchange Server 2007
Exchange Server 2007 has been one of the most anticipated versions of the
platform yet. Microsoft has collaborated at an unprecedented level with
Exchange administrators, partners and users to learn about the upgrades
they needed most, and then developed the features accordingly. A few of
these new features are described below.
Anywhere Access
The first and probably most noticeable improvement in Exchange Server
2007 is anywhere access. The most talked-about feature that demonstrates
this capability is unified messaging -- the integration of voicemail, e-mail, fax
and scheduling in a single inbox. Voicemail messages and received faxes can
now be routed directly to the user’s mailbox. Users can also use a telephone
to listen and respond to e-mail and voicemail contained in their mailbox.
Exchange Server 2007 comes with a new version of both Outlook Web Access
(OWA) and ActiveSync. The OWA interface is easier to use and offers more
security features. ActiveSync also has some security improvements.
Operational Efficiency
Every organization wants to operate more efficiently and save money in the
process. In Exchange Server 2007, Microsoft defines operational efficiency in
terms of improved productivity and performance.
Exchange administrators will immediately notice improved productivity
through the command line interface known as PowerShell. With PowerShell,
administrators have new capabilities for scripting and automating tasks that
they had to perform manually in the previous version.
Exchange server’s performance is also better. Exchange Server 2007 is now
only supported on a 64-bit platform. This allows administrators to put more
users on a single server without losing any system performance. This
approach provides significant cost savings through server consolidation and
simplified administration.

Built-in Protection
Exchange Server 2007 offers security and protection that’s better than ever.
It now includes integrated anti-virus, anti-spam and anti-phishing
technologies. Microsoft has also made it easier for users to plug in their own
anti-virus or anti-spam solutions. This functionality provides added
safeguards without a decrease in performance.
Exchange Server 2007 also automates the use of transport rules and
message retention policies to assist with regulatory compliance. With this
functionality, administrators do not need to rely on users to save or delete e-
mail according to company policies.

Best Practices in Deployment
With all these enhancements, you’re wise to consider moving to Exchange
Server 2007. In the following sections, this document will cover the best
practices for migrating to Exchange Server 2007. First, it will discuss
migration planning, including how to perform a thorough assessment of the
existing environment. Next, it will address the importance of archiving
before you migrate to minimize the amount of migration data to speed up
the migration. Then, the actual migration process will be discussed, including
Microsoft’s supported paths and which path is best for you. Finally, effective
management of the new Exchange 2007 environment will be discussed,
including the identification of key management priorities. As well, the
appendix will offer introductions to Quest Software technologies that can
assist you with public folder migration and high availability in Exchange.

PRE-MIGRATION ASSESSMENT

Introduction
With the critical importance of e-mail, it’s imperative that you plan
extensively before undertaking an Exchange migration. Exchange has so
many different components that you must have both high-level and detailed
views to determine the specific needs for the migration plan. Unfortunately,
many administrators do not have the information they need to make
decisions for planning. “How many users do I have?” and “Where is the
greatest amount of e-mail traffic?” are just two important questions that can
prove difficult to answer in a large organization.
Some of the goals of a migration to Exchange Server 2007 include
consolidation, cost reduction, improved performance and stronger security.
You cannot achieve these goals unless you perform a proper pre-assessment
and use the data as a guide. For example, administrators need to know
where their users are located and how many are using various servers
throughout the organization before they can begin to think about where they
will consolidate servers and storage.
This chapter includes excerpts from the white paper, “Understand Your
Exchange Environment Better,” written by Microsoft Exchange Most Valuable
Professional (MVP) David Sengupta of Quest Software. David covers the
complexity of Exchange and what it takes to plan a migration to this
environment. He also offers an extensive list of questions that organizations
need to answer to perform a thorough Exchange assessment. In addition,
this document will discuss the advantages of using Quest MessageStats™ in
an Exchange assessment. The entire document appears in Appendix C.

Exchange Environments Can Be Complex
Let’s face it, Exchange environments are often complex. Many pieces of
technology come together to provide the messaging infrastructure that
organizations rely on. Active Directory (AD) is core to authentication,
security, and account and distribution group management. And with
Exchange 2007, Active Directory is core to routing. DNS is critical to message
addressing, routing and delivery. Wireless and wired networks are required
for timely message transport, data synchronization, client access and overall
availability. Firewalls, routers, anti-virus and anti-spam technologies are
essential for security and e-mail hygiene. Clients such as Microsoft Outlook,
Outlook Web Access (OWA), Outlook Express, Outlook Mobile Access (OMA)
and Entourage are crucial for rich client e-mail accessibility. In addition,
hundreds of third-party tools exist to facilitate any number of Exchange-
based solutions that may exist in your organization. All of these
technologies—combined with your company’s human resources—factor in to
the complexity associated with managing your Exchange environment. Also,

consider the many incremental changes that happen over time within any
corporate network environment, and you soon have a whole lot of moving
pieces that make up your Exchange ecosystem. Unfortunately, in many
companies these represent largely uncharted waters and therefore pose
some significant challenges.
Whether you’re an Exchange administrator, IT manager, IT director, CIO or
consultant, you’ll have varying perspectives on how effectively your
organization’s messaging systems fit together, and how well the overall
messaging environment is functioning. You need to understand both the
business dependencies and the technical ins and outs associated with your
Exchange infrastructure. You need to ensure performance. You need to
ensure 24x7 service availability. And you need to ensure all new solutions
you deploy don’t degrade system performance (perceived or actual) or
impact availability. E-mail is mission-critical for most organizations today.
Because of this, Exchange drives business processes, approvals, workflows,
customer and partner relationships and team collaboration. If you’ve ever
walked by the company cafeteria during a large-scale Exchange outage,
you’ll understand how critical it has become.
The success of your business depends on an Exchange environment that is
always up and running. So if you’re planning an Exchange migration, you
need to do it with little affect on your users. In fact, users should be
completely unaware that their mailboxes have been migrated. If you’re
planning other work that impacts the Exchange environment, such as the
implementation of a new anti-spam gateway, you’re also expected to keep
Exchange up and running throughout that process. Unfortunately many
Exchange-related projects are initiated without a full understanding of how
the environment is being used.

Planning a Migration to Exchange Server 2007
Whether you’re performing the migration in-house or bringing in a
consultant, your migration team will need some core information during the
planning phase. First, you’ll need to understand the business rationale behind
the migration. Key questions you need to answer are in three areas:
Business Drivers
• Will Exchange Server 2007 reduce existing operational costs?
• Will you be able to consolidate servers and reduce storage needs? If
so, can you estimate cost savings and confirm these are based on
actual pre-migration metrics (i.e., predictive modeling)?
• Where does the Exchange migration fit in to your list of priorities?
• What are three high-level successes you must achieve in Exchange-
related projects -- planned or in progress -- to ensure the CIO gets an
annual bonus?

Technical Drivers
• What are the current or most recent challenges within the Exchange
environment?
• What have been the top three critical events affecting the environment
over the past year and the past three years?
• What opportunities exist around consolidation of e-mail and voice
messaging systems?
Logistics
• Who are the members of your migration team? Do you have
management representatives for projects, corporate support, servers,
messaging, directories, desktops, infrastructure and networks?
Once you answer these questions, you’ll then need to perform an accurate
and comprehensive inventory assessment of your entire Exchange
environment. If you’re a consultant, this should be part of your standard
environment review process. In most cases you won’t find all this information
in one place, or you may not have a record of any of this at all. If that’s the
case, you’ll want to invest some time creating and maintaining an accurate
inventory. This will give your organization the agility to respond rapidly to a
crisis or ongoing Exchange-related initiatives. You can collect this information
manually or via commercial software packages. You’ll find a sample of a
thorough Exchange assessment in the section below titled “Sample Exchange
Assessment Questions.”
Once you’ve performed your pre-migration assessment to help plan the post-
migration environment, you’ll want to perform some modeling forecasts to
ensure that the new environment can sustain the expected loads. You’ll need to
take into account the varying loads on your existing Exchange environment as
gathered during your assessment (message, quantity and volume). Based on
site, server and storage consolidation gains you expect, you can forecast loads
for the new environment. If you can estimate growth rates for mailboxes (e.g.,
10-percent growth in number of mailboxes, year over year) and for Exchange
storage (e.g., total mailbox store sizes will double every year), then you’re well
on the way to validating your migration plans.
Finally, as you commence your migration, you’ll want to regularly reassess your
environments to look for unusual or unexpected trends, and to ensure your
migration is taking place as planned. (In some cases you’ll have multiple
Exchange organizations, depending on how you migrate.) Having an adequate
Exchange assessment mechanism in place before you start your migration
planning is critical to your success in moving to Exchange Server 2007.

Sample Exchange Assessment Questions
This section provides a detailed example of the many questions that you
need to answer as part of an Exchange assessment. If you’re doing the
assessment in-house, use this list to make sure you haven’t missed anything.
If you’ve decided to bring in outside help, compare the results of the
consultant’s environmental review with what’s on this list. Either way,
answers to the questions on this list should give you a clear understanding of
what’s in your Exchange environment and help you reduce risks in your
Exchange migration or Exchange-related projects.

Windows Environment
Versions
• What’s the current Windows environment?
o Windows NT?
o Windows 2000?
o Windows 2003?
Forests
• Is AD deployed?
• If so, what’s your forest model?
• Are multiple forests involved?
Domains
• What’s the domain model in place?
o Are you using a master domain model?
o Multi-master model?
• Where is Exchange implemented?
o In master account domains? In resource domains?
o In a single domain? In multiple domains?
Trusts
• What’s the trust model in place?
Servers
• Is Exchange installed on any domain controllers?
• Is there a global catalog (GC) server local to every Exchange server?
o How would you describe the GC model?

Accounts and Mailboxes
• Are dedicated mailbox containers in use (e.g., Exchange 5.5 recipients’
containers or organizational units in AD)?
• Are dedicated custom recipients or contact containers in use?
• Are dedicated distribution lists/distribution group containers in use?

Infrastructure Environment
• What is the network architecture supporting the Exchange
environment?
o Where are primary and remote data centers and offices located?
o What speed connectivity exists between primary sites?
o What speed connectivity exists between remote sites?
• What are the types of domain name systems (DNS) in use (e.g., AD
integrated, BIND, split-brain)?
• What are the internal and external DNS zones, MX records, forwarders
and zone transfers?
• Have DNS MX records been tested (e.g., telnet to port 25)?
o What happens if an SMTP server becomes inaccessible? Does
mail queue up somewhere? Has this been tested and confirmed?
• Are smart hosts in use?
• Describe the Windows Internet Naming Service (WINS) topology.

Exchange Environment
Versions
• What versions are in the environment?
• Is it mixed mode or native mode?
Organizations
• How many Exchange organizations are present?
• What are the organization names?
• Have organization names (display name or CN) ever been changed?
Sites/Routing Groups
• How many Exchange sites/routing groups are there?
• What are their names?
• How many servers are in each?
• Is the AD site design appropriate for e-mail routing?

Servers
• How many Exchange servers are there?
• What are the Exchange server names?
• What version of Exchange is running on each server?
• What service pack and/or hotfixes are installed on each Exchange
server?
• What is the locale for each Exchange server (e.g., U.S. English,
German, French)?
• What is the function of each Exchange server (e.g., mailbox, public
folder, bridgehead, X.400, NNTP, Internet mail, chat, front-end SMTP
or virtual server or SMTP connector, front-end HTTP or OWA, front-end
POP3, front-end IMAP4, T.120 multi-point control unit (MCU) Exchange
conferencing server (ECS), Windows 2000 multicast address dynamic
client allocation protocol (MADCAP), ECS host, instant messaging and
connector for Lotus notes, GroupWise, SNADS, IBM PROFS, or Mobile
Information Server Enterprise Edition)?
• Is the Exchange Best Practices Analyzer (ExBPA) tool in use?
• Are these Exchange servers dedicated to a primary function, or are
they multi-function servers?
• What was the first Exchange 5.5 server (if applicable) in each site? If it
was removed, was it removed properly or simply turned off?
Third-Party Servers
• What third-party Exchange-related servers or appliances are in place?
o Anti-virus (gateway-scanning, store-scanning)
o Anti-spam (in-house or hosted)
o E-mail archiving
o Secure messaging
o Unified messaging
o Wireless messaging
o Workflow
o Electronic forms
o Document management
o Records management
o Fax
o Backup
o Electronic discovery

o Storage management
o Event management
o Performance management
o Diagnostics
o Reporting
o Monitoring
o Instant messaging
o Desktop search
o Others
Storage
• How many storage groups do you have?
o What are the storage group names?
o Locations?
o Is full-text indexing in use?
• How many stores do you have?
o What are the store names?
o Locations?
• What types of stores are in use?
o Mailbox stores?
o Public stores: (MAPI and non-MAPI top-level hierarchies, or
TLHs)?
Mailboxes
• How many mailboxes are there?
• What are all the key attributes (e.g., display names, aliases, server,
associated accounts, hidden)?
Public Folders
• How many public folders are there?
o What are all the key attributes (e.g., display names, server,
SMTP address, if mail-enabled)?
• How is public folder replication configured?
o Is hub-and-spoke replication in use?
o What is the replication topology?
o Have any public folder replication issues occurred?

Contacts
• How many contacts [and custom recipients for 5.5 users] are there?
o What are all the key attributes (e.g., display names, server,
SMTP address, parent container)?
Distribution Groups
• How many distribution groups and query-based distribution groups are
there?
o What are all the key attributes (e.g., name, e-mail address,
scope, type --i.e., query-based or static)?
Connectors
• How many connectors are there?
• Identify the following for each connector:
o Name
o Type
o Costs
o Application (e.g., *, @exchange.mydomain.com, etc.)
SPAM
• Are Exchange 2003 real-time block lists (RBLs) in use?
• Is Exchange 2003 sender filtering in use?
• Are intelligent message filters (IMF) in use?
• Is Microsoft Forefront Security in use?
Virtual Roots
• How many virtual roots are there?
• Identify the following for each virtual root:
o Virtual root names
o Associated servers
o Virtual root type (e.g., HTTP, POP3, SMTP, IMAP4)
o Listen on IP (e.g., any, 10.1.1.20)
o Host header (e.g., any, http://header1.mydomain.com)
Queues
• What are queue names for each key server?
• What’s the associated virtual server name?

Client Access
• What clients are in use?
o Outlook 9x via MAPI
o Outlook 2000
o Outlook 2003 via MAPI
o Outlook 2003 RPC over HTTP
o Outlook Express via IMAP4
o Outlook Express POP3
o Entourage
o HTTP or HTTP/S (OWA)
o ActiveSync
o Other
• What mobile clients are in use?
o Smartphones
o Windows Mobile 5.0
o Windows Mobile 6.0
o Good Technology
o RIM Blackberry
o Other
• Are virtual private networks (VPNs) in place?
o Why are they used?
• What client-side authentication mechanisms are used to accomplish
the following:
o Access Exchange?
o NT Authentication?
o Log on ‘locally’ using Outlook?
o Log on ‘locally’ using Outlook Express?
• Is Outlook 2003 cached mode in use?
• Do any existing definitions of low, medium and heavy users exist?
What are they?
• Is Loadsim used for testing?
• What client operating systems are in use?

Collaboration and Development-Related Inventory
• What Microsoft SharePoint solutions are in use?
• What organizational forms (OFs) libraries are in use?
o Names?
o Locales?
o Associated organization?
• What types of E-forms are in use?
o 16-bit MAPI?
o 32-bit Outlook?
o ‘Web store’ forms?
• Are any application-specific web store schemas in place?
• Are any transport or store event sinks in place?
• Are any non-MAPI top-level hierarchies in place (i.e., have any non-
MAPI public stores been created for custom applications)?
• Are any Windows Server 2003 AD application mode (ADAM) schema
partitions in use for custom applications?
Directories and Lookup
• Are any meta-directories in place?
• Is directory synchronization in place (automated or manual) between
the Exchange directory or AD and any other data source/directory?
• Is there an inter-org synchronization tool in place anywhere?
o Has it been used previously in production?
• Are offline address books (OABs) used?
• Are multiple global address lists (GALs) in use?
o How are security access control lists (ACLs) defined to ensure
uniqueness per user?
• Are multiple Exchange 5.5 address book views or Exchange 2000/2003
address lists (ALs) in use?
o How is security configured for these?
• How long is free/busy information published by all Outlook clients?
• Is free/busy information published to any FTP servers?
• Is free/busy information replicated across all sites?

Security Authorities
• Is Microsoft Windows Rights Management Services in use?
• Are certificate authorities in use for Exchange?
• Is two-factor authentication required for access to any Exchange-
related functionality or data stored anywhere in Exchange?
• What kind of security is required for data center access?
o How is this enforced for lights-out data centers?
• What kind of security policies are in place?
o Is there a security officer in place?
o What’s this person’s role with respect to Exchange operations?
• Are security devices (e.g., smart card readers, retinal scanners)
required for access to anything related to Exchange?
Administration and Management
• If applicable, what’s the Exchange 5.5 service account name?
o Is the password secure?
o Is the password ever changed?
o What happens when someone who knows the password leaves
the company?
• Which accounts/groups have:
o Service account level access to Exchange?
o Full administrator level access to Exchange?
o Administrator access to Exchange?
o View-only administrator-level access to Exchange?
o Rights to modify the configuration container (Exchange 5.5) or
configuration naming context or CNC (Exchange 2000/2003)?
o Rights to modify the organization container (Exchange 5.5)?
o Rights to extend the AD schema?
• Have administrative rights been delegated (Exchange 2000/2003) to
any users/groups?
o Are users enabled to modify their distribution list/group
membership?
o Are any self-service administration tools in place?
• Are there any mailbox-only administrators?
• Are there any distribution list/group-only administrators?

• Is security clearance required for certain levels of administrative
access to the Exchange environment?
o What levels are required and how are these obtained?
o How is this enforced?
o What happens when someone with administrative access leaves
the company?
• Is Exchange administered centrally?
o If not, how is Exchange ownership distributed across the
business units of your company?
• Who is notified of critical events to do with Exchange?
o Is this automated?
o What tools are in place to achieve this?
• Who is notified of e-mail-borne viruses detected in the Exchange
environment?
o How are these detected?
o How (and how often) are virus definition lists updated?
• How are notifications sent (e.g., by e-mail, pager, messenger service,
instant messaging, phone call, manual)?
Risk Management and Ownership
• What are the business impacts if the entire messaging system (or a
critical region) becomes unavailable? What if downtime occurs for:
o 1 hour?
o 4 hours?
o 8 hours?
o 24 hours?
• Who has ultimate authority for the corporate messaging system?
o What is the reporting tree from this person down to the
Exchange administrators and support personnel?
o Whom does this person report to?
• Who has day-to-day operational responsibility for the Exchange
environment?
o How would you define success in Exchange
planning/deployment/management for this individual.
• Is there any part of Exchange operations or support that is
outsourced?
o To whom?

o If this is an application service provider (ASP), is your
messaging system on a shared or dedicated hosted
environment?
• Are any high availability solutions in place?
Backup and Recovery
• What backup software is in use?
• Are any Continuous Data Protection (CDP) solutions in use?
• How are changes in the backup vendor and version tracked
historically?
• What backup rotation scheme is in use?
• What on-site and off-site backup media storage locations are in use?
• How is backup media inventoried and who has access to inventories?
• How is backup media secured during transport and storage and who
has access? Is access logged in any way?
• Is deleted item retention in use?
• Is deleted mailbox retention (Exchange 2000 and higher) in use?
• Are Exchange 2003 recovery storage groups in use?
• Is item-level recovery provided as a service to end-users? To
executives?
• Is an Exchange recovery environment or lab maintained? How would
you describe it?
Provisioning
• Are there any self-service provisioning tools in place?
• Are there any bulk-provisioning tools in place?
• Are there any electronic workflow tools in place to facilitate repetitive
tasks (e.g., e-forms for request and/or workflow for new user creation,
human resources notification)?
• Are there documented processes or tools in use for simplification of
the creation, modification or deletion of:
o Mailboxes?
o Distribution lists?
o Contacts?
o Public folders?
o Other Exchange-related objects?
• Do you provision various groups of users differently? For example:

o Are company executives’ mailboxes placed on a specific storage
group, store or server?
o Are attributes used to identify or differentiate between groups of
users (i.e., is custom attribute 1 set to “Executive” or something
similar)?
Policies
• Describe the addressing policies in place:
o Internal SMTP namespaces (e.g., @mycompany.com,
@myothernameformycompany.com)
o Recipient policies (e.g., SMTP, X.400)
o Detail templates
• Do the SMTP transport policies allow:
o Out of office (OOF) to the Internet?
o Automatic replies to the Internet?
o Automatic forwarding to the Internet?
o Non-delivery reports (NDRs) to the Internet? Action on NDR?
o Preservation of display names to the Internet?
• Describe the storage policies in place:
o Mailbox quotas (warning, prohibit send and prohibit
send/receive)
• Describe other traffic polices related to:
o Message size limits for internal e-mail
o Message size limits for e-mail to the Internet
o Maximum recipients per message
• Can you provide a copy of all written corporate policies, such as:
o E-mail policy?
o Security policy?
o Disaster recovery/business continuity plan?
o E-mail compliance policy?
o Change management (and patch management) policies?
Usage
• Is usage tracked for:
o E-mail?
o Phone?
o Instant Messaging?

• What are per-server traffic patterns (e.g., quantity and volume
messages, system and user-generated traffic) for the following periods
of time:
o Last week?
o Last month?
o Last year?
• What are forecasts for future time periods?
• What are inter-server delivery times?
o Is there an established service level agreement (SLA) for intra-
organizational message delivery?
o Are there bottlenecks in SMTP transport evidenced by low
delivery times?
• Based on usage patterns and new functionality in Exchange 2003 and
Outlook 2003 cached mode, are there opportunities for site and server
consolidation?
• Are there opportunities for storage consolidation?
• What are top mailbox sizes?
• Who are top senders and receivers (e.g., by quantity and volume)?
o What about to and from the Internet?
• Which distribution lists or groups are used the most?
o Which are not being used?
• Which Public Folders are empty?
• Which Internet SMTP domains receive the most mail from the
company?
o Which Internet SMTP domains send the company the most e-
mail?
o Do these appear to be used for business-related or personal
purposes?
o Is this appropriate based on the company’s e-mail policy?
o Can I estimate how much personal e-mail is costing the
company?
• Is the company sending/receiving e-mail to or from questionable
domains?
o Pornographic sites?
o Competitors?
Is this appropriate?
Is there liability associated with this?

Clean-up and Server Health
• Are there servers with unnecessary open ports?
o Is this a security risk?
• Which servers are causing bottlenecks?
o Do we need to add CPU, faster disk, etc?
• Which mailboxes are consistently exceeding quotas?
o Do we need to educate users?
o Do we need to deploy archival solution?
o Do we need to increase quotas?
o Do we need to increase storage?
• Which mailboxes have no quotas set?
o Are we risking mail loops or DDOS attacks filling our server disk
drives and compromising messaging system availability?
• What needs to be cleaned up prior to migrating to Exchange Server 2007?
o Which cleanup operations would reduce software licensing costs
as part of a migration or for ongoing operations?
o Are there orphaned mailboxes (i.e., mailboxes without an
associated account)?
o Are there inactive mailboxes (i.e., mailboxes that haven’t been
accessed or that haven’t sent any mail over a given period of
time)?
o Are there duplicate display names in the environment that will
cause problems, mid-migration?
o Are there disabled accounts that don’t need to be migrated?
o Are there mailboxes owned by NT groups that will fail mid-
migration?
o Are there empty Public Folders that can be cleaned up?
Hopefully you’ve found these sample Exchange assessment questions to be
useful. Of course, you’ll need to fine-tune this list and add any questions you
think are missing, but this should give you a good starting point to ensure
that from now on your Exchange assessments are as thorough as possible!

Pre-Migration Assessment with Quest MessageStats
As shown in the previous section, there are a large number of questions that
you need answered during an Exchange assessment. You need to do both a
one-time and an ongoing gathering of information to determine trends and
traffic patterns. Given the busy workload of most Exchange administrators,
these tasks will seem daunting. Quest MessageStats streamlines these tasks
and make it easier for administrators to perform a complete assessment.
MessageStats not only provides information for migration, but it can also
measure e-mail traffic, report policy compliance, defend SLAs and ensure
sufficient capacity during and after a migration. It offers high-level, business-
focused reports with graphics, metrics, interactivity, drill-down capabilities
and powerful customization. MessageStats allows administrators to perform
a complete Exchange analysis prior to migration to facilitate planning for
both the migration and the new Exchange Server 2007 environment.
MessageStats provides a wide range of reports to accomplish Exchange
assessments, as shown in Figure 1 and Figure 2.

Figure 1. MessageStats provides a high-level view of your corporate
Exchange environment.

Figure 2. MessageStats provides detailed inventory reports.

Please visit http://www.quest.com/messagestats/ for more information about
MessageStats.

Summary
Exchange assessments are an important part of the process in planning for a
migration. Administrators must have detailed information about their
Exchange environment to plan properly and thoroughly before a migration.
Exchange is a complex platform that has a lot of moving parts.
Administrators must examine all of these parts in an Exchange assessment
and consider each one when planning for migration. There are a lot of
questions that need answers, but Quest MessageStats can provide assistance
that will dramatically save time and reduce expenses.

ARCHIVE BEFORE YOU MIGRATE

Introduction
Gone are the days of multi-million, multi-year migration deals. The goal of
most organizations today is to shorten the time it takes to migrate so they
can begin using their new messaging environment. After a thorough
discovery of their messaging environment, many organizations discover a
bloated system with a massive number of files that are large, outdated and
unused, costing the organization a lot of expense to store and maintain. You
should give serious consideration to archiving that data before migrating to
Exchange, since data older than one year has a less than a two percent
chance of being accessed again.
Dealing with the data bloat issue prior to migration will provide many
benefits during the migration process. Most importantly, it speeds up the
migration and shortens the co-existence period. Also, you can achieve
greater efficiency in storage operations by accurately archiving non-accessed
data to a data management system. In addition, you can provide this data in
a platform that is less expensive than Exchange storage solutions. Lastly,
you will minimize data loss, and reduce or eliminate the impact of migration
on end users.
This section of the document will discuss the problems of data bloat in many
messaging environments and the benefits of using Quest Archive Manager to
archive before you migrate.

Defining the Problem
Storage
Exchange administrators are often surprised when they go into a migration
project and realize just how much data there is to move. E-mail traffic has
increased so much that a once-small messaging system deployed simply for
communication has become a major collaboration tool. Users now send each
other documents for collaboration, schedule meetings, keep track of
contacts, and assign tasks to manage projects across teams. E-mail systems
don’t just send messages anymore.
Not only is the e-mail traffic increasing but the size of the documents
exchanged in e-mail messages is also growing. Users now swap large files
such as large PowerPoint presentations, photos and even videos. Exchange
was never designed as a file repository, yet there is an ever-increasing trend
toward storing large files in e-mail folders.

As e-mail traffic and exchanged files increases, so does the amount of
storage required to keep a messaging system running efficiently. In the
context of migration, the larger the mailbox or information store is, the
longer it will take to migrate that data. Since migrations have some impact
on existing IT resources, it is advantageous to reduce the amount of data in
the e-mail system to shorten the time it takes to migrate.
Data Retention
Messaging is arguably the most mission-critical application in any
organization. If e-mail goes down, users lose the ability to communicate
with customers, take orders and collaborate with other members of their
team. When it is down, you are losing employee productivity and revenue
from customers.
Since e-mail is such a critical part of day-to-day operations, it is no surprise
that users are storing more and more e-mail records for longer periods of
time. But referencing old e-mails and documents is not just important to
individual users. Administrators need to quickly find information to defend or
protect their company in legal or compliance matters.
With employees keeping all the e-mail they deem important and companies
struggling to retain all proprietary data, the size of e-mail storage is
ballooning. But how do administrators know which data is still relevant and
which data can be purged before a migration project? They don’t – and it
would be quite costly as well as practically impossible to have them make
these determinations. Asking users to constantly review all of their files and
store them efficiently would actually decrease productivity and impact
operations. Even if users could take the time to do this, they typically lack
the knowledge to do it properly and the recall to do it according to uniform
company practices. Ensuring consistency in e-mail storage standards
throughout the organization would be a daunting endeavor.
Single-Instance Storage
Another issue that administrators have to tackle during a migration project is
the loss of single-instance storage, the process by which several e-mails or
files in a messaging system with exactly the same data will reference that
data from a single stored copy of an e-mail or file. This saves space in a
messaging system because only one copy of a file or e-mail sent to several
users is stored.
Single-instance storage is completely seamless to end users. They see the
data as just another e-mail and do not know that each person who receives
the same e-mail is referencing the same piece of data.
Single-instance storage is tracked only by the information store or database
that the data is stored in. Therefore, if that data is migrated between two
Exchange organizations or from foreign e-mail platforms, single-instance
storage is lost. This can cause a dramatic increase in the storage size
needed on the target platform to store the same amount of data that existed

on the source platform. In some cases, administrators may need to increase
their storage requirements by 75 to 90 percent.
There are really no options to work around the issue of single-instance
storage without a third-party solution. Typically, the administrators are
tasked with the uncertain job of estimating the increase in the size of storage
needed post-migration.

Archiving Before Migration
When carrying out a migration project, it is essential to reduce the amount of
data that needs to be migrated, while ensuring that legacy data is retained
and easily accessible. It’s also important to reduce storage requirements by
retaining single-instance storage. Quest Archive Manager meets all of these
needs. It is a comprehensive solution that makes e-mail a true asset for
organizations. Archive Manager captures, indexes and stores messaging data
for easier mailbox management, compliance and knowledge-sharing. In the
following sections, this document will discuss the benefits of using Quest
Archive Manager prior to migration.
Data Reduction
Using Quest Archive Manager, Exchange administrators can effectively strip
all e-mail data prior to a set date or archive attachments above a set size.
All data identified according to this criteria is removed from the Exchange
store automatically and placed in the archive. Users or administrators are not
required to sort through mailboxes and remove messages that might be too
large or that are not referenced any longer. A special shell of that message,
also called a stub message, is left behind in the e-mail box. This stub
message looks like a normal e-mail message but is merely a pointer that
allows the user to have seamless access to archived data, as shown in Figure
3. This is true whether they are using Outlook, Outlook Web Access,
Blackberry or mobile support.

Figure 3. Stub e-mail message in Outlook.

When used before a migration, Quest Archive Manager reduces the amount
of data that needs to be migrated as well as the time it takes to complete a
migration. Users are provided with a limitless mailbox size allowing them
access to critical data when they need it. This will also shorten the
coexistence period in migration.
Data Retention
As mentioned in the previous section, Quest Archive Manager can archive a
user’s e-mail that is older than a pre-defined date. This older, rarely
referenced e-mail is stored in the archive. It is still easily accessible and
searchable by users and administrators. Users would not need to deal with
personal storage files (PSTs) and mailbox quotas. In fact, Quest can assist
you in collecting PSTs company-wide, and prevent PCs from generating PSTs
in the future.
Using Quest Archive Manager before a migration also allows administrators to
comply with internal and external data retention requirements. All archived
data remains searchable through the Archive Manager platform in case it is
needed for a legal or regulatory purpose.
Data Maintenance
Using Quest Archive Manager before a migration allows administrators to
reduce the amount of storage they will need on the target Exchange servers
by providing single-instance storage after the migration. The pointers to the
archived data are migrated into the target mailboxes, allowing access to that
data. This minimizes the risk of increased storage requirements during a
cross-organization migration. It also allows administrators to save money on
storage hardware and see improved performance and stability from their
Exchange servers.
Multiple Platform Support
When Quest Archive Manager is used alongside Exchange tools, data can also
be archived from other platforms such as GroupWise. This minimizes the
amount of data created from the conversion to the Exchange platform.
Data can also be archived from Lotus Notes prior to migration. Quest Notes
Migrator for Exchange can be used to export filtered data from Notes to PSTs and
those PSTs can be imported directly into the archive. This greatly decreases the
amount of time it takes to migrate from the Notes platform to Exchange.
After a migration has occurred, administrators no longer need to maintain
multiple data stores to house e-mail data or to maintain non-Exchange systems
for accessing legacy data. All data from GroupWise and Notes can be stored in a
user’s archive and easily accessed from Outlook or Archive Manager.

Summary
Managing the massive amount of existing data in a messaging environment
is an important part of the migration process. Since the cost for storage is
considerably less than it used to be, organizations just keep buying more
storage. But with a full data center, they require a small army to manage
that data.
Quantifiable benefits come from reducing the amount of data for migration,
retaining access to legacy data after migration, and maintaining single-
instance storage during migration. Quest Archive Manager is the tool needed
to achieve these benefits and help organizations begin using Exchange
Server 2007 more quickly.
With Quest Archive Manager, you can avoid multi-million dollar, multi-year
migration engagements. In addition, you can take full control or your data
and unlock its potential. Consider using Quest Archive Manager to archive
before you migrate.
Please visit http://www.quest.com/archive_manager/ for more information
about Quest Archive Manager.

MIGRATING TO EXCHANGE SERVER 2007

Introduction
Now that you have performed your pre-migration assessment as well as
archived your existing data, you can migrate to Exchange Server 2007. This
section of the document will cover the migration process from a high level.
It will discuss the types of migration, the one you should choose, and why
your choice would make sense for your organization. The process discussion
will focus heavily on a cross-organization (cross-org) migration which is
typically the best, lowest impact approach. It will present all of the
components you need to perform this type of migration. Quest’s migration
solutions will also be introduced.

Transition or Migration?
Microsoft defines the two paths for moving to Exchange Server 2007 as a
transition and a migration.
A transition occurs when an Exchange organization is upgraded to Exchange
Server 2007. As shown in Figure 4, Exchange 2007 servers are added to the
existing Exchange 2000/2003 organization and mailboxes are moved to the
new servers. Coexistence is not really needed since users already share a
GAL and public folders, and can continue to communicate within the same
organization. Because Exchange Server 2007 runs on a 64-bit platform,
there is no path for an in-place upgrade.

Exchange 2000 Exchange 2007

Exchange 2000 Exchange 2007 Exchange 2000 Exchange 2007

Existing Exchange 200x New Exchange 2007
Organization Organization

Figure 4. Transition

A migration occurs when data from a non-Exchange platform or from an
existing Exchange organization is moved to a new Exchange 2007
organization without retaining any of the configuration of the original source
organization, as shown in Figure 5. For non-Exchange platforms, this is the
only way of migrating to Exchange Server 2007. For Exchange platforms
there is a choice between migrating and transitioning.

Coexistence

Exchange 2000 Exchange 2007

Exchange 2000 Exchange 2000 Exchange 2007 Exchange 2007

Existing Exchange 200x New Exchange 2007
Organization Organization

Figure 5. Migration with coexistence

Microsoft supports a transition if you are moving to Exchange Server 2007
from the following platforms: Exchange 2000 or Exchange 2003.
Microsoft supports a migration if you are moving to Exchange Server 2007
from the following platforms: Exchange 2000 or Exchange 2003 or Lotus
Notes.
Microsoft offers no transition or direct migration path from Exchange 5.5.
User accounts must first be moved to a supported platform such as Exchange
2003 and then transitioned to Exchange Server 2007. This is a major two-
stage project that most administrators will not want to attempt. A third-
party tool is the only solution for moving directly from Exchange 5.5 to
Exchange Server 2007.
Obviously, if you are coming from Exchange 5.5, or a Notes or GroupWise
platform, you will perform a migration to Exchange Server 2007. But if you
are coming from Exchange 2000 or 2003, then the choice is not so obvious.
Here are reasons you may want to perform a migration from Exchange 2000
or 2003:
Merger or Acquisition – If there are multiple organizations involved and
you want to consolidate those in the process of migrating to Exchange Server
2007, then a migration is the clear choice. It is the only way to merge two
or more existing organizations.

Complex Infrastructure – If your current environment is complex,
requiring administration from many different groups, then a migration may
be an easier path. You might also consider a resource forest for Exchange
Server 2007 if there’s separate administration for AD and Exchange groups.
Routing Groups – Routing groups are no longer available in Exchange
Server 2007. Instead, Exchange now uses site topology in AD to send e-mail
within an organization. If this topology is not optimized for e-mail traffic,
you can perform a migration to a new forest with Exchange Server 2007 that
is already optimized for e-mail traffic.
Low Impact – Performing a migration to Exchange Server 2007 is lower-
impact. If done properly, a cross-org migration leaves the source
organization completely intact. Other users excluded from the migration are
not affected and migrated user accounts can be rolled back if there is a
problem. This also eases the pilot stage of the migration project.
Whichever path you choose, be sure that it meets all of your business needs
and goals. Also, ensure that it will have little to no impact on your current
environment and on your users.

The Migration Process
Here are steps in the process for a low-impact cross-org migration to
Exchange Server 2007, followed by some details for each one:
• Deploy Exchange Server 2007
• Deploy Outlook
• Connect foreign systems
• Establish coexistence
o Directory synchronization
o Public folder replication
o Calendar and Free/busy synchronization
• Mailbox migration
• Profile updating
• Decommission source system

Deploying Exchange Server 2007
Let’s assume that you have already deployed Exchange Server 2007 in your
new target environment. In doing so, you used the data from your pre-
migration assessment to decide where all servers will be located and where
users and their mailboxes will reside. You also chose the options to keep
public folders for free/busy lookups. In addition, you decided that you will

initially migrate public folders from the source organization and retain them
until they can be moved to SharePoint. Once Exchange Server 2007 is fully
deployed and has been tested in the target environment, you can move on to
migrating the users and their data. Since this document is focused on
Exchange migration, let’s assume that the user accounts have already been
migrated or populated in AD, and are waiting to be mailbox-enabled to
receive data.

Deploying Outlook
This is a step that may be optional for you. If you already have Windows
machines with Microsoft Office installed, you may already have Outlook
deployed in your environment. In fact, if your source system is Exchange
5.5, Exchange 2000 or 2003, then certainly you already have Outlook. But if
you are migrating from Lotus Notes or GroupWise, you will need to deploy
Outlook and set up profiles for the users that will be migrated to Exchange
Server 2007. This can be done through SMS or Group Policy.
You may also want to upgrade your Outlook clients to Outlook 2007.
However, at this point in the migration, it is not crucial to do this. It might
even be easier to upgrade those clients after you complete the migration.
The major consideration here is that some of the features are only available
with Exchange Server 2007. The way free/busy is handled in Outlook 2007
may also be an issue. To prevent users from having an incomplete
experience with the new Outlook client, migrate them first and then deploy
Outlook 2007 after all clients have been migrated. This will give them all of
the features available in Outlook 2007 and will not create any compatibility
issues. Since Outlook 2007 is not supported as a client to Exchange 5.5, the
move to Outlook 2007 will have to occur after the migration.

Connect Foreign Systems
Foreign systems are mainly Lotus Notes and GroupWise. Since you will want
users to continue to communicate and schedule meetings with each other
during the migration, you will need a connection between the Exchange
Server 2007 server and GroupWise or Notes. If your source system is Lotus
Notes, you can do this easily through the connector offered by Microsoft (in
beta). The connector will provide directory synchronization, e-mail
redirection, and scheduling along with free/busy lookups between the two
systems. It is important to establish this before the migration begins so that
you can provision any users, as necessary, in AD.
For GroupWise, it is not so easy to create a connection. Microsoft has
discontinued support for the GroupWise connector in Exchange Server 2007.
You can, however, still connect to an Exchange 2003 server. This means
that you will need to install an empty Exchange 2003 organization prior to
establishing this connection. Then, you will need to upgrade that organization

to Exchange Server 2007, keeping at least one Exchange 2003 server in the
environment as a bridgehead server for the GroupWise connector.
Please note that you can execute most of the functions of these connectors
through SMTP routing for e-mail and iCAL for calendaring. The experience
for the end user is not as rich, though, and these two technologies do not
always retain the message formatting the sender might have intended.

Establish Coexistence
Migrations do not occur overnight or even over a weekend. They usually
take from a few weeks to a few months -- or even a year if you are a large
organization. In the meantime, you still need to provide your users
messaging functionality. At some point during the migration, some user
accounts will reside in Exchange Server 2007 and some will still reside in the
source system. This is where coexistence comes in to play.
Coexistence between the source messaging environment and Exchange
Server 2007 should cover three key areas of synchronization: directory,
public folder and calendar. Synchronization in these three areas should
allow administrators to generate a copy of their current messaging
environment in their target Exchange Server 2007 system. It should be a
two-way synchronization so that any changes made by users that are already
migrated will be replicated back to the source. This keeps both systems
completely mirrored throughout the migration project.
The goal is that users won’t have to change the way they work just because
of a migration. In fact, they should not even know that it’s in progress.
Once migrated, they should see the same GAL they had in the source
environment and be able to send e-mail -- regardless of whether they were
migrated without additional steps. They should also be able to see a user’s
free/busy information to schedule appointments no matter where they are
located. Finally, they should be able to continue to work in the shared
workspace that public folders offer. If they make a change to a document in
a public folder, those changes should be viewable by other users no matter
whether they are located on the source or the target system.
Let’s take a deeper look at the components that make up coexistence to
ensure a seamless experience for users.

Directory Synchronization
The primary goal of directory synchronization is to establish a consistent GAL
between the source and target messaging systems for a seamless end user
experience. Directory synchronization should also provide administrators
with automated setup of the other required steps for migration.
Directory synchronization should include the automatic creation of mailboxes
and user accounts as needed. Most likely, you have already migrated user
accounts into AD. You will need to mailbox-enable these accounts so they

can receive e-mail migrated from the source system and so they will show up
in the GAL. If you are going through an acquisition where Exchange Server
2007 is in the target environment, you will need to create mailbox-enabled
users in the source system so that they can be seen in the GAL. These
“stub” accounts only need to have a forwarding address since these users
exist in the target.
Directory synchronization should also automatically set up mail redirection
for administrators. All of the user mailboxes created in the target Exchange
Server 2007 system should have a forwarding address directing messages
back to the same mailbox on the source system. This way, e-mails from
Exchange Server 2007 mailboxes sent to accounts still in the source
environment will reach those still using the source mailbox. Likewise, any
users that existed in Exchange Server 2007 prior to migration would need a
forwarding address set up on their corresponding source mailbox to forward
e-mail back to the mailbox they are actually using. This mailbox redirection
can be handled using the alternate recipient field, with hidden contact and
custom recipients, or by using the Target Address field in AD, as shown in
Figure 6.

Exchange 5.5 Exchange 2007

Alternate
Recipient

Contact
Figure 6. Mail redirection with hidden contact.

Directory synchronization should also include other objects outside of
mailboxes. Contacts, custom recipients, and distribution lists should also be
synchronized between the two systems throughout the migration period. For
example, if there are any changes to DL membership whether in the source or
in the target, those changes should be replicated between the systems. This
reinforces a completely mirrored environment between the source and target.
Directory synchronization should also enable replies to e-mails sent before
the migration occurred. This is accomplished by placing an x.500 address in
the proxy addresses of all mailboxes involved in the migration. This x.500
address represents the source mailbox in the target mailbox list of
addresses. When someone replies to an e-mail that was sent before
migration, the return address will resolve to the user’s new mailbox in
Exchange Server 2007.

Public Folder Synchronization
The goal of public folder synchronization is to provide a seamless workspace
between the two platforms and also to migrate the data to the new Exchange
2007 server. Public folder migration and synchronization involve the public
folder hierarchy, permissions and data within the folders.
Public folder synchronization should move the entire hierarchy in the source
Exchange server and mirror that in the target. This includes all public folder
root folders and the child folders. The operation should also enable a
consolidation or collapse of public folders so that the hierarchy can be
simplified on the target server, as shown in Figure 7. It should synchronize
the creation of new folders and the deletion of old folders so that public
folders can be managed from either the source or the target platform.

Source Org 1

Synchronize

Source Org 2

Figure 7. Combining public folder hierarchies.
Public folder synchronization should also include the synchronization of
permissions between the source and target systems. After users are
migrated, they should still be able to access the same public folders they
could access before the migration. If any permissions are changed during
the migration process, they should be kept in sync between the source and
target systems.
Last but not least, public folder synchronization should include the most
important part of the public folder migration: the data. The content within
the public folders should be kept in synch throughout the migration. If a
user works on a document in a public folder and makes some changes, those
changes should show up in that folder on the source and target servers. This
way, all users -- whether or not they have been migrated -- can see the
changes. And if documents are deleted or created, those changes should
show up as well.

Bear in mind that you should only do a public folder synchronization if you
have decided against offloading your public folders to SharePoint server. If
this is the case, then please see Appendix A for best practices for migrating
public folders to SharePoint.

Calendar and Free/Busy Synchronization
Another important requirement of coexistence is to provide users a way to
continue scheduling meetings with each other across the two environments.
Calendar and free/busy synchronization are two components in ensuring that
users still have this ability during migration.
Free/busy lookups are managed by the Schedule+ Free Busy folder stored in
Exchange when a user is using an Outlook client that is not Outlook 2007.
This folder contains a message with information about free/busy data for
each user. Periodically, this information is updated as users create and/or
accept new appointments and meetings. This folder needs to contain the
same information in both the source and target systems during migration.
As the data in the folder is updated in one system, the changes need to be
synchronized with the other system. This will allow users to still see
free/busy data for other users whether or not they have been migrated.
Free/busy synchronization is a great first step at Calendar coexistence,
however free/busy alone doesn’t provide necessary synchronization for
delegates of other user’s calendars or mailboxes used as meeting rooms and
other resources. In those calendars, users not only need to see free/busy
information but they also need to see the detail behind the free/busy data.
They need to know who has the resource scheduled and whether or not that
can be moved or edited. Administrative assistants need to be able to
schedule meetings for their managers. If they were migrated and their
supervisors were not, then they would have a hard time doing that.
Synchronizing the calendar item detail between two mailboxes will solve
these problems.

Mailbox Migration
Now, let’s say you have completed all the previous steps and have
established coexistence between your two environments. If you’ve done this
correctly, the target Exchange Server 2007 system is a mirror image of the
source. Users should see exactly the same things they did before they were
migrated. Migrate a few test mailboxes first to see if everything is working
fine. If so, you are now ready to start migrating the real mailboxes.
Mailbox migration should include all of the elements in the mailbox that are not
handled by calendar synchronization. Data from e-mail, contacts, tasks, notes,
journal items and all of the standard folders used in Exchange should be
migrated. This data should also include user-modified items such as custom
folders and permissions they may have given to others to view those folders.

The best practice for migrating mailbox data is a phased approach. The goal
is to minimize the impact on the Exchange server performance as well as the
traffic on the LAN or WAN segments through which data will travel. To
accomplish this, you should migrate the data in small chunks. And it’s best
to first migrate a small pilot group of users, and monitor their experience.
Mailbox migration should be a phased approach with continued
synchronization. Any new e-mail received and any changes made to the
mailbox or its data should be synched to the target mailbox.

Profile Updating
After your mailboxes are completely in synch, the entire source organization
is now completely replicated to the target. The only task that remains is to
simply switch the users from their source mailboxes to their target mailbox in
Exchange 2007. This is accomplished by changing the alternate recipient
information to redirect mail and by updating the users’ Outlook profiles.
Changing the alternate recipient information in Exchange simply involves
removing the information from the target mailbox and adding it to the source
mailbox. This will redirect e-mail to the target mailbox. After you do this,
users will no longer receive e-mail in their source mailboxes and only receive
it in their target mailboxes.
Profile updating should involve a solution that allows easy deployment from a
central location. It should run silently in the background so that users are not
troubled by confusing dialogue boxes. Profile updating should achieve more than
simply pointing the Outlook clients to the new mailboxes. It should also involve
updating other items that can only be modified through the client or those that
are stored with the client. This includes items such as the Outlook shortcut bar,
address books, rules, delegates, read/unread status and PST files. You will also
determine that there are many other items that should be updated as well. The
goal is to give users a seamless experience and allow them to retain as many of
their Outlook settings as possible.

Decommission Source System
After all users and data have been migrated to Exchange Server 2007, you
can remove any connectors you have in place and decommission the source
messaging system. This may simply involve removing the servers or just
ensuring that no one continues to access the source mailboxes. In Notes or
GroupWise migrations, you may need to keep these systems around for
awhile if there are Notes applications are still being used or other shared
resources that have yet to be migrated. It is important, however, to make
sure that users only have one mailbox after migration is complete. Having
users work in two systems that are not synchronized is not productive.

Migrating with Quest Software
As you can see, there are a lot of moving parts in a migration to Exchange
Server 2007. The goal is to minimize the impact on users as much as
possible and automatically provide true coexistence. Quest’s broad offering
of migration solutions, as shown in Figure 8, can help you do just that from
any major messaging platform.

Figure 8. Quest’s Exchange migration and management solutions.

Listed below is a brief overview of the solutions Quest offers to
migrate to Exchange Server 2007:
Quest Exchange Migration Wizard enables organizations to migrate from
Exchange 5.5 directly to Exchange Server 2007 with true coexistence and
ZeroIMPACT™ to the end user.
Quest Migration Manager for Exchange is a ZeroIMPACT™ solution for a
seamless Exchange 2000/2003 to Exchange Server 2007 cross-org
migration.
Quest Notes Migrator® for Exchange enables organizations to migrate
from Lotus Notes to Exchange Server 2007 with complete project
management and reporting while minimizing impact on users.
Quest GroupWise Migrator for Exchange is a comprehensive enterprise
migration solution from GroupWise to Exchange Server 2007 with minimal
user impact.
Visit www.quest.com/migration for more information about Quest’s Exchange
migration solutions.

Summary
There are two paths to Exchange Server 2007. The first is a transition that is
similar to an organization upgrade. The other is a cross-org migration. A
migration has much less impact on the Exchange environment but can have
a lot more moving parts that must be properly managed for success.
Understanding the process of a cross-org migration and how coexistence
plays a vital role is key to minimizing impact on users. Since there are so
many factors for success, you need to find the best solutions to accomplish
your goals. Quest offers solutions that enable seamless migration from all
major messaging platforms to Exchange Server 2007.

MANAGING EXCHANGE SERVER 2007

Introduction
Now that you have successfully migrated to Exchange Server 2007, you are
probably wondering what to do next. Most administrators are concerned
about finding tools that will allow them to effectively manage their new
Exchange Server 2007 platform. This section will discuss the two most
important aspects of managing any Exchange messaging platform:
availability and information management. It will also discuss the solutions
that Quest offers to help you achieve your goals.
Exchange Server 2007 is one of the most capable messaging platforms that
Microsoft has yet to deploy. But new features including anywhere access,
operational efficiency and built-in protection all translate into more
complexity within this new version of Exchange. To add features like built-in
protection and unified messaging, Microsoft had to create some specific
server roles to provide those functions. In fact, there are a total of five new
server roles in Exchange Server 2007. Microsoft also changed the way
messages are routed in this version of Exchange. Exchange now uses AD
site-based routing to deliver e-mail to appropriate locations. All of these
complexities change the way administrators need to think when they deploy
their new architecture.
Along with concerns about these new complexities comes the overall need to
make sure that your messaging system is available to end users and that the
information within the system is appropriately managed so that it remains
useful and relevant.

Messaging Availability
IT departments are responsible for making sure that users can access the
systems they put in place and need to make sure that business critical systems,
such as Exchange, remain available to the end users all of the time. To achieve
these goals, several things need to be considered and managed in Exchange.
First administrators need to ensure good health in their Exchange system.
The various servers within an Exchange Server 2007 organization depend on
each other to provide access and complete e-mail delivery. All servers within
the Exchange organization need to be watched for any potential problems
that may occur. Administrators need to receive warnings in advance of any
problems. For example, if disk space on a server is filling up then an
administrator needs to be alerted to the problem before that server crashes.
Dunn & Bradstreet estimates that 59 percent of Fortune 5000 companies
experience a minimum of 1.6 hours of downtime per week. That downtime
could be reduced or eliminated if IT administrators were alerted to problems
before they occurred.

Administrators also need to ensure that they can quickly resolve problems
when they do occur. Meta Group has estimated that one in four e-mail
outages last longer than 48 hours. For companies that rely on Exchange
24x7, this amount of downtime is simply unacceptable. When Exchange is
down and data is lost, administrators need the ability to restore that data
and the state of Exchange quickly so that downtime for users is minimized.
Sometimes an outage is unavoidable. In that case administrators need to
make sure that business continuity is not interrupted and that users can
continue to function as if Exchange had never gone down. Osterman
Research concludes that 79 percent of companies use e-mail as a form of
order acceptance from customers; 53 percent of companies had monetary
losses as a result of e-mail downtime; and 35 percent have even lost e-mail
data due to a technical failure of some kind. E-mail outages make
companies lose data, customers and money.
Quickly fixing any problems that do occur and restoring the system to its
original state takes time, so users should be offered a seamless, alternate
solution during the outage so they can continue to communicate without
changing the way they work. Because this is a very difficult mandate to
achieve, administrators should look for third-party solutions to assist them
with this task.

Messaging Information Management
Another issue facing IT departments is the ability to manage all of the
information stored in their messaging system. The problems of information
management in Exchange can be broken down into the following areas:
Managing Storage
Administrators need the ability to control and forecast the growth of data in
their environment. As mentioned in previous sections of this paper,
Exchange has become the storage place for many large, important
documents. The size of this data is growing at a very fast pace. By 2008,
the Radicati Group estimates that an average corporate email user will
process up to 15.8MB of data per day. Effectively managing and forecasting
data growth in Exchange will allow administrators to keep this problem under
control.
Compliance and Discoverability
With companies facing new regulatory compliance mandates, data discovery
has become an important area in messaging in recent years. Administrators
now need to have the ability to capture, index and recover all messaging
information in their environment. In 2005, Morgan Stanley dealt with this
problem first hand when it had to pay a penalty of $15 million, a large part of
which was due to their failure to provide e-mail evidence. Administrators

need to be able to effectively manage all data and information in Exchange
so it is safe, easily found and quickly recovered.
Maintaining the End-user Experience
ClearContext’s 2006 E-mail Usage Survey found 34 percent of people receive
between 50 and 100 e-mails per day. With that kind of traffic, it is no
wonder that users are losing valuable productivity spending time managing
their personal e-mail. Users need to worry about what e-mails need to be
saved and what ones can be deleted. They need to ensure that they do not
go over their mailbox size quota so they can continue to work.
ClearContext’s finding also makes it plain to see that users have come to rely
more on e-mail for communication. Administrators can provide users with an
improved messaging experience by managing storage on the back end to
eliminate user quotas and providing uninterrupted communication even in
the case of an outage.

Quest Management Solutions
Effectively managing the information contained within Exchange and
providing an environment that is available all the time are two enormous
tasks that can’t be taken lightly. With so much to consider and so much at
stake, it is important for administrators to look for vendors that offer
complete solutions for Exchange management. Quest Software offers a
comprehensive list of solutions that can assist in all management areas.
MessageStats
• Gauge messaging system usage
• Manage capacity
• Analyze, report and audit the messaging system
• Monitor e-mail usage and chargeback
• Pre-migration assessments
Spotlight on Exchange
• Detect, diagnose and resolve Exchange issues
Availability Manager for Exchange
• Ensure business continuity
• Provide seamless end-user experience during outages
• Allow continued communication
Archive Manger
• Archive all e-mail with single-instance storage
• Discover and eliminate PSTs
• Make historical messaging data available anywhere, anytime

• Eliminate mailbox quotas
Recovery Manager for Exchange
• Provide quick item-level recovery from Exchange backup media
• Discover e-mail data
Visit http://www.quest.com/Exchange for more information about Quest’s
Exchange management solutions.

Summary
In many ways, Exchange Server 2007 is the most complex Exchange version
released so far. In addition to dealing with these complexities,
administrators also need to make sure that their Exchange system is always
available and that the information within it is secure and managed. Quest
Software offers a comprehensive list of Exchange management solutions to
assist administrators with these tasks.

REFERENCES

2006 E-mail User Survey. San Francisco: ClearContext, 2006. Retrieved
from: http://blog.clearcontext.com/2006/05/clearcontext_20.html.

Bluestein, Greg. AP Release: Morgan Stanley Paying $15M for E-Mails.
New York: Associated Press, May 10, 2006.

E-mail User Statistics. Palo Alto, CA: Radicati Group, 2006. Retrieved
from: http://www.radicati.com/news/news.asp.

Sengupta, David. Understand Your Exchange Environment Better. Aliso
Viejo, CA: Quest Software, November 2006.

Contributors
The following Quest writers contributed to this document:
David Sengupta, Director Product Management
Peter terSteeg, Technical Director
Sergey Goncharenko, Software Analyst
Todd Landry, Product Manager
Rob Sargent, Product Manager

APPENDIX A: MIGRATING PUBLIC FOLDERS
TO SHAREPOINT

Note: To view appendices, right click on the thumbnail graphic and choose Open File from the dialog box.

APPENDIX B: EXCHANGE SERVER 2007
AVAILABILITY APPROACHES

APPENDIX C: UNDERSTAND YOUR EXCHANGE
ENVIRONMENT BETTER

Best practices for Exchange Server 2007 migration

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to Best practices for Exchange Server 2007 migration

Similar to Best practices for Exchange Server 2007 migration (20)

More from Balaji Ravi

More from Balaji Ravi (10)

Best practices for Exchange Server 2007 migration