Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS

Transcription

1 Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS Written by Nathan Winters, Unified Communications Lead at Grey Convergence and Declan Conroy, Founder of Cheddon Consulting Ltd WHITE PAPER

2 2010 Quest Software, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Quest Software, Inc. ( Quest ). The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document. If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters LEGAL Dept 5 Polaris Way Aliso Viejo, CA [email protected] Refer to our Web site for regional and international office information. Trademarks Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure, Benchmark Factory, Big Brother, BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender, DeployDirector, Desktop Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk Authority, Imceda, IntelliProfile, InTrust, Invirtus, itoken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin, MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!, PowerGUI, Quest Central, Quest vtoolkit, Quest vworkspace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle Map, SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon, Tag and Follow, Toad, T.O.A.D., Toad World, vautomator, vcontrol, vconverter, vfoglight, voptimizer, vranger, Vintela, Virtual DBA, VizionCore, Vizioncore vautomation Suite, Vizioncore vbackup, Vizioncore vessentials, Vizioncore vmigrator, Vizioncore vreplicator, WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. Other trademarks and registered trademarks used in this guide are property of their respective owners. Updated July 21, 2010 White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 2

3 Contents Introduction... 5 Exchange 2010 Key Functionality... 6 How the Features of Exchange 2010 Affect GroupWise Migrations... 7 Active Directory and the Global Address List... 7 No Native Tools... 7 Data Archives... 7 Migration Challenges... 9 Technical Challenges... 9 Ensuring Coexistence... 9 Migrating Data Logistical Challenges The Migration Schedule User Training and Support Deploying Outlook to the Desktop Cultural Challenges The Seven Steps to a Seamless Migration Overview Step 1. Perform a pre-migration assessment Step 2. Provision your Exchange 2010 mailboxes Step 3. Integrate GroupWise and Exchange Option 1: Exchange 2003 Connector for Novell GroupWise Option 2: SMTP Forward Domain Step 4. Establish a migration baseline Step 5. Run a pilot migration Step 6. Plan data storage Step 7. Migrate the data and track migration progress Tips and Best Practices for Migration to Exchange 2010 On-Premises Work with the product, not against it Know your numbers and your limits Run a directory export from each post office Forward mail sent using GroupWise Frequent Contacts White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 3

4 Enable GroupWise flat forwarding Plan conversion of GroupWise archives Scale your Exchange transaction log volumes during migration Be flexible with maintenance windows, but don t cancel them Outlook Client Configuration How the Features of BPOS Impact GroupWise Migration Bandwidth and WAN On-premises and Online Interoperability Personal Archives Tips and Best Practices for Migration to BPOS Directory Setup Connecting Clients with MAPI: the SSO Issue Administration Usability: End User URL Simplification Summary About the Authors Nathan Winters Declan Conroy About Quest Software, Inc White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 4

5 Introduction There has never been a better time to migrate to Microsoft Exchange Server from other messaging platforms such as Novell GroupWise. With the release of Exchange Server 2010, Microsoft s messaging system took a huge leap forward in terms of cost of ownership, flexibility of integration, and ease of both use and management, and it is now clearly the world s leading messaging platform. This white paper will help you understand the process of migrating from GroupWise to Exchange 2010 and the cloud, including how the features of Exchange 2010 will affect your migration. You will then learn seven steps and best practices to help you overcome any challenges and ensure a seamless transition. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 5

6 Exchange 2010 Key Functionality Exchange 2010 builds on Exchange 2007 s strong foundation, adding superb functionality in three key areas: Flexibility and Reliability. Exchange 2010 offers enhanced availability and redundancy, ease of management and deployment, as well as online integration. Specifically, Exchange 2010 has again improved on IOPS (input output per second) requirements, significantly improves continuous replication down to the disk block level, and introduces the Database Availability Group (DAG). In addition, Exchange 2010 has been specifically engineered to make use of low-cost, large-capacity storage in the form of 2TB+ SATA drives. Anywhere Access. Exchange 2010 provides access across mobile and desktop clients; this is a key component in making online deployments of Exchange possible. Exchange 2010 also makes things easy for the end user. For example, the Exchange Control Panel (ECP) is a simple, web-based control panel that enables end users to configure the way their mailbox works, such as changing distribution group membership and updating contact information. In addition, Mail Tips provides relevant information to users about they are about to send, reducing the number of undeliverable messages and accidents. Protection and Compliance. Exchange 2010 offers enhancements in data security as well. Its close integration with Active Directory Rights Management Services can help prevent data leaks, both within the organization and when working with partners. Security is provided by tight integration with the Forefront product suite, which can protect Exchange from viruses and spam either in the cloud or on-premises. Another key new feature for improved protection and compliance is archiving, which can have a big impact on migration and is explained in detail in the next section. These three sets of enhancements are all underpinned by the ability to integrate closely between on-premises and online deployments, enabling on-premises users to interact with those hosted online. The Microsoft Business Productivity Online Suite (BPOS) offers two types of online offerings, and it is important to understand the differences between them: BPOS-Standard (BPOS-S) is a shared service in which multiple customers share one hosted and collaboration environment. This offering is often adopted by small and medium-sized businesses with sizes ranging from a few hundred to several thousand users. However, it has the ability to scale up to approximately 30,000 users. BPOS-Dedicated (BPOS-D) is a managed service in which individual customers have their own dedicated and collaboration environment that Microsoft operates for them. BPOS-D is typically adopted by large organizations with 5,000 or more users. It gives you the flexibility to make changes and integrate more closely with your business systems than BPOS-S does. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 6

7 How the Features of Exchange 2010 Affect GroupWise Migrations Many of the new features of Exchange 2010 focus on providing enhanced levels of redundancy, availability, and simplicity for users, and therefore do not significantly affect migration from GroupWise to Exchange. However, there are some important differences between migration to Exchange 2010 and migration to earlier versions of Exchange. Active Directory and the Global Address List In Exchange 2010, the Global Address List (GAL) is the Exchange equivalent of the GroupWise Address Book. The GAL is a filtered view of Active Directory objects, showing both standard user attributes and Exchange attributes. GroupWise, on the other hand, maintains its own directory, much like Exchange 5.5 used to do. The GroupWise directory is the domain database, wpdomain.db. The user object, however, resides in edirectory, which is also called Novell Directory Services (NDS). The mailbox is created in the GroupWise domain database and linked or associated with a user object in edirectory. No Native Tools The most significant difference between the 32-bit versions of Exchange (2003 and earlier) and the 64-bit versions of Exchange (2007 and on) is the lack of Microsoft native tools for establishing GroupWise and Exchange coexistence. Microsoft s GroupWise coexistence tools, Novell GroupWise Connector and Calendar Connector, were discontinued in Exchange The lack of native coexistence tools impacts Exchange 2010 migrations because many third-party products rely on the native tools for some aspect of coexistence, such as providing free-busy calendar lookups between GroupWise and Exchange. If free-busy interoperability is required and you need to use the native tools, your only option is to use an Exchange 2003 bridgehead server in the Exchange 2010 environment and a supported version of GroupWise running the GroupWise Gateway. Data Archives An effective migration requires an understanding of the different types of data stores and archiving processes in both the old and new mail systems. The following archives are relevant in a GroupWise migration: GroupWise Archive. GroupWise archives differ from Outlook archives or Exchange 2010 Personal Archives in both layout and ease of use. The key differences are as follows: Within the GroupWise client, a user can simply right-click any message and archive it; Outlook autoarchive is driven by the archive wizard. The GroupWise Archive contains the same folder structure as the mailbox in its entirety; in Outlook, you can choose which folders to include in the archive. GroupWise archives are designed to be fully supported for local or network storage; Outlook.pst files that are used for either manual or auto-archiving are explicitly designed for local disk storage only. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 7

8 Outlook.pst files. Organizations frequently limit the size of Exchange user mailboxes to 5-10 GB to prevent performance problems. Therefore, users often move mail from their primary mailbox into a.pst file to keep their mailbox size down. They also use pst files for other purposes, such as to keep all mail from a certain year in a single file. Users can move mail into a pst file manually, or Outlook Auto-Archive can automatically move mail at a regular interval. However,.pst files have important drawbacks. They can be costly to store, difficult to back up, and inconvenient to use because they are available only on the local machine where they are stored. Moreover,.pst files represent a significant compliance risk, since there is no easy way to recover and present.pst data to auditors or regulators. Exchange 2010 Personal Archive. To address the problems with.pst files, Exchange 2010 introduces the Personal Archive, which operates as a secondary mailbox that can be stored either on the same or a different database as the primary mailbox. Mail is moved automatically from the primary mailbox into the archive based on the policies you set, so users can meet mailbox size requirements without creating new.pst files. Archived.pst files can be imported into the archive, so they can be managed, backed up, and searched as required by your organization. Unlike.pst files, the archive is fully discoverable and can even be put on litigation hold to prevent changes and deletions from destroying evidence. The Exchange Personal Archive works just like a user s regular mailbox, so no additional training is required. The archive works with Outlook 2007, Outlook 2010, and Outlook Web App, and is available anytime you have a connection to the Exchange server. Third-Party Archiving Solutions, including Quest Archive Manager. Third-party solutions like Quest Archive Manager extend the functionality built into the Exchange Personal Archive. Archive Manager simplifies and accelerates compliance initiatives with powerful search capabilities to retrieve and export relevant content for legal investigations. Granular retention policies provide more flexible control over the disposition of the ensuring that you keep only what you need. In addition, Archive Manager uses true single instance storage to reduce the amount of stored on your server and the archive; it stores message attachments separate from the message body and metadata and keeps only a single copy of an attachment. This reduces backup and restore times, and helps improve system performance. How do these archives affect migration? One key to a successful move to Exchange is to bring all of your data under the control of Exchange so it can be managed, backed up and searched. Quest offers tools that can migrate any GroupWise archives into Exchange or.pst files. The final exciting archiving development is that Exchange 2010 SP1 along with the Exchange 2010 version of BPOS will enable you to host the primary mailbox on-premises and the archive mailbox in the cloud. This means you could allow a third party (Microsoft) to manage your legacy archive data, including backups and storage, while maintaining closer control over your live business data in mailboxes. Migration tools like Quest GroupWise Migrator for Exchange support adoption of these hybrid on-premises/cloud environments by enabling migration to Exchange Server and Exchange Online. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 8

9 Migration Challenges There is more to a successful migration than installation of the correct software and patches. Migration challenges tend to fall into three broad categories: Technical Logistical (processes) Cultural (people) Technical Challenges Migration to an existing target Exchange 2010 system typically involves two technical stages: 1. Ensuring coexistence 2. Migrating data Ensuring Coexistence Some organizations opt to go with a big bang approach, migrating from GroupWise to Exchange over an extremely aggressive period, such as a weekend. This minimizes migration complexity and provides a uniform experience to all users. Quest GroupWise Migrator for Exchange can be scaled out to move large quantities of mailboxes in parallel. For example, GroupWise Migrator for Exchange can successfully move several hundred mailboxes and multiple terabytes of data in a 48-hour migration window, running on four migration servers. When planned correctly, a big bang approach can work for small and medium-sized organizations. However, most organizations migrate from GroupWise to Exchange over a longer period of time and require coexistence, which means the two systems behave, look and feel to the end users as a single system. This requires some thought in three areas: Directory synchronization Mail flow Calendar and free-busy lookups Directory Synchronization The first key coexistence step is provisioning of objects in Active Directory. If the AD object doesn t exist, it won t get a mailbox or appear in the Exchange GAL. Getting AD right is critical. When GroupWise and Exchange 2010 exist in parallel, both systems should have the same view and agree on the definition of users, groups and resources. Both systems need to display the same address book or GAL. If Active Directory objects are provisioned from edirectory using Microsoft Directory Synchronization Services (MSDSS) or Quest NDS Migrator, then GroupWise resources won t have corresponding Active Directory objects to mailbox-enable, and other steps may need to be taken before these resources can be migrated. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 9

10 Mail Flow Ensuring accurate and continuous mail flow requires planning for the following four cases: 1. Mail from non-migrated GroupWise users needs to be properly routed to users migrated to Exchange Mail from migrated users needs to be routed correctly to users still on GroupWise. 3. Mail from the outside needs to be routed correctly to GroupWise or Exchange, depending on which mail system the recipient is using. 4. Mail from either GroupWise or Exchange needs to be routed properly to the outside world. If you treat the combined mail system of GroupWise and Exchange as a whole, then you can address two simpler scenarios. Mail within the system. Mail to and from the system. Calendar and Free-Busy Lookups Exchange 2010 is a messaging and collaboration product. Legacy calendar content can be migrated easily, but collaborative use of calendaring between GroupWise and Exchange 2010 is not delivered by either product natively. Because both the Novell GroupWise Connector and Calendar Connector were discontinued in Exchange 2007, freebusy calendar lookup between GroupWise and Exchange 2010 can be accomplished only by using the Exchange 2003 native tool, Calendar Connector. Once configured for GroupWise, it then shares the Microsoft Connector for Novell GroupWise with directory synchronization and mail flow. Without free-busy information sharing, meeting requests will still work, but without the luxury of a scheduling assistant. Migrating Data The second stage of migration, and usually the longest and most visible to the end user community is moving data. Begin by asking the following questions: How much data do you intend to move? How much space does it consume now? How much space will it consume after it s moved? The choices for migration include: Not migrating New, empty mailboxes (every GroupWise user gets an empty mailbox in Exchange 2010, with no data migration) Legacy Exchange 2003 Server Migration Wizard Third-party tools such as the Quest GroupWise Migrator for Exchange Logistical Challenges The logistics of managing a GroupWise migration to Exchange include the following three areas: Migration schedule User training and support Deploying Outlook to the desktop White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 10

11 The Migration Schedule In its simplest form, a migration schedule needs to include a list of names and dates. Start with a definitive list of users, mailboxes, and resources, and then, with some careful coordination by office location and department, draft a migration schedule. Organizations often choose to migrate entire departments (or other groups of users that collaborate) at the same time because it reduces the need for collaboration between the legacy source and the new target system, and allows the staff to share their experiences and support each other during the process. Finding the right time for each department can be a challenge: you should consider the role that the department plays and any calendar or scheduling deadlines they may have, such as end-of-month for sales people, financial year-end for accounting departments, or shift schedules for businesses that operate outside of regular 9 5 office hours. Note that coordinating and managing migration logistics is a full-time job. Migrations go far more smoothly when this role is assigned and taken seriously than when a more laid-back and reactive approach is used. User Training and Support GroupWise and Outlook behave differently. As you migrate users to Outlook and Exchange, your processes and help desk staff need to be able to support them. The best way to smooth the transition for staff is to provide basic training at the right time. You don t want to train users too late, but if you train them too early, the training will be forgotten. Don t underestimate the work involved in coordinating training schedules as you migrate batches of users. Make allowances for each department s scheduling constraints, including sick leave and vacations, as well as for new employees. The content of the training is also critical. The vast majority of help desk calls after a migration fall into the following two categories: Training requests: How do I do in Outlook what I already knew how to do in GroupWise? Inconsistencies between source and target address lists. These lead to non-delivery reports (NDRs) caused by missing users or missing distribution lists or membership. To minimize training requests, choose a training course or trainer who doesn t simply cover textbook Outlook, but is familiar with issues for users moving from GroupWise. The most confusing topics to GroupWise users new to Outlook are delegate and shared access, send on behalf of, and send as. Also be sure to cover the GroupWise and Outlook features that sound similar but behave differently, such as message tracking options and message recall. The second type of support calls can be minimized by careful object and resource provisioning. When merging directories from GroupWise, edirectory, and Active Directory, be sure to look out for GroupWise or edirectory objects with slightly different spellings, and issues with maiden name versus married name when the address and GroupWise object are updated but the edirectory object isn t. Also be very careful that you don t end up with malformed SMTP addresses that GroupWise can handle but Exchange, with its more strict RFC compliance, can t. Deploying Outlook to the Desktop Don t overlook Outlook deployment and configuration. Outlook 2010 is the client of choice for Exchange 2010, and replaces GroupWise on the desktop. GroupWise and Outlook can coexist on the same workstation, but only if Outlook is installed last: if you install GroupWise over Outlook, then Outlook stops working. There are several ways to deploy Outlook: Group Policy, System Center Configuration Manager, or manual install. There are also many configurable options that can be customized and tailored using the Office Customization Tool, which has replaced the Custom Installation Wizard. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 11

12 Cultural Challenges The migration can cause great stress to both your IT department staff and your end users. Not everybody is going to welcome Microsoft Exchange. Users may have strong loyalty to GroupWise, and you may have to deal with fear, uncertainty, doubt, and possibly passive or even active resistance. Administrators may resist the change, especially if the migration to Exchange 2010 is likely to reduce the number of IT staff required. Don t underestimate the work involved in communicating and managing this culture change. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 12

13 The Seven Steps to a Seamless Migration Overview A successful migration should include the following steps: 1. Perform a pre-migration assessment 2. Provision your Exchange 2010 mailboxes 3. Integrate GroupWise and Exchange Establish a migration baseline 5. Run a pilot migration 6. Plan data storage 7. Migrate your data and track migration progress Step 1. Perform a pre-migration assessment Before you begin your migration, try to gain a really clear understanding of what will be involved and what criteria you will use to measure success. Agreeing that you are finished can be difficult if you don t agree up-front what finished is. Be realistic. In particular, understand that it is unreasonable to expect 100 percent of your data to be migrated successfully. GroupWise is a file-based mail system, and like any other mail system, it is prone to file or database corruption. In addition, not every GroupWise message type has an equivalent in Exchange. Therefore, the reality is that not every message in GroupWise will be intact after the migration. Pick an achievable threshold, such as that 98 percent of messages should migrate for 98 percent of mailboxes. Tracking the percentages is the key to any successful migration, and tracking results is only possible if you start with a pre-migration assessment. In addition to establishing completion criteria, you should ask the following questions: How many domains, post offices, and physical servers exist? How many mailboxes do you have? How many of these are expired, disabled, orphaned or unused? (Disabled or expired mailboxes can t be migrated by Quest GroupWise Migrator for Exchange) How much data is there between the combined mailboxes and archives? How much data do you intend to migrate, e.g., all, two years, or only the last six months? Will GroupWise archives be migrated to Exchange 2010 or to Outlook.pst files? How much storage do you estimate you will have after migration? You can use native tools like the GroupWise Utilities to list mailboxes and estimate data volumes. Use Quest GroupWise Migrator for Exchange to perform a Directory Export against each post office, and combine the data to obtain a definitive list of objects for migration. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 13

14 You should then pull a detailed statistics output from the GroupWise post office Library Maintenance. These statistics can be exported into a.csv file or Excel spreadsheet listing mailboxes with sizes and number of items, as shown below: Username Fullname Size (MB) Inbox Wastebin Sizelimit (MB) Threshold Exceeded UID FPierce Flavia Pierce percent No non GClooney George Clooney percent No abc RReagan Ronald Reagan percent No 2fr HFonda Henry Fonda percent No fro Figure 1. Sample pre-migration report on mailbox size This report gives you a definitive list of mailboxes, an approximate number of items, and an estimate of data size. Knowing the mailbox sizes is important; it enables you to batch mailboxes together with some confidence that no batch exceeds the capacity of the migration tool. Step 2. Provision your Exchange 2010 mailboxes When creating AD objects for Exchange 2010 mailboxes, remember that the GroupWise directory is separate from edirectory, and that GroupWise resources don't need edirectory user objects. These objects may need to be created using a different mechanism than regular user objects, if you have chosen to migrate user objects from edirectory. Step 3. Integrate GroupWise and Exchange 2010 You need to identify how you intend to provide directory synchronization between GroupWise and Exchange 2010 to ensure that the GroupWise Address Book and the Exchange Global Address List reflect the same users, distribution groups, and resources. Use SMTP routing to route mail between GroupWise and Exchange, and between the combined GroupWise/Exchange hybrid system and the outside world. Take note of message size limits and message formats. Mail flow with the outside world works as follows: In order for two mail systems to share a common mail domain, one system needs to be authoritative, and the other needs to be non-authoritative. Mail is passed to the non-authoritative system first, which delivers mail for any mailboxes it owns, and then passes (or forwards) mail for unresolved recipients to the authoritative system. The authoritative system is the end of the line: if it has a matching mailbox, it delivers the mail; if it doesn t have a mailbox, it generates a non-delivery report (NDR). Mail flow between GroupWise and Exchange can be achieved in either of two ways: Exchange 2003 Connector for Novell GroupWise SMTP forward domain White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 14

15 Option 1: Exchange 2003 Connector for Novell GroupWise If you implement an Exchange 2003 server in your Exchange 2010 organization, you can pass mail between GroupWise and Exchange 2010 using the Exchange 2003 Connector for Novell GroupWise. If your MX record points to GroupWise, GroupWise becomes non-authoritative, and forwards mail for unresolved recipients to Exchange. In order for the Exchange 2003 Connector to accept and process forwarded messages from GroupWise, it is often necessary to run the GroupWise Internet Agent (GWIA) with Internet Addressing Disabled, using the /DIA switch. Adding the /DIA switch can alter the SMTP addresses of delivered mail for your production GroupWise mailboxes. The Internet address for the GroupWise mailboxes is ignored, and mail is delivered to addresses that GroupWise builds from both the user ID and the foreign domain ID. If these are not the same as the SMTP addresses in use, mail is returned to the sender with an NDR. Regardless of where your MX record points to, Exchange or GroupWise, mail is delivered first to the non-authoritative system and then relayed to the authoritative one via the Connector. In this scenario, the GroupWise components of the connector predate HTML as a popular message format, so any messages are converted to plain text as they pass over the Connector. Option 2: SMTP Forward Domain The second and more popular option for SMTP routing between source and target systems is to use a forward domain. One system (usually GroupWise) keeps its live mail domain while the second system (usually Exchange) gets more than one mail domain per mailbox: the live one and a secondary mail domain, which is usually, but not necessarily, a sub-domain. Mail is forwarded from Exchange to GroupWise using the live production SMTP domain. This approach has some significant advantages. You know that mail delivery to the production SMTP domain works for the existing GroupWise system, and, most importantly, you don t have to make any changes to the production system. In GroupWise Migrator for Exchange you use the secondary address as a forward domain to send mail to users migrated to Exchange via client-side rules set by the Quest tool. Client-side forwarding offers some other advantages, because GroupWise can be configured not to delete or purge forwarded messages. This provides you with a safety net as you resolve unexpected or unplanned issues with mail size restrictions or quota limits between source and target systems. Flat forwarding in GroupWise, which allows mail to be forwarded from the original sender and not from the source GroupWise mailbox, is enabled via the /FLATFWD switch in the GWIA configuration. Calendar free-busy lookup is available only if before you install Exchange 2010, you setup an Exchange 2003 machine running the relevant coexistence connectors. Step 4. Establish a migration baseline After you obtain a definitive list of mailboxes for migration from your pre-assessment, you need to know how fast the data can be moved. This information comes from a migration baseline that is obtained by performing a controlled migration of a known quantity of production GroupWise data on a single migration server. Production data and production systems are critical for several reasons: You need to understand how the production environment is going to behave; a baseline in a lab environment does not provide that information. You can gain some level of expectation about message or database corruption, the number of instances of message type that don t exist in Exchange, and target thresholds to aim for based on your sample data. The migration baseline comes down to a number: the throughput in GB/hour. The throughput dictates how long the total data volume will take to migrate, and therefore how long the project will run. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 15

16 Throughput is a function of several factors, including the bandwidth available to GroupWise in a WAN environment and server performance as limited by memory or CPU. There are several ways to help optimize throughput. Quest GroupWise Migrator for Exchange is multi-threaded, and each thread moves a certain amount of data per hour; increase the number of threads and you increase your migration performance. Another option is to scale out instead of scaling up: if the migration server starts to get stressed, run two or more in parallel. However, scaling up or scaling out the migration infrastructure can overcome bottlenecks only up to a certain point. Somewhere along the line you are likely to hit an optimal throughput. Exchange 2010 Server by default will allow only 32 MAPI sessions for each migration account, and the legacy GroupWise server can cope with only so many client connections before the CPU exceeds 80 percent. Other factors that affect throughput are server and mailbox placement. Multiple GroupWise post offices running on multiple servers will give you better performance than having all of your mailboxes on a single server. In collocated onpremises GroupWise to Exchange migrations, we ve often seen throughput of GB/hour on a regular basis, but the figures vary, and we ve seen anything from 2-20 GB/hour. In general, 6-10 GB/hour is a good target to aim for. The migration baseline feeds into several other migration and planning activities, including: Planning the migration schedule. The baseline throughput per server multiplied by the number of migration servers dictates the volume of mail that can be moved, and hence the number of mailboxes per migration batch, as well as the number of required batches to complete the project. For example, in one real-world project we had to move 7.7 terabytes of mailbox data in a 12-week window. Given our baseline migration rate of 14 GB/hr, we had to schedule 563 hours of data migration. To get the migration done on time, we scaled out to three migration servers and ran two migrations per week, each with an eight-hour window. Establishing success criteria. The test migration used to establish the baseline will also help you estimate the number of errors to expect from the GroupWise data. Quest GroupWise Migrator for Exchange logs errors related to the consistency of GroupWise data, so you can set expectations with users about what data will migrate, what won t, and what conversion issues should be expected. Step 5. Run a pilot migration The goal of a pilot migration is to identify challenges you might face once full migration starts, and determine how to prevent or resolve them. Therefore, you should expect and even welcome problems during the pilot migration. A pilot must be large enough to capture a representative sample of the issues that can be expected during migration. If the number of mailboxes you are migrating is in the low thousands, including about 5 percent of the total user population should give a good sample; for extremely large migrations, the percentage can be smaller. Step 6. Plan data storage Before you begin migrating data, be aware that the amount of disk space required on the target can vary greatly from the source, depending on the version of GroupWise and the platform it s running on. Older versions of GroupWise running on NetWare servers, which are the most likely candidates for migration, use a heavily modified FAT32 file system, whereas Exchange 2010 uses NTFS. The effect can be a net reduction in volume post migration, even allowing for the removal of single instance storage (SIS). We ve seen 40 percent reductions in data volume based on the smaller sector size alone during migration. Obviously, sometimes the volume of data on target will be greater than the data on the source. The only way to know how your data is going to behave is to test it. Consider archiving before you migrate. Quest Archive Manager can archive mailbox content from GroupWise, then you can use Quest GroupWise Migrator for Exchange to very quickly move the small or empty mailboxes to Exchange, where the Outlook client reconnects the existing archive to the new Exchange mailbox for each user. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 16

17 Step 7. Migrate the data and track migration progress After migration of each batch of mailboxes, Quest GroupWise Migrator for Exchange produces a results log file for the batch that lists among other things, the total number of messages moved, the total number of messages filtered (skipped), and the total number of errors or warnings per mailbox. Individual logs for each migrated mailbox list the total number of messages and appointments the mailbox started with. Interpreting this data is not rocket science; add the number of filtered items to the number of moved items, subtract the number of errors, and divide the result by the total message count to calculate a percentage. If that percentage is 98 percent or higher, you can confidently sign off on the mailbox as a success. (In the real-world example below, the filtered message count is high because we applied date filtering to our migration.) MovedMsgCnt MovedApptCnt ErrorCnt TotalMsgCnt WarningCnt FilteredMsgCnt Percentage % 1, , , % 5, , % % , , % Figure 2. GroupWise Migrator for Exchange results log The results from a batch of migrated mailboxes can be dropped into a spreadsheet and graphed within minutes of completing the migration. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 17

18 Tips and Best Practices for Migration to Exchange 2010 On-Premises Over many migration projects, we ve picked up some general tips and advice that make a migration project from GroupWise to Exchange go more smoothly. Work with the product, not against it Don't try to make Exchange behave like GroupWise. The GroupWise client and server have different features and capabilities than the Outlook client and Exchange server. Try to take this into consideration from day one. It can be tempting to try to recreate something in Outlook and Exchange that worked in GroupWise, but you ll often be disappointed. Know your numbers and your limits Run enough test migrations to understand the performance limits of the GroupWise and Exchange systems and the migration infrastructure. Spend time with the logs and the numbers to understand the percentages of messages that migrate, or fail to migrate, and how fast data is moving. Run a directory export from each post office The GroupWise Migrator for Exchange Directory Exporter can see all objects on a post office, and all objects with GroupWise visibility set to system. It will not see GroupWise objects on post offices other than the one currently used by the Directory Export or any objects that are not set to system visibility. Run a Directory export from each post office, and combine the results to create a master list. Forward mail sent using GroupWise Frequent Contacts After a user is migrated, mail can sometimes still make it into the user s old GroupWise mailbox. The most common reason this occurs is that mail is sent by a GroupWise user using Frequent Contacts. GroupWise Frequent Contacts is similar to the Outlook nicknames cache; it s built up over time from the addresses you use when you send or reply to messages. It is used heavily in GroupWise, and in a local environment it often contains a GroupWise format address for local mailboxes. When a message is sent from a GroupWise client, the recipient can be selected automatically from the Frequent Contacts using this GroupWise format address, and even if the user has been migrated to Exchange, the mail is delivered locally to GroupWise. The client side forward is one way to handle this issue. Enable GroupWise flat forwarding With flat forwarding, mail sent from the GroupWise mailbox to the Exchange mailbox of a migrated user is seen as coming from the original sender and the recipient can reply to it. Without flat forwarding, such mail is seen as having come from the GroupWise mailbox that is doing the forwarding, which is less useful. You can enable flat forwarding on the GWIA using the /FLATFWD switch. Be careful about changing settings on the production GWIA because there could be dependencies on existing behavior. A better and safer option is to set up a new GWIA simply for SMTP coexistence and set the /FLATFWD switch on that GWIA. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 18

19 Plan conversion of GroupWise archives If you intend to use Quest GroupWise Migrator s Self-Service Desktop Migrator option to convert GroupWise Archives to Outlook.pst files, then you will need to retain the GroupWise client on the desktop. The Quest product is essentially client-side driven, and you need native GroupWise API s to open the GroupWise mailbox, then Outlook API s to open the Exchange mailbox, to move messages from one to the other. If you remove GroupWise from the desktop too early, or don t plan an alternative strategy for archives (such as copying them to a central location and processing them with the GroupWise Migrator for Exchange Admin-Driven Batch utility), you may not be able to convert archives. Scale your Exchange transaction log volumes during migration Exchange database changes are written to transaction log files. In a migration scenario, all migrated data is new data to Exchange and gets written to logs before it is committed to the database. Every 100 GB of database is also 100 GB of log files. Therefore, without correctly scaled log volumes, you run the risk of log volumes filling up during migration. Other options include circular logging or more frequent backups to clear down the log files during busy migration windows. During the migration, you should give Exchange 2010 the low-cost disk that it needs to allow for transaction logs to grow. Be flexible with maintenance windows, but don t cancel them Don t neglect regular maintenance of both the source and target systems during migration. Expect that maintenance and administration activities may need to change. In particular, remember the following: GroupWise maintenance has likely been scheduled to coincide with low productivity hours, such as evenings and weekends. These same low productivity hours will most likely be the first preference for migration, so the maintenance window may have to move, but it should not be simply cancelled. Remember that GroupWise mailbox maintenance is the single biggest resolution to migration issues. Exchange backups may have to be run more frequently to handle increased transaction logging with onpremises Exchange. Outlook Client Configuration There are very few client configurations we recommend, since what works for one organization may not work for another. However, there are a handful that keep coming up. First, Outlook can use two different formats for.pst files: UNICODE and ANSI standard. The most significant difference between these formats is the size: ANSI standard.pst files stop growing at around 2 GB, while UNICODE can grow to 20 GB. It s worth making some changes to your default Outlook install to accommodate UNICODE.pst files. The second important Outlook configuration we recommend is to include the Outlook Address Book as a service in the default Outlook MAPI profile. This service controls the availability of the Show this folder as an Address Book check box on the Outlook Address Book tab for contacts migrated from GroupWise. Without the MAPI Address Book service installed, migrated users can t actually use any of their migrated address books for automatic recipient resolution, which is a source of real frustration. Finally, two small configuration options that tend to be popular are to enable Spell Check by default and to set the default mail format to HTML. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 19

20 How the Features of BPOS Impact GroupWise Migration Bandwidth and WAN Because BPOS is not local to your users, bandwidth and WAN links can significantly impact your migration. Microsoft suggests that you should expect approximately 2 GB/hour throughput per migration instance. Multiple instances can be used. In real-world tests, we have found somewhere between GB/hour to be possible. This low throughput rate can cause two problems. First, the transfer has the potential to saturate slow or medium links, which could cause significant disruption to your business. Therefore it is very important to schedule migrations carefully. Second, the migration can potentially take a very long time, so planning and coexistence are important. It is also critical to ensure that you have redundant bandwidth. It is not uncommon for WAN links to go down, which can be very disruptive, and may reduce or even erase any return on investment (ROI) from migrating your mail online. Finally, when thinking about bandwidth, be sure to consider the user experience. Operating Outlook in cached mode will improve the experience of remote users; however, if users regularly send large attachments to each other, the attachments will first be uploaded to the server and then downloaded, potentially multiple times to individual clients, hurting performance. There is little that can be done about this problem, since using WAN accelerator appliances at each end of the link (a common approach) is not possible with the locked-down nature of BPOS. On-premises and Online Interoperability Another important feature of Exchange 2010 is the close integration and interoperability between Exchange Online and on-premises deployments. In particular, you have the flexibility to migrate some users to an on-premises solution while moving the bulk of your users to Exchange Online. In that case, you must consider how users will interact with each other across the two systems. Important features include mail flow and calendar free/busy. Mail flow is handled by making one system authoritative for the domain name and then creating a relay domain. This domain forwards any mail not for mailboxes owned by the authoritative system to the secondary system. The sharing of free-busy information between on-premises and online deployments will significantly improve with the Exchange 2010 version of BPOS because the Microsoft Federation Gateway will enable on-premises and online users to easily share calendars, tasks, and contacts with each other. Microsoft provides an easy-to-use, trimmed-down version of their directory synchronization tool, Forefront Identity Manager to enable the provisioning of users into the online service from an existing on-premises AD. The big difference from the on-premises deployment of Exchange is that you don t have to carry out schema extensions. Personal Archives As explained earlier, Exchange 2010 SP1 will enable you to host the primary mailboxes on-premises while hosting the archive mailboxes in the cloud. This means that you can have a third party (Microsoft) manage your legacy archive data, including backups and storage, while you maintain closer control over your live business data in mailboxes. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 20

21 Tips and Best Practices for Migration to BPOS Directory Setup During a migration to Exchange Online, it s a good idea to migrate the GroupWise directory to an on-premises Active Directory (AD). The Microsoft Online Services Directory Synchronization tool can then be used to synchronize the onpremises Active Directory with the hosted Active Directory. However, the Microsoft tool does not have the ability to filter which users it synchronizes, so it synchronizes all users from the local AD, including any legacy users. Therefore, it is a best practice to ensure that the staging AD is as clean as possible so as not to sync unnecessary objects to the cloud. When items are synced to the cloud, disabled accounts are created. These can be bulk enabled through the Microsoft Online Services Administration Center interface in batches of 250 when you start migrating mailboxes. Connecting Clients with MAPI: the SSO Issue For BPOS-S migrations, the MAPI profile configured for use with Quest GroupWise Migrator for Exchange, as well as all other Outlook mailbox profiles, must be set to use Outlook Anywhere, or RPC/HTTPS. RPC/HTTPS by default uses basic authentication, which prompts for a password. Microsoft provides a client-side single sign-on application tool to simplify this situation. This tool can be used with GroupWise Migrator for Exchange, but is not required. Administration Another fundamental difference with cloud messaging is ongoing administration. Active Directory is the central repository of resources and objects within a Microsoft environment. Active Directory was designed to provide a single point of administration for objects within an enterprise. This works when Exchange is installed locally in an Active Directory that the user is joined to, but things are not so simple in a hosted mail situation. BPOS does not require the local Active Directory to have the schema extended for Exchange 2010, so the Exchange attributes are not immediately available for use. This means that users have to be managed on-premises and synchronized into the cloud, while Exchange administration is performed via a web interface directly within the cloud. Usability: End User URL Simplification One final difference when migrating to the cloud is a technical point concerning usability. With BPOS, the URL provided for users to access OWA while on the move is long; it incorporates the MODRD (Microsoft Online Direct Routing Domain). This can make the switch difficult for users, since they can forget the new OWA domain. The solution is to create and use a suitable re-direct from an on-premises website. Then users have to type in a simpler, more memorable name, such as webmail.company.com, and IIS will redirect the users to the longer OWA BPOS URL. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 21

22 Summary Exchange 2010 offers important new functionality, including the ability to closely integrate on-premises and online deployments. For this reason, migrating from GroupWise to Exchange can offer significant benefits. Understanding the common challenges of migration and following the migration procedure outlined in this document will help ensure that your project is successful. White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 22

23 About the Authors Nathan Winters Nathan Winters is the unified communications lead at Grey Convergence, a specialist Microsoft partner for unified communications and collaboration. Nathan has been working in IT for eight years and specializes in unified communications with a focus on Microsoft Exchange and Office Communications Server. Nathan has consulted at numerous Fortune 100 companies across a variety of vertical markets. In 2006, Nathan founded the Microsoft Messaging and Mobility User Group UK, which holds regular meetings in the UK to discuss topics related to Exchange. In 2007, Nathan was named a Microsoft MVP (Exchange Server) for his work with MMMUG and his regular contributions to the Mark Minasi Forum, and he has received the same honor each year since. Nathan s articles have been published on leading websites and magazines, including Windows IT Pro Magazine, MSExchange.org, Simple-Talk.com, Microsoft (TechNet Industry Insiders), and the MMMUG website. You can contact Nathan at [email protected] or through his blog at Declan Conroy Declan Conroy has worked with Microsoft messaging solutions since MSMail. Declan has been a messaging consultant for 12 years and has worked for Compaq and Hewlett Packard. In 2004 Declan founded Cheddon Consulting Limited, an IT consultancy company that specializes in messaging migration to Microsoft Exchange and related technologies. To date, Cheddon Consulting has facilitated the migration of more than 250,000 mailboxes from platforms such as IBM Lotus Notes, Novell GroupWise and previous versions of Exchange. In his spare time, Declan likes to run barefoot and swim in open water. For further detail on any of the advice, tips, and experiences in this article, please feel free to contact Declan at [email protected]. If you have any questions, feel free to contact us. We would welcome your feedback to help us make future documents even better White Paper - Seven Steps for a Successful GroupWise Migration to Exchange 2010 and BPOS 23

24 WHITE PAPER About Quest Software, Inc. Now more than ever, organizations need to work smart and improve efficiency. Quest Software creates and supports smart systems management products helping our customers solve everyday IT challenges faster and easier. Visit for more information. Contacting Quest Software PHONE (United States and Canada) If you are located outside North America, you can find your local office information on our Web site. MAIL Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA USA WEB SITE Contacting Quest Support Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have a valid maintenance contract. Quest Support provides around-the-clock coverage with SupportLink, our Web self-service. Visit SupportLink at SupportLink gives users of Quest Software products the ability to: Search Quest s online Knowledgebase Download the latest releases, documentation, and patches for Quest products Log support cases Manage existing support cases View the Global Support Guide for a detailed explanation of support programs, online services, contact information, and policies and procedures. 5 Polaris Way, Aliso Viejo, CA PHONE WEB [email protected] If you are located outside North America, you can find your local office information on our Web site Quest Software, Inc. ALL RIGHTS RESERVED Quest Software is a registered trademark of Quest Software, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. WPW-7Steps4SuccessfulGroupWiseMigrat-US-AG