If you would like to read the other articles in this series please go to:
- Migrating from Domino to Exchange 2007 (Part 1)
- Migrating from Domino to Exchange 2007 (Part 2)
- Migrating from Domino to Exchange 2007 (Part 3)
- Migrating from Domino to Exchange 2007 (Part 4)
- Migrating from Domino to Exchange 2007 (Part 5)
This is the sixth and final part of this article that has seen us cover the new Transporter Suite for Lotus Domino. We’ve covered the installation of the transporter suite, the configuration of directory synchronization and calendar free/busy sharing between neilhobson.com’s Exchange system and nghcloud.co.uk’s Domino system, and also the migration of users from the Domino directory to Active Directory. In this final part we’ll cover the actual migration of the Domino mailbox contents into an Exchange 2007 mailbox. There are a couple of things to consider before we actually migrate the mailbox data, so let’s start with the enabling of Exchange impersonation.
Exchange Impersonation
Before you migrate the nghcloud.co.uk users’ mailbox contents to the neilhobson.com Exchange system, you must enable Exchange impersonation. This is a process that allows the user account that you are using to temporarily be authenticated as the mailbox owner. If you don’t do this, you’ll see the error below when attempting to migrate a mailbox.
Figure 46: Impersonation Error When Migrating a Mailbox
To set Exchange impersonation, you need to use the Exchange Management Shell. The cmdlet to use is the Add-ADPermission cmdlet. In my example scenario, the user account that I am using to migrate the mailboxes is neilhobson.com’s Administrator account. In this case, the cmdlet syntax is as follows:
Add-ADPermission – Identity (Get-ExchangeServer).DistinguishedName –User (Get-User –Identity Administrator | Select-Object).Identity –ExtendedRight ms-Exch-EPI-Impersonation
That’s quite a complicated cmdlet so be sure to type it correctly unless you are pasting it in. If you do paste it in, make sure you change the account name if you need to; the account name in my example is ‘administrator’ found roughly in the middle of the overall cmdlet. In Figure 47, you can see the cmdlet being run and the resulting output:
Figure 47: Running Exchange Impersonation Cmdlet
Handling Large Attachments
The final thing to consider before performing the actual migrations is the handling of large attachments. Exchange Web services are used to migrate the mailbox contents but by default Web services will not migrate attachments that are larger than 4MB unless some additional configuration is made. The error that you will see when attempting to migrate attachments greater than 4MB is shown in Figure 48. Note the warning error text that includes the subject of the message, which in this case was ‘Large attachment’ as well as the error detail of ‘maximum request length exceeded’.
Figure 48: Attachment Migration Warning
To raise the limit past 4MB requires a change to be made on every Client Access Server within the Exchange organization. The change is to add an additional line into the web.config file that is part of the EWS virtual directory on a Client Access Server. You can either make this by browsing for the file within the file system itself, or via IIS Manager. The latter option ensures that you are modifying the correct file so that’s what we’ll use here. The change is achieved by the following series of steps:
- Run IIS Manager.
- Expand the Client Access Server name, which is W2K3BASE in this example. Under that, expand Web Sites followed by the Default Web Site object to reveal the virtual directories underneath. One of these will be the EWS virtual directory.
- Right-click the EWS virtual directory and choose Explore from the context menu. In the right-hand pane several files should now be visible as shown in Figure 49.
Figure 49: Exploring the EWS Virtual Directory
- Notice that one of the files is named web.config. Right-click this file and choose Open from the context menu. In the resulting window, select the Select the program from a list option and click OK.
- You should now be at the Open With window. Choose the Notepad application to open the web.config file with, and optionally the check box to Always use the selected program to open this kind of file.
- The web.config file should now be open in Notepad. Locate the string <system.web> that is found towards the end of the file. Under this text, add the following string. Note that in the example I’m using below the value is set to 20480, which is in KB. Thus, I’m allowing attachments up to 20MB.
<httpRuntime maxRequestLength=”20480” />
- Your web.config file should now look like the one shown in Figure 50 below. Assuming you’re happy with this, save the file and then close both Notepad and IIS Manager.
Figure 50: Modified web.config File
Mailbox Migration
We are finally there – the point where we can now migrate the mailbox contents off of the Domino server and onto the Exchange 2007 server. The neilhobson.com administrator will be running the migration process from the actual Exchange 2007 server itself, since this is where the Notes client has been installed. It is possible to run the migration process from a workstation, although the Exchange Management Console and Notes clients must also be installed there. The Notes client ID file must have Reader access or higher to the databases containing the mailbox information that is to be migrated.
Here are the steps required to complete the mailbox migration:
- Run the Transporter Management Console and navigate to the Mailboxes object in the console tree.
- In the work pane, right-click the mailbox or mailboxes to be migrated and choose Migrate Selected Mailbox… from the context menu. In actual fact, even the context menu text changes to Migrate Multiple Mailboxes… if you select multiple mailboxes for migration. This will invoke the Domino Mailbox Migration wizard, which has an opening Introduction screen.
- The next screen, the Migration Options screen, should be configured as follows. A completed screen is shown in Figure 51.
a. Target Exchange Mailbox Database. Here you need to click the Browse… button and in the resulting Select Mailbox Database window choose the relevant database to store the new mailbox. This is a required action even if you created a mailbox when migrating the Domino user from the Domino directory to Active Directory.
b. Filter Options. Choose the date range for mailbox data that you want migrated. If you want everything migrated, leave the check boxes deselected.
Figure 51: Mailbox Migration Options Screen
- The next screen is the Progress screen. Just click the Migrate button to commence the migration process. If the migration process completes successfully, you should see the Completion screen looking like the one shown in Figure 52.
Figure 52: Successful Domino Mailbox Migration
Of course, as you’ve guessed by now you can also use the command shell to migrate mailboxes as well. The Move-DominoMailbox cmdlet is the one to use. For example, to migrate the mailbox belonging to the Domino Administrator account to Exchange 2007, we’d use a cmdlet such as:
Move-DominoMailbox –SourceIdentity “Domino Administrator/nghcloud.co.uk” –TargetMailboxDatabase “W2K3BASE/First Storage Group/Mailbox Database”
I’ve wanted to focus more on using the management console in this article but as you can see the command shell is very useful for performing tasks such as the bulk migration of users from Domino to Exchange.
Just to satisfy ourselves what things look like when migrated, Figure 53 shows Domino User 9’s Inbox after migration. The calendar and tasks items also migrated too.
Figure 53: Migrated Domino Mailbox
Summary
Over the six parts of this article we’ve covered the main feature set of the new Transporter Suite for Lotus Domino, allowing neilhobson.com and nghcloud.co.uk to initially coexist with shared address books, but ultimately to migrate nghcloud.co.uk from Domino to Exchange. There are things that the tools won’t migrate, such as encrypted mail and archives. There are 3rd party tools that can help in some areas, but the transporter suite sure is a good place to start if you’re planning a migration from Domino to Exchange. Or even just planning a coexistence phase, of course.
If you would like to read the other articles in this series please go to:
