Chatee ahora con Soporte
Chat con el soporte

Migrator for Notes to Exchange 4.16.3 - Pre-Migration Planning Guide

About the Migrator for Notes to Exchange documentation Introduction Critical considerations Other strategic planning issues Appendix A: Known limitations of the migration process

Bidirectional resource booking

The Quest Coexistence Manager for Notes (CMN) product includes a Mail Connector that supports resource booking in both directions during the transition period of a migration. In earlier releases CMN did not support Notes user booking of Exchange resources, and that limitation introduced a "double booking" problem that administrators addressed by migrating all resource objects at the end after all the users had been migrated. Now that CMN supports bidirectional resource booking, you can migrate resources whenever you like.

Exchange users can book Domino resources by sending requests to the resource original Notes addresses. Domino acts on the request in its reservations database the same as if it had come from a Notes user.

Notes-to-Exchange resource booking is typically accomplished by one of two methods:

•
To support free/busy inquiries with N-to-E resource booking: Deletes the Domino resource and uses the CMN Directory Connector to create a forwarding contact to replace it—to route resource requests to the corresponding resource object in Active Directory.
•
If free/busy is not required: Notes-to-Exchange resource booking can be achieved by mail forwarding, where the resource in Domino is configured to forward its mail (resource requests) to the corresponding resource object in AD. (MNE can automatically configure this mail-routing when it migrates the resource.)

The best practice for resource migration is using one of the two methods described here. If you do not intend to configure the CMN Free/Busy Connector, you can migrate resource objects in the same collections with the users who use them (or whenever most of the users who use them are migrated).

Migrating Notes groups (distribution lists)

Groups, which include distribution lists, are exported from the Domino directory by the MNE Directory Export Wizard so they can be provisioned correctly in Active Directory. Since the only data associated with a group is its member list, group migration consists of provisioning the group in Active Directory. MNE includes a Groups Provisioning Wizard that can provision groups in AD from a designated group collection.

When a group is provisioned into AD, it also remains on the Domino server (the Notes/Domino original is copied, not destroyed or altered), and after migration the two groups exist independently of each other. This coexistence introduces the potential for discrepancies between the two group membership lists as group members can be added and deleted during the transition period. You can re-run the Directory Export Wizard and the Groups Provisioning Wizard to update the AD groups’ membership lists with any changes entered into the Notes/Domino originals, but there is no practical mechanism for updating in the opposite direction, from AD back to Notes.

Since the only practical update path for groups is one-way, Notes to Active Directory, most organizations wait until all users are migrated before provisioning groups into AD. This approach eliminates the need for periodic updates, and already-migrated users can address emails to Notes/Domino groups the same (transparent) way they send emails to not-yet-migrated users.

Your Migration Plan should specify whether you intend to use this "groups last" strategy or some other approach.

Migrating folder ACLs and delegation (send on behalf of) rights

By default, the Data Migration Wizard and Self-Service Desktop Migrator (SSDM) both preserve ACL information, including calendar and task folder ACLs, as they migrate Notes source data to Exchange. To disable this feature, you can set ACLs=0 in the [General] section of Task Parameters or Global Defaults (for the Data Migration Wizard), or in the notesdtapp.ini file (for the Desktop Migrator).

 
* 
IMPORTANT: For delegates and ACLs to migrate properly:
•
The ACL/Delegates' mailboxes in Exchange must be mailbox-enabled.
•
The AD profiles for users receiving migrated ACL information in Outlook must be enabled in AD. (If the user cannot log on to Outlook, MNE cannot migrate the ACL data.) If you inadvertently migrate users who are not enabled in AD, you can remigrate with RemigrateMode=0 to replace the previous data (without ACLs) with new copies of the same data with ACLs.

A few other notes about migrating ACLs and Delegation Rights:

•
MNE maps the Notes Delegate permissions to Exchange so that, if no permission level in Exchange corresponds exactly to the Notes Delegate permission level, Exchange assigns the next lower level. This prevents a case in which a non-exact match yields a higher level of permissions in Exchange than was allowed in the Notes source. For example, if a Notes Delegate with access level Editor is authorized to Delete owned document but not to Delete any document, Exchange assigns the Delegate to the Author level in Exchange.
•
Migrator for Notes to Exchange migrates the Delegates and ACLs of all folders involved in the migration.
•
Exchange does not assign the non-specific Custom access level but assigns the defined, more specific access level that is closest to the original Notes level without exceeding any Notes permissions.

Migrating root folder permissions

Permissions on each folder in Exchange are configured to grant equivalent access, depending on the type of content being migrated to the folder. In addition to configuring permissions on folders where content is being migrated, MNE also configures permissions on the mailbox root folder. Although the root folder does not contain any content, the permissions on this root folder affect how folders in the mailbox can be accessed by other users using Outlook. You can use the parameter [Exchange] RootFolderAclMode to control how permissions are migrated to the root folder. The allowed values of this parameter are discussed in the following sections.

[Exchange] RootFolderAclMode=0

This setting directs MNE to not migrate permissions to the root folder at all. Permissions are only set on the content folders. Without permissions on the root folder, users can access content only by directly opening a folder using the Outlook Open user folder feature. This feature only supports so called “well-known folders”, such as the Inbox, Calendar, Contacts, etc.

Use this setting to limit access to well-known folders.

 
* 
NOTE: Permissions are still configured on custom folders. It can be difficult to access custom folders with no permissions configured on the root folder, but do not assume that it is impossible to do so.
[Exchange] RootFolderAclMode=1

This setting directs MNE to limit permissions on the root folder to the Folder Visible right. The Folder Visible right grants users the right to view properties of the folder as well as inspect the folder for subfolders that the user can access. Users who have read access to content of any sort in Notes are migrated to the root folder in Exchange with the Folder Visible right.

With permissions granted on the root folder, users can access content by adding the mailbox to their Outlook profile, which allows the root of the mailbox to be listed on the Outlook Folder Pane. This makes it easier to explore the content of the mailbox, enabling users to access more folders than the well-known folders.

In Exchange, when a folder is created, it is initialized using the permissions of its parent folder. As a result, when using this setting, any folders that are created directly under the mailbox root after the migration has completed are initialized with Folder Visible rights only. If the folder is intended to contain mail content, users who have access to the content of other mail folders may not have access to the content within this new folder.

Conversely, users who have access to calendar data, but not mail data, are able to navigate the folder structure within this new folder (but not see the contents of the folder), because those users will have been granted the Folder Visible right.

Use this setting to allow users to navigate through all migrated content to which the user had access in Notes without automatically granting access to folders that are created directly under the root folder after the migration has completed.

[Exchange] RootFolderAclMode=2

This setting directs MNE to configure permissions on the root folder identically to all other mail folders (such as the Inbox).

This configuration allows users with access to mail to access content by adding the mailbox to their Outlook profile, allowing the root of the mailbox to be listed on the Outlook Folder Pane. This makes it much easier to explore the content of the mailbox, enabling users to access more folders than the well-known folders. Users who have access to calendar data, but not mail, can only access the calendar folder by directly opening the calendar using Outlook Open user folder feature.

As previously discussed, any new folders that are created directly under the root inherit their permissions from the root folder. As a result, new mail folders that are created after the migration have their permissions granted exactly the same as all other mail folders.

Use this setting to allow for new mail folders to be configured the same as other mail folders. It is acceptable for users with calendar access only to open the calendar folder directly through Outlook.

[Exchange] RootFolderAclMode=3

This setting combines the previous two settings (1 & 2). Users who have access to mail content in Notes have identical access granted to the root folder. Users who have access to calendar data, but not mail data, are granted Folder Visible rights on the root folder.

This configuration allows users with access to content of any kind to access the mailbox by adding it to their Outlook profile, allowing the root of the mailbox to be listed on the Outlook Folder Pane. This simplifies access for all users who have been granted some kind of access to the Notes mail file.

As previously discussed, any new folders that are created directly under the root inherit their permissions from the root folder. Any new folders that are created at the root of the mailbox after the migration contain the permissions necessary to allow users with access to mail content to access the content of this new folder.

Users who have access to calendar data, but not mail data, are able to navigate the folder structure within this new folder (but not see the contents of the folder), because those users have been granted the Folder Visible right.

Use this setting if simplicity of access is of paramount importance, while ensuring that the content of new mail folders can be accessed by users with access to mail content. It is acceptable that users with access to calendar data can view the folder structure of newly created folders (but not their content).

 
* 
NOTE: This setting is the default setting for the RootFolderAclMode parameter
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación