Migrate Domino Mail-In Databases (Group Mailboxes) to Outlook 2010

Posted on by
1

When working on a recent email migration project from Domino r8.5 to Exchange 2010 (using Quest Notes Migrator and Quest CMN) I encountered a familiar challenge.   This was how to approach the migration of the customers 500 Domino Mail-In Databases across to Exchange 2010 ?  I had anticipated this being one of the more challenging parts of the email migration project, so I had persuaded everybody that this activity was best left to last – after all the Domino user mailboxes had been migrated to Exchange 2010.   The legacy Lotus Notes client had been left behind so users were instructed to access Lotus Notes to work with any Mail-in Databases they required in the interim.

At the start of the email migration project, when all users were on Lotus Notes, the Mail-In Databases migration caused anxiety for the customer.   This anxiety reduced markedly once all users were successfully migrated to Exchange 2010, with Outlook 2010 on the desktop, due to increased confidence.   This was a big help when we came to migrate the Mail-In Databases.  It is always best to get the confidence of the business for email migration projects, and keep hold of that confidence throughout.

I found it easier to refer to the Mail-In Databases as Group Mailboxes, as that is the terminology I used to describe the same entity if it was on Exchange 2010.   Converting the customer to speak Microsoft is always a good idea !

Some users managed up to five Mail-In Databases from their Lotus Notes Workspace, and were used to switching rapidly between the different inboxes, and managing different settings for each – for example, different signatures, and Rules.  Users were even fussy over which Sent Items folder would get emails they sent from a Group Mailbox – all these concerns needed to be allayed.

On previous email migration projects, trying to match the equivalent functionality using Outlook 2007 was always a challenge, and a recent customer decided to Domino web-enable all their Mail-In Databases, rather than try and get users working with them from Outlook 2007.   The main reason for this was the single “primary” Outlook 2007 mailbox was generally the user’s mailbox, with secondary mailboxes added in as Additional Mailboxes for any Group Mailboxes.   This worked up to a point, but did not allow for a user to set up Rules for the secondary Group Mailboxes or custom signatures, as these options were only available for the “primary” mailbox.  You could set up multiple MAPI Profiles for all required Group Mailboxes, but this becomes unusable very quickly.

However, Microsoft have made some giant leaps forward (in my opinion) with Outlook 2010.  With Outlook 2010 you have the ability to add in an Additional Account to your Outlook Setup, via the File tab (top left) and the Add Account option.

Outlook 2010 "Add Account" Option

Assuming your mailbox has been granted Full Access and Send As rights (best scenario for a Group Mailbox in my experience), you can add in the Group Mailbox via this option.

Selecting a Group Mailbox to add to Outlook 2010 via "Add Account"

To add the required Group Mailbox you only need to know its full SMTP email address, and enter that value into Email Address field.  Enter some text for the Group Mailbox name – this does not need to match the Display Name value.  You do not need to input any Passwords, as if you have Full Access (with Send As), this is not required.  Select Next, and on the next screen your settings are validated.  If all three validation checks receive the green tick, you can select Finish.

You can now switch between Accounts and setup, for either mailbox,  Rules & Signatures, and a myriad of other settings under the File tab.

For the email migration project, due diligence is still required to ensure all discovery information is a captured for any Mail-In Database, such as Access Control Lists and Rules.   An AD security group can be used to apply the same permissions post-migration, and the key business users can re-create any Rules they may have had after the migration.

The Add Account feature must not be confused with the facility to add in Additional Mailboxes (via the MAPI Profile properties).

My rule is that:

  • If the relationship is between two user mailboxes (CEO and Assistant, for example) then use the MAPI Profile Additional Mailbox feature (coupled with Delegate Access and Send on Behalf).
  • If the relationship is between a user mailbox and a Group Mailbox, then use the Add Account feature instead (coupled with Full Access and Send As rights).

Suddenly the convenience factor is available for users who manage multiple Group Mailboxes, with Outlook 2010 presenting a viable migration approach for all those Domino Mail-In Databases that often get left to last in an email migration project, and commonly never actually make it off Domino at all !

Domino Migration to Exchange – User Behaviour with Calendaring

Reply

On a recent email migration project from Domino r8 to Exchange 2007, I noted a pattern of behaviour amongst the user population with regard to support calls related to booking appointments in Outlook 2007.

In Domino, when users made a calendar booking involving a Resource, they would use the Rooms&Resource Domino Database to make the booking in the actual Resource calendar, and then all other attendees would be invited at this point also.   The person making the booking did not necessarily have to be part of the booking.

However, in Exchange 2007 (and Outlook 2007) the mechanism of making Resource bookings is very different.   The Organiser of the booking typically makes the appointment in their own Calendar, and invites all other attendees, including any required Resources.   The Resource would then auto-accept the booking request.

The support calls that I experienced demonstrated that users were opening up the Calendar belonging to the Resource, and then trying to create a new appointment.  At which point they received an error, saying they did not have permissions to do this.   The situation was presented mainly because the Quest Notes to Exchange Migrator tool migrated the Resources across to Exchange – but included default Reveiwer access for all users.   This is typically not the case when creating a new Exchange Resource – whereby default access allows Free/Busy lookups and the ability for users to make (and modify) their own appointments.

At migration time, it is advisable to highlight the differences in the way Resource bookings are made, and to check what default permissions are applied to any Resources that are migrated to Exchange using a migration tool – such as Quest.

Any default permissions that have been decided upon for Resources at migration time, need to be maintained when new Resources are created in Exchange.

Domino Rooms & Resources Migration to Exchange 2007/2010 using Quest – random thoughts

Reply

Within Domino, the Rooms and Resources Database provides a rich user experience when it comes to making Calendar bookings from the end-user perspective using the Lotus Notes client.   During a typical email migration from Domino to Exchange2007/2010 there is often negative feedback when people use Outlook Calendaring due to the slightly lesser “experience” offered within Exchange 2007/2010.

The differences in Calendaring between the two email platforms is often under estimated, and Rooms & Resources are usual migrated to Exchange at the end of co-existence.  The project is typically keen to wrap things up at this stage, rather than focusing on the details of this phase.    The Personal Assistants to the VIPs in the company are the ones who often use Calendaring  the most – be warned !

As an example, there is a feature in Domino that allows users to set a pre-defined favourite location which presents only Rooms and Resources that belong to the same location.   There is no such equivalent feature in Outlook/Exchange.   Also you can organise a meeting for a group of users (and a room) without having it in your own Calendar.

One way of configuring Exchange 2007/2010 to make the transition easier, is to pre-define a set of custom Address Book Views, each of which contains a custom list of Resources.   Exchange 2007/2010 allows these Address Book Views to be nested (2 levels only) as well.  These Address Book Views allow the Outlook user to use these custom Address Lists instead of the Global Address List to find certain mail objects quicker.

An example would be to use EMC to create a new top level Address List container under Organization->Mailbox->Address Lists>New Address List.     Then set a name such as “Rooms and Resources“, with “None” as the Recipient Type.   Then complete the Wizard with Next, Next , Finish.   This will create a new top-level container, under which you can now create some custom Address Lists.

Outlook users can then use the Address Book View to see a subset of Resources when creating a new Appointment.  For example, all the Resources in a particular physical location.

You can now create any number of new Address Lists via the EMC, and select the Container “Rooms and Resources” to list them under.   EMC offers some basic filters you can apply, such as all Resource mailboxes.

Exchange 2007/2010 uses slightly different terminology for these objects.  The term Resource covers both sub-types: Equipment and Rooms.   Whereas in Domino, there is no overall term – only “Rooms and Resources“, which are all stored in a Domino database.   The use of the word “Resources” can cause confusion when being discussed in the context of Domino and Exchange 2007/2010.

EMS can be used to create Address Book Views with more advanced filters.   One example is to create an Address Book View that contains all Rooms and Resources from a particular physical location.     This can be done by ensuring all Active Directory User Accounts to be used for Resources have the PhysicalDeliveryOffice AD attribute populated with a standardised entry representing the location they are in (example = Dallas).

1. Ensure that all AD User Objects for Resources in the “Dallas” location have the PhysicalDeliveryOffice attribute (Office) set to = “Dallas”

2. Create a top level Address Book View Container called “Rooms and Resources” – as per the above instructions.

3. Use EMS to run the the following command:

New-AddressList -Name “Dallas” -recipientfilter {((Office -eq ‘Dallas’) -and (RecipientType -eq ‘UserMailbox’ -and ResourceMetaData -like ‘ResourceType:*’ -and ResourceSearchProperties -ne $null))} -Container ‘Rooms & Resources’

4. Use EMS to run the following command to apply the new Address List

update-addresslist “Dallas”

5.  Restart Outlook, and check the Address List dialog box to see if the new Address List View is present

It is also possible to define Address Book Views with the DirSync Objects representing the Domino Rooms & Resources.   This is a good way of migrating Rooms & Resources from Domino to Exchange, as allows you to do their migration last, after all users are on OutlookExchange.   This would be during co-existence.  One way of doing this is to use EMC to create new Address Lists filtered on “Users with External Addresses” and “Custom Attribute#1=Dallas“.   This also has the added advantage of representing the Resources in Outlook with the correct icon (OHP and Door).     Then the Address List View can be re-created after the Rooms & Resources have been migrated fully to Exchange 2007/2010.

EmailMigrations.com Tip – you get the benefit of the correct Outlook icon (OHP and Door) for Domino Rooms&Resources if you leave them as DirSync Contacts (assuming you are using the Microsoft Transporter Suite).   If you then use Quest NME to perform a merge operation into their AD user accounts (creating mail-enabled objects) then the Outlook icons previously displayed drop off, and they revert back to the “Custom Address” type icon.   This will cause users to complain.   Therefore, the AD Merge step must be done immediately prior to the actual migration of Rooms and Resources across to Exchange 2007/2010.

EmailMigrations.com Tip – if you use Microsoft Transporter and Quest Note Migrator to Exchange products, then you can use Quest NME to merge the Windows DirSync Mail Contacts into the new AD User Accounts, and then Quest NME to convert the Mail-Enabled AD User Accounts to Exchange Resource mailboxes.    Quest is aware that these objects in Domino are Rooms&Resources, and creates them as Exchange Resource mailboxes.   In addition, Exchange examines the name of the object and decides whether the resultant Exchange Resource is Room or Equipment.    Don’t forget to enable the Auto Accept agent for the Exchange Resources as this is not done by default – this can be done in OWA for each Resource , or via the following example EMS command:

Set-MailboxCalendarsettings -Identity MeetingRoom1 -automateprocessing:AutoAccept

EmailMigrations.com Tip – After migrating any Room&Resource from Domino to Exchange, make sure that user access to the legacy Domino instance is disabled.

Using Quest Notes Migrator to remove Domino Forwarder

Reply

On a recent email migration project, from Domino r8 to Exchange 2007, there was a requirement to roll-back a group of migrated users to Domino.    We were using Quest Notes Migrator to Exchange (QNME) 4.3 for the migration so were able to create a collection containing the details of the users to be rolled back, and used the option to set mail delivery for these users to Domino which:

  • Removed the Notes forwarder to Exchange
  • Changed the Mail Type back to Domino
  • Re-enabled the Foreign DirSync option

We then deleted the Exchange 2007 mailboxes, and re-ran the Transporter Directory Synchronisation process.

This all went through as expected, and the Domino Person Records were set back to their original state.  Or so we thought, as users started complaining that they were not receiving emails.   We double-checked the Domino Person Records in Domino Admin and were able to re-confirm that they were set correctly.   The Domino Address Book was refreshed, and re-indexed, but this did not resolve the issue.   Then, for some reason, we tried a “Save and Close” on one of the Person Records in Domino, and this fixed the issue !

It appeared as though QNME had made the correct changes, but they had not been committed within Domino.     Hopefully this is not a common scenario for your email migration project, but if it is then this may help.

When discussing this incident with Domino Administrators it appears that there are other instances, within Domino, whereby opening the Person Record and then doing a “Save and Close” resolves the issue.

OST Seeding and Network Saturation

Reply

A common challenge when migrating mailboxes to any Microsoft Exchange platform, where the end user devices use Outlook 2007/2010 with caching, is the initial generation of OST files.

Outlook with cached mode is the most efficient method in terms of network footprint – estimated to be approx 2.5k per user. However, you have to complete the caching of the local mail file copy first (the OST file).

This post examines one particular mitigation against the burst of network traffic resultant from the initial OST file generation.

Network saturation can occur if any one of the following scenarios are realised:
* Mailbox sizes are large
* The Exchange Mailbox server resides across the WAN
* WAN link is not very fast, and is overloaded

This may result in loss of network service to the users for an unknown period of time, whilst the initial OST files are generated.

Microsoft have written many detailed tech notes on this subject, with a popular mitigation for large mailboxes being to pre-seed the OST file back at the Data Centre. To do this, you disable cached mode on the end user device (via GPO maybe), then when the mailbox is on the new Exchange system a device in the Data Centre location is used to start Outlook as the user in cached mode. Once the OST file is generated, it is shipped down to the remote site where the end-user’s device is.

Next, copy the OST file into the correct path in the user’s Window Profile (check the Microsoft information for this). Then modify the user’s Outlook MAPI profile Advanced settings to set the OST file location. For this step it may appear as though the OST file is already selected, but actually it isn’t. You must browse to the OST file (that was copied earlier), and re-select it with the OK button. Save the changes to the Outlook MAPI Profile. Then go back into the Outlook MAPI Profile, and enable cached mode.

Next, start Outlook, and monitor the folder in the Windows Profile, which contains the OST file, to ensure that it is this file that is being updated, and that no new OST file has been generated.

The Microsoft steps for this task are very detailed, but do not focus on the need to re-select the OST file in the Outlook MAPI Profile, once it has been deployed on the end-user device.

Enable-ContinuousReplicationHostName – Exchange 2007

Reply

Getting Exchange 2007 CCR cluster nodes to use a private network for CCR log shipping – easy or hard ?  Bit of both really.

This article is really a companion guide to the information already out there on this topic.  I got stuck implementing it, figured out why, and decided to share this with you.

I have been working on a new Exchange 2007 CCR implementation where we decided to deploy a pair of cross-over cables between the two CCR cluster nodes.   The design aim for this was to allow Windows 2008 Clustering to utilise them for the cluster heartbeat traffic, and to allow Exchange 2007 to use them for CCR log shipping.  Looked good on the Visio diagram !

Windows 2008 clustering was simple to setup to utilise the cross-over cables for the heartbeat traffic.  This area is covered in great detail on a number of websites, and I do not repeat the steps here.

The focus of this blog is to add some key information that I could not find on the web to get this going.   Firstly, the technical work required is covered in this excellent article:

http://www.simple-talk.com/sysadmin/exchange/cluster-continuous-replication-network-design/

My Exchange 2007 CCR cluster nodes had the following NICs configured:

CCR Node1:

Windows 2008 Server Name:  CCRSERVER1

Prod Team (nic1 and nic2 teamed with fault tolerance):   192.168.1.100

Private1 (cross over):  10.1.1.10

Private2 (cross over)  10.1.1.11

CCR Node2:

Windows 2008 Server Name:  CCRSERVER2

Prod Team (nic1 and nic2 teamed with fault tolerance): 192.168.1.101

Private1 (cross over): 10.1.1.20

Private2 (cross over): 10.1.1.21

Exchange Virtual Server Name: EVS1

The Windows 2008 Cluster was setup with the File Share Witness with no issues, and all was well in FailOver Cluster Management.   Exchange 2007 was installed on top (with the usual niggles), but successfully in the end.

Using the Get-ClusteredMailboxServerStatus EMS command showed that the Production network was being used for CCR log shipping, which is not very efficient considered I had 2 pairs of cross-over cables not doing very much.

I then started to follow the excellent article (listed above) to resolve this.

The following sections contain the keys to the puzzle for me:

The Replication Host names that you use must be no longer than 15 characters as are used at a NETBIOS layer.

You can pre-create the Replication Host names within AD as Computer Objects, and grant Full Access rights to the objects to: the Windows 2008 CCR name, and each of the physical CCR node names.  Doing this in advance will help.

The IP addresses that you decide to use for the Replication Host names must not be in use anywhere on your system.  Not as alternate IPs on the NICs, nowhere.  They must be new IP addresses, but in the same subnet range as the Private NIC IPs used for the Heartbeat traffic.

So, you could use the following as the Replication Host IPs and Host names:

10.1.1.12  CCRSERVER1LGSP1

10.1.1.13  CCRSERVER1LGSP2

10.1.1.22  CCRSERVER2LGSP1

10.1.1.23  CCRSERVER2LGSP1

You must then add the above entries into a HOSTS file on each CCR node, as DNS will be no use as you should have set the Private NICs to not use DNS – so back to good old HOSTS files !!  At this point you will not be able to ping the new host names as they do not exist on the network at this point.

You are now ready to run the EMS commands on each CCR node, to setup the Log Ship Replication traffic over the cross-over cables.

You can run the commands from one node, but I prefer to run two commands on one, and two on the other.

Run these commands on CCRSERVER1 (you will be prompted to press “Y” to confirm):

Enable-ContinuousReplicationHostName -identity EVS1 -TargetMachine CCRSERVER1 -HostName CCRSERVER1LGSP1 -IPV4Address 10.1.1.12

Enable-ContinuousReplicationHostName -identity EVS1 -TargetMachine CCRSERVER1 -HostName CCRSERVER1LGSP2 -IPV4Address 10.1.1.13

Run these commands on CCRSERVER2 (you will be prompted to press “Y” to confirm):

Enable-ContinuousReplicationHostName -identity EVS1 -TargetMachine CCRSERVER2 -HostName CCRSERVER2LGSP1 -IPV4Address 10.1.1.22

Enable-ContinuousReplicationHostName -identity EVS1 -TargetMachine CCRSERVER2 -HostName CCRSERVER2LGSP2 -IPV4Address 10.1.1.23

Each of these will take a few seconds to complete.

When done, you will be able to ping the new host names from a CMD window on both CCR nodes.  Also run the EMS command Get-ClusteredMailboxServerStatus again, and you should see your new Replication networks in place, and in use.

Go to the Failover Cluster Manager and you will see your new networks in place underneath the Exchange Virtual Server name (eg: EVS1).

The Application Event Logs on both nodes will show some replication errors around the time that the commands were run.  This is expected and sorts itself out after a few minutes.

If you make a mistake and are prevented from re-running the above EMS commands, then you need to go into Failover Cluster Manager and delete the new Group object that matches the Replication Host Name you were trying to create.  Do this carefully as it sits alongside the Exchange Virtual Server object.

Once I realised that I needed completely new IPs to assign to the replication host names then the mist began to clear ….  Hope this helps at least one other person out there !

Any questions/feedback please let me know.

Problems Moving or Removing MS Transporter Suite

Reply

When using MS Transporter Suite for Directory Sync and Free Busy there can be instances when you need to use the product on a different Exchange 2007 Hub Transport Server, which might be in a different AD Site.   This could be because you are having technical issues with that server.   You may have already configured a new Directory Connector and a new Free Busy Connector (on HUB_Server_A).   If you install the MS Transporter Suite on the new Hub Transport Server (HUB_Server_B), you will see the two Connectors that you have already installed.

However, if HUB_Server_A requires removong or re-installing, then these Connectors will drop off the MS Transporter Console on HUB_Server_B.   This is because, although the configuration appears as if it is shared, each Connector is “owned” by the Hub Transport Server that it is first configured.

If you break out to the Transporter Shell and run the command:

get-dominodirectoryconnector

You will see that one field shows which server is the owner.

The equivalent command for the Free Busy Connector is:

get-dominofreebusyconnector

One approach, and probably the most reliable, is to take screen shots of your configurations, and remove the Transporter Connectors from the Transporter Console off HUB_Server_A.   Then run the get-dominodirectoryconnector  and get-dominofreebusyconnector  commands from the Transporter Shell to ensure they have been cleaned up.    Then wait for AD replication to take place.  Next check in the Transporter Console on HUB_Server_B and the two Connectors should have been removed.  Also check using the Transporter Shell using the same commands as listed above to ensure that they have gone.

I have seen scenarios where the Connectors are not showing in the Transporter Console, but are showing from the Transporter Shell.   This will prevent any new Connectors from being added to the Transporter Console, as you will get an error saying an instance of the Connector already exists.  No matter how many times you remove and re-install the MS Transporter application, the situation will remain.

You will need to try the following Transporter Shell command from the Exchange 2007 Hub Transport Server:  (make sure you are Enterprise Admin to do this)

remove-dominodirectoryconnector -identity “<enter name of connector here>”

Get the name of the Connector(s) from the information presented by the following Transporter Shell commands:

get-dominodirectoryconnector

If you get really stuck then you can use the following Transporter Shell commands to set any missing attributes, such as the “Name” field.  I have seen instances where this value has become dropped, and this is preventing the Connectors removal.

set-dominodirectoryconnector -Name “<enter the name here>”

Microsoft provide a full reference to the command parameters for the above.

The last resort, if the above steps do not help, is to remove any required instances of the Directory Connector and/or the Free Busy Connector, by using ADSIEDIT from a Windows 2003 domain member server.  You need to be logged in with sufficient rights, and always test in a lab environment first.  Navigate to the Configuration container, then locate the Exchange Administrative Group, then locate the Routing Group container.  This will contain the connector instances related to the Transporter Connectors described here.  Be very careful when deleting the required connector from here – as there is no restore path.  Wait for AD replication.   Then you should be able to create the connector from new again.   This has saved me a few times when some of the connector attributes have been dropped or been corrupted.

This information should provide enough clues to tidy up any troublesome Transporter Suite issues.   The product works well for the DirSync and FreeBusy functions, but is certainly prone to error if you have to start removing it from a Hub Transport Server onto another, especially in a different AD Site.   Watch out for AD replication as well – always ensure it has taken place before making any further changes.

Free Busy Lookup Between Exchange 2007 SP2 and Domino R8 (8.0.2)

Posted on by
3

Introduction:

I have just completed the Free Busy (FreeBusy) connection between Microsoft Exchange 2007 SP2 and Domino r8.0.2.  This was in combination with a customised MS Transporter Suite setup involving sub-domain routing.   And a little help from a Domino r7.0.x server.

I failed to find exact instructions on how to successfully implement this on the web – however there is plenty of related information on this topic, but no overall one solution worked for me.  So here is my implementation for those of you struggling with this seemingly complex task.  I have tried to focus on the key areas only, but can add extra steps if you ask.

This will also work in a mixed Exchange 2007 / Exchange 2010 environment, so should be useful for those people who have been waiting for Exchange 2010 before moving off Domino.   Note that if you want to use this for a migration to Exchange 2010, then you must install an Exchange 2007 server as the first Exchange Server in the Exchange Organization.  You cannot add an Exchange 2007 server into an Exchange 2010-only Organization.

Ensure you have the MS Transporter documentation and there is also a good MSExchange.org article covering this.  Just ensure you use my steps and only refer to the other docs when asked or for reference/background.

Section A – Basics:

Install Lotus Notes 8.0.2 Client on the nominated Exchange 2007 Hub Transport Server, and configure it with an administrator-level ID file against Domino.

Install 64-bit Transporter Suite on the nominated Exchange 2007 Hub Transport Server.

Follow the sub-domain routing model in the Microsoft Transporter documentation.  Use Exchange as the Foreign Domain name, and use mail.box as the target for mail routing and calendaring requests.   Do not attempt the Transporter Free Busy setup steps at this point.

Modify the TBL files as per my blog post on that topic, giving you addresses of type:

<firstname>.<lastname>@exchange.contuso.com to represent the Exchange mailboxes in the Domino Address Book.

And

<firstname>.<lastname>@notes.contuso.com to represent the Domino mailboxes in the Exchange Global Address Book.

Test mail routing between the two.  Do not proceed until this is working.

Ensure you have a Public Folder in Exchange 2007 and test it works within Exchange for Free Busy by using Outlook 2003 between two Exchange mailboxes.  One Public Folder is enough at this stage.  Don’t complicate matters by having more.

Ensure the native Exchange 2007 Availability Services are working by checking Free Busy between mailboxes using Outlook Web Access.

Section B – Domino:

Evidence suggests that this solution will work on a Domino 8.0.2 server.  However, I found best results with a Domino 7.0.x server as the connection point for Free Busy.  Your Notes Admin person will need to help provision one, or they may be one you can use already.

Ensure the MS Transporter steps are followed in relation to sub-domain routing on Domino, especially the provisioning of @notes.contuso.com as a valid alias address for all Notes people.  There are other vital steps covering the Rich Text formatting as well.  Do all steps carefully.

You only need one Foreign Domain Document called “Exchange”.   Do not create any additional ones.

Install the 32-bit Transporter files onto the nominated Domino 7.0.x server, and modify the NOTES.INI file as per the Transporter documentation, but use the mail.box not the Foreign Domain name in the EXCALCON string.

Example:  EXCALCON <server FQDN> MAIL.BOX 1

Then re-start the Domino service, and check the Console.  Using the “1″ adds extra logging.   You will see an error concerning the Exchange Free Busy Connector.  Don’t worry, we will configure that next, and then re-start the Domino service again later.

Section C – Exchange Free Busy Connector:

On the Exchange 2007 Hub Transport Server, add the Free Busy Connector to the Transporter Connector, and add the NOTES.CONTUSO.COM and CONTUSO.COM namespaces.  Set the Cache and Timeout values on the General Tab to zero.  Set the Schedule to Every 30 minutes.   Stop the Directory Connector service, and start the Free Busy Connector service.   Then start the Directory Connector Service.  The order here is important.

Then re-start the Domino service on the Domino 7.0.x Server, and check the Domino Console.   There should be no errors in relation to the Exchange Free Busy service.

Section D – Test Free Busy

At this stage you can use any Outlook client (Outlook 2003, 2007, or OWA) to test a Free Busy look up against a Notes mail address entry in the Global Address List.   This should work, and is the easier direction to get this service working successfully.

If you test a Free Busy look-up from Domino to Exchange I expect it to fail at this point.  Many people reach this point, and no further.  This leads to the key to the solution.

Section E – The Key

I discovered that by further editing my custom TBL DirSync files to ensure that any Exchange mailbox had a Domino Person Record with a Forwarding Address of the format:

<firstname.lastname>@exchange.contuso.com@exchange

Was the key to success, and allowed successful Free Busy lookups to that Exchange mailbox.  Don’t forget to ensure there are some test appointments in the Exchange mailbox you are testing against.

Edit the ExchangeToDomino.TBL file line entry as follows (note: do not do a copy&paste of this as it will not work – see blog comment, you must type in it in manually!):

FwdAddr = STRIP(PriSMTP, “@”, “L”, “R”) “@exchange.contuso.com@exchange”

Then, re-run a full Dir Sync in the direction of Exchange to Domino, and check that the Person Records are updated with this new address format.

Re-start your Domino client and re-test a Free Busy look up.  And check the Domino Console for signs of a look-up.  This should now magically work.

A good tip for trying to get Free/Busy lookups working from Domino to Exchange is to manually enter the Exchange mailbox address into the Notes Client when creating a new appointment, as this gives you the chance to try different target address formats without having to waste time changing the Dir Sync operation.

For example, you could enter an attendee address of:

fred.bloggs@exchange.contuso.com@exchange

and

john.smith@exchange.contuso.com

And see which one works.

Once you have hit upon a successful target address then you can retrospectively configure Dir Sync to present the required forwarding addresses on the Notes Person Records.

Different versions of Domino seen to demand different settings to make Free Busy work, so it pays to be familiar with the information presented here, and to experiment to get a result.

Let me know if this worked for you, or any updates required to this article.

Transporter Directory Synchronisation and Sub-Domain Routing Between Exchange 2007 (2010) and Lotus Domino r8

7

This post covers some of the challenges faced when using the Microsoft Transporter Suite to perform Directory Synchronisation (Synchronization for US citizens!) between Exchange 2007 and Lotus Domino (Lotus Notes), and then introducing a sub-domain routing topology during the migration period.    Detailed technical documentation is hard to come by for this.

The version of Lotus Notes in my example is r8.   I mention Exchange 2010 in the post title, as Microsoft current advise deploying certain Exchange 2007 technologies (eg- Transporter Suite) to facilitate a migration from Lotus Notes to Exchange 2010.

By following the detailed Transporter documentation (free download alongside the Transporter binaries) a basic Directory Synchronisation can be achieved, with Lotus Notes addresses represented in Active Directory, and Exchange addresses represented in Domino.

Things get interesting when you try and implement a sub-domain routing topology to allow for a single domain name-space to be used for both Domino and Exchange.      For example, if  CONTUSO.COM was being migrated from Domino to Exchange 2007, then best-practice dictates you implement Transporter Suite DirSync,  an SMTP connector between the two environments,  and route all inbound internet email via Exchange.  Then start migrating mailboxes.  This, of course, is trivialising a complex operation.

However, a key aspect of this situation is the ability to use sub-domains for email routing.

For emails from Exchange to Domino, you could use the namespace:   @NOTES.CONTUSO.COM

For emails from Domino to Exchange, you could use the namespace:   @EXCHANGE.CONTUSO.COM

There are two aspects to this:

1)  Internet email needs to be go via Exchange to Domino.   It would be great if we could get all Domino addresses into AD with an accurate relay address to get the emails onto Domino.  In reality this is rarely the case, and to mitigate the issue, Exchange 2007 allows for an SMTP connector to forward all mail it cannot match to AD, onto a Smart Host (Domino).  So no real issue here.

2) During the migration there will be users on both Domino and Exchange.   The Exchange users need to be able to email Domino users from the Global Address Book (GAL).   Therefore the Windows Contact objects need to contain a valid Target Address (relay) field.

This is where the main reason for this post appears….

The default Target Address generated by Transporter to represent a Domino user would be as follows:

Fred_Bloggs/CONTUSO%CONTUSO@notes.contuso.com

The problem is that the FULL NAME field in the Notes Person Record for this user = “Fred Bloggs”, with no underscore character.   Mail to this address may not be delivered and generate a Non Delivery Report (NDR).   Transporter has inserted the underscore character to replace the space character, as that is not valid in an SMTP address.

If your Domino environment is small, maybe you manually (or via an Agent) add an additional address for each user with the underscore.  But if there is a large number of users this may not be possible.

All is not lost though.   In the Transporter application Windows folder structure, there are a set of configuration files that are used by Transporter.   This can be manipulated to help with this situation.

Typically the files are under   c:program filesmicrosoft transporter toolsconfigconnector*

The file you are after is dominotoexchangerules.tbl

Backup all files in this folder before you start making any changes, and do all your tests in a lab environment before committing to production.

The section in the dominotoexchangerules.tbl file you need is:

Alias = ISEQUAL( Alias, “”, ISEQUAL( InetAddr, “”, SecALIAS, Strip( InetAddr, “@”, “L”, “R” ) ), Alias )
DispName = ISEQUAL( Resource, “”, X500( FullName, “CN” ), Strip( FullName, “;”, “L”, “R” ) )
Name = Strip( FullName, “;”, “L”, “R” )
LastName = ISEQUAL( LastName, “”, ISEQUAL( FirstName, “”, X500( FullName, “CN”), “” ) , LastName)
NOTESADDR = NotesLocal “@” MailDomain
TA = ISEQUAL( FwdAddr, “”, ISEQUAL( CFGPARM(“DominoSmtpDomain”), Strip( InetAddr, “@”, “L” ), InetAddr, ISEQUAL(SmtpLocal, “”, SmtpLocEsc, SmtpLocal) “%” MailDomain “@” CFGPARM(“DominoSmtpDomain”)), FwdAddr )

For details on the syntax used do a search on Google for “Exchange 2003 Lotus Notes Connector TBL”.   The syntax used for Exchange 2007 is similar, but not the same.

The trick is to edit the file so it looks like this:

Alias = ISEQUAL( Alias, “”, ISEQUAL( InetAddr, “”, SecALIAS, Strip( InetAddr, “@”, “L”, “R” ) ), Alias )
DispName = ISEQUAL( Resource, “”, X500( FullName, “CN” ), Strip( FullName, “;”, “L”, “R” ) )
Name = Strip( FullName, “;”, “L”, “R” )
LastName = ISEQUAL( LastName, “”, ISEQUAL( FirstName, “”, X500( FullName, “CN”), “” ) , LastName)
NOTESADDR = NotesLocal “@” MailDomain
;TA = ISEQUAL( FwdAddr, “”, ISEQUAL( CFGPARM(“DominoSmtpDomain”), Strip( InetAddr, “@”, “L” ), InetAddr, ISEQUAL(SmtpLocal, “”, SmtpLocEsc, SmtpLocal) “%” MailDomain “@” CFGPARM(“DominoSmtpDomain”)), FwdAddr )
TA = STRIP(PriSMTP, “@”, “L”, “R”) “@notes.contuso.com”

This has placed a semi-colon at the front of the original line starting with TA = , and then added a new line for this parameter, which will generate a Target Address using the left-hand side of the internet address and the SMTP sub-domain name-space used to route mail to Domino.

There is an entry in the GUI config of the Transporter to specify the Domino SMTP domain also – good idea to put in the same sub-domain value here.    This is what was used to generate the default TA value, and is overridden by the change I suggest.    However, I advise setting it anyway as a reference.

Note:  if you wish, you can use an alternate naming format based on the alias value.  You just use this line instead:   TA = Alias “@notes.contuso.com”

The reason I do not generally recommend the use of the Alias@notes.contuso.com   name format is that in Domino your Resources and Mail-In Databases do not have an Alias value set, and have no Alias field that can be populated.   However, they do have an internet address field set.   Therefore, you can include them in Dir Sync by populating them all with a valid internet address.  This will allow them to appear in the Exchange GAL via Dir Sync.  If they have a blank internet address field in Domino, they will not appear in the Exchange GAL via DirSync.

Once you have made the change, you need to remove all the Lotus Notes Windows Contacts from AD, restart the Transporter Directory Sync Windows Service, and force a Full Sync from Domino to Exchange.

(Don’t forget, you can always go back to the original configuration if this produces results you do not expect.)

In Exchange 2007 Management Console (EMC), check the Target Address fields after the Sync has completed.  You should see the new format of   firstname.lastname@notes.contuso.com .    This is now a valid Target Address for Domino user mailboxes.   Domino is tolerant of receiving emails that are not an exact match – it will perform a series of look-ups to try and get a match.

The new Target Address for the example user will now be:

Fred.Bloggs@notes.contuso.com

Now you need to edit the exchangetodominorules.tbl file in a similar way.  For this file you need to comment out the line starting with “FwdAddr ……” and replace it with this line.

FwdAddr = STRIP(PriSMTP, “@”, “L”, “R”) “@exchange.contuso.com”

This will generate an address entry in the Domino Address Book for any new Exchange mailboxes, and will stamp a forwarding address of format:

John.Bloggs@exchange.contuso.com

You have a successful sub-domain routing mechanism for mail flow and DirSync setup between Domino and Exchange 2007.  You can start looking at Free/Busy, and at the actual migration.

As always, test this to your own satisfaction in a private lab scenario.