Home › Migrator for Notes to Exchange 4.16.0 Scenarios Guide

Migrator for Notes to Exchange 4.16.0 Scenarios Guide

File info: application/pdf · 72 pages · 791.03KB

Migrator for Notes to Exchange 4.16.0

Full PDF Document

If the inline viewer fails, it will open the original document in compatibility mode automatically. You can also open the file directly.

Extracted Text

Quest � Migrator for Notes to Exchange 4.16.1
Scenarios Guide

� 2020 Quest Software Inc.
ALL RIGHTS RESERVED. This guide contains proprietary information 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. The information in this document is provided in connection with Quest Software 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 Software products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST SOFTWARE 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 SOFTWARE 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 SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software 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 Software 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 Inc. Attn: LEGAL Dept. 4 Polaris Way Aliso Viejo, CA 92656 Refer to our website (www.quest.com) for regional and international office information. Patents Quest Software is proud of our advanced technology. Patents and pending patents may apply to this product. For the most current information about applicable patents for this product, please visit our website at www.quest.com/legal. Trademarks Quest and the Quest logo are trademarks and registered trademarks of Quest Software Inc. in the U.S.A. and other countries. For a complete list of Quest Software trademarks, please visit our website at www.quest.com/legal. Microsoft, Windows, Outlook and Active Directory are registered trademarks of Microsoft Corporation in the United States and other countries. Office 365 is a trademark of Microsoft Corporation in the United States and other countries. Domino is a registered trademark of International Business Machines Corporation, registered in many jurisdictions worldwide. All other trademarks, servicemarks, registered trademarks, and registered servicemarks are the property of their respective owners.
Legend CAUTION: A CAUTION icon indicates potential damage to hardware or loss of data if instructions are not followed.
IMPORTANT NOTE, NOTE, TIP, MOBILE, or VIDEO: An information icon indicates supporting information.
Migrator for Notes to Exchange Scenarios Guide Updated - November 2020 Software Version - 4.16.1

Contents

About the Migrator for Notes to Exchange documentation . . . . . . . . . . . . . . . . . . . . . . . . 5 About this Scenarios Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
About the Migrator for Notes to Exchange documentation suite . . . . . . . . . . . . . . . . . . . . 5 Other sources of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Scenarios overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 About Migrator for Notes to Exchange scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Migration to proprietary Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Migration to Microsoft Office 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Offline migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Phased (staged) migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Silent mode options in per-desktop migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Migration to a proprietary Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Migration to a proprietary Exchange target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Pre-migration preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Step 1: Install and configure your target Exchange environment . . . . . . . . . . . . . . . . . . 20 Step 2: Verify all system requirements are satisfied . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Step 3: Install and configure the Migrator for Notes to Exchange software . . . . . . . . . . 20 Step 4 (if mail routing using domain differentiation): Configure mail routing domains . . 24 Step 5 (optional): Configure coexistence strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Step 6 (for Exchange 2010 or later target): Configure throttling policy . . . . . . . . . . . . . . 25 Step 7: Discover Notes information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Step 8: Export Notes directory data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Step 9: Review and verify/modify exported data in the SQL database . . . . . . . . . . . . . . 26 Step 10: Define user collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Step 11: Provision AD with mail-enabled users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Step 12: Assess per-user migration volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Step 13 (when appropriate): Redirect inbound external mail to Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Step 14 (if necessary): Replicate or copy local data to a central location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Step 15 (if using smart hosts for mail routing): Configure smart hosts . . . . . . . . . . . . . . 30 Batch migration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Step 1: Sync the AD and Domino directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Step 2: Refresh the Migrator for Notes to Exchange SQL data . . . . . . . . . . . . . . . . . . . 32 Step 3: Reassess and refine user collection membership . . . . . . . . . . . . . . . . . . . . . . . 33 Step 4: Create Exchange mailboxes and perform Notes administrative operations . . . . 33 Step 5: Set Notes-to-Exchange mail forwarding, and migrate user data . . . . . . . . . . . . 34 Step 6: Distribute .pst files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Post-migration activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Step 1: Provision Notes groups into Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Step 2 (optional): Configure ongoing dirsyncs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Step 3: Update mail routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Contents

Step 4: Post-migration cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Migration to Microsoft Office 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pre-migration preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Step 1: Establish Office 365 account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Step 2: Verify all system requirements are satisfied . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Step 3 (if provisioning from local AD): Install and configure local Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Step 4: Install and configure Migrator for Notes to Exchange . . . . . . . . . . . . . . . . . . . . . 39 Step 5 (if mail routing by domain differentiation): Configure mail routing domain for Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Step 6 (only for coexistence with Quest CMN): Install and configure CMN components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Step 7: Discover Notes information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Step 8: Export Notes directory data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Step 9: Review and modify exported data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Step 10: Define user collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Step 11 (if you provision Office 365 from local AD): Provision local AD . . . . . . . . . . . . . 47 Step 12: Provision Office 365 from local AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Step 13: Assess per-user migration volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Step 14 (if necessary): Copy end-user local data to a central location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Step 15 (if using smart hosts for mail routing): Configure smart hosts . . . . . . . . . . . . . . 50 Batch migration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Step 1 (optional): Re-run directory connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Step 2: Refresh the MNE SQL data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Step 3: Reassess and refine (if necessary) user collection membership . . . . . . . . . . . . 52 Step 4: Create Office 365 mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Step 5: Grant Exchange Admin accounts Full Access rights to created mailboxes . . . . 54 Step 6: Run the Data Migration Wizard to set Notes-to-Exchange mail forwarding and migrate data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Step 7: Distribute .pst files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Post-migration activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Step 1: Provision Notes groups into Office 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Step 2 (optional): Configure ongoing directory coexistence . . . . . . . . . . . . . . . . . . . . . . 56 Step 3: Update mail routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Step 4: Post-migration cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
SSDM (per-desktop) migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 When to use the SSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Before running the SSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Configuring the SSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Silent mode options in per-desktop migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
About us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Technical support resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Contents

About the Migrator for Notes to Exchange documentation

� About this Scenarios Guide � About the Migrator for Notes to Exchange documentation suite � Other sources of information

About this Scenarios Guide
This Scenarios Guide is designed to help you prepare for your organization's migration from Notes to Microsoft Exchange using Quest Migrator for Notes to Exchange. These pages can familiarize you with Migrator for Notes to Exchange component tools, explain how those tools are used within the broader context of an overall migration project, and provide step-by-step instructions on how to prepare for migration and how to migrate the data in various scenarios.
This guide is intended for network administrators, consultants, analysts, and any IT professionals who will use the Migrator for Notes to Exchange (MNE) tools or participate in planning for a migration project.
The primary contents of this guide are divided into these chapters:
� Chapter 1: Scenarios Overview
� Chapter 2: Migration to a Proprietary Exchange
� Chapter 3: Migration to Microsoft Office 365
� Chapter 4: Per-Desktop Migration
Quest recommends that administrators read chapter 1 and browse chapter 2 or 3 (depending on the target type) to orient themselves to the various processes and how they vary from one scenario to another. If you intend to migrate any portion of user data using the MNE per-desktop Self-Service Desktop Migrator (SSDM) tool, read chapter 4. The process instructions in chapter 2 or 3 can serve as a step-by-step checklist when performing the migration tasks.

About the Migrator for Notes to Exchange documentation suite

This Scenarios Guide is one of several documents that explain various aspects of the Migrator for Notes to Exchange (MNE) product. The complete documentation suite includes:
� Quick-Start Guide: An orientation to Migrator for Notes to Exchange basic purposes, components and features, with a case study to illustrate typical usage. Also includes instructions for downloading and installing the software.
� Pre-Migration Planning Guide: A checklist of strategic and tactical issues that an organization must consider and accommodate before beginning a migration project. An appendix also documents known limitations of the migration process.
� Scenarios Guide: Descriptions of the most common migration scenarios--migrating to different target environments and for an array of other variables and preferences--with process instructions and flow charts that explain how to use Migrator for Notes to Exchange tools and features in each scenario.
� Administration Guide: Operational details, application notes and screen-by-screen field notes for the administrator components of Migrator for Notes to Exchange.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide About the Migrator for Notes to Exchange documentation

� Self-Service Desktop Migrator User Guide: Operating instructions, application notes and screen-byscreen field notes for the Self-Service Desktop Migrator (SSDM) component of Migrator for Notes to Exchange. The SSDM User Guide is provided as a separate PDF document so that an administrator can distribute it to any end users who will run the per-desktop program.
� Program Parameters Reference: A listing of all the Migrator for Notes to Exchange program parameters (and their valid values) in the Task Parameters and Global Defaults, and how to use them to control various program behaviors.
� Online Help: Context-sensitive field definitions and application notes for all the Migrator for Notes to Exchange wizards and other component applications.
All the documents, except the SSDM User Guide, are intended for network administrators, consultants, analysts, and IT professionals who will install the product, use its tools, or contribute to migration project planning. The PreMigration Planning Guide and Scenarios Guide present a more conceptual view of the product, while the Administration Guide provides the hands-on, screen-by-screen descriptions and field notes. The SSDM User Guide is intended for end users or administrators who will use the Self-Service Desktop Migrator component.
NOTE: Quest recommends that all administrators read all of the Quick-Start Guide and Pre-Migration Planning Guide (in that order), and the first chapter of the Scenarios Guide. Use the information to prepare a detailed written Migration Plan before attempting the migration process. When you are ready to begin the migration process, refer as needed to the process instructions and notes in the Scenarios Guide and the operational details in the Administration Guide.
Other sources of information
Visit our Quest online communities
The Quest Communities web site is an interactive online community dedicated to issues relating to:
� Migration of email, identity and applications to the Windows Exchange platform, either on-premises or hosted Exchange platforms like Office 365--including migrations from Exchange, GroupWise, and Notes.
� Active Directory migrations.
� Migrations from Notes application and Exchange public folders to Sharepoint.
� Coexistence strategies and tools.
The community is designed to foster collaboration between Quest Migration experts and users. It's a place where you can:
� Learn about product releases and betas before anyone else.
� Get access to Quest product leaders and subject matter experts on migration and coexistence.
You can browse around the forums and the library, but to take full advantage of the community, post new threads, respond to messages from others, and rate our documents and downloads, you must Join the community. If you already have a Quest account or are a member of another Quest community, Sign in. The Sign in and Join features are both available from links near the top-right corner of the page at the Quest Communities web site.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide About the Migrator for Notes to Exchange documentation

1
Scenarios overview

� About Migrator for Notes to Exchange scenarios � Migration to proprietary Exchange � Migration to Microsoft Office 365 � Offline migration � Phased (staged) migration � Silent mode options in per-desktop migrations

About Migrator for Notes to Exchange scenarios

The Scenarios Guide provides an overview of the process instructions that show how Migrator for Notes to Exchange (MNE) is used within a migration project. The processes described include steps that are performed outside the scope of Migrator for Notes to Exchange--within Notes and Exchange, and with coexistence tools such as the Quest Coexistence Manager for Notes (CMN)--because the sequence and interplay among the solutions and environments are important. Flow charts illustrate the correct sequence of steps for common scenarios.
Most migrations follow a similar basic process, with variations to accommodate each organization's circumstances and needs--collectively called a scenario. Most variations to the process result from:
� Migration Destination (the Exchange target type):
Proprietary (on-premises) Exchange network
A proprietary Exchange environment is one whose hardware and software are wholly under the control of the migrating organization. Ordinarily this is a local Exchange network--on the same premises as the Notes source, or at least near enough to use high-performance network cables. But a proprietary Exchange target can also reside in a different location from the Notes source.
Hosted Exchange platform ("the cloud")
A hosted Exchange platform is one in which the hardware and software are owned and controlled by a third party. The hosting entity sells, as a service, access to disk space and the Exchange software. This service model is also known as cloud computing. The overwhelming majority of migrations to a hosted Exchange are to Microsoft Office 365.
� Pre-Migration State of Existing Local Active Directory: Part of the migration process depends on whether your organization already has a local Active Directory running for login and security purposes and, if so, the state of any objects already provisioned there.
If you are migrating to a proprietary Exchange: Do you already have an Active Directory up and running? If an existing AD has already been provisioned, are its objects already mail-enabled, mailbox-enabled, or neither?
If you are migrating to Office 365: Will you use a proprietary local Active Directory to provision the hosted environment and, if so, will you keep the local AD active after the migration? This method of provisioning permits single sign-on, also called identity federation, so users can access Office 365

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

services with the same corporate credentials (user name and password) they use for the local Active Directory. Alternatively, you could provision Office 365 without a local AD by using Migrator for Notes to Exchange to provision Office 365 directly from the Notes/Domino source.
Different combinations of target types and states of an existing local AD produce an array of migration scenarios. This Scenarios Guide describes these combinations and summarizes the migration process for each:
� Migration to Proprietary Exchange:
No existing Active Directory (or no AD objects yet exist).
AD objects exist in Active Directory.
� Migration to Office 365:
Provisioning Office 365 from a local Active Directory.
Provisioning Office 365 directly from Notes/Domino source.
This guide also describes three special scenarios, each of which would occur in combination with one of the previously described scenarios:
� Offline Migration: A migration strategy in which Notes source data, previously extracted from Notes, is migrated directly to the Exchange target. This option supports scenarios in which it is impossible or impractical for the source and target servers to be connected to Migrator for Notes to Exchange at the same time and where data cannot be copied directly from the source to the target.
� Phased (Staged) Migration Options: A migration strategy in which all but the most recent source data is "pre-migrated" to Exchange while users remain active in Notes so that the remaining Notes data (a smaller volume) can be migrated much faster. Often users can be migrated together in a final cutover migration. Users continue to receive and send mail and manage their calendars in Notes throughout the transition period while their older data is migrated to Exchange. If the final cutover can be accomplished in a single day or weekend, this strategy can eliminate the need for email, calendar, and free/busy coexistence.
� Silent Mode Options: A strategy to configure the MNE Self-Service Desktop Migrator (SSDM), the perdesktop migration application, to hide some or all its screens, and obtain some or all of its required values from a pre-configured .ini file, thus eliminating or minimizing any need for interaction with the end user.
Chapters 2 and 3 of this guide provide step-by-step process instructions that cover these scenarios. Since all migrations follow the same basic process, with a few variations for particular needs and preferences, there are two linear procedures that are suitable for most scenarios:
� migration to a proprietary Exchange (chapter 2)
� migration to Office 365 (chapter 3)
Some steps in both scenarios are optional or conditional, depending on local variations in needs and preferences, and these are marked by an "If" icon and note:
Conditional Step: Conditional steps appear within the process instructions (in chapters 2 and 3) marked with this "If" branching-arrows icon.
Chapter 4 explains the administrative activities and considerations associated with per-desktop migrations which can occur with or without batch migrations, or may not be used at all--depending on your needs.
Migrator for Notes to Exchange pre-migration preparations and batch-migration processes are illustrated in two flow charts for each primary target type: proprietary (on-premises) and hosted (Office 365). The flow charts appear in this chapter as introductory process overviews, and appear again as references with the process instructions in chapters 2 and 3.
The process instructions are also meant to serve as summary checklists so they do not include the operational details and screen-by-screen field notes for the Migrator for Notes to Exchange component applications. Many steps in these procedures refer to those details in particular chapters and sections of the Migrator for Notes to Exchange Administration Guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

Migration to proprietary Exchange
A proprietary or on-premises Exchange environment is one where the hardware and software are wholly under the control of the migrating organization. A proprietary Exchange server is commonly in the same location as the source Notes environment, but might reside at another location.
When you are migrating to a proprietary Exchange, some steps in the procedures depend on the state of any objects that already exist in Active Directory (AD). An organization might have an existing Active Directory for login and security purposes. If user accounts already exist in Active Directory, Migrator for Notes to Exchange can use these objects to preserve the same credentials and security within the environment. AD objects must also be mailenabled and mailbox-enabled before data can be migrated for those users. (An object is said to be mail-enabled when Exchange can accept a message for it because the object record contains a forwarding address to which mail can be routed. An object is said to be mailbox- enabled only when it has an active mailbox in Exchange.)
If your target AD has is not yet installed and configured, or if your migrating Notes users are not provisioned into the target AD, pre-migration preparations include optional steps to install and configure the target Exchange environment, and provision and mail-enable AD objects.
NOTE: Exchange cannot send a free/busy query to an external server for a user who has an Exchange mailbox. Exchange can direct such queries only to the Exchange user mailboxes, so free/busy queries for not-yet-migrated Notes users work only if the users do not yet have Exchange mailboxes.
Since many organizations use the Coexistence Manager for Notes (CMN) Free/Busy Connector during the transition period, pre-migration preparations provision mail-enabled objects into Active Directory without mailboxes. Objects must be mail-enabled for mail-forwarding, but not before, so you do not create users' mailboxes until prior to their migration--in the batch migration process (per user batch). This mitigates the effects of the Exchange free/busy limitation by limiting its duration (the time between mailbox creation and migration).
If mailboxes already exist in target Exchange, free/busy queries to not-yet-migrated Notes users do not work until those users are migrated to Exchange. Optional pre-migration steps can be skipped, but some configuration and administrative tasks are still required before the migration can begin.
All scenarios include optional steps for coexistence, as described later. And pre-migration preparations include steps to verify all object target/forwarding addresses to ensure correct mail routing.
In these scenarios, an administrator runs Migrator for Notes to Exchange applications using accounts that are configured with the necessary permissions to access the directories and user data in both the source and the target environments.

Step-by-step instructions and detailed notes for migrations to proprietary Exchange targets appear in chapter 2.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

Migration to Microsoft Office 365
Migrator for Notes to Exchange can migrate to hosted Exchange services, typically to Microsoft Office 365 Exchange Online. Migration to Office 365 is similar to on-premises migrations, but there are key differences so the processes are described separately in this Scenarios Guide (chapters 2 and 3).

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

The account permissions required for migration to Office 365 are different from those required when migrating to proprietary Exchange since the hosted services are shared resources controlled by an external entity (Microsoft). Access to either target type is set at the mailbox level through Remote PowerShell, as described in the Migrator for Notes to Exchange Quick-Start Guide and Pre-Migration Planning Guide (see the System Requirements section in either book).
Throttling and throughput
Office 365 introduced throttling on user connections which impacts migration performance. The throttling is a peruser limitation that reduces throughput after more than two connections by a single user (including the <MigrationAdmin> user). With previous versions of Exchange Online, migration throughputs of 3-5GB/hr per machine were common. But the Office 365 throttling reduces typical throughput to 500MB/hr or less per machine.
Quest recommends that you use multiple migration machines (or virtual machines) running in parallel to achieve the desired throughput when migrating to Office 365. Use a separate unique <MigrationAdmin> account for each machine, to bypass the Office 365 throttling. Also, each migration machine should be configured with fewer threads (2�4) to optimize throughput.
Quest is working directly with Microsoft to test modifications to Office 365 throttling policies and their impact on migration throughput. It may soon be possible to modify the throttling policies to improve migration throughput. However, multiple migration machines with unique migration accounts may still be desirable and/or necessary for more efficient migration to Office 365.
Using an Admin account pool
Since Microsoft throttling is applied per administrator account, Migrator for Notes to Exchange runs multiple administrator accounts simultaneously on separate machines, each set to migrate with only one thread at a time. The net throughput becomes a function of the sum of all these multiple accounts' processing threads--one per administrator account.
MNE includes an Admin Account Pool utility that helps you manage a pool of Office 365 administrator accounts and to coordinate these administrator accounts. For information, see the "Office 365 Admin Account Pool utility" chapter in the NME Administration Guide.
Provisioning and mailbox creation
The Microsoft AD synchronization tool can provision Office 365 with object data from local AD by synchronizing the two directories. This provisioning method permits single sign-on or identity federation so users can access Office 365 services with the same credentials (user name and password) they use for local AD.
If you are provisioning Office 365 using the Microsoft AD Sync tool, from local AD, you can provision the local AD the same as for a proprietary Exchange target--using MNE features (with or without Quest CMN). The Microsoft AD Sync tool can provision the hosted AD from the local AD.
Migrator for Notes to Exchange can also manage mail routing throughout the project and perform several serveradministrative tasks commonly associated with migrations.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

If you do not have local Active Directory, you can use MNE to provision Office 365 directly from the Notes source and create the hosted mailboxes. Otherwise, you could provision a hosted AD manually using the Microsoft Office 365 admin portal. Many administrators use scripting to automate some portions of the process.
NOTE: Exchange-to-Notes mail forwarding requires mail-enabled objects in Office 365. However, an Exchange-to-Notes free/busy query (an Office 365 user seeking free/busy info for a Notes user) requires that the Notes user not have an Exchange mailbox. (Exchange cannot send a free/busy query to an external server for a user who already has an Exchange mailbox. Exchange can send such queries only to its own mailboxes.)
To have both Exchange-to-Notes mail routing and Exchange-to- Notes free/busy queries during the transition period, you must:
� Provision all Notes users into Office 365 as mail-enabled objects, but without mailboxes, before the first users are migrated.
� Do not create user mailboxes until prior to their migration (per user collection).
If you cannot provision objects and create mailboxes separately, one or the other of those two features will be sacrificed. Microsoft's AD Sync tool can provision mail-enabled objects from local AD into Office 365 without simultaneously creating mailboxes, but other provisioning methods create Office 365 mailboxes at the same time they create the mail-enabled user objects.
Provisioning Office 365 by any method other than by the Microsoft AD Sync tool (from local AD) makes it impossible to have both Exchange-to- Notes mail forwarding and Exchange-to-Notes free/busy queries during the transition period.
This Exchange free/busy limitation is irrelevant if you do not intend to configure any free/busy coexistence. In that case, provision all users (in all collections) into the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.
Mail routing
For most scenarios, inbound external (Internet) mail is not redirected to Office 365 until the last user has been migrated. We leave the MX record pointing to Notes throughout the entire transition period, and Migrator for Notes to Exchange can set Notes-to- Exchange forwarding for users as their collections are migrated. When the last user in the last collection is migrated, we update the MX record to redirect external inbound mail to the new hosted mailboxes.
If you want to keep your Notes environment running for a time after the migration, you should leave the Notes-toExchange forwarding in place, so any internal Notes mail is routed to the new hosted Exchange mailboxes.
Since inbound external mail is not routed to Office 365 until after all users have been migrated, Exchange-to-Notes forwarding is necessary only for internal mail from already-migrated Exchange users to not-yet-migrated Notes users. Mail routing in the Exchange-to-Notes direction requires mail-enabled objects in the hosted AD, but Exchange-to-Notes free/busy queries will not work if the Notes user already has an Exchange mailbox. (See the Important note in the preceding section for more information about this.)

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

If your organization wants both capabilities, you must use Microsoft AD Sync tool to provision Office 365 by directory synchronization from a local AD since that is the only method that lets you create mail-enabled objects and hosted mailboxes at different times. Provisioning from a local AD lets you create mail-enabled objects for all users in the Pre-Migration Preparations and to create mailboxes later during the Batch Migration Process--per user collection, prior to their migration.
If you are provisioning using some other method, you must choose whether you want Exchange-to-Notes mail routing or Exchange-to-Notes free/busy queries.
Directory coexistence with Office 365
A Microsoft-hosted Active Directory (for Office 365) imposes strict access restrictions that prevent direct directory coexistence between Notes and a hosted AD. With Quest Coexistence Manager for Notes, however, you could establish a "two-step" coexistence between Domino and Office 365 by this process:
1 Configure the CMN Directory Connector for bidirectional updates between Notes and a local, proprietary Active Directory.
2 Configure Microsoft AD Sync tool to synchronize the local AD with Office 365.
The combination of the two configures an effective directory coexistence between Domino and Office 365.
Mail, calendar and free/busy coexistence with Office 365
Office 365 introduces new options for coexistence and hybrid deployments. These include identity and calendar federation options that can be leveraged for Notes projects. Microsoft calendar federation requires a local Exchange server, but enables bi-directional free/busy lookups with Office 365 users.
Coexistence Manager for Notes can leverage this configuration to provide free/busy lookups with Notes users, although free/busy queries in the Exchange-to-Notes direction require that Notes users (awaiting migration) not already have an Exchange mailbox, which in turn requires that Office 365 be provisioned from a local AD by Microsoft AD Sync tool. (This is explained in the Provisioning and mailbox creation section.)
CMN also enables direct email and calendar coexistence with Office 365.
Offline migration
Migrator for Notes to Exchange supports scenarios where it is impossible or impractical for the source and target servers to be connected to Migrator for Notes to Exchange at the same time so the data cannot be copied directly from the source to the target. An offline migration is a strategy in which Notes source data that was previously extracted from Notes is migrated directly to the Exchange target.
An offline strategy can be useful:
� if problematic bandwidth makes direct connection impractical (for example, if the source and target servers are far apart geographically and/or from a network perspective).
� if the Domino environment is managed by a third party that does not allow administrative access.
� in a disaster scenario in which the Domino server is destroyed, but backup NSF files survive.
An offline migration can be accomplished by one of these two approaches:
� Notes source data is saved to replica or otherwise-disconnected NSFs, and the MNE Data Migration Wizard migrates from the NSF files directly to Exchange.
� The Data Migration Wizard migrates Notes source data to PST files (rather than directly to an online Exchange target), and the PST files are imported into the Exchange target by some other application. 'The Quest Migration Manager for PSTs is a good choice for this purpose.
The following topics provide specific requirements and guidance for these offline scenarios.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

How to save Notes data to NSF or PST files
For either NSFs or PSTs, you need:
� the main Notes Address Book containing all the objects you intend to migrate
� all mail files and archives.
� all personal address books.
� an admin ID file that can decrypt the data for all of these objects.
Saving Notes data to NSFs is a native Notes/Domino feature. If necessary, see the Notes documentation for more information.
Using Migrator for Notes to Exchange to migrate Notes data to PST files
� Configure the Migrator for Notes to Exchange Data Migration Wizard to migrate all data types to PST files either in the program UI, or by setting these parameters in the Task Parameters or Global Defaults:
[General] PABDest=PST ServerMailDest=PST ArchiveDest=PST
� Migrator for Notes to Exchange (MNE) may try to query and set information in the Exchange environment as part of the migration conversions, but the attempt will return an error if there is no direct connection to an Exchange server. To disable these verifications, set ACLs=0 in the [General] section of Task Parameters or Global Defaults.
� In the MNE Notes Migration Manager, on the Notes Server Configuration screen, ensure the Always use these values check box is not selected.

How to migrate from disconnected NSFs or PSTs to Exchange
In the MNE Notes Migration Manager (before you run the Data Migration Wizard):
1 On the Exchange Server Configuration screen, ensure the Always use these values check box is not selected.
2 Under Discover Notes Information:
1 On the Find NABs screen, load and enable the offline copy of the Notes Address Book. Locate and load the offline copy manually using the Add NAB button. (The Find NABs button does not work since the Notes server is offline.)
2 On the Find Domains screen, click Find Internet Domains to load the domains from the offline NAB.
3 On the Export Notes Directory screen, click Export Directory, to launch the MNE Directory Export Wizard, and:
a Click Edit to edit Task Parameters. In the configuration file, add the parameter offline=1 to the bottom of the [Notes] section. Save and close the file and click Next.
b On the Specify Notes Login Information screen for Domino Server, enter the name of the original Domino server from which the NAB files were copied. Specify the offline migration ID file and password for the User ID file and Password fields.
c Complete the Directory Export Wizard.
3 In the Notes Migration Manager, under User Collections on the Locate Notes Data Stores screen, click Locate data stores to launch the Notes Data Locator Wizard for the designated user collection.
1 On the Select Notes Data Store Type(s) to Locate screen, select Find new data stores and gather statistics, and set the Add/Replace mode to Replace data previously found....

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

2 Select the data types you want to locate and click Next.
3 Ensure that Scan file system directories that I specify is selected and click Next.
4 On the following pages, for each data type, browse to the directory where the items you want are located, and add them to the scan lists.
Note: You must specify the root folder, one folder above where the mail files are located. Also, the mail files must reside in a directory whose name matches the one from which the mail files came.
5 Complete the Notes Data Locator Wizard run.
4 Use the MNE Data Migration Wizard to migrate the NSFs or PSTs into Exchange.
Phased (staged) migration
The term phased migration or staged migration refers to the process of pre-migrating or pre-populating data to target Exchange mailboxes before the final cutover migration. The staged migration can occur across the bandwidth or, in many cases, be implemented in conjunction with the offline method previously described.
With a staged approach, most of the data can be pre-populated to the target mailboxes which reduces the volume of data that must be transferred during the final migration. Users remain active in Notes throughout the transition period, receiving and sending mail and managing their calendars in Notes while their older data is migrated to Exchange. After the older data is migrated, a smaller volume of remaining data can be migrated quickly so that a large numbers of users (or all users) can be migrated together within a shorter window. Since Migrator for Notes to Exchange migrates copies of Notes data (does not delete the originals), the older data is still available to users in Notes throughout the transition period.

With a phased migration, it is beneficial to separate older mail from newer mail. You can accomplish this using one of two methods:
� Replica method: The agreements created to replicate NSFs can be configured to limit the data included in the replica NSF. With this approach, the replicated data can be limited to the subset of information you want to include in the pre-cutover phase.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

� Date filter method: The Data Migration Wizard has integrated filtering options to specify date limits and ranges for messages to be migrated--to migrate only messages on or after (or before) a certain date, or within a range of dates. Date filters are applied only to mail and calendar items, and not to user contacts.
Migrator for Notes to Exchange also contains Smart Remigration technology so that previously migrated items are detected and not duplicated if they are inadvertently migrated again.
End-user communication is critical in a phased migration to ensure the users understand the migration schedules. Depending on the migration timing and configuration, modifications and deletions made in Notes between the migration events may not be reflected in Exchange after the final migration.
In a phased-migration, the Exchange accounts and mailboxes must be created to accept the migrated data before end users start using their Exchange accounts. Run the Migration Wizard at least twice for each user group:
� First Pass: Mailbox-enable the user accounts on Exchange, set mail-forwarding rules on Exchange (to forward mail back to Notes until the user is migrated), and migrate older user data to the new server.
� Second Pass: Reverse the mail routing (to forward mail from Notes to Exchange) and migrate the remaining data.
NOTE: A phased migration requires the creation of Exchange mailboxes for all Notes users as part of the pre-migration preparations. However, this strategy eliminates the need for free/busy coexistence since all users and their free-busy data remain in Notes throughout that period. Also, since all users migrate together during the final cutover migration, a phased migration removes the need for Exchange-to-Notes mail forwarding in most cases.
Silent mode options in per-desktop migrations
The Self-Service Desktop Migrator (SSDM) offers a Silent Mode configuration. This optional configuration is used to minimize end user involvement when the SSDM is deployed, while maintaining the flexibility and other benefits of a distributed migration.
When Silent Mode is configured, the migration team configures the application in advance within the notesdtapp.ini file to determine what data will migrate, the target for each migrated data type, and the filters and other configuration elements for the migration.
The SSDM Silent Mode options are described in chapter 4 of this guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Scenarios overview

2
Migration to a proprietary Exchange

� Migration to a proprietary Exchange target
� Pre-migration preparations
� Batch migration process
� Post-migration activities
Migration to a proprietary Exchange target
A proprietary or on-premises Exchange environment is one in which the hardware and software are under the control of the migrating organization. A proprietary Exchange server typically is on the same premises as the Notes source but could reside elsewhere. This chapter applies only if you are migrating to a proprietary Exchange target. If you are migrating to hosted Exchange, see chapter 3 (Migration to Microsoft Office 365).
Migration to a proprietary Exchange environment includes a few scenarios depending on whether the organization already has Active Directory (AD) configured and, if so, whether the objects that AD contains are mail-enabled, mailbox-enabled, or neither.
NOTE: A mail-enabled Active Directory object is one with a mail-address attribute for an address outside the Exchange domain so that AD can forward the object mail to its external address. A mailbox-enabled object is one that has an Exchange mailbox. An AD object that is mail-enabled cannot receive mail in Exchange unless it is also mailbox-enabled. A mail-enabled AD object without a mailbox can only forward mail to an object's external forwarding address.
An organization might have an existing Active Directory in place for login and security purposes. When user accounts already exist in an established AD, Migrator for Notes to Exchange can use these objects to preserve the same credentials and security currently in use within the environment, but the objects must also be mail-enabled and mailbox-enabled before data for these users can be migrated.
Your coexistence strategy also figures into this category of scenarios. For most organizations the migration plans include some form of coexistence which requires extra steps to configure and use.
This chapter provides process instructions and application notes for this group of traditional scenarios.
In these scenarios, Migrator for Notes to Exchange tools are run by administrator accounts that are configured with the necessary permissions to access to directories and user data in both the source and target environments.
Pre-migration preparations
Any migration scenario requires preparation of the source and target environments, configuration of administrator accounts, and preparation of the required software. Most also require configuration of a coexistence strategy. Premigration procedures can be time consuming because they include activities spanning multiple environments, configuring applications that will run concurrently to facilitate the migration, and other considerations.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Pre-migration preparations are typically performed only once, before the first users are migrated, and need not be repeated.
The following flow chart illustrates the necessary pre-migration preparations when migrating to a proprietary Exchange target.
Conditional Step: Steps that apply only in certain circumstances are marked with the "If" branchingarrows icon and a note that explains when the step applies.
The step numbers in the flow chart correspond to the step numbers in the process instructions that follow.

NOTE: This process does not create the user Exchange mailboxes until prior to their migration (per user collection in the Batch migration process) due to the Exchange free/busy limitation explained in chapter 1. See the Important note under Provisioning and mailbox creation for Office 365.
If you will not configure free/busy coexistence, you can create Exchange mailboxes earlier in the process in these Pre-Migration Preparations, as long as you also set Exchange-to-Notes mail forwarding for not-yetmigrated Notes users.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Step 1: Install and configure your target Exchange environment
If you have not yet installed and configured your destination Exchange environment, install and configure the Exchange server and Active Directory at this time. Provisioning of Active Directory (if not already provisioned) occurs in a later step.

Step 2: Verify all system requirements are satisfied
All system requirements must be satisfied before you install Migrator for Notes to Exchange (MNE). System Requirements are documented in the MNE Release Notes. The administrator accounts to be used to run the applications and access data and features in the Notes/Domino and in Exchange/AD environments also require specific permissions, as described in the MNE Pre-Migration Planning Guide (see the topic Configuration requirements and account permissions).
If these accounts do not already exist, create and configure them now.

Step 3: Install and configure the Migrator for Notes to Exchange software

The Getting Started section of the MNE Quick-Start Guide explains how to install Migrator for Notes to Exchange. The topics that follow describe the configuration tasks that should be performed now as part of the Migrator for Notes to Exchange configuration before the first run of any MNE component application. (All but the first are optional or conditional.)
NOTE: The user account used to run the MNE console must belong to the Local Administrators group. You can add the user account to Domain Admins group as the Domain Admins group belongs to the Local Administrators group by default.
Consider also whether the MNE Self-Service Desktop Migrator (SSDM) will be used as part of your Migration Plan. If so, it should also be installed and configured.
IMPORTANT: Any antivirus software on the admin workstation must be configured to not scan the Quest program files directory or %temp% directory, or can be turned off prior to running any Quest admin application. (Although it may be restarted after the program runs.) MNE program calls will not succeed if an antivirus scan tries to "clean" an Migrator for Notes to Exchange temporary file that it misinterprets as a threat.

Configure SQL Server and Migrator for Notes to Exchange default settings
Most the features and wizards of Migrator for Notes to Exchange (MNE) require access to the information stored in a central database on the SQL server. Most also require access to the Notes server, Exchange server, Active Directory, and the shared directories that contain the Self-Service Desktop Migrator (SSDM) and its log and status files and application log files. The MNE wizards need to know the pertinent server names, locations, configuration options, access credentials, and so on for the various servers.
Enter these Default Settings into Notes Migration Manager (the MNE console) before other you use other MNE features or the wizards so that the information is available and need not be entered again. If the information is not entered upon installation, the wizards prompt for the values as needed and most of the values must be entered more than once--entered for each feature and wizard that needs them.

NOTE: Quest recommends you access all five of the Edit Default Settings screens in Notes Migration Manager now to enter this information. The Notes Migration Manager is described in chapter 1 of the Migrator for Notes to Exchange Administration Guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Configure the MNE Task Scheduler for migration to on-premises Exchange
Migrator for Notes to Exchange tasks are defined by wizards, most of which let you schedule tasks. The Manage Scheduled Operations screen in Notes Migration Manager lets you revise these task-execution schedules. However. the wizards and Manage Scheduled Operations screen only manage the task schedules since the schedules are saved in the SQL database. A scheduled task does not execute by itself. Tasks are executed by the MNE Task Scheduler (qsched.exe).
The task scheduler is a separate command-line application that executes the scheduled MNE tasks. The program checks the SQL database to see if any tasks have been scheduled to run since the last check and executes the tasks. You manage the task scheduler as any other Windows service using the Windows Service Manager. Instructions for configuring a Windows service can be found at: http://msdn.microsoft.com/enus/library/ms681921(v=vs.85).aspx
For information about configuring and using the task scheduler, see the section titled "Using the Qsched.exe taskscheduling utility" in the Migrator for Notes to Exchange Administration Guide.

Conditional: Configure SetUserAccountControl and UserAccountControl parameters

Conditional Step: This step applies only if you will use Migrator for Notes to Exchange to create objects in the target AD.
If you using Migrator for Notes to Exchange to create user objects in the target AD, use a text editor to edit the following parameter settings in the Global Defaults:
[Active Directory] SetUserAccountControl=1 UserAccountControl=512

Optional: Configure automatic retries of Provisioning Wizard communications with Active Directory
The MNE Provisioning Wizard includes the ability to retry transmissions to Active Directory when issues occur. In some environments, transmissions to AD can be occasionally interrupted which can lead to incomplete provisioning. If you expect your provisioning may be significantly affected by such issues, use a text editor to configure these program parameters in the [ActiveDirectory] section of Task Parameters and Global Defaults:

[ActiveDirectory] PSRetryAttempts=<#> PSRetryWait=<##>

// integer (number of retries), default=3 // integer (seconds), default=15

The PSRetryAttempts parameter tells the Provisioning Wizard how many times to retry the transmission at intervals specified by the PSRetryWait parameter. If the error persists through all retry attempts, the wizard logs an error, skips the current message property or element, and continues to process the next item. Depending on the Log level setting (on the Specify Run Information screen), the retry attempts can appear in the program logs with no other documented error or warning. The default settings (PSRetryAttempts=3, PSRetryWait=15) tell the wizard to retry an AD transmission to a maximum of three attempts at 15-second intervals.
IMPORTANT: If you set the PSRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter. WatchDogMinutes specifies the number of minutes (default=180) of inactivity the Data Migration Wizard waits before concluding the connection has timed out and ending the process. Quest recommends you set WatchDogMinutes at the greater of: its 180-minute default, or a setting of 10 minutes for every 30 seconds of retry waiting (PSRetryAttempts x PSRetryWait).
Conditional: Prepare customattrs.tsv file to migrate Notes custom attributes

Conditional Step: This step applies only if you want to migrate Notes custom attributes.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

A Notes message contains several standard attributes such as the From, To and Subject fields, and can also include user-defined fields. The MNE Data Migration Wizard and SSDM can migrate custom Notes attributes from email messages and Notes contacts to unused properties in Exchange, but only if the migration software knows which properties in the target correspond to which attributes in the source. The migration of custom attributes requires that you map these source-to-target attribute associations in a tsv data file, before the migration, so the migration apps can refer to that file to migrate the attributes.
This mapping file must be a Unicode (not ANSI) file named customattrs.tsv located in the installation folder for the Data Migration Wizard (by default C:\Program Files\Quest\Migrator for Notes to Exchange) and also in the folder containing the notesdtapp.exe file if you want to migrate Notes custom attributes via the SSDM. The migrator applications can refer to this file to map the source attributes to free (unused) properties in Exchange.
Migrator for Notes to Exchange installs a Unicode attrs.tsv file, with the same column headings required for customattrs.tsv that you can use as a template to create the customattrs.tsv file.
To create and prepare the customattrs.tsv file
1 Use a text editor to open attrs.tsv, and save the open copy under the new name customattrs.tsv. Ensure you save customattrs.tsv as a Unicode (not ANSI) file in the appropriate folder. Delete any data rows that appear in the copy.
2 Enter a data row for each custom attribute you want to migrate and enter pertinent values for these columns:
ID: Name of the custom attribute--a unique string that distinguishes the row's custom attribute from all other attributes in the file.
IMPORTANT: If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files.
SourceProperty: Name of an attribute that has been added to a Notes mail message or a Notes contact, to be migrated to a property in Exchange.
TargetPropertySet: The GUID for the target property set, which must be one of these values:
PS_PUBLIC_STRINGS {HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH}
... where each "h" is a hexadecimal character, with letters uppercased.
If the TargetPropertySet value is PS_PUBLIC_STRINGS, the familiar GUID for the set named will be substituted for the string provided.
TargetPropertySet can be left blank but TargetProperty must be an integer property ID in the range 0x0000-0x7FFF.
TargetProperty: Name of the corresponding MAPI property in Exchange. A hexadecimal userproperty value is created in Exchange on each migrated mail message or contact with the Notes property which will hold the value. The hexadecimal values of the created properties is reported in the log (search for "custom attr" in the log file).
If TargetPropertySet is left blank, the TargetProperty value must be specified as a 16-bit integer in the range 0x0000-0x7FFF that is not already defined for another MAPI property.
TargetPropertyType: The data type of the MAPI property which must logically correspond to the data type used in Notes. Valid values are: STRING, MV_STRING, LONG, SYSTIME, BOOLEAN.
Also, "PT_" may be prepended to any of the five types so valid values include PT_STRING, PT_MV_STRING, etc.
3 Save and close the updated customattrs.tsv file.
For example, a typical customattrs.tsv file might look as shown in the following table:

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

ID SourceProperty
Attr1 ArchiveId Attr2 ArchivedDate Attr3 SaveSetId Attr4 RetentionCategory Attr5 HasAttachments

TargetPropertySet
{D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428}

TargetProperty
Archive ID Archived Date Saveset ID Retention Category HasAttachments

TargetPropertyType
STRING STRING STRING STRING STRING

Troubleshooting problems in migrating Notes custom attributes
You can use the Microsoft MfcMapi.exe utility to view the property and its value. (The utility is a free download from Microsoft. You can search in Google for "mfcmapi" and visit the www.microsoft.com/downloads link.)
Most problems in migrating custom attributes can be diagnosed by these quick tests:
� Verify that the target property that is specified in the customattrs.tsv file does not already exist and that the target property is in the correct format. See About MAPI properties for more information.
� Verify that the customattrs.tsv file is Unicode, not ANSI.
� Verify that the last line in the customattrs.tsv file is followed by a line feed and carriage return (position the cursor at the end of the last line and press Enter).
� If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files.
About MAPI properties
A named property name is a property-set GUID and an ID that is either a 32-bit integer or a string. A 16-bit integer alias in the range 0x8000 to 0xFFFF is assigned to the named property by MAPI. That alias is mailbox-specific.
An unnamed property name is a 16-bit integer in the range 0x0001 to 0x7FFF. That 16-bit integer is valid in all mailboxes. Examples of unnamed properties are 0x0070 (i.e., PR_CONVERSATION_TOPIC) and 0x6656, both of which are used by MAPI. So you cannot use these two examples as target property values for message attributes since they are already used though they may be used to map Notes contact attributes to Exchange.
A custom property can be unnamed or named.
If the custom property is unnamed, select a 16-bit integer TargetProperty in the range 0x0001 to 0x7FFF that is not already in use by MAPI. The following values are reserved by MNE:
� 0x6306
� 0x6309
� 0x630A
� 0x630B
� 0x630C
If the custom property is named, select any property-set GUID. If you select a property set that is already in use, you must choose a 32-bit integer or string ID that is not already in use in that property set. If you select a brand new property-set GUID, you need not worry about IDs already in use because there will not be any.
If you want named custom properties, Quest recommends you use the PS_PUBLIC_STRINGS property-set GUID, (PS_PUBLIC_STRINGS being an alias for {00020329-0000-0000-C000-000000000046}), and use string IDs with a prefix that is unique to your application (like "Quest-").

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Step 4 (if mail routing using domain differentiation): Configure mail routing domains
Conditional Step: This step applies only if you will configure email coexistence using temporary routing domains (domain differentiation in DNS) during the migration. If you use smart hosts for mail routing or will not configure mail routing at all, skip to step 5.
Whether your organization is implementing SMTP mail connectivity only or full coexistence with Quest CMN, most organizations use temporary SMTP domains to route traffic between Notes and Exchange. Other administrators prefer to configure SMTP mail routing with smart host servers for single-namespace environments. The routing method must be configured at the server and user levels. At the user level, Notes person documents and AD object records are configured later in this procedure when you provision the target AD and synchronize the two directories.
Notes-to-Exchange mail routing is configured so that new mail in Notes, both external inbound mail and internal mail from not-yet-migrated Notes users, is routed to already-migrated recipients in Office 365. The Notes-toExchange routing domains must be configured (but not yet activated) before the first user collection is migrated to Exchange. The forwarding rules are activated for each user collection as that collection is migrated.
External inbound mail can be switched (by MX record) to arrive in Exchange instead of Notes any time after mailenabled objects are provisioned into AD--before, during or after the migration. Many administrators prefer to minimize changes before and during the migration process so they update the MX record only when the migration is complete. Others prefer to minimize the forwarding "hops" by switching halfway through the migration process. And some administrators make the switch as soon as the target AD objects are mail-enabled.
Whenever the DNS switch occurs, the Notes routing domains for Exchange-to- Notes mail routing must be configured before the switch so Exchange can route mail for not-yet-migrated recipients to their Notes mailboxes.
To configure subdomains for mail routing by domain differentiation
The routing domains may be subdomains of the primary domain (e.g., notes.domain.com and ex.domain.com) or completely separate SMTP domains. As long as they are unique to the respective mail systems, they will suffice for routing purposes. To configure subdomains:
1 If appropriate SMTP domains are not already available, create them in DNS. One domain directs traffic to Exchange (e.g., exchg.domain.com). Mail sent to the Notes mailboxes of migrated users is forwarded to the corresponding mailboxes in Exchange using the exchg.domain.com domain. The other domain (e.g., notes.domain.com) is used to route mail back to Notes for users who have not yet migrated.
2 After configuring the new exchg.domain.com domain in DNS, configure Exchange to accept the SMTP domain and create a recipient policy to generate secondary SMTP addresses so all Exchange users are able to receive mail at this domain.
3 Configure Notes to accept mail to the new notes.domain.com SMTP domain/address.
4 Verify the new domains by testing mail flow.

Step 5 (optional): Configure coexistence strategy

Conditional Step: This step applies only if you will configure some method of email, directory and/or free/busy coexistence during the migration transition period. If you will migrate without coexistence, skip to step 6.

Configure your coexistence strategy:
� For complete coexistence with Quest CMN: Refer to the Coexistence Manager for Notes documentation to install and configure the desired components (Directory Connector, Free/Busy Connector, and/or Mail

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Connector). Directory Connectors must be created and run to update Domino and Active Directory with routing objects that correspond to the users in the other system to establish complete directories.
IMPORTANT: If you have existing mail-enabled objects in AD, enable the MNE Compatability Mode for the CMN Directory Connectors that will populate AD from Notes to avoid duplicate entries in AD. The CMN Mail Connector and Free/Busy Connector can be configured similar to other scenarios. See the Coexistence Manager for Notes User Guide for more information.
Verify your CMN configuration by testing mail flow. � For SMTP mail routing (without CMN): If you have not tested mail flow to verify the subdomains you
configured in the preceding step, do so now.
If you will use the CMN Free/Busy Connector
Define the free/busy and mail domains in the Domino Administrator: � Add a Foreign Domain for the free/busy server: Mail Information tab: Set Gateway server name to the name of the Domino mail server. Calendar Information tab: Set Calendar server name to the name of the Domino server where qcalcon.exe is installed. � Add a Foreign SMTP Domain for the mail server. On the Routing tab: Set Internet Domain to the name of the Exchange subdomain. Set Internet Host to the IP of the Internet host.
NOTE: These procedures do not create user Exchange mailboxes until prior to migration (in the Batch migration process) due to the Exchange free/busy limitation (as explained in chapter 1--see the Important note under Provisioning and mailbox creation for Office 365). If you create Exchange mailboxes earlier in this procedure, be aware that free/busy data for not-yet-migrated Notes users are unavailable until the users are fully migrated to Exchange.
Step 6 (for Exchange 2010 or later target): Configure throttling policy
Conditional Step: This step applies only for migrations to an Exchange 2010 or later target environment, and is optional but recommended.
Some migrations to Exchange 2010 or later have achieved improved throughput using a custom throttling policy. This topic is discussed in detail in this article.
Step 7: Discover Notes information
Migrator for Notes to Exchange needs to know the location of the Notes Address Books (NABs) that serve as data sources for the Directory Export Wizard in the next step. MNE also needs to know the Internet domains that are used to generate the user SMTP aliases. MNE includes the following wizards to search through your Notes environment and return the necessary information:
� NABs Discovery Wizard: Locates available NABs and lets you specify the ones to be exported. � Internet Domains Discovery Wizard: Identifies associated Internet domains. Run these two wizards to prepare for the Directory Export Wizard in the next step. For operational details, see the Migrator for Notes to Exchange Administration Guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Step 8: Export Notes directory data
The MNE Directory Export Wizard extracts user and group data from the Notes environment and populates the MNE SQL database and other data files with this information. Other applications require this data for input values.
Run the Directory Export Wizard to capture the necessary information. For more information and instructions for using the Directory Export Wizard, see the Directory Export Wizard chapter in the Migrator for Notes to Exchange Administration Guide.
Step 9: Review and verify/modify exported data in the SQL database
The data captured by the Directory Export Wizard provides critical input to other MNE programs so it is important to verify that the information is accurate and correctly formatted. The verification step also provides an opportunity to update addresses and other attributes before initiating migrations. For example, the content can be modified to facilitate consolidation to a new SMTP domain as part of the migration process.
Verify the matching criteria for the provisioning process (in a later step). A unique matching attribute is required to match each Notes user to a corresponding security object in AD. A matching attribute may already be available, or a custom attribute can be populated in the Domino Directory and exported, or a matching attribute can be populated into the MNE SQL database via TSV export/import.
If mail-enabled users already exist in Active Directory: Ensure the addresses listed in the TargetAddress column are appropriate, since Migrator for Notes to Exchange will use that value to locate the AD object for mailbox creation. The value of the TargetAddress in the SQL database must match a valid SMTP address on the mail-enabled AD object. The TargetAlias addresses are also applied as secondary/proxy addresses, so it is important to verify them before proceeding.
If the target AD Is configured for a resource forest and a user forest: prepare the SQL database for mailbox-enabling
Conditional Step: This step applies only if your target AD is configured for a resource forest and a user forest, with corresponding user accounts.
For the Data Migration Wizard to enable mailboxes and to associate the resource accounts with the user accounts, you must configure the Global Default Settings in Notes Migration Manager and prepare (or verify) the per-user values in a column of the exported directory data. These preparations are necessary for the Data Migration Wizard to correctly associate the resource accounts with the user accounts and enable mailboxes.
Before you begin, determine which column in the SQL Server database will correspond to which AD attribute for the wizard to match corresponding user accounts in the resource forest and user forest. The column (AdSearchCol) and attribute (AdAttribute) are both specified in the [ActiveDirectory2] section of the Global Default Settings of Notes Migration Manager:
� AdSearchCol: The column in the SQL Server database whose values the program searches for each AdAttribute value to match corresponding user accounts in the resource forest and user forest. The column specified here and its per-user values must exist before the Data Migration Wizard is run.
IMPORTANT: This AdSearchCol parameter value must be set to SearchKey2 for the mailboxenabling process to succeed. The parameter default is AdSearchCol=SearchKey2.
� AdAttribute: The AD attribute whose values the program reads in the AdSearchCol column of the SQL database to match corresponding user accounts in the resource and user forests. For example:
[ActiveDirectory2] AdSearchCol=SearchKey2 AdAttribute=userPrincipalName

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

... tells the wizard to match AD objects with users such that the value of the userPrincipalName attribute for each AD object matches the value of a corresponding user SearchKey2 column in the SQL Server database.
To configure the Global Default Settings 1 In Notes Migration Manager, select File | Global Default Settings. The program opens the program configuration settings in Windows Notepad. The settings look like the contents of an INI file but are saved as a part of the SQL Server database.
2 In the [ActiveDirectory2] section, set the appropriate parameter value for AdAttribute.
3 Close Notepad. Notes Migration Manager copies the new parameter value back into the SQL Server database.
To enter or edit the AdSearchCol column values 1 In Notes Migration Manager, in the Export Notes Directory screen, click Export objects to TSV. A dialog box prompts for a destination folder and filename for the exported file.
2 Use Microsoft Excel (or some other tsv-editing program) to enter or edit the contents of the column you designated as the AdSearchCol column.
3 In the Export Notes Directory screen, click Import objects from TSV to import the edited .tsv file into the SQL Server database. A dialog box prompts for the filename and its location.

Step 10: Define user collections

Many MNE wizards are applied to particular user collections, user-defined subsets of all Notes users to be migrated. User collections can come in all sizes, from a single user to all Notes users in one collection. Collections typically number 100 or so users per batch when migrating to a local Exchange.
The Migrator for Notes to Exchange Pre-Migration Planning Guide (see chapter 3, Batch vs. Per-Desktop Migration) explains factors that can affect your optimum number of users per collection and why it is important to decide on a grouping strategy when defining collections.
Use the Collection Wizard now to define your user collections. Remove any objects from collections you do not want to provision into the target AD. See the Collection Wizard chapter 5 of the Migrator for Notes to Exchange Administration Guide for more information.
NOTE: Notes groups (distribution lists) are typically migrated separately after all users have been migrated. The definition of group collections and migration of groups are among the Post-migration activities.
Later in this procedure you can assess per-user data volumes in the Notes source, and adjust your defined collections.

If migrating to two or more mail stores ...
Some administrators prefer to provision users in the same user collection to two or more Exchange mail stores. This can be accomplished by updating the SQL database to include appropriate values for the HomeMDB of each user.
The HomeMDB column specifies the Exchange mailbox store for each migrating user and is used when mailboxenabling users through the Exchange Administrative Operations of the Data Migration Wizard. For example:
CN=Mailbox Store (MOBE),CN=First Storage Group,CN=InformationStore,CN=MOBE, CN=Servers,CN=First Administrative Group,CN=Administrative Groups, CN=User, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Example,DC=com
The Exchange administrator credentials supplied to Migrator for Notes to Exchange must have sufficient rights to create mailboxes on the Exchange servers specified in this HomeMDB column. If the HomeMDB column is blank, the value specified in the MNE GUI is used for the destination Exchange mailbox store.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Also: Define custom design classes
Conditional Step: This step applies only if your Notes environment uses any non-standard design classes.
The MNE Notes Migration Manager (the console) lets you identify any non-standard Notes design classes that are associated with Notes NSF files but that the wizards would not recognize because the class names are different from the Notes-standard design classes. The Design Classes table in Notes Migration Manager enumerates all non-standard design classes and associates each design class with one or more data types: mail, archives, or PABs. If the Data Migration Wizard or SSDM finds an NSF file that does not match any of the default design classes for archive, mail or PAB files, the program will look at these tables to find an alternate design class, and determine the file type.
If your Notes environment has any non-standard design classes, use the Manage Design Classes screen in Notes Migration Manager to define them now. This feature is fully documented in the Migrator for Notes to Exchange Administration Guide, chapter 1 (see User Collections: Manage Design Classes).
Step 11: Provision AD with mail-enabled users
Users must be provisioned as security principals in the target Active Directory before any user data can be migrated. Your choices for provisioning methods, and the implications of those choices, are explained in the Migrator for Notes to Exchange Pre-Migration Planning Guide (see Provisioning the Target Active Directory in chapter 2).
Migrator for Notes to Exchange tools can provision AD from the Notes source. This provisioning step also includes object merging (if necessary) and mail-enabling of the provisioned objects. By the end of this step, AD should contain a single mail-enabled object that corresponds to each user you intend to migrate in the Domino source directory.
NOTE: This process does not create user Exchange mailboxes until prior to their migration (per user collection, in the Batch migration process) due to the Exchange free/busy limitation (explained in chapter 1, see the Important note under Migration to proprietary Exchange). If you will not configure free/ busy coexistence, you could create Exchange mailboxes earlier in the process in these Pre-Migration Preparations, as long as you also set Exchange-to-Notes mail forwarding for not-yet-migrated Notes users.
The typical and most direct method to provision Active Directory begins with an MNE directory export (step 8), followed by a directory update by the CMN Directory Connector, The illustration that follows includes the export of Domino directory data into the MNE SQL server database.
This provisioning step is necessary even if you have an existing AD that is already provisioned with user objects, since the AD object records must be synchronized with the latest Notes source object records before migration.
Quest recommends the following process to provision Active Directory (after the directory export has populated the MNE SQL server database, in step 8):
1 Synchronize the Notes/Domino directory with AD. Use the CMN Directory Connector (or some other method) to perform a bidirectional update between the two directories. Other tools and methods are also possible but CMN was designed to complement the Migrator for Notes to Exchange tools. The synchronization reads user data from the Notes source to create corresponding mail-enabled contacts in AD, and vice-versa, to update both directories with routing objects that correspond to users in the other system (to establish complete directories).
If Active Directory does not already contain user objects, the directory update will create them. Many organizations will already have an Active Directory in place for network authentication with users provisioned as security objects. In this case, configure the directory update to create new contacts in AD, which correspond to the existing user objects in AD. (The CMN Directory Connector can detect and merge potential duplicate entities by comparing their addresses but security objects that have been used only for network authentication typically do not have email addresses assigned. See the Coexistence Manager for Notes User Guide for more information.) If applicable, create the necessary connectors in the CMN Directory Connector component and run them to update both directories.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

NOTE: Migrator for Notes to Exchange also includes a feature that can provision users in AD and Exchange with mailboxes directly from contact objects. This can be useful in environments where security principals do not exist in AD and CMN is used to create routing contacts in AD. This approach also is useful for provisioning resource objects in some scenarios. This behavior is controlled by the MBoxFromContact parameter setting described in the Migrator for Notes to Exchange Program Parameters Reference.
2 Run the MNE Provisioning Wizard for all user collections to consolidate duplicate entities in AD and mail-enable objects already in AD. The Provisioning Wizard merges each information for each contact into the original corresponding AD object record and deletes the contact, leaving a single mailenabled object in AD for each Notes user. Future directory updates will detect the merged AD object address attribute and will not re-copy the corresponding Notes object.
If contacts were not added to AD for directory coexistence, use the Provisioning Wizard (without contacts) to mail-enable the existing security principals. Addresses and attributes are pulled from the MNE SQL database to mail-enable objects since no corresponding contacts exist in AD.
In any of these scenarios, the result is a single, mail-enabled user object corresponding to each Notes user, and the preservation of any existing security, credentials, and routing. See the Migrator for Notes to Exchange Administration Guide (the Provisioning Wizard chapter) for instructions and application notes.
3 Verify Notes forwarding addresses. Your mail-routing method allows migrated users to communicate with not-yet-migrated Notes users, relying on existing mail-enabled AD objects to do so. The routing addresses must be verified and tested to ensure proper delivery.

Step 12: Assess per-user migration volume
Before you migrate users, you need an estimate of the volume of data to be migrated by each user and in each user collection. Migrator for Notes to Exchange provides a Notes Data Locator Wizard that finds source data stores and determines the per-user data volumes within those stores.
Run the Notes Data Locator Wizard to find the source data and review per-user data volumes for all user collections and to verify ownership of archives and PABs prior to migration.
Select View Summaries | User and Resource Detail to review the per-user data volumes and refine your collection members to accommodate any unexpected or atypical data volumes. The Notes Data Locator Wizard is

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

documented in the Migrator for Notes to Exchange Administration Guide. The View Summaries features are part of Notes Migration Manager documented in chapter 1 of the Administration Guide.

Step 13 (when appropriate): Redirect inbound external mail to Exchange
Modify the MX record to direct incoming external (Internet) mail to the Exchange server. The DNS modification can occur at any time after the user AD accounts are mail-enabled--before, during or after the migration. Some administrators prefer to minimize changes before and during the migration process so they update the MX record after the migration is complete (as described in the Post-migration activities at the end of this chapter).
Other administrators prefer to minimize the "hops" in the forwarding route by modifying the DNS halfway through the migration process. Others make the switch after the target AD objects are mail-enabled (in an earlier step).
In any case, after inbound mail is directed to Exchange, the Notes forwarding addresses in mail-enabled AD objects will route incoming mail to the Notes mailboxes of not-yet-migrated users until they are migrated. Incoming mail is not sent to Exchange mailboxes until MNE tells Exchange to stop routing mail to Notes for those users-- when the users are migrated to Exchange with their own Exchange mailboxes.

Step 14 (if necessary): Replicate or copy local data to a central location
Conditional Step: Applies only if you want to use the MNE Data Migration Wizard to batch-migrate data that resides on end-user workstations.
Migrator for Notes to Exchange includes several options for migrating data that resides on end-user workstations. One approach uses the MNE Self-Service Desktop Migrator (SSDM), which offers an optional Silent Mode to minimize user interaction and impact. This approach is discussed in detail in chapter 4 (SSDM (per-desktop) migration) of this Guide.
Some scenarios, however, require centralized batch migration of local Notes PABs and archives. The MNE Data Migration Wizard (described in the next section under Batch migration process) can migrate content to Exchange mailboxes, personal archives, or PST files. The program must have access to the source data.
Migrator for Notes to Exchange includes a PAB Replicator feature to automate the process of replicating end-user PAB data to server-based NSFs or the mail file of each user. Alternatively, user local data could be copied to a central location by some other means.

Step 15 (if using smart hosts for mail routing): Configure smart hosts
Conditional Step: Applies only if you intend to use smart hosts for SMTP mail routing.

Establish and configure the Domino and Exchange smart host servers and verify the configurations by testing mail flow. The creation of mail-enabled Active Directory accounts (in an earlier step) has entered the necessary targetAddress values into the AD object records.
The details of configuring smart-host SMTP mail routing are beyond the scope of this guide, but see your Domino and Exchange documentation and online resources for information about configuring smart hosts for those servers.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

To configure smart-host SMTP routing with Quest CMN, both smart hosts are configured to point to the CMN server. In CMN, one set of SMTP IN and SMTP OUT queues is configured to accept mail from Domino and deliver it to the receiving Exchange server, while another set is configured to accept mail from Exchange and deliver it to Domino. Multiple CMN servers can be deployed for load balancing and redundancy. The Coexistence Manager for Notes User Guide (chapter 3) explains these configurations.
When pre-migration preparations are complete ...
When you have completed the pre-migration preparations, go on to the Batch migration process section and/or see chapter 4 for information about SSDM (per-desktop) migration.
Batch migration process
Migrator for Notes to Exchange includes two migration engines:
� The Data Migration Wizard migrates batches of users simultaneously, and performs valuable administrative functions (e.g. mailbox creation, routing updates, etc.), provisions public distribution lists.
� The Self-Service Desktop Migrator (SSDM) runs on end-user local workstations and migrates content for one user. SSDM streamlines the migration of local content, reduces burden on the migration team, and includes a Silent Mode to minimize end-user interaction and requirements.
Either migration engine can be used independently for the entire data migration, or the two may be used together to meet a variety of project requirements, as discussed in the Pre-Migration Planning Guide (see the Batch vs. Per-Desktop Migration topic in chapter 3).
This section provides process instructions for a typical migration to a proprietary Exchange, in which an administrator uses the Data Migration Wizard to perform the migrations for multiple batches (user collections) of users. SSDM (per-desktop) migration, described in chapter 4, may also be part of your Migration Plan.
IMPORTANT: Be sure you have completed the Pre-migration preparations described in this chapter before you begin this batch-migration process.
This batch-migration procedure is repeated for each group of users to be migrated, as shown by the looping arrow in the flow chart. The first pass through the procedure begins with these assumptions:
� The target Active Directory is provisioned with a single mail-enabled object for each Notes object you want to migrate but no mailboxes are yet created for these objects.
� The Notes forwarding addresses in the target AD objects are verified as functional for forwarding mail from Exchange back to Notes.
� MNE user collections are defined (although they can be adjusted with each pass through the batchmigration process).
� If you intend to use a coexistence strategy, your coexistence method and tools (such as Quest Coexistence Manager for Notes) are configured for the coexistence features you plan to use.
The following flow chart summarizes the batch-migration process for a proprietary Exchange target. The step numbers in the flow chart correspond to the step numbers in the process instructions. The instructions and field notes here and in the Migrator for Notes to Exchange Administration Guide contain special notes for optional and conditional steps in the procedures.
Step 1: Sync the AD and Domino directories
Conditional Step: This step applies only if CMN is used for directory updates. If not, skip to step 2.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Organizations typically experience staff additions and departures during a migration transition period. Any directory changes that occur during the migration project can introduce data inconsistencies between the source and target environments--changes that occur after the initial directory updates in the pre-migration preparations. These can be reconciled using the CMN Directory Connector. See the Quest Coexistence Manager for Notes User Guide for details.
The CMN Directory Connector can be configured to automatically run directory updates at scheduled intervals. However, it may be useful to also initiate updates manually at this step in the process to ensure the directories are consistent prior to migrating each collection.
Step 2: Refresh the Migrator for Notes to Exchange SQL data
To ensure your target AD is provisioned with current object data, update the MNE SQL database before migrating each user collection. If you have updated the directories in step 1 (optional), this process will also copy all updated directory data into the SQL database.
To update the SQL server database
1 Re-run the MNE NABs Discovery Wizard and Internet Domains Discovery Wizard to refresh the location of the Notes Address Books (NABs) and the list of Internet domains that will be used to generate users' SMTP aliases.
2 Re-run the Directory Export Wizard to refresh the SQL database.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Step 3: Reassess and refine user collection membership
You defined your user collections (migration groups) in the Pre-migration preparations earlier in this chapter. Each pass through this Batch migration process applies these migration tasks to a single collection.
Now that you have updated your directories and refreshed your SQL data (the two preceding steps), you should:
1 Re-run the Data Locator Wizard for this collection (only) and select View Summaries | User and Resource Detail to reassess the per- user data volume in the Notes source for this collection. The Notes Data Locator Wizard is documented in chapter 7 of the Migrator for Notes to Exchange Administration Guide. The View Summaries features are part of Notes Migration Manager, documented in chapter 1 of the Administration Guide.
2 Reassess the collection membership with respect to the total data volume to be migrated for the collection members. You can move some members from one collection to another to better conform to your organization's grouping strategy (see the Batch vs. Per-Desktop Migration topic in chapter 3 of the Migrator for Notes to Exchange Pre-Migration Planning Guide).
3 If necessary, rerun the Collection Wizard for this collection to change its membership. Chapter 5 of the Migrator for Notes to Exchange Administration Guide provides instructions for the Collection Wizard.
NOTE: Notes groups (distribution lists) are typically migrated separately after all users are migrated. The Post-migration activities include the migration of groups.

Step 4: Create Exchange mailboxes and perform Notes administrative operations

Run the MNE Data Migration Wizard to create Exchange mailboxes and perform pertinent Notes administrative tasks for the users in the current collection. See the Data Migration Wizard chapter of the Migrator for Notes to Exchange Administration Guide for complete instructions. After this step Exchange routes all free/busy queries for these users to their new Exchange mailboxes to which the users are fully migrated in the next step.
The Notes administrative operations you select will depend on your local circumstances and needs. The available Notes admin operations are:
� Set foreign directory sync (feature available only when not setting or removing mail routing): Tells the wizard to let the CMN Directory Connector extract user data from the Notes directory during its directory synchronization. (This corresponds to the Notes parameter Allow foreign directory synchronization.) To disable foreign directory sync, leave the check box selected but select Disable in the drop-down list.
In some configurations, migrated objects that have been merged or mailbox-enabled in AD become unrecognizable to a Notes' directory update, so the update mistakenly creates duplicate objects in AD. You must Disable foreign directory sync if all three of the following conditions are true:
You are using the CMN Directory Connector to perform directory updates from Notes to Exchange during coexistence.
Your mail-routing method during coexistence is to use Notes forwarding addresses to set forwarding from Notes to Exchange.
The Notes person documents are not set to turn users into Exchange objects.
� Set user visibility in the Domino directory: Tells the wizard to let you specify the scope of user visibility in the Domino directory. The visibility setting is important when the Quest Coexistence Manager for Notes (CMN) is used to update both directories with modifications. As mailboxes are created in Exchange for migrating users, it can be advantageous to set visibility for the same user population. This eliminates the possibility of duplicate entries appearing in the Domino directory for migrated users after subsequent runs of the Directory Connector. The timing of this operation should be coordinated with the Exchange-to-Notes Connector schedule in CMN to ensure the Exchange entries for migrated users are synchronized to Notes shortly before or after the visibility change.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

� Set Person Document Attributes: Tells the wizard whether to assign attribute values to Notes person documents as defined by parameters in the [PersonDocCustom] section of the Task Parameters. (See this section of the Migrator for Notes to Exchange Program Parameters Reference for information about how to assign the values.) If this check box is clear, the wizard ignores the [PersonDocCustom] section of the Task Parameters.
Step 5: Set Notes-to-Exchange mail forwarding, and migrate user data
NOTE: Quest recommends you perform the final cutover tasks in a separate program run of the Data Migration Wizard, rather than in the same run with mailbox-enabling and Notes admin operations (in the preceding step). Some admins have reported latency conflicts when trying to perform all of these tasks together in a single program run.
A user is said to be migrated when he or she has an Exchange mailbox and all external and internal mail for that user is routed to the new Exchange mailbox, and all of the user data has been copied to Exchange (mail, calendar entries, address books, archives, etc.). The event that migrates a user to the target environment is called the user final cutover. In this procedure you migrate the user data in the same program run that you set Notes-to- Exchange mail forwarding.
It is critical to set Notes-to-Exchange mail forwarding for these users upon their final cutover, so any mail that arrives during or after the migration will route to Exchange as expected. The Notes-to-Exchange forwarding must remain in place until the MX record is updated to point to Exchange (in the Post-migration activities at the end of this chapter), and all Notes users have been migrated to Exchange.
NOTE: If you are migrating data using file system access (rather than by server access): � Verify that all migrating users are logged off before you start the Data Migration Wizard. If the data is accessible through the Domino server, Quest recommends you locate and migrate the data using server access. If that is not possible, and you need to use file system access to locate and migrate the data, you must ensure that all users to be migrated (in the current collection) are logged off the system. � Also, ensure that the server no longer has the NSF file open in its cache. The dbcache flush command closes all files being held open by the server for users that are no longer logged onto the server. Running the dbcache flush command prevents the server from blocking the Migrator for Notes to Exchange program's access to the NSF files during the migration run.
Run the Data Migration Wizard again now, to perform this final cutover for users in the designated collection: Set Notes-to-Exchange mail forwarding, and migrate user data from Domino to Exchange. See the Data Migration Wizard chapter of the Migrator for Notes to Exchange Administration Guide for complete instructions.
Step 6: Distribute .pst files
If the Data Migration Wizard migrates any data to Outlook Personal Folder (.pst) files when the migration is complete you must either:
� Notify users of the locations of their new .pst files so each user can specify the location within his or her own desktop copy of Outlook.
- OR -
� Distribute the newly created .pst files to users' desktops.
The Data Migration Wizard names any new .pst files using the common filename, if specified, or the specified filename format. if more than one file is generated per User ID, incremental numbers are appended to the filename. For example, Smith.pst, Smith-1.pst, Smith-2.pst, etc.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

NOTE: The location of the PST files is reported in: � The User migration status per collection report, available from the View Summaries screen of Notes Migration Manager. � The Report Pack Report, available from the View Report Pack screen of Notes Migration Manager.
Was that your last migration collection?
If this is not your last migration collection: Repeat all the steps of this Batch migration process for the next collection. If this is your last migration collection, but you have more Notes users to be migrated individually by the MNE SSDM: See the SSDM (per-desktop) migration chapter in this guide. When no users remain to be migrated, see Post-migration activities.
Post-migration activities
Step 1: Provision Notes groups into Exchange
Groups are typically provisioned into Exchange separately after users are migrated in the Batch migration process (earlier in this chapter). Run MNE Groups Provisioning Wizard to provision Notes groups into Exchange as distribution groups. Groups information was earlier extracted from the Domino source and copied into the SQL database by the MNE Directory Export Wizard. Notes groups can be divided into collections using the MNE Collection Wizard for more convenient processing. If appropriate, you can update group membership and attributes in the SQL database (via TSV export and import) prior to provisioning the groups into Active Directory. For operating instructions and application notes, see the Groups Provisioning Wizard chapter of the Migrator for Notes to Exchange Administration Guide. If your scenario gives you some reason to provision groups before all Notes users (in all collections) have been migrated, be sure to check the Message Delivery Restrictions for any Exchange group to which you want Notes users to be able to send messages. Any such Exchange group must be of the universal distribution type to be mail-enabled. To change settings, beginning in the Exchange Management Console:
1 Under Recipient Configuration | Distribution Group, select and double-click the group you want to edit.
2 Click the Mail Flow Settings tab, highlight Message Delivery Restrictions, and click Properties.
3 Clear the check box for Require that all senders are authenticated.
4 Click Save and restart the MS Exchange transport service.
Step 2 (optional): Configure ongoing dirsyncs
Conditional Step: This step applies only if you are using the Quest CMN product for ongoing directory updates after the migration.
If you want to keep your Notes environment up and running with an active Domino directory for a period after the migration, or indefinitely, you may want to configure the Quest CMN Directory Connector to run regular directory updates for as long as the Notes and Exchange environments coexist.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

Step 3: Update mail routing
Migrator for Notes to Exchange is commonly used to automatically update mail forwarding in both systems to ensure proper routing during the migration. Migrator for Notes to Exchange can set and remove forwarding rules in both environments, as long as the mail routing domains or smart hosts are properly configured.
When the users and groups are all migrated, routing can be permanently updated to direct external incoming (Internet) mail to Exchange instead of to the Notes environment. This step includes modifying the MX record(s) to point to Exchange. In some environments, updating mail routing also includes updating routing tables and/or firewall modifications.
Most organizations prefer to update mail routing only after the last user has been migrated to minimize change before and during the migration process. However, the MX modification can occur at any time after the Notes users are provisioned into Active Directory as mail-enabled objects. (If routing is updated to send inbound mail to Exchange before a user is provisioned, there is no forwarding address in AD to relay the user mail to Notes.)
Step 4: Post-migration cleanup
To clean up after the last user has been migrated:
1 Verify the Notes server is inactive. Ensure that the Notes server is no longer processing mail traffic or utilized for active applications.
2 If you were using SMTP mail coexistence: Delete the temporary mail routing MX domain(s) you created in the Pre-migration preparations, to support routing between Notes and Exchange during the transition. Now that all users have been migrated to Exchange and inbound traffic is routed directly to Exchange, the temporary routing domain(s) should no longer be required.
3 If you no longer need the Notes environment: After you have verified Notes is inactive, you may take a final backup and decommission the environment.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to a proprietary Exchange

3
Migration to Microsoft Office 365

� Pre-migration preparations � Batch migration process � Post-migration activities

Pre-migration preparations
This chapter applies only if you are migrating to Microsoft Office 365. If you are migrating to proprietary (onpremises) Exchange, see chapter 2 (Migration to a proprietary Exchange).
Any migration scenario requires preparation of the source and target environments, implementation of a coexistence strategy, configuration of administrator accounts, and preparation of the required software. These procedures can be time consuming because they include configuring accounts and permissions across multiple environments, configuring applications that run concurrently to facilitate the migration, and other considerations. However, these procedures are typically performed once, before the first users are migrated, so they need not complicate the entire migration process.
Before you begin, decide your strategy for accommodating the Exchange free/busy limitation as explained in the Migrator for Notes to Exchange Pre-Migration Planning Guide (chapter 2, see Provisioning the Target Active Directory).
The flow chart that follows illustrates the pre-migration preparations for migration to Microsoft Office 365. The step numbers in the flow chart correspond to the step numbers in the process instructions that follow.

NOTE: Steps that apply only in particular circumstances are marked with the and a note explaining when the step applies.

branching-arrows icon

Step 1: Establish Office 365 account
Contact Microsoft to establish your Office 365 account (if you haven't already).
If you will provision Office 365 from existing local Active Directory (AD), your Office 365 setup must include installing a Microsoft AD synchronization tool. See your Microsoft documentation for guidance in the installation and configuration of the AD sync tool.

Step 2: Verify all system requirements are satisfied
All system requirements must be satisfied before you begin. System requirements are documented in the Migrator for Notes to Exchange Release Notes. System requirements include the administrator accounts that are used to run the Quest applications and to access data and features in the Notes/Domino and Exchange/AD environments. The accounts require specific permissions, also specified in the system requirements. If these accounts do not exist, create and configure them now.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 3 (if provisioning from local AD): Install and configure local Active Directory
Conditional Step: This step applies only if you intend to provision Office 365 from local proprietary Active Directory. If you will provision by some other method, skip to step 4.
Install and configure the local proprietary Active Directory (AD) with the Exchange schema, if it is not already up and running. Provisioning the local AD occurs at a later step in this procedure.
IMPORTANT: If you upgrade from Exchange 2010 to a later Exchange version while the migration is in progress, you must also upgrade the AD schema to match.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 4: Install and configure Migrator for Notes to Exchange
The Getting Started section of the Migrator for Notes to Exchange Quick-Start Guide explains how to install the product. The topics that follow here describe several configuration tasks that must be performed as part of MNE configuration before the first run of any wizard. (Some are optional and apply only in particular circumstances, as noted.)
Consider also whether the MNE Self-Service Desktop Migrator (SSDM) will be used as part of your Migration Plan. If so, it should also be installed and configured.
IMPORTANT: Any antivirus software on the admin workstation must be configured to not scan the Quest program files directory or %temp% directory. You can turn off the antivirus software before running any Quest application and turn it on again after the program runs. Migrator for Notes to Exchange program calls will not succeed if an antivirus scan tries to "clean" an Migrator for Notes to Exchange temporary file that it misinterprets as a threat.
Configure SQL Server and Migrator for Notes to Exchange default settings
Most features and wizards of Migrator for Notes to Exchange require access to information stored in a central database on the SQL server. Most also require access to the Notes server, the Exchange server, Active Directory, and the Shared Directories that contain the Self-Service Desktop Migrator and its log and status files, and application log files. The features and wizards need to know the names, locations, configuration options, access credentials and so forth for the various servers.
Enter the Default Settings now into the Notes Migration Manager (the MNE console) before other program components are used so that the information will be available to them and need not be entered again. If the information is not entered now, upon installation, the features and wizards will prompt for the values as needed, and most of them will have to be entered more than once--reentered for each feature and wizard that needs them.
NOTE: Quest recommends you visit all five of the Edit Default Settings screens in the Notes Migration Manager now to enter this information. The Notes Migration Manager is described in chapter 1 of the Migrator for Notes to Exchange Administration Guide.
Configure the Task Scheduler for an Office 365 migration
The Migrator for Notes to Exchange tasks (program runs) are defined by wizards, most which let you schedule tasks to run at particular times on particular days. The Manage Scheduled Operations screen in Notes Migration Manager lets you revise these task-execution schedules. But the wizards and Manage Scheduled Operations screen manage only the scheduling of task runs as these schedules are saved in the SQL database, and a "scheduled" task does not execute by itself. Tasks are executed by the MNE Task Scheduler utility as described in this section.
Scheduled tasks are executed using a separate command-line application called the Migrator for Notes to Exchange Task Scheduler (qsched.exe) which is located in the installation directory. The program regularly checks the SQL database to see whether any tasks have been scheduled to run since the last check, and executes the tasks at their scheduled times.
The task scheduler runs as a Windows service and is automatically installed when you install Migrator for Notes to Exchange. You can manage the task scheduler as you would any other Windows service using the Windows Service Manager. Instructions for configuring a Windows service can be found at: http://msdn.microsoft.com/enus/library/ms681921(v=vs.85).aspx.
For information about configuring and using the task scheduler, see the section titled "Using the Qsched.exe taskscheduling utility" in the Migrator for Notes to Exchange Administration Guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Mandatory parameter for Office 365 licensing
The Data Migration Wizard reads a mandatory program parameter to get the two-character Usage Location code that Microsoft requires for its Office 365 licenses (per this Microsoft article). Set this value, in Migrator for Notes to Exchange Global Defaults or Task Parameters before you try to License users:
[Exchange] O365UsageLocation=<xx>
The parameter value is a two-letter keyword, which must conform to the standardized values listed for ISO 3166-1alpha-2.

Configuring Migrator for Notes to Exchange performance for migration to Office 365
Migration to Office 365 uses the Internet to transport data which is slower and less reliable than local network connections. Migrator for Notes to Exchange offers several parameters to minimize timeouts when data transmission delays are encountered during a migration.
Quest recommends you set parameters as detailed in the following sections.
MAPI error retry features for MNE-Exchange connections
Migrator for Notes to Exchange lets you configure the Data Migration Wizard to retry MAPI calls to Exchange and/or Office 365 when issues occur. In some environments, MAPI communications/connectivity can be occasionally interrupted, which can lead to incomplete migration results. This feature controls MAPI retries when certain errors are encountered.
When you are using the default Quest MNE MAPI/HTTP library, the MAPI error retry feature is simplified. When you are using the legacy Outlook library, there are more parameters to configure. For information about when to use the Outlook MAPI/HTTP library, see the parameter [Exchange] UseMneMapiHttpLib in the MNE Program Parameters Reference Guide.
The retry algorithms for both libraries are described in the following sections.
Quest MNE MAPI/HTTP library
The feature is configured by the MessageRetryWait parameter in the [Exchange] section of Task Parameters and Global Defaults:
If MNE encounters a MAPI API function that fails with a network or session connection related error, it attempts to recover using the following algorithm:
1 If a network communication error occurs when sending the MAPI/HTTP request to the server, the request is sent again after a short delay.
2 If, after several attempts, the request still cannot be sent to the server, or if the error is more serious and cannot be resolved by resending the request, the existing MAPI/HTTP session is closed.
3 MNE attempts to open a new MAPI/HTTP session after pausing for a period of time as specified by the MessageRetryWait parameter.
4 If MNE is able to open a new MAPI/HTTP session, it attempts to store the migration object again (such as message, task, folder, contact, etc.).
5 If a network communication issue prevents MNE from opening a new MAPI/HTTP session, MNE tries again after pausing for the period of time specified by the MessageRetryWait parameter. MNE continues to attempt to reopen the session until the session has been successfully opened, or until the user cancels the migration.
Outlook MAPI/HTTP library
The feature is configured by the following program parameters in the [Exchange] section of Task Parameters and Global Defaults:

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

� MAPIRetryCount
� MessageRetryCount
� MessageRetryWait
� MaxSessionReconnectCount
If MNE encounters a MAPI API function that fails with a network or session connection related error, it attempts to recover using the following algorithm:
1 If a MAPI call fails, the API call is made again after pausing for the number of seconds specified by MessageRetryWait. MNE keeps retrying for a maximum of MAPIRetryCount times.
2 If MNE cannot recover from the MAPI error by repeating the API call within the maximum number of retries, it attempts to close the MAPI session and open a new one.
3 If the attempt to open a new MAPI session fails, MNE waits for the number of second specified by MessageRetryWait and tries opening a new session again. MNE keeps trying to reconnect for a maximum of MaxSessionReconnectCount times.
4 If MNE cannot reconnect within the maximum number of reconnect attempts, it ends the migration.
5 If MNE was able to open a new MAPI session (in step 2), it attempts to store the migration object again (i.e. message, task, folder, contact, etc.).
6 MNE attempts to migrate each object using the algorithm up to a maximum of MessageRetryCount times. If MNE reaches the MessageRetryCount limit, it assumes that there is something wrong with the object itself and it proceeds to the next object to be migrated.
Logging
For both the Quest MNE MAPI/HTTP library and the Outlook MAPI/HTTP library, depending on the Log level set in the Specify Run Information screen, retry attempts may appear in the program logs without any other documented errors or warnings.
Specific to migrating using the Outlook MAPI/HTTP library
For the Outlook MAPI/HTTP library, the default settings tell the wizard to retry a MAPI call that returns the error 80040115 or 80040125, to a maximum of three attempts at 10-second intervals.
IMPORTANT: If you set the MessageRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter as described in the next Important note that follows.
WatchDogMinutes parameter
In the Migrator for Notes to Exchange Global Defaults, the WatchDogMinutes parameter:
[General] WatchDogMinutes=180
... specifies the number of minutes of inactivity an Migrator for Notes to Exchange Wizard will wait before it concludes that a data connection has encountered a fatal error and ends the process. Migration to hosted platforms often generates more process timeouts than migration to a local server. This can cause problems particularly when migrating quantities of large messages (usually due to large attachments). Quest recommends using the default WatchDogMinutes=180 for connections to Office 365, to make the migration program "forgiving." A substantially lower setting of WatchDogMinutes=30 might be better suited to migration to a local server, where shorter and higher-quality transmission paths make timeouts less common.
IMPORTANT: If you set the MessageRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter. Quest recommends you set WatchDogMinutes at the greater of: its 180minute default, or a setting of 10 minutes for every 30 seconds of retry waiting (MessageRetryCount x MessageRetryWait).
If you still encounter timeouts with a higher WatchDogMinutes value, you can disable the feature by setting WatchDogMinutes=0. Be careful with this option, however, because it tells the program to wait indefinitely for activity, rather than reporting a fatal error after some period of time.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Configure SetUserAccountControl and UserAccountControl
Conditional Step: This step applies only if you are provisioning Office 365 from local Active Directory.
In the Global Defaults: If you intend to provision Office 365 from local AD (only), Quest recommends you set the following parameters:
[Active Directory] SetUserAccountControl=1 UserAccountControl=512
Configuring Migrator for Notes to Exchange to accommodate Office 365 Wave 15 throttling
Conditional Step: This step applies only if you are migrating to Office 365 Wave 15.
The 4.7 release of Migrator for Notes to Exchange (MNE) improved support for Microsoft PowerShell throttling in Office 365 Wave 15, and introduced two new program parameters pertaining to PowerShell connections for Wave 15. If you are migrating to O365 Wave 15, you can improve Migrator for Notes to Exchange performance by setting these two parameters in the [PowerShell] section of Global Defaults and Task Parameters:
� Configurable limit for PowerShell connections: This parameter lets you specify a per-server limit for the number of concurrent PowerShell connections Migrator for Notes to Exchange can open. For example:
[PowerShell] MaxPowerShellConnections=2
The parameter should be used to eliminate the possibility of MNE exceeding the PowerShellMaxTenantConcurrency allowed by Microsoft for the tenant. The default for this throttle is 9 simultaneous runspace connections (remote PowerShell). To calculate the recommended setting for MaxPowerShellConnections:
R / S
... where R is the number of simultaneous runspaces allowed by your tenant (9 by default), and S is the number of migration servers you will use. If the quotient is not a whole integer, round down to the next lower whole integer for the MaxPowerShellConnections parameter value. For example, if your limit is 9 runspaces and you intend to use one migration server, 9/1 = 9, and MaxPowerShellConnections=9. Or for a 9-runspace limit with 2 migration machines: 9/2 = 4.5, so MaxPowerShellConnections=4.
The default MaxPowerShellConnections=0 is interpreted as "no limit," effectively turning off this limiting feature.
� Configurable "wait" for idle remote PowerShell connections: This parameter lets an administrator specify how long (in seconds) MNE will hold open an idle remote PowerShell connection before closing it. The default:
[PowerShell] IdleConnectionTimeoutSeconds=30
... is suitable for most environments. This feature applies only to the duration of an idle state during a connection. Each command execution resets the timer to zero so a series of commands with only short idle periods between commands could keep the connection open indefinitely.
IdleConnectionTimeoutSeconds=0 would tell MNE not to wait (wait 0 seconds) for a second command after a first so every PowerShell connection would close immediately after only one command.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Prepare customattrs.tsv file to migrate Notes custom attributes
Conditional Step: This step applies only if you intend to migrate Notes custom attributes.

A Notes message contains several standard attributes such as the From, To and Subject fields and can also include user-defined fields.The MNE Data Migration Wizard and SSDM can migrate custom Notes attributes from email messages and Notes contacts to unused properties in Exchange, but only if the migration wizard knows which properties in the target correspond to which attributes in the source. The migration of custom attributes requires that you map these source-to-target attribute associations in a tsv data file before the migration so the migration applications can refer to the file to migrate the attributes.
This mapping file must be a Unicode (not ANSI) file named customattrs.tsv located in the default installation folder for the Data Migration Wizard (typically C:\Program Files\Quest\Migrator for Notes to Exchange), and also in the folder containing the notesdtapp.exe if you want to migrate Notes custom attributes using the SSDM. Both migrator applications can refer to this file to map the source attributes to free (unused) properties in the MAPI target mailboxes.
Migrator for Notes to Exchange installs a Unicode attrs.tsv file, with the same column headings required for customattrs.tsv that you can use as a template to create the customattrs.tsv file.
To create and prepare the customattrs.tsv file
1 Use a text editor to open attrs.tsv and save the open copy under the new name customattrs.tsv. Save customattrs.tsv as a Unicode (not ANSI) file in the folder and delete any data rows that appear in the copy.
2 Enter a data row for each custom attribute you want to migrate such as: ID: Name of the custom attribute--a unique string that distinguishes this row's custom attribute from all others in the file.
IMPORTANT: If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files.
SourceProperty: Name of an attribute that has been added to a Notes mail message, or to a Notes contact, to be migrated to a property in Exchange.
TargetPropertySet: The GUID for the target property set, which must be one of these values:
PS_PUBLIC_STRINGS {hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh}
... where each "h" is a hexadecimal character, with letters uppercased.
If the TargetPropertySet value is PS_PUBLIC_STRINGS, the familiar GUID for the set named will be substituted for the string provided.
TargetPropertySet can be left blank but TargetProperty must be an integer property ID in the range 0x0000-0x7FFF.
TargetProperty: Name of the corresponding MAPI property in Exchange. A hexadecimal userproperty value is created in Exchange on each migrated mail message or contact with the Notes property which holds the value. The hexadecimal values of the created properties are reported in the log (search for "custom attr" in the log file).
If TargetPropertySet is left blank, this TargetProperty value must be specified as a 16-bit integer in the range 0x0000-0x7FFF that is not already defined for some other MAPI property.
TargetPropertyType: The data type of the MAPI property which must logically correspond to the data type used in Notes. Valid values are: STRING, MV_STRING, LONG, SYSTIME, BOOLEAN.
Also, "PT_" can be prepended to any of the five types so valid values include PT_STRING, PT_MV_STRING, etc.
3 Save and close the updated customattrs.tsv file.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

For example, a typical customattrs.tsv file might look something like this:

ID SourceProperty
Attr1 ArchiveId Attr2 ArchivedDate Attr3 SaveSetId Attr4 RetentionCategory Attr5 HasAttachments

TargetProperty
Archive ID Archived Date Saveset ID Retention Category HasAttachments

TargetPropertyType
STRING STRING STRING STRING STRING

Troubleshooting problems in migrating Notes custom attributes
You can use the Microsoft MfcMapi.exe utility to view the property, and its value, if it has been created. (The utility is a free download from Microsoft; Google "mfcmapi" and visit the www.microsoft.com/downloads link.) Most problems in migrating custom attributes can be diagnosed by these quick tests:
� Verify that the target property specified in the customattrs.tsv file does not already exist, and that the target property is in the correct format. See About MAPI properties for more information.
� Verify that the customattrs.tsv file is UNICODE, not ANSI.
� Verify that the last line in the customattrs.tsv file is followed by a line feed and carriage return (position the cursor at the end of the last line and press Enter).
� If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files.

About MAPI properties
A named property name is a property-set GUID and an ID that is either a 32-bit integer or a string. A 16-bit integer alias in the range 0x8000 to 0xFFFF is assigned to the named property by MAPI. That alias is mailbox-specific.
An unnamed property name is a 16-bit integer in the range 0x0001 to 0x7FFF. That 16-bit integer is valid in all mailboxes. Examples of unnamed properties are 0x0070 (i.e., PR_CONVERSATION_TOPIC) and 0x6656, both of which happen to be used by MAPI. So these two examples cannot be used as target property values for message attributes since they are already used, although they may be used to map Notes contact attributes to Exchange.
A custom property can be unnamed or named. If it is unnamed, you must select a 16-bit integer TargetProperty in the range 0x0001 to 0x7FFF that is not already in use by MAPI. If it is named, you can select any property-set GUID. If you select a property set that is already in use, you must choose a 32-bit integer or string ID that is not already in use in that property set. If you select a brand new property-set GUID, you need not worry about IDs already in use because there will not be any.
If you want named custom properties, Quest recommends you use the PS_PUBLIC_STRINGS property-set GUID, (PS_PUBLIC_STRINGS being an alias for {00020329-0000-0000-C000-000000000046}), and use string IDs with a prefix that is unique to your application (such as Quest).

Step 5 (if mail routing by domain differentiation): Configure mail routing domain for Exchange

Conditional Step: This step applies only if you will configure email coexistence by temporary routing domains (domain differentiation in DNS) during the migration. If you will instead use smart hosts for mail routing (or will not configure mail routing at all), skip to step 6.
Whether your organization implements SMTP mail connectivity only or full coexistence with Quest Coexistence Manager for Notes (CMN), most migrating organizations use temporary SMTP domains to route traffic between Notes and Office 365. Other administrators configure SMTP mail routing with smart host servers for singlenamespace environments. The routing method must be configured at both the server and user levels. At the user level, Notes person documents and AD object records are configured later in this procedure when provisioning the target AD and synchronizing the two directories.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

If you are using subdomains for mail coexistence, configure the servers now as described the following procedure. If you are using smart hosts for mail routing, skip this step since you will configure the smart hosts in step 15.
To configure distinct domains for mail routing:
The routing domains can be subdomains of the primary domain (e.g., notes.domain.com and exchg.domain.com) or completely separate SMTP domains. As long as they are unique to the respective mail systems and resolvable (via DNS or host files), they will suffice for routing. To configure routing domains:
1 If appropriate SMTP domains are not already available, create them in DNS. One domain must direct traffic to Exchange (e.g., exchg.domain.com). Mail sent to the Notes mailboxes of migrated users will be forwarded to the corresponding mailboxes in Exchange using the exchg.domain.com domain. The other domain (e.g., notes.domain.com) is used for connectivity to Notes.
2 After configuring the new exchg.domain.com domain in DNS, configure Exchange to accept the SMTP domain, and create a recipient policy to generate appropriate secondary SMTP addresses, so all Exchange users will be able to receive mail at this domain.
3 Configure Notes to accept mail to the new notes.domain.com SMTP domain/address.
4 Verify the new domains by testing mail flow.
Step 6 (only for coexistence with Quest CMN): Install and configure CMN components
Conditional Step: This step applies only if you use the Quest Coexistence Manager for Notes (CMN) for directory, email, and/or free/busy coexistence during the migration. If you will migrate without CMN coexistence, skip to step 7.
Refer to the Quest Coexistence Manager for Notes User Guide to install and configure the desired components: Directory Connector, Mail Connector, and/or Free/Busy Connector.
Verify your CMN configuration by testing mail flow.
Free/busy coexistence with Office 365
Exchange cannot route a free/busy query to Domino for a user who already has an Exchange mailbox. Exchange can route such queries only to its own Exchange mailboxes. This Exchange free/busy limitation is explained in greater detail in chapter 1 of this Scenarios Guide (see the Provisioning and mailbox creation topic under Migration to Microsoft Office 365).
The chapter 1 reference describes a method of provisioning Office 365 that can preserve both Exchange-to-Notes free/busy queries and Exchange-to-Notes mail routing.
Directory coexistence with Office 365 and a local AD
Microsoft restricts access to its hosted AD, and these restrictions prevent the CMN Directory Connector from supporting directory coexistence directly between Domino and Office 365. But if you have a local AD, you can establish a "two-step" coexistence between Notes and Office 365, as follows:
1 Configure the CMN Directory Connector for bidirectional updates between Notes and a local, proprietary Active Directory.
2 Configure Microsoft AD Sync tool to synchronize the local AD with Office 365.
The combination of the two, run sequentially, would configure an effective directory coexistence between Domino and Office 365.
Most organizations will perform a directory synchronization as part of the process to provision a local proprietary AD (in a later step, if you intend to provision Office 365 from a local AD), and the CMN Directory Connector is well suited to that purpose.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 7: Discover Notes information
Migrator for Notes to Exchange (MNE) needs to know the location of the Notes Address Books (NABs) that will serve as data sources for the Directory Export Wizard in the next step. MNE also needs to know the Internet domains that will be used to generate the user SMTP aliases. MNE includes the following wizards to search through your Notes environment and return the necessary information:
� NABs Discovery Wizard: Locates available NABs and lets you specify the ones to be exported.
� Internet Domains Discovery Wizard: Identifies associated Internet domains.
Run these wizards to prepare for the Directory Export Wizard in the next step. See the NABS Discovery Wizard and Internet Domains Discovery Wizard chapters in the Migrator for Notes to Exchange Administration Guide for information.

Step 9: Review and modify exported data
The data captured by the Directory Export Wizard provides critical input to other Migrator for Notes to Exchange programs, so it is important to verify that the information is accurate and properly formatted. This verification step also provides an opportunity to update addresses and other attributes as necessary before initiating migrations. For example, the content may be modified to facilitate the organization's consolidation to a new SMTP domain as part of the migration process.
If you will provision the hosted AD from a local AD: It is important to verify the matching criteria for the objectmerge process (in a later step). A unique matching attribute is required to match each Notes user to the corresponding security object in AD. A matching attribute may already be available, or a custom attribute can be populated in the Domino Directory and extracted, or a matching attribute can be populated into the MNE SQL database via TSV export/import.
If mail-enabled users already exist in a local proprietary Active Directory: Ensure the address listed in the exported TargetAddress column is appropriate. With existing mail-enabled users, Migrator for Notes to Exchange uses the TargetAddress to locate the AD object for mailbox creation. The value of the TargetAddress in the SQL database must match a valid SMTP address on the target mail-enabled object. Also, the TargetAlias addresses will be applied as secondary/proxy addresses, so it is important to verify them before proceeding.

Step 10: Define user collections
Many of the Migrator for Notes to Exchange wizards are applied to particular user collections: user-defined subsets of the total universe of Notes users to be migrated. For example, in the batch migration of users by the MNE Data Migration Wizard, the batches are defined by the user collections.
User collections can come in all sizes, from a single user up to the entire universe of users all in a single collection. Collections typically number a hundred or so users per batch when migrating to a local proprietary Exchange, but often are much smaller when migrating to Office 365. The Migrator for Notes to Exchange Pre-Migration Planning Guide (see Batch vs. Per-Desktop Migration in chapter 3) explains how target type influences the optimum number of users per collection, and why it is important to devise a grouping strategy for defining collections--to specify number of users per collection, grouping method, and migration scheduling.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Use the Collection Wizard now to define your user collections. Remove any objects from collections that you do not want to provision into the target AD. Chapter 5 of the Migrator for Notes to Exchange Administration Guide provides instructions and application notes for the Collection Wizard.
NOTE: Notes groups (distribution lists) are usually defined and migrated separately, after all users are migrated. The Post-migration activities at the end of this chapter include the definition of group collections and migration of groups.
Later in this process you can assess per-user data volumes in the Notes source, and adjust your collection definitions if appropriate.
Also: Define custom design classes
Conditional Step: This step applies only if your Notes environment uses any non-standard design classes.
The MNE Notes Migration Manager (the MNE console) lets you identify any non-standard Notes design classes that are associated with Notes NSF files, but that the wizards would not recognize because the names are different from the Notes-standard design classes. The Design Classes table in Notes Migration Manager enumerates all such non-standard design classes, and associates each design class with one or more particular data types: mail, archives, or PABs. If the Data Migration Wizard or SSDM finds an NSF file that doesn't match any of the program's default design classes for archive, mail or PAB files, the program will look at these tables to find an alternate design class, and thereby determine the file type.
If your Notes environment has any non-standard design classes, use the Manage Design Classes screen in Notes Migration Manager to define them now, as part of this collection-definition step. This feature is fully documented in the Migrator for Notes to Exchange Administration Guide, chapter 1 (see User Collections: Manage Design Classes).
Step 11 (if you provision Office 365 from local AD): Provision local AD
Conditional Step: This step and the next apply only if you intend to provision Office 365 from a local proprietary AD. If you are provisioning Office 365 by Migrator for Notes to Exchange or some other method, the provisioning must occur in the Batch migration process later in this chapter. For now, skip to step 13.
In this step you provision only local Active Directory. The local AD is provisioned the same way whether your ultimate destination is a local proprietary Exchange or Office 365 (to be provisioned from the local AD). The typical and most direct method begins with an MNE directory export (step 8), followed by a bidirectional directory update by the CMN Directory Connector, as noted in the steps that follow. An illustration that follows shows the export of Domino directory data into the MNE SQL server database, which precedes the CMN directory update.
This step is necessary even if you have an existing AD already provisioned with user objects since the AD object records must be synchronized with the latest Notes source object records before migration begins. The step to provision the local AD also includes object merging (if necessary) by the MNE Provisioning Wizard to merge existing AD objects with the corresponding contacts created by the directory update. The Provisioning Wizard eliminates contact duplicates, leaving a single mail-enabled AD object corresponding to each Notes user you intend to migrate.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Quest recommends this process to provision a local Active Directory (after the directory export):
1 Synchronize the Notes/Domino directory with the local AD. Quest recommends using the CMN Directory Connector to perform a bidirectional update between the Domino directory and Active Directory. Other tools and methods are also possible, but CMN was designed to complement the Migrator for Notes to Exchange tools. This synchronization extracts user data from the Notes source and creates corresponding mail-enabled contacts in AD, and vice-versa, to update both directories with routing objects corresponding to the users in the other system (to establish complete directories).
If the local AD does not already contain user objects, this directory update creates them. Many organizations will already have an AD in place for network authentication with users provisioned as security objects. In this case, the directory update is configured to create new contacts in AD which correspond to the existing security objects in AD. (The CMN Directory Connector can detect and merge potential duplicate entities by their addresses but security objects are used only for network authentication typically do not have email addresses assigned. See the Coexistence Manager for Notes User Guide for information.) If applicable, create connectors in the CMN Directory Connector and run them to update both directories with routing objects that correspond to users in the other system.
2 Run the MNE Provisioning Wizard for all user collections to consolidate any contact/object duplicates in AD and to mail-enable objects that are already in AD. The Provisioning Wizard merges the contact information into the original corresponding AD object record, and deletes the contact, leaving a single mailenabled object in AD for each Notes user. If contacts are not added to AD for directory coexistence, the Provisioning Wizard can (without contacts) mail-enable the existing AD security principals. When no corresponding contacts exist in AD, the wizard pulls attributes and addresses from the MNE SQL database to mail-enable objects.
When migrating to Office 365, inbound external (Internet) email is never routed in the Exchange-to-Notes direction if you defer switching the MX until after all users are migrated. However, the Notes addresses in AD (when synchronized up to Office 365) are used to route internal mail from already-migrated Office 365 users to not-yet-migrated Notes recipients.
This provisioning step is important because it consolidates contact/object duplicates. An object's address attribute will tell future CMN directory updates to not re-copy the same Notes object.
In any of these scenarios, the result is a single, mail-enabled user object that corresponds to a Notes user and preserves existing security, credentials, and routing. See the Migrator for Notes to Exchange Administration Guide (the Provisioning Wizard chapter) for instructions.
3 Verify Notes forwarding addresses. A merged AD object address attribute tells future CMN directory updates to not re-copy the corresponding Notes object. The routing addresses must be verified before you continue this process.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 12: Provision Office 365 from local AD
Conditional Step: Applies only if you are using the Microsoft AD Sync tool to provision Office 365 from local Active Directory. If you are provisioning using Migrator for Notes to Exchange or some other method, you do not provision Office 365 until the Batch migration process described later in this chapter. Skip to step 13.

Microsoft AD Sync tool copies object data from your local Active Directory up to Office 365, and can provision mailenabled objects into Office 365 without (yet) creating mailboxes. In this step:
1 Run the MNE Data Migration Wizard to Prepare local Active Directory accounts for MS AD Sync. This is a necessary administrative step that must precede your running the AD Sync tool.
2 Run Microsoft AD Sync tool to provision all users in all collections into Office 365 as mailbox-enabled users. At this point, the mailboxes are created.

Step 13: Assess per-user migration volume
Before you migrate any users, you should have a general sense of the volume of data to be migrated by each user, and in each user collection. Migrator for Notes to Exchange offers a Notes Data Locator Wizard that finds source data stores, and determines the per-user data volumes within those stores.
Run the Notes Data Locator Wizard now to find the source data and review per-user data volumes for all user collections, and to verify ownership of archives and PABs prior to migration. Select View Summaries | User and Resource Detail to review the per-user data volumes and to modify your collections to accommodate unexpected or atypical data volumes. See the Notes Data Locator Wizard chapter in the Migrator for Notes to Exchange Administration Guide. The View Summaries features are part of Notes Migration Manager, described in chapter 1 of the Administration Guide.

Step 14 (if necessary): Copy end-user local data to a central location
Conditional Step: Applies only if you want to use the MNE Data Migration Wizard to batch-migrate data that resides on end-user workstations.
Migrator for Notes to Exchange includes several options for migrating data that resides on end-user workstations. One approach uses the MNE Self-Service Desktop Migrator (SSDM), which offers an optional Silent Mode to minimize user interaction and impact. This approach is discussed in chapter 4 (SSDM (per-desktop) migration) of this guide.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Some scenarios require central migration of local Notes PABs and archives. The MNE Data Migration Wizard (in the Batch migration process, as described in this chapter) can migrate content to Exchange mailboxes, personal archives, or PST files. The program must have access to the source data. Migrator for Notes to Exchange includes a PAB Replicator feature to automate the process of replicating end-user PAB data to server-based NSFs or into the mail file of each user. Alternatively, the user local data could be copied to a central location by other means. See chapter 9 of the Migrator for Notes to Exchange Administration Guide for information about how to use the MNE PAB Replicator.
Step 15 (if using smart hosts for mail routing): Configure smart hosts
Conditional Step: Applies only if you will use smart hosts for SMTP mail routing.
Mail coexistence is configured in both directions when migrating to Office 365. Some organizations use temporary SMTP domains to route traffic between Notes and Office 365, while others prefer to configure SMTP mail routing with smart host servers for single-namespace environments. If you have not configured mail routing by subdomains (domain differentiation) in step 5, you should now establish and configure the smart host servers for Domino and Office 365.
Either method must be configured at both the server and user levels. At the user level, Notes person documents and AD object records were configured when provisioning Office 365 and synchronizing the two directories. The details of configuring smart-host SMTP mail routing are beyond the scope of this guide. See your Domino and Exchange documentation and online resources for information about configuring smart hosts for those servers. In particular, see the Microsoft article Create a Send connector to route outbound mail through a smart host. To configure smart-host SMTP routing with Quest Coexistence Manager for Notes (CMN), both smart hosts are configured to point to the CMN server. Within CMN, one set of SMTP IN and SMTP OUT queues is configured to accept mail from Domino and deliver it to the receiving Office 365 server, while another set is configured to accept mail from Exchange and deliver it to Domino. Multiple CMN servers can be deployed for load balancing and redundancy. The Coexistence Manager for Notes User Guide (chapter 3) explains these configurations. Verify your smart host configurations by testing mail flow.
When the pre-migration preparations are complete
When you have completed the pre-migration preparations described in this chapter, go to Batch migration process, and/or see chapter 4 for information about SSDM (per-desktop) migration.
Batch migration process
Migrator for Notes to Exchange includes two migration engines: � The Data Migration Wizard migrates batches of users simultaneously, performs important administrative functions (mailbox creation, routing updates, etc.), and also migrates public distribution lists. � The Self-Service Desktop Migrator (SSDM) runs in memory on an end-user local workstation and migrates content for one user. SSDM streamlines the process of migrating local content, reduces burden on the migration team, and includes a Silent Mode to minimize end user interaction and requirements.
Either migration engine can be used independently for the entire data migration, or the two may be used together to meet a variety of project requirements, as discussed in the Pre-Migration Planning Guide (see the Batch vs. Per-Desktop Migration topic in chapter 3).

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

This section provides process instructions for the batch-migration portion of a migration to Office 365 where an administrator uses the Data Migration Wizard to perform the migrations for multiple batches (collections) of users. SSDM (per-desktop) migration, described in chapter 4, can also be part of your Migration Plan.
NOTE: Do not begin the batch-migration process until you have completed all the Pre-migration preparations described earlier in this chapter.
The flow chart that follows summarizes the batch-migration process for an Office 365 target. The step numbers in the flow chart correspond to the step numbers in the narrative process instructions.
This batch-migration procedure is repeated for each user collection to be migrated as shown by the looping arrow in the flow chart.
NOTE: Notes groups (distribution lists) are typically migrated separately after all users have been migrated. The Post-migration activities described at the end of this chapter include the migration of groups.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 1 (optional): Re-run directory connectors
Conditional Step: Applies only if you provisioned Office 365 from a local AD, and used Quest CMN when provisioning your local AD, in which case this step is optional but recommended. Otherwise, skip to the next step.
Many organizations experience staff additions and departures during a migration transition period and employees move from one office to another or are promoted or reassigned. Directory changes that occur during the migration project after the initial directory updates in the Pre-Migration Preparations can introduce data inconsistencies between the source and target environments. You can reconcile these differences using a "two-step" directory update between Domino and Office 365:
1 Configure the CMN Directory Connector for bidirectional updates between Notes and the local Active Directory. For details, see the Directory Connector chapter in the Coexistence Manager for Notes User Guide.
2 Configure Microsoft AD Sync tool to synchronize the local AD with Office 365.
Both the CMN Directory Connector and the Microsoft AD Sync tool can be configured to automatically run directory updates at scheduled intervals. However, you should also run directory updates manually at this step to ensure the directories are consistent before migrating each collection.
NOTE: An object that is synchronized to Office 365 with proxyAddresses will lose the proxyAddress upon the next synchronization if the UPN is changed to match the Office 365 login--which disables mail routing from Domino to Exchange.

Step 2: Refresh the MNE SQL data
To ensure your target Exchange is provisioned with current object data, update the information in the MNE SQL database before migrating each user collection. If you have updated the directories in the preceding step (optional), this process will also relay all directory changes into the SQL database. To update the SQL server database:
1 Re-run the MNE NABs Discovery Wizard and Internet Domains Discovery Wizard to refresh the location of the Notes Address Books (NABs) and the list of Internet domains that are used to generate user SMTP aliases.
2 Re-run the Directory Export Wizard to refresh the data in the SQL server database.

Step 3: Reassess and refine (if necessary) user collection membership
The MNE Data Migration Wizard is applied to particular groups of users, called collections, which were defined in the Pre-migration preparations earlier in this chapter. Each pass through this Batch Migration Process applies these migration tasks to a single user collection.
Now that you have updated your directories and refreshed your SQL data (in the two preceding steps), you should:
1 Re-run the MNE Data Locator Wizard for this collection (only), and select View Summaries | User and Resource Detail, to reassess the per- user data volume in the Notes source for this collection. The Notes Data Locator Wizard is documented in chapter 7 of the Migrator for Notes to Exchange Administration Guide. The View Summaries features are part of Notes Migration Manager, documented in chapter 1 of the Administration Guide.
2 Reassess the collection membership with respect to the aggregate data volume that will be migrated with the collection members. You may want to adjust the collection membership to better conform to your organization's grouping strategy, to take into account grouping method, optimum number of users per collection, and migration scheduling, as described in chapter 3 of the Migrator for Notes to Exchange PreMigration Planning Guide (see the Batch vs. Per-Desktop Migration topic).

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

3 If necessary, revisit the Collection Wizard for this collection to change its membership. See chapter 5 of the Migrator for Notes to Exchange Administration Guide for instructions.
NOTE: Notes groups (distribution lists) are typically migrated separately after all users are migrated. The Post-migration activities section at the end of this chapter includes group migration.
Step 4: Create Office 365 mailboxes
There are two different ways to proceed for this step depending on whether you are provisioning Office 365 from a local AD (using the Microsoft AD Sync tool) or directly from the Notes/Domino environment.

If you are provisioning from local AD
1 Run the MNE Data Migration Wizard and select Prepare local Active Directory accounts for MS AD Sync. This is a necessary administrative step that must precede running the MS AD Sync, and must precede running the wizard for any other function.
2 Run Microsoft AD Sync to create Office 365 mailboxes for the accounts in this collection which were previously provisioned (in the Pre-migration preparations) as mail-enabled (only) objects.
3 Run the MNE Data Migration Wizard again and select Set Office 365 resource capacity to complete mailbox-enabling in Office 365.
Skip to step 5 to migrate data.
If you are provisioning directly from Notes/Domino
Run the MNE Data Migration Wizard and select Create Office 365 accounts for this user collection. This feature provisions all Notes users into Office 365 and creates mailboxes for them.
- OR Provision Office 365 manually with the Microsoft online administrative tools or by some other method.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 5: Grant Exchange Admin accounts Full Access rights to created mailboxes
For MNE to connect to and write migrated content to each target mailbox, the Exchange account that is used to perform the migration must be granted Full Access rights to the mailbox. Unlike on-premises Exchange, Office 365 does not allow you to grant access at the database level. You can only grant access at the mailbox level. The permissions of each mailbox in the user collection must be configured individually. Microsoft does not provide a method to configure permissions for a group of mailboxes in Office 365 at once.
By default, MNE checks the configured permissions of each mailbox in the user collection at beginning of the migration. If permissions are insufficient, MNE grants the necessary permissions to perform the migration. However, Quest strongly recommends that you DO NOT rely on this built-in mechanism since there is a noticeable delay between granting mailbox permissions to a user and successful logins by that user. The delay before the permissions take effect is highly variable. It can be several seconds or several minutes, even as long as 30 minutes, adding unnecessary delay to the migration start.
If MNE must wait for the configured permissions to take effect, the wait time can lead to a failed migration. There is a maximum amount of time that MNE will wait for permissions to take effect, 30 minutes by default.
Quest strongly recommends that you grant the necessary permissions ahead of the scheduled migration at least one hour before the migration start time.
Using PowerShell cmdlets to configure mailbox permissions
MNE provides the following PowerShell cmdlets in the MNE PowerShell library to assist with granting permissions:
� Add-MneMailboxAdminPermission � Grants the Full Access rights needed to perform the migration. Run this cmdlet before the migration.
� Remove-MneMailboxAdminPermission � Revokes the Full Access rights. Run this cmdlet after the migration is complete.
Both cmdlets are executed within the scope of a specific user collection, provided as a parameter when the cmdlet is executed. The cmdlets configure Full Access rights for each mailbox within the user collection using the configuration information stored in the MNE database (or optionally within an external configuration file provided through a cmdlet parameter). See the MNE Administration Guide for details about the cmdlets.
If you are migrating using a pool of admin accounts, MNE grants permissions using the Role Group for the admin accounts. This ensures that MNE can access each mailbox regardless of which account in the pool is used to perform the migration.
When you perform the migration task, MNE does not know if you have pre-configured the mailbox permissions. As a result, it still takes time to verify the permissions on each mailbox within the collection. To eliminate the time taken to verify the permissions, you can also configure the [Exchange] AddFullAccessPermission INI setting to 0. Setting this parameter to 0 tells MNE that you have taken responsibility to ensure the mailboxes have the necessary permissions, and that MNE is not responsible for verification.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Step 6: Run the Data Migration Wizard to set Notes-to-Exchange mail forwarding and migrate data
IMPORTANT: If you are migrating data using file system access (rather than by server access): � Verify that all migrating users are logged off before running the MNE Data Migration Wizard. If the data is accessible through the Domino server, Quest recommends you use server access to locate and migrate the data. If server access is impossible or impractical, and you need to use file system access to locate and migrate the data, you must ensure that all users in the current collection are logged off the system. � Also, ensure the NSF file is not open in the server cache. The dbcache flush command closes all files being held open by the server for users that are no longer logged onto the server. Running the dbcache flush command prevents the server from blocking MNE access to the NSF files during the migration run.
Run the Data Migration Wizard again to:
� Set Notes-to-Exchange mail forwarding for the users in this collection.
� Migrate user data from the Domino server to the Exchange environment, for the users in the selected collection.
See the Data Migration Wizard chapter of the Migrator for Notes to Exchange Administration Guide for complete instructions and application notes.
Step 7: Distribute .pst files
If the Data Migration Wizard migrates any data to Outlook Personal Folder (.pst) files, when the migration is complete you must either:
� Notify users of the locations of their new .pst files (so each user can specify the location within his or her own desktop copy of Outlook). -- OR --
� Distribute the newly created .pst files to users' desktops.
The Data Migration Wizard names any new .pst files using the common filename, if specified, or the specified filename format. if more than one file is generated per User ID, incremental numbers are appended to the filename. For example, Smith.pst, Smith-1.pst, Smith-2.pst, etc.
NOTE: The location of the PST files is reported in: � The User migration status per collection report, available from the View Summaries screen of Notes Migration Manager. � The Report Pack Report, available from the View Report Pack screen of Notes Migration Manager.
Was that your last migration collection?
If this is not your last migration collection: Repeat this entire Batch migration process for the next collection. If this is your last migration collection, but you have more Notes users to be migrated individually by the SSDM: See the SSDM (per-desktop) migration chapter in this guide.
If this is your last migration collection and no users remain to be migrated by the SSDM (per-desktop) program, see Post-migration activities.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Post-migration activities

Step 1: Provision Notes groups into Office 365
Groups are typically provisioned separately, after all users are migrated in the Batch migration process (the preceding section of this chapter). Since the only data associated with a group is its member list, group migration consists only of the group being provisioned into the target directory. Use the MNE Groups Provisioning Wizard to provision groups either directly from Notes to Office 365, or to a local "staging" AD from which you can use Microsoft AD Sync tool to provision the groups from the local AD to Office 365.
Before you run the Groups Provisioning Wizard, you can divide the groups into collections using the MNE Collection Wizard for convenient processing. If necessary, you can update group membership and attributes in the SQL database (via TSV export and import) prior to provisioning the groups into Active Directory. For instructions, see the Groups Provisioning Wizard chapter of the Migrator for Notes to Exchange Administration Guide.
NOTE: You must run the Microsoft AD Sync tool twice to completely provision nested Notes groups (i.e., Group A contains Group B) in Office 365.
To provision groups before all Notes users are migrated, check the Message Delivery Restrictions for any Exchange group to which you want Notes users to be able to send messages. Any such Exchange group must be of the universal distribution type to be mail-enabled.
To change group distribution settings
1 In the Exchange Management Console under Recipient Configuration | Distribution Group, select and double-click the group you want to edit.
2 Click the Mail Flow Settings tab and highlight Message Delivery Restrictions and click Properties.
3 Clear the check box for Require that all senders are authenticated.
4 Click Save and restart the Exchange transport service.

Step 2 (optional): Configure ongoing directory coexistence
Conditional Step: This step applies only if you will also maintain a local proprietary AD in addition to the hosted platform.
If you are going to keep a local Active Directory up and running, you can configure the Microsoft Online Services AD Sync tool to regularly synchronize the local and hosted AD. Refer to Microsoft documentation to configure the Microsoft AD Sync tool for these ongoing synchronizations.
If you intend to keep your Domino directory running for a time, or indefinitely, you should also configure the CMN Directory Connector to regularly update the Domino directory and your local AD.

Step 3: Update mail routing

Migrator for Notes to Exchange is commonly used to automatically update mail forwarding in both systems to ensure proper routing during the migration. Migrator for Notes to Exchange can set and remove forwarding rules in both environments, as long as the mail routing domains or smart hosts are properly configured.
When the users and groups are all migrated, routing can be permanently updated to direct external incoming (Internet) mail to Office 365 instead of to the Notes environment. This step includes modifying the MX record(s) to redirect the inbound external mail. In some environments, updating mail routing also includes updating routing tables and/or firewall modifications.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

Most organizations prefer to update mail routing only after the last user has been migrated, to minimize change before and during the migration process. But the MX modification can occur at any time after all Notes users have been provisioned into Office 365 as mail-enabled objects. (If routing is updated to send inbound mail to Office 365 before a particular user is provisioned, there will be no forwarding address in Office 365 to relay the user's mail back to Notes.) The timing of this step depends on how you provisioned Office 365:
� If you provisioned Office 365 from a local AD using Microsoft AD Sync: Notes users are provisioned into Office 365 as mail-enabled objects in the Pre-migration preparations.
� If you provisioned Office 365 directly from the Notes/Domino source: Notes users are not provisioned into Office 365 until prior to their migration, per user batch.
Step 4: Post-migration cleanup
To clean up after the last user has been migrated:
1 Verify the Notes server is inactive. Ensure that the Notes server is no longer processing mail traffic or utilized for active applications.
2 If you were using SMTP mail coexistence: Delete the temporary mail routing MX domain(s) you created in the Pre-migration preparations to support routing between Notes and Office 365 during the transition. Now that all users have been migrated to Office 365 and inbound traffic is routed directly to Office 365, the temporary routing domain(s) should no longer be required.
3 If you no longer need the Notes environment: After you have verified Notes is inactive, you may take a final backup and decommission the environment.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Migration to Microsoft Office 365

4
SSDM (per-desktop) migration

� When to use the SSDM � Before running the SSDM � Configuring the SSDM � Silent mode options in per-desktop migrations

When to use the SSDM
Batch migrations and per-desktop migrations are performed using different migration engines, both included with Migrator for Notes to Exchange. This chapter describes administrator planning for and deployment of the perdesktop Self-Service Desktop Migrator (SSDM). For batch migration (multiple users at a time, performed by an administrator), see the Batch Migration sections of the preceding two chapters for migration to a proprietary Exchange target and migration to Microsoft Office 365.
The SSDM is used by an end user, or by an administrator on behalf of an end user, to extract a single user's Notes data and migrate it to Exchange. Depending on your circumstances and preferences, you may choose to migrate some or all of your users one at a time, from each user desktop, using the SSDM. For example, some administrators prefer the per-desktop tool to migrate user archives when the archives reside on individual user workstations, where that option seems easier than prepping exported user data in the SQL database with per-user values for the locations of all the local archives.
The SSDM provides a distributed migration option which runs in memory on the user workstation. The SSDM runs from a share, offers an optional Silent Mode to minimize end user interaction, and does not install anything locally. These features can eliminate the need for desktop visits by the administrator during or after the migration, although an administrator can run the SSDM at user desktops, perhaps selectively for some users. The perdesktop migration option can be used for a portion of the migration (e.g., for local archives) or to migrate all a user's data: the Exchange mailbox, PST files, or both.

Before running the SSDM

Verify all the Pre-Migration Preparations are complete before the first desktop migration is performed (see the PreMigration Preparations sections of the preceding two chapters). Pre-migration tasks are performed once prior to the first run of either the SSDM or Data Migration Wizard and not repeated for each run of a migration application.
If you are migrating with coexistence: An update of the exported directory data in the SQL database may be necessary if any users have joined or left the organization since the last run of the Directory Export Wizard. For the recommended procedure to update the directories and update Quest data tables, see the topic "How Do I Synchronize Directory Data and Update the SQL Server Database?" in Appendix A of the Migrator for Notes to Exchange Administration Guide.
Consider the following:
� SSDM customization options
� Verify .Net version and CAS permissions
� Distribution of SSDM program and user notifications

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

� If you want to run the SSDM with App-V
SSDM customization options
The SSDM can be configured to behave differently in different environments, to suit different needs and preferences. The topics that follow explain how to configure the SSDM to suit your needs. These program customizations are accomplished by manipulating certain parameters in the notesdtapp.ini file, as described in the topics under Configuring the SSDM.
Some SSDM customization features let you enforce or eliminate certain choices to match your migration strategy. For example, if you intend to migrate user server mail and address books in batches, and use the Desktop Migrator to migrate only user archives, you can customize the SSDM to migrate only archives and to not offer the option to migrate server mail or address books.
Verify .Net version and CAS permissions
The SSDM requires Microsoft .Net Framework version 2.0 be installed on each end user's workstation. If end users run the SSDM application from a network share (rather than from each user's own local copy) each user workstation must also have .Net 3.5 SP1 (or later) installed or a Code Access Security (CAS) policy granting full trust to SSDM in the network share.
For the SSDM to authenticate with Office 365 using Modern Authentication, .Net 4.5 or later must be installed. If .Net 4.5 or later is not installed, the SSDM falls back to migrating without Modern Authentication.
To add the CAS policy on an end-user workstation
If, for example, SSDM resides in a folder \\server1\shared\SSDM\, the necessary permissions can be granted by an administrator executing this command on the client machine:
%windir%\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -machine -addgroup 1 -url file:\\server1\shared\SSDM\* FullTrust -name MNE_SSDM
For more information about CasPool.exe, see this article in Microsoft online technical library, and see also the Microsoft KB article: How to determine which versions and service pack levels of the Microsoft .Net Framework are installed.
Distribution of SSDM program and user notifications
If your users (rather than you or another admin) will run the SSDM, you will need to tell them where the program file is, how to prepare their desktops for the program runs, and how to run the program.
IMPORTANT: Verify that all users have read-only access to the share containing notesdtapp.exe (the SSDM program file) and the AddressTranslation.bin file. The path is specified in the Common application directory field, on the Shared Directories Configuration screen in the MNE Notes Migration Manager. SSDM requires access to the address translation file generated by the Directory Export Wizard to convert addresses in messages, address books, and calendar content.
IMPORTANT: Any antivirus software on an end-user SSDM workstation must be configured to not scan the Quest program files directory or %temp% directory. Or a user can turn off any antivirus software prior to running the SSDM application and restart it after SSDM runs. You may want to provide instructions for how to turn off (and back on) antivirus and desktop-search applications. If an antivirus scan misinterprets an Migrator for Notes to Exchange temporary file as a threat, it will try to "clean" the file, which generates an error when the program call fails.
Typically an administrator will send an email to migrating users with a link to the SSDM program so each user can click the link in the email to launch the program. The email can also provide other pertinent information (see preceding notes), to minimize help-desk calls.
You can also include a copy of the Self-Service Desktop Migrator User Guide in PDF format, which explains how to operate the per-desktop program from the end-user point of view. The User Guide is included with your "clean"

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

software. You can either copy the PDF file to a public-access folder and link to it from the same email that introduces the SSDM to your users, or add it to the email as an attachment.
If you want to run the SSDM with App-V
The SSDM must be sequenced in with the Outlook virtual application package. The SSDM cannot be sequenced separately nor can it access a local Outlook installation directly. The Notes client must be installed locally or also sequenced in with the Outlook package.
Also, you must edit the OSD file for NotesDtApp.exe. Find:
<VM VALUE="Win32"> <SUBSYSTEM VALUE="windows"/>
</VM>
... and change the parameter value from windows to console.

Configuring the SSDM

The SSDM can be configured to behave differently in different environments to suit different needs and preferences. The following topics explain how to configure the SSDM to suit your needs. These program customizations are accomplished by manipulating certain parameters in the notesdtapp.ini file as described:
� Enabling/disabling and configuring Notes "Active Mail" processing
� Configure data destinations for different data types
� Option to track unmigrated messages
� Option to show (or hide) Error Log Report button
� Prepare SSDM scheduling and throttling
� Prepare for SSDM statistics collection
Other SSDM customization features let you enforce or eliminate certain choices to match your migration strategy. For example, if you intend to migrate users' server mail and address books in batches and use the SSDM to migrate only user archives, you can customize the SSDM to migrate only archives and to not offer the option to migrate server mail or address books. These "silent mode" features are described in Silent mode options in perdesktop migrations.

Enabling/disabling and configuring Notes "Active Mail" processing

Active Mail processing is an optional feature that can detect and convert Notes rich-content features whereby messages carry live or active functional content. For information about Active Mail, see Migrating Notes "Active Mail" in chapter 3 of the Migrator for Notes to Exchange Pre-Migration Planning Guide.
The MNE Data Migration Wizard provides options to enable/disable and configure Active Mail processing. In the SSDM you can enable and configure these features using program parameters in the notesdtapp.ini file. Active Mail processing is disabled by default (if the parameters are omitted from notesdtapp.ini).
To enable and configure Active Mail processing in SSDM, set the following parameters in the notesdtapp.ini file:
� [Notes] MigrateActiveMail=<#> Boolean; default = 0 Determines whether Migrator for Notes to Exchange's Active Mail features are enabled (1) or disabled (0).
� [Notes] ActiveMailTemplatePath=<string> String; default = <Migrator for Notes to Exchange installation directory>\ActiveMail.ntf Specifies the full path including the filename of the MNE Active Mail template file. This file provides the information necessary for MNE to process the Notes OND attachment and produce the Active Mail

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

attachment file. MNE installs a default ActiveMail.ntf to the installation directory, and that path is the default string for this parameter. However, you can specify a different path.
� [Notes] ActiveMailNotificationMessagePath=<string> String; default = <Migrator for Notes to Exchange installation directory>\ActiveMailNotificationMessage.txt Specifies the full path including the filename of the MNE Active Mail notification message text file. The SSDM inserts the contents of this file at the top of the body of any migrated message containing Active Mail. MNE installs a default file, ActiveMailNotificationMessage.txt, to the installation directory and that path is the default string for this parameter, However, you can specify a different path.
NOTE: The text file must be UTF-8 encoded and must contain a placeholder, called $ActiveMailAttachment$, that the SSDM replaces with the Active Mail NSF attachment when the message is migrated. Since the content of this file becomes part of an RTF body, characters such as "\", "{", and "}" must be escaped with a leading "\" (so they become, respectively, "\\", "\{", and "\}").
� [Notes] ActiveMailAttachmentName=<string> String; default = ActiveMail.nsf Specifies the filename you want MNE to assign to Active Mail attachment files as it will appear in the Outlook message.
� [Notes] ActiveMailTypes=<#> Integer; default = 31 Specifies which types of Active Mail will be processed. The value is the sum of the associated values of these individual types:
Encrypted mail (value = 1) Stored forms (value = 2) Hotspots (value = 4) Rich markup (value = 8) Messages with no "Form" field (value = 16) Dropdown sections (value = 32)
For example, to tell the SSDM to process encrypted mail (1), stored forms (2), and dropdown sections (32), the ActiveMailTypes value would be 35 (1 + 2 + 32). The default value 31 tells the SSDM to process every type except dropdown sections.

Configure data destinations for different data types
In the SSDM, the destination within Exchange of migrated data is not selectable in the GUI, but is controlled by three parameters in the [General] section of the notesdtapp.ini file. MNE lets you specify a migration destination within Exchange or Office 365 for each of the three primary data types to be migrated: archives, address books, and server-based data. Each type can be migrated to: user server-mail mailboxes, to user pst files, or to personalarchive (server-based) mailboxes.
The migration destination is not selectable in any screen of the SSDM (as it is in the Data Migration Wizard for batch migrations), but is controlled by three parameters in the [General] section of the notesdtapp.ini file:
[General] ArchiveDest=Server PABDest=Server ServerMailDest=Server
Each parameter determines the destination of a particular data type (archives, PABs, or server mail), to be sent to the user server mail or to a pst file.

Option to migrate encrypted messages to PSTs

The SSDM can optionally direct encrypted messages to a separate PST file, no matter how many source.nsf files are selected for the migration. The feature is enabled/disabled by a notesdtapp.ini parameter that also specifies the full filename and extension for the target PST file:
[General] EncryptedPstFileName=<filename.pst>

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

In any subsequent SSDM runs, the program preserves the earlier PST files and automatically appends a digit to the designated filename to differentiate it from previously migrated PST files (filename.pst, filename_1.pst, filename_2.pst, etc.).
The default is [null], which disables the feature so that encrypted messages are sent to the same PST files as all other (unencrypted) migrated items.
This feature is enabled only when all migrated items are directed to PST files by:
[General] ServerMailDest=PST ArchiveDest=PST PABDest=PST
If any of the item types are directed to a non-PST destination, the EncryptedPstFileSuffix parameter is ignored.
Option to track unmigrated messages
You can configure the SSDM to generate a folder of messages that are not migrated to the target. These items are referenced as doclinks in a new folder in the user Notes mailbox. You enable/disable and configure the feature using two parameters in the [Notes] section of the notesdtapp.ini file:
[Notes] WriteFailedMessageListToThisMbxFolder=<string> WriteFailedMessageListClass=<keyword(s)>
The WriteFailedMessageListToThisMbxFolder parameter specifies a name for the folder to be added to the user mailbox to contain the unmigrated messages. WriteFailedMessageListClass specifies one or more types of message failures for the feature to capture. Valid keyword values are: Errored, Skipped and Filtered.
To specify more than one type, separate multiple keywords by the pipe ("|") character, as in this example:
WriteFailedMessageListToThisMbxFolder=FailedMessages WriteFailedMessageListClass=Errored|Skipped|Filtered
The example tells the SSDM to create copies of any Errored, Skipped and/or Filtered messages and save them in a new folder named FailedMessages in the user mailbox.
You enable this feature by entering any value for the WriteFailedMessageListToThisMbxFolder parameter. (If that parameter is omitted or its value is left empty, the feature is disabled and the WriteFailedMessageListClass parameter is ignored.) The feature is disabled by default (WriteFailedMessageListToThisMbxFolder is omitted or its value is [null]), and by default WriteFailedMessageListClass=Errored (only).
Option to show (or hide) Error Log Report button
The SSDM is configured by default to offer an Error Log Report button that lets the user view the program log file for more information about any errors that may have occurred during the program run. (The button does not appear if no errors have occurred.) From the Error Log Report, a user may also save the log file or print a copy.
This feature is enabled by default, but may be disabled (so the button does not appear in any case) by a boolean parameter in the notesdtapp.ini configuration file:
[General] ShowSSDMErrorLogButton=<#>
Disabling the button may be useful in some environments where accessing a large log file might cause a user desktop to hang.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

Prepare SSDM scheduling and throttling
Migrator for Notes to Exchange includes an SSDM Throttling Utility that lets you control users' execution of the SSDM, to more evenly distribute the demand on network and server resources. Each user collection is assigned a migration "window": a specific date and time period when its member users are permitted to migrate. When a user runs the SSDM, the program identifies the user by his or her login credentials, and checks the schedule to see whether the user is early, late, or "in the window" for his or her migration.
The SSDM Throttling Utility also lets you limit to the number of concurrent SSDM program runs to prevent processing bottlenecks that might occur if too many users run the SSDM at the same time. If a user's SSDM run exceeds the limit, the user is offered the option of "parking" in a waiting list so that his or her migration program would run in the next available slot.
If you want to regulate end-user use of the SSDM in this way, run the SSDM Throttling utility before you begin the migration. Chapter 14 of the Migrator for Notes to Exchange Administration Guide provides instructions for this utility.
Prepare for SSDM statistics collection
Migrator for Notes to Exchange includes an SSDM Statistics Collection Wizard that can be configured to gather migration statistics written by the SSDM and load the data into the SQL database so you can track the progress of a migration project. Each time a user runs the Self-Service Desktop Migrator, the program writes its run statistics to a specified directory. The wizard gathers the statistics and adds them to the SQL Server database so they appear in the Project View screen of Notes Migration Manager.
For instructions to configure the SSDM Statistics Collection Wizard, see chapter 11 of the Migrator for Notes to Exchange Administration Guide.

Silent mode options in per-desktop migrations
The Self-Service Desktop Migrator is simple enough that most end users can run it. Some administrators simplify the process even more by customizing the desktop program to enforce or eliminate certain choices in accordance with a particular migration strategy. For example, if you intend to migrate users' server mail and address books in user batches and use the SSDM to migrate only user archives, the SSDM can be customized to migrate only archives, and to not offer the option to migrate server mail or address books.
The SSDM can be customized to skip certain screens, or even to hide all screens--to run in a true "silent mode," requiring no entries or other intervention from the end user. Whenever the program is configured to skip a screen, the program must have an alternate method to obtain the information it would collect from fields on the screen. The program can obtain some values from the operating environment--from the Windows Registry and the Outlook initialization files, etc.--and some values can be specified by parameters in the notesdtapp.ini file. Some values can also be specified by parameters in the notesdtapp.ini file, described in the first topic.
The silent-mode program customizations are optional, accomplished by manipulating certain parameters in the notesdtapp.ini file. If you leave the parameters at their default values, the SSDM runs in default mode, displaying all screens and all options.
Multiple configurations can be established in advance of the migration to meet the needs of a variety of user types, and separate links can be distributed so that different users launch different configurations of the application. For details, see:
� Command-line switches for running the desktop migrator in silent mode
� Configuration of silent mode in notesdtapp.ini
� Providing program entry values in notesdtapp.ini

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

� Hiding entire screens from the user
� Hiding certain user choices on the Specify Data for Migration screen
� For example: to migrate archives only
Command-line switches for running the desktop migrator in silent mode
When the SSDM runs in a silent mode, the program can obtain some entry values from the operating environment--from the Windows Registry and Outlook initialization files--and some values can be obtained from parameters in the notesdtapp.ini file. Some values can also be provided by command-line switches appended to the program command when the Desktop Migrator is executed. For example:
notesdtapp /silent /notesid "%LOCALAPPDATA%\IBM\Notes\Data\jdoe.id" /notespass <password>
In this list of available switches for the notesdtapp command, the /silent switch is the only one that does not have an argument:
� /silent: Enforces a true "silent" run of the program--no screens at all. The program logs errors in the log file and can end the process if it requires input data that is not available through other switches or INI-file parameters, or that cannot be obtained from the operating environment.
� /notesid <UserID>: Full path and file name of user Notes UserID.
� /notespass <NotesPassword>: Password associated with the UserID.
� /tgtprofile <ProfileName>: Outlook profile that you want to migrate -- the one into which your Notes server data, archive and/or personal address books should be placed.
� /tgtpass <OutlookPassword>: Password associated with the target Outlook profile.
� /tgtdomain <DomainName>: Domain name of the target Exchange mail server.
� /tgtuser <ADUserName>: AD user name associated with the Outlook profile.
� /tgtmsgstore <MailboxName>: Name of the target Outlook mailbox (if the Outlook profile contains more than one mailbox).
Configuration of silent mode in notesdtapp.ini
When Silent Mode is configured, the migration team configures the application in advance within the notesdtapp.ini file to determine what will migrate, the target for each migrated data type, and the filters and other configuration elements for the migration. For example:
[General] MigratePAB=0 MigrateServerMail=0 MigrateArchives=1 ArchiveDest=Server ArchiveDestServerArchive=1
... tells SSDM to migrate only archives when launched by the end user and to place the migrated data in the user server-based personal archive.
Various degrees of the silent mode option can be configured depending on the flexibility and control you want to provide to the users. However, the mode is commonly configured to run as "silently" as possible, which means users are able to complete their migrations by entering their Notes passwords.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

Providing program entry values in notesdtapp.ini
If the Self-Service Desktop Migrator (SSDM) is configured to skip certain screens, the program must have an alternate method to obtain the information that would be collected from fields on those screens. The program can obtain some values from the operating environment--from the Windows Registry and the Outlook initialization files--but some values can be provided by parameters in the notesdtapp.ini file.
When an value is specified in the INI file, the value appears as the default if the corresponding screen and option appear in the program run, or will be the prevailing value if the screen and option do not appear.

Migration choices in the Specify Data for Migration screen

Any of the migration choices in the Specify Data for Migration screen can be specified in notesdtapp.ini using these parameters:

[ArchiveData]
MigrateArchives=1 MigrateTrashFolder=1 MigrateServerMail=1 MigratePAB=1

[ServerData] MigrateTrashFolder=1

A value of 1 sets the option to "yes" (the data type is migrated if the screen does not appear), or sets the check box to be selected by default. A value of 0 sets the option to "no," or sets the check box to be empty by default. If a feature is disabled by AppDoesXxxx=0 (see Hiding certain user choices on the Specify Data for Migration screen), the corresponding INI-file parameter is ignored.
Usually these parameters are used provide the necessary values when the program is configured to skip the Specify Data screen using MigrateWhat=skip or MigrateWhat=silent (see Hiding entire screens from the user).

Outlook profile in the Select Profile screen
If the program finds more than one eligible Outlook profile on the user computer, or does not find a profile, the program displays a Select Profile screen to prompt the user to specify the profile. If one eligible Outlook profile is found, the program assumes it is the correct profile and the Select Profile screen does not appear.
You can configure the end-user program to skip the Select Profile screen but the program must be able to determine the correct Outlook profile. You can specify the user Outlook profile in notesdtapp.ini using:
[General] SelectedProfile=<ProfileName>
Specifying the user Outlook profile in the INI file is useful only if:
� All users who run the program with the INI file have the same profile name (for example, some generic name such as My Profile) though each user profile resides on the user local workstation and is independent of other user profiles.
- OR -
� A different INI file is prepared for each user run of the program so that the individual profile names can be specified.
The program does not need the ProfileName value if only one eligible profile is found on each user workstation.

Outlook mailbox in the Select Mailbox screen
If MNE finds more than one mailbox in the selected Outlook profile, MNE displays a Select Mailbox screen to prompt the user to designate the target mailbox. If only one mailbox is found for the selected profile, MNE assumes it is the correct mailbox and the Select Mailbox screen does not appear.
You can configure the SSDM to skip the Select Mailbox screen, but in that case (or if more than one mailbox is associated with the Outlook profile) the program must be able to determine the correct mailbox. You can specify the user target mailbox in notesdtapp.ini using:

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

[General] SelectedMailbox=<MailboxName>
Specifying the target mailbox in the INI file is useful only if:
� All users who run the program with that INI file have the same mailbox name (for example, some generic name like My Mailbox) though each user mailbox resides on the user local workstation and is independent of other user mailboxes)
- OR -
� A different INI file is prepared for each user run of the end-user program so that individual mailboxes can be specified.
The SSDM does not need this MailboxName value if one and only one mailbox will be found in the user's Outlook profile.
Archive destination folder in the Specify Directory for Migrated Archive screen
You can specify the destination folder (path) for the user migrated archive in the [General] section of notesdtapp.ini using:
[General] SelectedPstDir=<path>
... where <path> is the full UNC path relative to the user computer.
This value, if necessary in a particular program run, would otherwise be specified in the Specify Directory screen.
The default for this parameter is the Outlook Default Directory which the program can determine from the operating environment. This parameter is necessary only if you want user migrated archives to go to a location other than the Outlook Default Directory.
Filter conditions in the Select Date and Size Filters screen
The Self-Service Desktop Migrator (SSDM) lets you specify date limits and ranges for messages to be migrated-- to migrate only messages timestamped on, after, or before a certain date, or within a particular date range. You can also specify a maximum size limit for attachments. The date and size filters can be specified during a program run on the Select Date and Size Filters screen, However, the screen is hidden by default (see next section) and the filters can be defined by these parameter settings in the [Filter] section of notesdtapp.ini:
[Filter] AttachSize=<####> FirstDate=<mm/dd/yyyy> LastDate=<mm/dd/yyyy>
The AttachSize value is numeric in kilobytes. You must enter the date parameter values in an eight-digit, slashseparated format as shown, with a zero preceding any single-digit month or day. The defaults for the parameters are null so no filtering occurs.
Hiding entire screens from the user
You can customize the Self-Service Desktop Migrator (SSDM) program to make some of its screens "silent" (invisible to the end user) or to conditionally skip a screen, making it visible only if the program cannot find information from the operating environment or in the notesdtapp.ini file. The display option for each screen can be set to one of three parameter values in the notesdtapp.ini file:
� show: The screen appears in every program run.
� skip: The screen appears only if the program cannot obtain the required information from the operating environment or from parameters in the notesdtapp.ini file.
� silent: The screen does not appear in any program run. The information that would be collected by the screen is provided by notesdtapp.ini parameters or obtained from the operating environment. If the program cannot determine the necessary information, the function fails and the user is not migrated.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

(A likely cause of a failed or incomplete single-user migration is if the INI file was modified to make one or more screens "silent.")
The show, skip or silent mode can be applied to each of ten program screens by setting parameter values in the [Screens] section of notesdtapp.ini for the following:

Parameter

Screen Name (In title bar)

default

Welcome=

Welcome

show

MigrateWhat=

Specify Data for Migration

show

SelectAddrBook= Select Notes Address Books to Migrate

show

SelectArchive=

Select Notes Archive Files to Migrate

show

SelectMailFile=

Select Notes Local Mail File Replica

show

Filter=

Select Date and Size Filters

no-op*

Profile=

Select Profile

skip

Mailbox=

Select Mailbox

skip

PstDir=

Specify Directory for Migrated Archive

show

Summary=

Selection Summary

show

Progress=

Migrating Data

show

Finished=

Migration Report

show

*no-op: Functionally equivalent to "silent", but signifies that the parameter value is unassigned--in which case the screen will not appear in a program run.

The visibility of the Enter Password screen (occurs between the Selection Summary and Migrating Data screens) cannot be set or changed in the notesdtapp.ini file. This Microsoft prompt for the user Exchange login credentials can appear if the Outlook profile is configured to require login credentials. If this screen is mandatory, a completely "silent" run of the program may not be possible. Even if you set the other screens to silent mode, the program might still prompt the user for Exchange login credentials.

Hiding certain user choices on the Specify Data for Migration screen
The default display of the Specify Data for Migration screen lets the user migrate any combination of three types of data: server mail, archives and/or personal address books (PABs). However, some administrators prefer to offer only one or two of the options. Four binary parameters in notesdtapp.ini, in the [General] section, control whether these options appear in the screen:
AppDoesArch= AppDoesEncrypted= AppDoesMail= AppDoesPabs=
For each parameter, the default value 1 makes the option visible to the user on the Specify Data for Migration screen, A setting of 0 does the following:
� Makes the option invisible (unavailable to the user) on the screen.
� Masks the portions of the Welcome and Migration Report screens that pertain to the hidden option.
� Disallows the migration of that data type regardless of other parameter settings in the INI file (would override MigrateXxxx=1).
If a parameter is left unspecified in the INI file, the corresponding option will appear on the screen.
These parameters do not set the marked-vs-unmarked status of the check boxes although those status settings can be controlled by other parameters (see Providing program entry values in notesdtapp.ini).
NOTE: If AppDoesArch=0 or AppDoesMail=0, Include Encrypted Messages is not displayed even if AppDoesEncrypted=1.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

For example: to migrate archives only
In the introduction to the How Do I Customize ...? section, an example was provided of an administrator who wants to migrate user server mail and address books in batches and use the Self-Service Desktop Migrator (SSDM) to migrate user archives. Since the SSDM is used to migrate archives only, the administrator wants to hide the other migration options (server mail and PABs) and streamline the user interface. To accomplish this task, set the following values in the notesdtapp.ini file:

[General] AppDoesMail=0 AppDoesPabs=0 MigrateArchives=1
[ArchiveData] MigrateTrashFolder=1

[Screens] Welcome=skip MigrateWhat=skip SelectAddrBook=skip SelectArchive=skip SelectMailFile=skip Profile=skip Mailbox=skip PstDir=skip Summary=skip Progress=skip Finished=show

These parameters configure the SSDM to run as follows:
1 Welcome screen: Does not appear since Welcome=skip and no user entries are requested on this screen.
2 Specify Data for Migration: Does not appear since MigrateWhat=skip, and AppDoesMail=0 and AppDoesPabs=0, and the program obtains necessary archive-migration orders from MigrateArchives=1 and MigrateTrashFolder=1.
3 Select Notes Address Books to Migrate: Does not appear since SelectAddrBook=skip and AppDoesPabs=0.
4 Select Notes Archive Files to Migrate: Does not appear if user archives reside in the default location (the "archive" subdirectory under the Notes data directory) since SelectArchive=Skip, and the program finds archives in their default location.
5 Select Notes Local Mail File Replica to Migrate: Does not appear since SelectMailFile=skip and AppDoesMail=0.
6 Select Profile: Does not appear if the program finds only one eligible Outlook profile on the user workstation. Otherwise, the user is prompted to designate the profile.
7 Specify Directory for Migrated Archive: Does not appear assuming the Outlook Default Directory is the preferred archive destination folder for each user. (If not, specify a valid path for SelectedPstDir under [General], or change PstDir=skip to PstDir=show.)
8 Selection Summary: Does not appear since Summary=skip and no user entries are requested.
9 Enter Password (for Exchange): May or may not appear, per user, depending on whether the user profile requires these credentials.
10 Migrating Data: Does not appear since Progress=skip and no user entries are requested.
11 Migration Report: Appears in every run since Finished=show.
So, omitting the skipped screens, and accepting the assumptions noted in items 4, 6, and 7, the program screen sequence consists of:
1 Enter Password (for Exchange): May or may not appear, per user, depending on whether the user profile requires these credentials.
2 Migration Report: Appears in every program run, since Finished=show.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide SSDM (per-desktop) migration

5
About us
Quest provides software solutions for the rapidly-changing world of enterprise IT. We help simplify the challenges caused by data explosion, cloud expansion, hybrid datacenters, security threats, and regulatory requirements. We are a global provider to 130,000 companies across 100 countries, including 95% of the Fortune 500 and 90% of the Global 1000. Since 1987, we have built a portfolio of solutions that now includes database management, data protection, identity and access management, Microsoft platform management, and unified endpoint management. With Quest, organizations spend less time on IT administration and more time on business innovation. For more information, visit www.quest.com.
Technical support resources
Technical support is available to Quest customers with a valid maintenance contract and customers who have trial versions. You can access the Quest Support Portal at https://support.quest.com. The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. The Support Portal enables you to:
� Submit and manage a Service Request. � View Knowledge Base articles. � Sign up for product notifications. � Download software and technical documentation. � View how-to-videos. � Engage in community discussions. � Chat with support engineers online. � View services to assist you with your product.

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide About us

Index

A
access rights to source and target environments, 20, 37 Account Pool Utility, 12 Active Directory, 7
local (to provision Office 365) pre-migration state of, 7
pre-migration state of, 7 Active Directory configured for resource forest and user forest, 26 Active Directory server, configuration of, 20, 39 Active Mail processing, 60 ActiveMail.ntf file, 60 ActiveMailAttachmentName parameter, 61 ActiveMailNotificationMessage.txt file, 61 ActiveMailNotificationMessagePath parameter, 61 ActiveMailTemplatePath parameter, 60 ActiveMailTypes parameter, 61 AdAttribute column in SQL Server database, 26 AddressTranslation.bin, 59 Admin Account Pool Utility, 12 AdSearchCol column in SQL Server database, 26 antivirus software (on an end user's SSDM workstation), 59 antivirus software on the admin workstation, 20, 39 AppDoesArch parameter, 67 AppDoesEncrypted parameter, 67 AppDoesMail parameter, 67 AppDoesPabs parameter, 67 App-V (running SSDM with), 60 App-V, running SSDM with, 60 ArchiveDest parameter, 61, 64 ArchiveDestServerArchive parameter, 64 AttachSize parameter, 66 attrs.tsv file, 22, 43
C
CAS policy, adding on end user's workstation, 59 CMN, 31, 50
configuring for coexistence, 24 Coexistence Manager for Notes, 31, 50
configuring for coexistence, 24 coexistence strategy,configuring, 24 Collection Wizard, 27, 33, 47, 53

collections, creating, 27, 47 collections, grouping method, 27, 46, 52 collections, scheduling for migration, 46, 52 collections, size of, 27, 46, 52 Common application directory field, 59 custom attributes, migrating, 22, 43 custom Notes attributes, migrating, 22, 43 customattrs.tsv file, 22, 43 customizing SSDM, 59, 60, 63
D
Data Locator Wizard, 29, 49 Data Migration Wizard, 33, 34, 55 data volume, 29, 49 date limits for messages to be migrated, 66 dbcache flush command, 34, 55 desktop migration, 58 desktop migrator, 58 destination (within Exchange) of migrated data, 61 destination of a migration, 7 Directory Export Wizard, 25, 46 directory update, 32, 52, 58 domains, temporary
for mail routing, 24, 44 Domino directory data, export of, 25, 46 Domino server, configuration of, 20, 39 duplicate objects in AD, 28, 48
E
Edit Default Settings (in Notes Migration Manager), 20, 39 end user training and communications, 59 Error Log Report button, hiding, 62 error retry features, 40 Exchange 2010 or later, throttling policy for, 25 Exchange mailboxes, creating, 9, 26, 28 Exchange server, configuration of, 20, 39
F
file system access to source data, 34, 55 Filter parameter, 67 filtering options, 66 Finished parameter, 67

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Index

FirstDate parameter, 66 free/busy server, 25
G
Global Default Settings, 26
H
hiding screen display elements from end users, 63, 67 hiding screens from end users, 63, 66 hiding screens from end users in SSDM, 63 hosted Exchange
defined, 7
I
identity federation and signle sign-on, 7 IdleConnectionTimeoutSeconds= parameter, 42 Internet Domains Discovery Wizard, 25, 46
L
LastDate parameter, 66

N
NABs Discovery Wizard, 25 Net Framework version, 59 Notes custom attributes, migrating, 22, 43 Notes Data Locator Wizard, 29, 49 notesdtapp.ini file, 59, 60, 63, 64, 65 notesid command-line switch for notesdtapp command, 64 notespass command-line switch for notesdtapp command, 64
O
Office 365 as a hosted Exchange target, 7 pre-migration preparations for, 18
Office 365 Admin Account Pool Utility, 12 Office 365 Wave 15
configuring MNE for, 42 Outlook profile, 65 Outlook virtual application package, running SSDM with, 60

M
mail forwarding rules, setting and removing, 34 mailbox enabling, 26 Mailbox parameter, 67 mail-enabled mailbox-enabled, defined, 18 Manage Scheduled Operations (in Notes Migration Manager), 21, 39 MAPI error retry features, 40 MAPI Properties, 23, 44 MaxPowerShellConnections= parameter, 42 merging contacts and security objects in AD, 29, 48 MfcMapi.exe utility, 23, 44 MigrateActiveMail parameter, 60 MigrateArchives parameter, 64, 65 MigratePAB parameter, 64, 65 MigrateServerMail parameter, 64, 65 MigrateTrashFolder parameter, 65 MigrateWhat parameter, 67 migration destination, 7 migration error retry features, 40 migration scenarios
defined, 7 migration statistics, 63 migration target "type", 7 MNE Compatability Mode in CMN Directory Connector, 25 MNE scenarios
defined, 7

P
PABDest parameter, 61 per-desktop migration, 58 PowerShell Runspace throttling in O365 Wave 15, 42 pre-migration preparations for proprietary Exchange and Office 365, 18 pre-migration state of proprietary local AD
as variable that determines scenario, 18 Profile parameter, 67 program parameters, 26 Progress parameter, 67 project statistics, 63 project status, 63 proprietary Exchange
defined, 7 pre-migration preparations for, 18 proprietary local Exchange network as a migration target, 18 defined, 18 Provisioning Wizard, 29, 48 pst files, distribution of (post-migration), 34, 55 pst files, location of, 34, 55 pst files, migrating to, 34, 55, 66 pst files, naming of, 34, 55 PstDir parameter, 67
Q
qcalcon.exe, 25 Quest CMN
configuring for coexistence, 24

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Index

R
recipient policy for temporary subdomain, 24 resource forest, 26 Runspace (PowerShell) throttling in O365 Wave 15, 42
S
scenarios defined, 7
scheduling and throttling (for SSDM), 63 SelectAddrBook parameter, 67 SelectArchive parameter, 67 SelectedMailbox parameter, 66 SelectedProfile parameter, 65 SelectedPstDir parameter, 66 SelectMailFile parameter, 67 Self-Service Desktop Migrator, 58
command-line switches for, 63 customizing, 59, 60, 63 distribution of, 59 end user communications for, 59 hiding screens from end users, 63 preparing for, 58 scheduling, 63 silent mode, 63 throttling, 63 Self-Service Desktop Migrator, statistics collected from, 63 ServerMailDest parameter, 61 setting displayed defaults for end users, 65 Shared Directories Configuration (in Notes Migration Manager), 20, 39 ShowSSDMErrorLogButton parameter, 62 silent command-line switch for notesdtapp command, 64 silent mode operation of Self-Service Desktop Migrator, 63 single sign-on and identity federation, 7 SMTP domains, temporary for mail routing, 24, 44 SMTP mail routing, 24, 44 for mail coexistence, 25 source data, access by file system, 34, 55 SQL Server configuration, 20, 39 SQL Server database, updating, 32, 52, 58 SSDM, 58 command-line switches for, 63 customizing, 59, 60, 63 distribution of, 59 end user communications for, 59 hiding screens from end users, 63 preparing for, 58 running with App-V, 60

scheduling, 63 silent mode, 63 throttling, 63 SSDM migration, 58 SSDM scheduling and throttling, 63 SSDM statistics, 63 SSDM Throttling utility, 63 statistics, 63 statistics from SSDM, 63 status of project, 63 Summary parameter, 67 synchronization of directories, 58
T
target type (of a migration), 7 temporary SMTP domains
for mail routing, 24, 44 tgtdomain command-line switch for notesdtapp command, 64 tgtmsgstore command-line switch for notesdtapp command, 64 tgtpass command-line switch for notesdtapp command, 64 tgtprofile command-line switch for notesdtapp command, 64 tgtuser command-line switch for notesdtapp command, 64 throttling and scheduling (for SSDM), 63 throttling policy for Exchange 2010 or later, 25 Throttling utility for SSDM, 63
U
updating SQL Server database, 32, 52, 58 user collections, 27, 46, 52 user forest, 26 user training and communications, 59
V
View Summaries (in Notes Migration Manager), 29, 33, 49, 52 volume of data, 29, 49
W
Wave 15 configuring MNE for, 42
Welcome parameter, 67

Quest Migrator for Notes to Exchange 4.16.1 Scenarios Guide Index