Anda di halaman 1dari 56

Migrating Domino Server to Exchange Server 2007

PART I A look at the new Microsoft Transporter Suite for Lotus Domino and how to use it to migrate to Exchange 2007
Exchange 2003 comes with several separate tools to allow you to coexist with, and migrate from, Lotus Domino. These are the Microsoft Connector for Lotus Notes, the Microsoft Exchange Calendar Connector and the Exchange Migration Wizard. The connector itself has two main purposes, namely to transfer messages between the two systems as well as to provide directory synchronization in both directions. The calendar connector, as its name suggests, allows users to see calendar free/busy information no matter whether they are located on Exchange or Domino, whilst the migration wizard extracts data from the Domino mail databases and imports it into an Exchange mailbox. These tools have served consultants and administrators well over the years as systems have been migrated from Domino to Exchange. Now with Exchange 2007 we have the new Microsoft Transporter Suite for Lotus Domino which offers new and updated tools in one convenient suite. In the same way that Exchange 2007 comes equipped with the Exchange Management Console, the transporter suite comes equipped with the Transporter Management Console. This ensures that administrators are presented with a familiar interface that they can quickly adapt to using. Furthermore, in the same way that Exchange 2007 comes equipped with the Exchange Management Shell, the transporter suite offers its own Transporter Command Shell meaning that administrators can take full advantage of the powerful shell commands to perform tasks such as the scripted migration of mailboxes from Domino to Exchange 2007.

The transporter suite consists of five components. These are:

Directory Connector. This synchronizes objects between the Domino Directory and Active Directory in much the same way the Microsoft Connector for Lotus Notes does in Exchange 2003. Free/Busy Connector. Like its Exchange 2003 counterpart, this gives users running the Outlook and Lotus Notes clients the ability to perform calendar free/busy queries across the two systems. Directory Migration. The directory migration component allows you to create new Active Directory user accounts for the Domino Directory users. Mailbox Migration. This performs the actual migration of user data from Domino mail databases to Exchange 2007 mailboxes. Application Migration. The application migration component allows for the migration of Domino applications to Microsoft SharePoint. One thing you may notice from the above list is the lack of anything that actually allows bi-directional message transfer between Domino and Exchange 2007. This is because message routing between Domino and Exchange 2007 now uses SMTP rather than the more traditional method of routing messages across the Microsoft Connector for Lotus Notes. I will not cover this area any further within this article as there is not much more to say about SMTP routing that has not been covered as yet in many other articles. I would also like to point out at this stage, that the focus of this article will be on the first four components listed above, which means that we will not be looking at how to migrate Domino applications to SharePoint. Additionally, I shall not be focusing on the specific steps on how to configure the Domino environment with regards to processes such as creating new person documents or setting up Domino for SMTP mail, for example. These processes are fully detailed in the online Domino documentation. What I will cover, though, is configuring the Domino foreign domain document required for the Free/Busy Connector in part three of this article. There is quite a lot of material to cover, so this article will be spread over six parts. Prerequisites and Version Support In most coexistence and migration scenarios, the particular version of the source messaging system that is supported by the migration tools is always of concern. The first thing to determine is that on the build of the transporter suite that

I tested, Microsoft states that it is a requirement that the Lotus Notes 6.x or 7.x client is installed on the server that will run the Directory Connector; the Directory Connector is something we will create later on. There are also things to note around Microsofts support for the versions of Lotus Domino. Only Lotus Domino 6.x and 7.x are supported for interoperability. In other words, you cannot use Lotus Domino 5 for directory synchronization, free/busy lookups or message routing using SMTP. However, Lotus Domino 5 is supported for the user and email migration that we will perform later on in this article. Finally, the transporter suite is not supported on Windows Vista at the time of writing this article. For this article, I am using Exchange 2007 and Lotus Domino 7.0.2. Coexistence & Migration Scenario In this article, I am going to use the scenario of two organizations called Contoso and Fabrikam. You may have heard of these organizations before. Contoso is already using Exchange 2007 and has recently purchased Fabrikam who is using Domino 7. Contoso has an SMTP domain name of contoso.com, whilst Fabrikam has an SMTP domain name offabrikam.com. Contoso decides to enter an initial coexistence phase with Fabrikam as it cannot migrate all users from Domino to Exchange immediately. There are four major steps required to complete the process of coexistence and migration from Domino to Exchange. They are:

Directory synchronization. This is where Contoso and Fabrikam share address books across the two systems. Free/Busy lookups. Configuration of the free/busy connector allows users on either system to check the availability of users on the opposing system. Migrate users to Active Directory. This process ensures that the Domino users email addresses are represented in the Exchange Global Address List (GAL). Migrate mail to Exchange. When Fabrikam is ready to move users from Domino to Exchange, this process moves the users mailbox items from one system to the other. To simulate this environment in my lab I have used just a single domain controller running Exchange 2007 and another server running Domino 7.0.2. Of course, in real-world environments it is likely that the various components, such as the

transporter suite itself, will be spread across different servers. Also, I am going to use the initial Domino administrator account that was first set up as the account that I will be using to run the transporter suite this will have all required Domino permissions. In a live environment, a dedicated account would likely be used and so where appropriate I will detail the Domino permissions required for this account. Installing the Transporter Suite Before we get on with directory synchronization and then the actual migration, we need to install the transporter suite on the Exchange 2007 server. Before we do that, do not forget that you will need the Notes client installed onto the Exchange 2007 server as well. As this is an article focused on Exchange, I will not give full details of that here there is plenty of online help in this area. The process of installing the transporter suite is a simple process which is achieved as follows: 1. Download the transporter suite from this location. Note that there are two versions of the file, namelytransporter.msi for 64-bit systems and transporter32.msi for 32-bit systems. 2. On the Exchange 2007 server, run the relevant MSI installer and go through the opening welcome screen followed by the license agreement screen. 3. At the Select Components and Install Location screen, ensure that the Microsoft Transporter Toolsoption is selected for installation but that the Free Busy Connector Add-In Task for Lotus Domino is not. Do not forget on this screen to make sure that the installation location is set to your desired location. The default location is C:\Program Files\Microsoft Transporter Tools. This screen is shown in Figure 1. 4. Finally at the Ready to Install screen, click Install.

Figure 1: Transporter Suite Component Selection Once installed, you will notice a new program folder called Microsoft Transporter Suite for Domino that contains the management console and shell. Directory Synchronization In our sample scenario, the first step for Contoso having acquired Fabrikam is for the two organizations to have a consistent GAL across the two systems. In other words, all users should be able to see every other user from within the Exchange and Domino systems. Domino users will be synchronized into Contosos Active Directory as mailenabled contacts, so it makes sense to create a specific Organizational Unit (OU) for this purpose. There can only be a single target OU defined as the import container and within this article this OU will be called Domino Users. Similarly, Exchange-related Active Directory objects such as users, groups and contacts will be synchronized into the Fabrikam Domino system, specifically into the default NAMES.NSF directory. You will see later on that there are check boxes for configuring whether or not Active Directory mail-enabled groups and contacts are synchronized into Domino, so these choices are optional.

Let us run through the process of creating the Directory Connector to allow this synchronization process to occur. To successfully complete the process from the Exchange side, the account used must be delegated the Exchange Server Administrator role. Actually creating the Directory Connector is a very straightforward affair as there arent any options to configure. You can either create the connector with the Transporter Command Shell or via the Transporter Management Console. Let us look at using the console first: 1. With the management console open, select the Connect option from the console tree. 2. Either right-click the Connect option and choose Create Directory Connector from the context menu, or choose the same named option from the Action pane. 3. You will now be at the Create Directory Connector wizard introduction screen. Click Next here and then click Create at the Progress screen. Job done! You can then click Finish to exit the wizard. To do the same via the shell, just run the New-DominoDirectoryConnector cmdlet. It is as easy as that, although you can create the connector and configure it with the various settings at the same time. The result is a newly created Directory Connector as seen in Figure 2. It is not configured though, which is something we will be looking at in part two of this article.

Figure 2: Newly Created Directory Connector

PART II The completion of the directory synchronization process between Exchange 2007 and Lotus Domino.
Domino Permissions Before we start configuration of the Directory Connector, it is worth noting the permissions required within Domino for this to work. As I said in part one of this article, I am using the default Domino administrator account that has all required permissions. If you want to use a different Domino account, Microsoft states that this account must have at least Editor access to the Domino directory which in Fabrikam's case is names.nsf. Additionally, the account will require the UserCreator and UserModifier roles as well as the ability to delete documents. How this is configured for the default Domino administrator account is shown in Figure 3, where the access control list for names.nsf is depicted. As you can see, the Domino administrator account has Manager access by default, which is higher than the required Editor access.

Figure 3: Domino Directory Access Control List

Configuring the Directory Connector Now let's go back to the Transporter Management Console and configure directory synchronization. In the main transporter suite window, you will see the newly created Directory Connector listed as shown in Figure 2 in part one of this article. Configuring the Directory Connector is more complicated than creating it. Let's walk through the process required by Contoso to complete the synchronization process with Fabrikam. 1. Highlight the Directory Connector that was just created, right-click it and choose Properties from the context menu. Alternatively, choose the Properties option from the Actions menu. 2. The properties of the Directory Connector are displayed and you will see four tabs to be configured. TheGeneral tab has various settings that are configured as follows. A screen shot of Contoso's configuration is shown in Figure 4. a. Sync Schedule. This is a drop-down selection box that has predefined options ranging from 15 minutes to 24 hours, as well as a 'never' option which is the default. Of course, you will want to choose an option that reflects how often you would like the address books updated. Let's choose 15 minutes for this article. b. Global Catalog. This is the global catalog server that will be used for the Active Directory reference when performing directory synchronization. Click the Browse: button and choose the relevant global catalog server. c. Domino Server. Obviously this is the name of the Domino server that you wish to connect to for directory synchronization purposes. In our example, this is DOMINO/FABRIKAM. d. Notes Password. Here you type the Notes ID password for the account that is configured on the Notes client installed on the server containing the Transporter Suite. Since we are using the Domino administrator account, we type that account's password here.

Figure 4: Directory Connector General Tab 3. The Sync to Active Directory tab controls which Domino directories are synchronized into Exchange. The specific options to configure are: a. Source Domino Directory. To complete this configuration, we should first click the Add button which presents the New Source Domino Directory Entry window. The fields in this window are configured as follows: a. In the Domino Directory field, we enter names.nsf which is the default Domino Directory that contains Fabrikam's users. These are the users that are required to be synchronized into Active Directory. b. In the Domain Name field, Fabrikam's Domino domain name is entered, which in this case is fabrikam.

c. In the SMTP Domain field, Fabrikam's SMTP address space is entered, which isfabrikam.com. The completed window is shown below in Figure 5.

Figure 5: New Source Domino Directory Configuration b. Target Active Directory. This option is used to choose the target OU that will be used to store the mail-enabled contacts that represent the Domino users. You will remember that we created the Domino Users OU specifically for this purpose so that's the OU that is specified here, chosen by clicking the Browse: button and selecting the relevant OU. The completed Sync to Active Directory tab is shown in Figure 6.

Figure 6: Directory Connector Sync to Active Directory Tab 4. The Sync to Domino tab is used to configure directory synchronization from Exchange to Domino. The specific options to configure are: a. Source Organizational Units. Here we choose the OUs in Active Directory that contain the Exchange users, groups or contacts that we wish to synchronize into Domino. In Contoso's case the Head Office OU is selected which results in all objects from this OU and all objects from all sub-OUs of the Head Office OU also being added. This is shown below in Figure 7. This is achieved by clicking theAdd button and then browsing to the relevant OU in the New Source OU Entry window that is displayed. b. Target Domino Directory Names and Addresses (NSF) File. This field is used to select the name of the Domino Directory that will receive the Exchange users, groups and contacts configured in the previous step. By default, this is set to names.nsf although this

can be changed to an alternative Domino Directory if required. In our case, Fabrikam requires that the Exchange information is synchronized into names.nsf. c. Routable Exchange Domains. Here we configure Contoso's SMTP domain name of contoso.com as a routable Exchange domain. If Contoso had additional SMTP domain names such as contoso.org, we would need to make sure that these were included as well. These can be added simply by clicking the Add button and entering the relevant SMTP domain name into the field in the Add Routable Exchange Domain Entry window.

Figure 7: Directory Connector Sync to Domino Tab 5. The final tab to configure is the Advanced tab. This is shown below in Figure 8. Note the options to choose whether to synchronize groups and contacts. You can also choose a list of Domino groups that you do not want to synchronize into Active Directory. We will leave the defaults within this article.

6. The configuration of the Directory Connector is now finished. Just click OK to return to the main transporter suite window.

Figure 8: Directory Connector Advanced Tab You can also create and configure a Directory Connector at the same time via the New-DominoDirectoryConnector cmdlet. I will not repeat all the various parameters here, but the Syntax portion of Figure 9 will show you what the parameter names are. Many of the parameter names are self explanatory as they can be linked to the options you've seen from within the Transporter Management Console. The transporter suite help file has full details if you are unsure.

Figure 9: New-DominoDirectoryConnector Syntax Performing a Synchronization Once the Directory Connector has been configured, the service must be started before any synchronization can take place. The service name is Microsoft Exchange Directory Connector Service for Lotus Domino and note that, by default, the service startup parameter is set to Manual so you will want to change this to Automatic. If you do not start the service yourself, you can see the timeout error shown in Figure 10 when attempting to synchronize directories.

Figure 10: Directory Connector Timeout Error You can either wait for the synchronization process to run according to your configured schedule, or, as is more likely the case when first setting up the Directory Connector, you can force a synchronization process immediately. In the console, right-click the Directory Connector within the Transporter Management Console and choose the Synchronize Now: option from the context menu or Action pane. Doing this invokes the Synchronize Directories Now wizard which has an introduction screen followed by: 1. Synchronization Options screen. Here you will see different types of synchronizations to perform such as 'update' or 'full' synchronizations, together with the direction in which you wish to perform them. Since this is the first time we are running the directory synchronization process between the two systems, we should choose the Full Synchronization option followed by the Full two way synchronization: option. This performs a fresh synchronization run, so

clearly you wouldn't want to run this process too often unless you had a specific need to. It will also delete existing objects from a previous synchronization run and re-create them if they still exist. The more likely on-going option to choose is the Update Synchronization option which merely changes updated or modified objects. Since this is the first directory synchronization run, you should choose to synchronize in both directions at this time. This screen is shown in Figure 11. Once you are happy with your choice, click Next. 2. The Progress screen is then displayed. Here, just click the Synchronize button. The connector will then begin the synchronization process, hopefully culminating in a successful synchronization. Then just click theFinish button to close the wizard.

Figure 11: Synchronize Directories Now Wizard You can use the shell to do the same thing via the following simple cmdlet:

Start-DominoDirectoryConnector -FullReloadToAD -FullReloadToDomino You do not need to use the -Identity parameter in this case since there is only a single Directory Connector. You can use the UpdateToAD and UpdateToDomino parameters to perform an update synchronization. Now that we have run the directory synchronization process, let's check that it has completed successfully. The first thing to do is to check the contents of the Domino Users OU and as you can see from Figure 12 this is now populated with mail-enabled contacts representing the Fabrikam Domino users and groups. Similarly, checking the Domino Directory reveals that this is now populated with the Exchange users and Groups as shown in Figure 13.

Figure 12: Domino Users in the Notes Users OU

Figure 13: Exchange Users in the Domino Directory Diagnostics Logging As you might expect, the transporter suite can also place information into the event log during the directory synchronization process which you can use for troubleshooting failed synchronization attempts. There are three different categories for the DominoDirectoryConnector application, which you can see if you perform the following cmdlet: Get-TransporterEventLogLevel | fl The result of this is shown in Figure 14, where you can see the three categories listed as Service, Controller andDirSync.

Figure 14: Results of Get-TransporterEventLogLevel

You will see that the first two categories are set to a Low diagnostics logging level, which is the default. If you want to ramp up the diagnostics logging for one of the categories you need to use the Set-TransporterEventLogLevel cmdlet with the Identity parameter. You will see in Figure 14 that the DirSync category is set to High. This was achieved by the following cmdlet (note the format of the Identity parameter and that it includes the application name ofDominoDirectoryConnector): Set-TransporterEventLogLevel -Identity DominoDirectoryConnector\DirSync LoggingLevel High Doing this results in much more information in the event log, such as the directory synchronization event example shown in Figure 15.

Figure 15: Example DirSync Logging Information

PART III Configuring the Domino environment to prepare it for the installation of the Free/Busy Connector.

So far in parts one and two of this article weve covered an introduction to the Transporter Suite for Lotus Domino, the installation of the suite, and the initial directory synchronization process between Contoso, running Exchange 2007 and Fabrikam, running Lotus Domino 7. Now that the address books are synchronized, the next logical step is to ensure that users from each organization can see each others calendar free/busy information. Having a shared address book is good, but having the ability to query calendar free/busy information across both systems is even better; this ensures a better meeting booking experience across the two systems. Free/Busy Connector The Directory Connector doesnt allow for the querying of free/busy information across systems thats the job of the Free/Busy Connector. Now that Contoso and Fabrikam users can see each other in their respective address books, they may start to attempt to book meetings with each other. Imagine that a user within Contoso, called Exchange User 1, attempts to book a meeting via Outlook Web Access with the Fabrikam user called Domino Administrator. Without the Free/Busy Connector, the Contoso user will get the familiar no information hatched line when querying for free/busy information as seen in Figure 16.

Figure 16: Life Without the Free/Busy Connector Before we go ahead and install the Free/Busy Connector, there are a few things to note about it:

A separate process of the transporter suite, excalcon.exe, must run on a Domino server to allow free/busy requests to work. Its required to create a foreign domain document in Domino for free/busy information, something that isnt a requirement for the Directory Connector. Microsoft states that the Domino server must be started as a service and not as an application for free/busy lookups to work. This can be configured from the window shown in Figure 17 when starting the Domino server. Note the option to always start as a service.

Figure 17: Starting Domino as a Service Prepare the Domino Environment Lets look at creating the foreign domain document. Heres the process that needs to be performed on the Fabrikam Domino server. The assumption here is that this task is performed using the Domino Administrator program. 1. Run the Domino Administrator program. 2. Click the Configuration tab and then expand Messaging in the left-hand pane. 3. From the list of options presented under Messaging, select Domains. This option is shown in Figure 18.

Figure 18: Notes Domain Configuration 4. Click the Add Domain button which then presents you with the New Domain window. 5. The Basics tab should now be selected by default. Make sure that the Domain type: field is set to Foreign Domain and then type

Exchange (without the quotes) into the Foreign domain name: field. Its probably best that you use Exchange as the foreign domain name in Domino, otherwise you have to run the SetDominoDirectoryConnector cmdlet with the ForeignDomain parameter to alter the Directory Connector configuration. The relevant portion of the completed Basics tab is shown in Figure 19.

Figure 19: Foreign Domain Basics Tab 6. Next click the Mail Information tab. Enter the name of the Domino server running excalcon.exe into theGateway server name: field. Now, we havent installed excalcon.exe onto a Domino server yet, but in this case we know that the Fabrikam administrator will install it onto the server called domino/fabrikam so thats what is entered here. In the Gateway mail file name: enter mail.box. The relevant portion of the completed Mail Information tab is shown in Figure 20.

Figure 20: Foreign Domain Mail Information Tab 7. Finally, click the Calendar Information tab. The Calendar server name: field should again contain the Domino server running excalcon.exe, namely domino/fabrikam in this article. The Calendar system: field should be configured with a name for the Exchange calendar system. Microsoft recommends using a name ofExchFreeBusy, so lets stick with that in this article as the name

explains the usage fairly well. The relevant portion of the completed Calendar Information tab is shown in Figure 21.

Figure 21: Foreign Domain Calendar Information Tab 8. Once these tabs have been completed, just click the Save & Close button to complete the foreign domain creation process. If all has gone well, you should see a screen similar to that shown in Figure 22.

Figure 22: Foreign Domain Creation Installing Excalcon.exe Whilst were in Domino configuration territory, we might as well perform another of the required Domino configuration steps, namely the installation of the excalcon.exe process. This needs to be installed onto Fabrikams Domino server and is achieved by running the transporter.msi file (or transporter32.msi if youre using the 32-bit version) on the Domino server. Here are the steps required:

1. Skip through the welcome screen, then onto the Licensing screen where youll obviously need to accept the license. 2. At the Select Components and Install Location screen, make sure that the Microsoft Transporter Tools component will not be installed and that the Free/Busy Connector Add-In Task for Lotus Dominowill be. Doing this makes sure that only excalcon.exe is installed onto the Domino server and not the rest of the transporter suite. This is shown in Figure 23 below.

Figure 23: Installing Free/Busy Components 3. Complete the installation by clicking the Next button and then the Install button on the Ready to Installscreen. 4. When the installation has finished, its now time to modify the notes.ini file found on the Domino server so that the excalcon.exe process is always loaded. By default, the notes.ini file will be found in the \Program Files\Lotus\Domino folder on whatever drive you installed Domino onto. One of the lines in notes.ini begins with the string ServerTasks= such as the example shown below in Figure 24.

Figure 24: Default notes.ini File 5. The highlighted line in notes.ini shown in Figure 24 needs to be modified to include the excalcon.exe process. The additional text required to make to the notes.ini file is in the following format: ,excalcon <Exchange server FQDN> <Foreign Domain Name> In our example, Contosos Exchange server is called W2K3BASE and is within the contoso.com domain. Youll remember that weve just created the foreign domain name with a name of Exchange, so this text becomes: ,excalcon w2k3base.contoso.com exchange Therefore, the modified notes.ini file will look like the one shown in Figure 25.

Figure 25: Modified notes.ini File 6. Once notes.ini has been modified and saved, you can either restart the Domino server application or invoke the excalcon.exe process without restarting Domino by entering the following command at the Domino server console: load excalcon <Exchange server FQDN> <Foreign Domain Name> So in our case this command becomes: load excalcon w2k3base.contoso.com exchange However, its not worth doing this yet as youll get an error when you attempt to load excalcon on the Domino server. If you think about it, weve not actually created the connector yet and the required service isnt running on the Exchange server. The error is shown in Figure 26.

Figure 26: Loading excalcon.exe on the Domino Server Summary advertisement Here in part three weve looked at the first steps required in preparation for the creation and configuration of a Free/Busy Connector between Exchange 2007 and Lotus Domino. These steps have centered around the preparation of the Domino environment. In part four, well look at preparing the Exchange environment, followed by creation and configuration of the Free/Busy Connector.

PART IV Preparing the Exchange 2007 environment, then the creation and configuration of the free/busy connector

Here in part four of this article we continue our look at how Exchange 2007 and Lotus Domino 7 can coexist with the future aim of migration from Domino to Exchange. In our sample scenario, Fabrikam is running Lotus Domino 7 and Contoso is running Exchange 2007. In part three, we prepared the Fabrikam Domino environment so it was ready for the Free/Busy Connector. In this part, well prepare the Contoso Exchange environment so it is also ready, then well

proceed to create and configure the Free/Busy Connector so that users can swap calendar free/busy information. Prepare the Exchange Environment The first requirement that must be met is to download and install the Exchange MAPI Client CDO 1.2.1 package from Microsoft, available here. From the link you should download a single file called ExchangeMapiCdo.exe that can be run to extract ExchangeMapiCdo.msi. The MAPI and CDO 1.2.1 package is required to be installed onto the Exchange 2007 server because the transporter suite requires it for some functionality; starting with Exchange 2007, MAPI and CDO are no longer supplied by default. The actual installation of this package consists of nothing more than a welcome and license screen within a wizard, so Ill not detail this any further. You may remember from your reading that its possible when installing Exchange 2007 to install it without creating a public folder store. Outlook 2007 no longer relies on system folders found in a public folder store to store free/busy data and so if all clients are running Outlook 2007 its no longer strictly necessary to have a public folder store. This is the case for Contoso since it has all desktop clients running Outlook 2007 and has installed Exchange 2007 without configuring a public folder store. Why is this of importance to Contosos coexistence with Lotus Domino? The answer to that lies in the fact that the Free/Busy Connector requires the free/busy system folder for functionality. Therefore, its a requirement to have a public folder store in Contosos environment. Lets first go over how to create this public store using the Exchange Management Console. You can obviously skip this part if you already have a public folder store. 1. Run the console. In the console tree navigate to Server Configuration and then Mailbox. 2. In the work pane, right-click the relevant storage group and choose New Public Folder Database from the context menu. This brings up the New Public Folder Database wizard. 3. In the Public folder database name: field, type a suitable name for the new public folder database. In this example, well call it Exchange Free Busy since that is all it is going to do; you might choose a different name if the store is to hold user public folders too. Click the Browse button next to the Database file path: field and ensure that the public folder store will be located where you want it to be. Once youve got the right

location, click the Save button which will then take you back to the opening screen of the wizard. Ensure that the Mount this database check box is selected then click the New button. The completed screen is shown in Figure 27.

Figure 27: New Public Folder Database Wizard 4. The new public folder database should then be created and mounted successfully. If you want to use the Exchange Management Shell to create the public folder database, use the New-PublicFolderDatabasecmdlet. 5. We now need to use the shell anyway to complete the configuration. To define the access method used for free/busy requests across forests, the Add-AvailabilityAddressSpace cmdlet must be used. The parameters we need are as follows: a. ForestName. This needs to be the SMTP domain used by Fabrikams

Domino users, namelyfabrikam.com. b. AccessMethod. The AccessMethod parameter should be set to a value of PublicFolder. Therefore our full cmdlet becomes: Add-AvailabilityAddressSpace ForestName fabrikam.com AccessMethod PublicFolder If all has gone well you should see a screen similar to that shown in Figure 28.

Figure 28: Add-AvailabilityAddressSpace cmdlet Disable Public Virtual Directory SSL There is one more step required before we proceed to create the Free/Busy Connector. This step may or may not be required, depending on the Exchange 2007 configuration. Microsoft states that if the Mailbox and Client Access Server roles exist on the same server, its a requirement to disable SSL on the Public virtual directory in Internet Information Services (IIS) Manager. Heres what to do: 1. Run IIS Manager. 2. Navigate to the Default Web Site and locate the Public virtual directory. 3. Right-click the Public virtual directory and choose Properties from the context menu. The Public Properties window appears. 4. Go to the Directory Security tab and click the Edit button found in the Secure communicationssection. This brings up the Secure Communications window.

5. Clear the Require secure channel (SSL) check box as shown in Figure 29. Once this has been done, click OK twice and then exit IIS Manager.

Figure 29: Clearing SSL on the Public Virtual Directory Creating the Free/Busy Connector That was quite a few steps required to configure the Exchange and Domino environments and weve not actually created the Free/Busy Connector yet! The actual creation of the Free/Busy Connector is very easy. However, before we get to that, heres a quick note about permissions. Youll remember that for this article Im using the default Domino administrator account when connecting back to Domino. The account connecting back to Domino requires a minimum ofEditor access to the Domino directory file, names.nsf. Fortunately, the default Domino administrator account hasManager access and thus this requirement is met; this was shown in Figure 3 from part two of this article. In a similar manner, Microsoft states that the account used to connect back to Domino requires at least Reader access to the Domino Local free time info database file called busytime.nsf. Now its time to create the Free/Busy Connector. From within the Transporter Management Console the steps are as follows:

1. Select the Connect option from the console tree. 2. Either right-click the Connect option and choose Create Free/Busy Connector from the context menu, or choose the same named option from the Action pane. 3. Youll now be at the Create Free/Busy Connector wizard introduction screen. Click Next here and then click Create at the Progress screen. Like the Directory Connector created in part one, thats all there is to it. You can then click Finish to exit the wizard. The result is a newly created but un-configured Free/Busy Connector thats shown below the previously created Directory Connector. This is shown in Figure 30.

Figure 30: Newly Created Free/Busy Connector To create the connector within the Transporter Management Shell all you need to do is to run the New-DominoFreeBusyConnector cmdlet. Configuring the Free/Busy Connector Like the Directory Connector, you can configure the Free/Busy Connector at the same time it is created by using the various command line parameters. Later well look at the cmdlet used to create the Free/Busy Connector created via the management console. For now, heres how to configure the Free/Busy Connector from within the management console. 1. Highlight the Free/Busy Connector that was just created, right-click it and choose Properties from the context menu. Alternatively, choose the Properties option from the Actions menu.

2. The properties of the Free/Busy Connector are displayed and you will see two tabs to be configured. The default General tab is displayed which can be configured as follows. A completed screen shot is shown in Figure 31. a. Schedule. This is obviously how often the free/busy process runs. You have a choice here of never, every 30 minutes, or every 1, 6, 12 or 24 hours. Well choose every 30 minutes for this article. b. Days of Free/Busy information. By default, 60 days worth of free/busy information will be retrieved but this can be changed if required. The default is fine for this installation. c. Maintain information in cache (seconds). This is set to 900 seconds by default, which is 15 minutes. Retrieved schedule information is held in cache for 15 minutes using this default value, which means that any if other schedule requests for users whose details are already held in the cache occur within 15 minutes, that information will be returned from the cache rather than being retrieved again. d. Timeout (seconds). The Exchange server will wait 15 seconds whilst contacting the Domino server for free/busy information, otherwise a timeout will occur. e. Domino Server running the ExCalcon.exe task. In this case, this is obviously Fabrikams Domino server that we just installed excalcon.exe onto. Its important to enter this information using the hierarchical Domino server name, which is domino/fabrikam in this case. f. Notes Password and Confirm Password. Here we need to enter the Notes ID password for the account thats configured on the Notes client installed on the server containing the transporter suite.

Figure 31: Free/Busy Connector General Tab 3. Finally, switch to the Advanced tab and enter any Domino connected SMTP domains via the Add button. In this case, fabrikam.com is entered as this is the SMTP domain name in use by Fabrikam. The completed screen is shown in Figure 32.

Figure 32: Free/Busy Connector Advanced Tab 4. Once all parameters and fields have been configured, click OK to close the properties window and youll then be returned to the main transporter suite window. You can also create and configure a Free/Busy Connector at the same time via the New-DominoFreeBusyConnector cmdlet. Like the Directory Connector there are a lot of parameters that I wont repeat here; the Syntax portion of Figure 33 should give you an idea of what the parameter names are. The transporter suite help file has full details.

Figure 33: New-DominoFreeBusyConnector Syntax You can now start the Microsoft Exchange Free Busy Connector for Lotus Domino service on the Exchange server. Dont forget to set it to a startup type of Automatic as well. Testing Free/Busy Access Earlier in Figure 16 from part three of this article, you saw the situation where Exchange User 1 attempted to book a meeting with the Fabrikam user called Domino Administrator. Without the Free/Busy Connector, the Contoso user saw the familiar no information hatched line when querying for free/busy information. What happens now? Lets have a look at Figure 34 and see what has happened.

Figure 34: Free/Busy Information Across Systems As you can see, Exchange User 1 can now see that the Fabrikam Domino user is busy at a potential meeting time.

PART V Migration of the Domino users to Active Directory.

If youve been following this article so far youll remember that weve installed the Transporter Suite for Lotus Domino onto our Exchange 2007 server, configured two-way directory synchronization between Exchange and Domino and also configured calendar free/busy access across the two systems. This has allowed Contoso, running Exchange, and Fabrikam, running Domino, to happily coexist but it has now become a requirement to migrate the Fabrikam Domino users to Exchange. However, before we migrate the mailbox contents from Domino to Exchange, we must first migrate the Domino users to Active Directory and that will be the focus here in part five of this article. Domino Directory Migration The transporter suite can be configured to migrate information from the Domino directory into Active Directory, either into existing user accounts or new user accounts. For this article, new Active Directory user accounts will need to be created in Contosos Active Directory domain. To support this, lets create a new Organizational Unit (OU) calledMigrated Domino Users. This OU will contain the newly created user accounts, whilst the Domino Users OU maintains the mailenabled contacts created as part of the directory synchronization process. Lets look at the steps required to complete the directory migration process. They are as follows: 1. Run the Transporter Management Console. 2. In the console tree, expand Migrate and then click Directory. You should be presented with the Enter Domino Credential window as shown in Figure 35. Enter the credentials of the Domino user in use by the Notes client, just as youve done before, and then click OK. In this case, this is the password belonging to the Domino Administrator account.

Figure 35: Enter Domino Credential Window 3. Back at the main transporter suite window, you should now see the Domino users listed as seen below in Figure 36. Note that the Active Directory Account field is currently blank since no Active Directory account has been created yet; that will change shortly. You can now select the users that you wish to migrate to Active Directory. I use the term users since you can shift-select or ctrlselect multiple users at the same time. As you can see from Figure 36, Domino User 1 has been selected for directory migration.

Figure 36: Selecting Users to Migrate to Active Directory 4. With the user(s) selected, right-click and choose Migrate selected user from the context menu or choose the same option from the Action pane. This is the process to use if you want to create new Active Directory accounts for the Domino users. Well cover the main difference with the other option, Migrate with manual Active Directory lookup later in this article. Right now, having selected the migrate user option, you should now see

the Domino User Migration wizard which commences with the Introduction screen. 5. The next screen is the New Account Options screen which should be completed as follows. A completed screen is shown in Figure 37. a. Active Directory container. Choose an OU to store new user accounts. In this example were going to store ours in the Migrated Domino Users OU. b. New account initial password. Since were creating new Active Directory accounts, we can choose to set the initial password at this point. Also note the option that forces the users to change their passwords at their first logon.

Figure 37: New Account Options Screen

6. Next up is the Mailbox Options screen, which allows you to create an Exchange mailbox for the Domino user account being migrated to Active Directory. You dont need to create a mailbox at this time since that can also be done when you move the mailbox contents from Domino to Exchange later on. Lets choose to create a mailbox now though, since we know were going to migrate the mailboxes from Domino to Exchange anyway. The completed screen is shown in Figure 38.

Figure 38: Mailbox Options Screen 7. The penultimate screen is the Progress screen, which simply requires you to click the Migrate button to complete the overall process. If all goes well, you should end up at the Completion screen with a successful migration as shown in Figure 39.

Figure 39: Completion Screen 8. Back at the main transporter suite screen, notice how the Active Directory Account field is now populated for the migrated Domino user as shown in Figure 40. Also, we can confirm the successful migration of the users by first checking the Migrated Domino Users OU for the presence of the Active Directory accounts as shown in Figure 41, and second by checking that the mailboxes were in fact created as shown in Figure 42. You can also confirm that the mail-enabled contact for Domino User1 is no longer present in the Domino Users OU.

Figure 40: Domino User Migrated to Active Directory

Figure 41: Migrated Domino Users OU After Migration to Active Directory

Figure 42: Migrated Domino Users Mailboxes After Migration to Active Directory Migration With Manual Active Directory Lookup Earlier in this article I stated that Id cover the main difference between the Migrate selected user and theMigrate with manual Active Directory lookup menu options. If you would like to associate the Domino users with existing Active Directory accounts youd choose the second option for manual Active Directory lookups. If you do this, the second screen in the wizard is then the Manual Active Directory Lookup screen as shown below in Figure 43. To choose an existing account you simply click the Browse button and select the relevant account.

Figure 43: Migrating Domino Users With Manual Active Directory Lookup Command Shell Migration As you can guess, you can also move users to Active Directory via the MoveDominoUser cmdlet. Do not confuse this with the Move-DominoMailbox cmdlet that well mention in the next and final part of this article. Lets move Domino User3 via the Transporter Command Shell. However, before we do, you should note that to supply the initial password requires a secure string in other words you cant simply type the text. Lets use a variable called $password as follows: $password = Read-Host Enter Initial Password -AsSecureString Note that the password is shown as each character being an asterisk, just as youd expect. This is shown in Figure 44.

Figure 44: Setting Secure String Password Now we can pass this password into the Move-DominoUser cmdlet as follows. The result is shown in Figure 45. Move-DominoUser SourceIdentity Domino User3/Fabrikam -TargetOU Migrated Domino Users -DominoDirectoryServer dom-domino.contoso.com InitialPassword $password

Figure 45: Migrating Domino Users via the Transporter Command Shell One thing to note with the previous cmdlet is that Ive elected not to create an Exchange 2007 mailbox on this occasion. If I wanted to do this, Id add the TargetMailboxDatabase parameter to the cmdlet.

PART VI The conclusion of this article with the migration of Domino mailbox contents into Exchange 2007 mailboxes.

This is the sixth and final part of this article that has seen us cover the new Transporter Suite for Lotus Domino. Weve covered the installation of the transporter suite, the configuration of directory synchronization and calendar free/busy sharing between Contosos Exchange system and Fabrikams Domino system, and also the migration of users from the Domino directory to Active Directory. In this final part well 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 lets start with the enabling of Exchange impersonation. Exchange Impersonation Before you migrate the Fabrikam users mailbox contents to the Contoso 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 dont do this, youll 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 Contosos 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 msExch-EPI-Impersonation Thats 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 thats what well use here. The change is achieved by the following series of steps: 1. Run IIS Manager. 2. Expand the Client Access Server name, which is W2K3BASE in this example. Under that, expand Web Sitesfollowed by the Default Web Site object to reveal the virtual directories underneath. One of these will be theEWS virtual directory.

3. 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 4. 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. 5. 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. 6. 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 Im using below the value is set to 20480, which is in KB. Thus, Im allowing attachments up to 20MB. <httpRuntime maxRequestLength=20480 />

7. Your web.config file should now look like the one shown in Figure 50 below. Assuming youre 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 Contoso 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: 1. Run the Transporter Management Console and navigate to the Mailboxes object in the console tree.

2. 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 Migrationwizard, which has an opening Introduction screen. 3. 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 resultingSelect 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 4. 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 youve 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 Administratoraccount to Exchange 2007, wed use a cmdlet such as: Move-DominoMailbox SourceIdentity Domino Administrator/Fabrikam TargetMailboxDatabase W2K3BASE/First Storage Group/Mailbox Database Ive 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 9s Inbox after migration. The calendar and tasks items also migrated too.

Figure 53: Migrated Domino Mailbox

Anda mungkin juga menyukai