• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Quest_Software_Best_Practices_for_Exchange_2007
 

Quest_Software_Best_Practices_for_Exchange_2007

on

  • 2,001 views

 

Statistics

Views

Total Views
2,001
Views on SlideShare
2,001
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Quest_Software_Best_Practices_for_Exchange_2007 Quest_Software_Best_Practices_for_Exchange_2007 Document Transcript

    • 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