I have seen a lot of posts out there in which people have quite a bit of issues with Free/Busy coexistence between Domino and Exchange 2007. Neil Hobson has an excellent walk through on the MSExchange.org site which you can find here. I wanted to go deeper into Free/Busy configuration, hence this article.
First of all, in order to get Free/Busy working, you need to go through the pre-requisites noted in the Transporter Suite documentation which you can find here. This includes getting the Directory Connector configured, installing the Free/Busy Connector on our Transporter Suite Server as well as installing ExchangeCalCon on our Domino Server. Make sure Domino is configured as a service to ensure there are no problems with Free/Busy Coexistence.
In our migration, we chose to use the Disparate Namespace Model. So let’s say our domain is shudnow.net, we are using Exchange.shudnow.net for our Exchange side and Domino.shudnow.net for our Domino side. I will not go into how to configure SMTP to allow for this as this article is focused on Free/Busy.
Some prerequisites before we proceed with configuration:
- Notes Client (preferably 7.0.2 or above and preferably installed in Single-User Mode)
- Notes Client configured with an ID File that has access to read the Address Book (names.nsf) and access to BUSYTIME for users
- Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 which you can download here
The first thing you need to do is ensure that connectivity between your Transporter Server and your Domino Server which is specified in the configuration of your Free Busy Connector have RPC connectivity between each other. The RPC Endpoint mapper uses port 135. Because of this, ensure that port 135 is open. RPC Endpoint mapper will tell the requesting server to use a specific port above port 135. Because of this, you will need to ensure just about all ports are open between your Transporter Server and your Domino Server.
Exchange Free/Busy Availability
There are a couple of things you will need to configure here. When an Outlook 2007 client selects a user from the GAL to add to a meeting, they are selecting a contact based on firstname.lastname@example.org. These contacts (or mail enabled objects if you are using Quest and used the Contact Merge) have an external e-mail address (TargetAddress) of domino.shudnow.net. Because of this, you must configure the Availability Service so all requests to domino.shudnow.net use public folders.
Because of the use of public folders, you should have an Exchange 2007 Mailbox Server hosting public folders. In Exchange 2007, if you have more than one public folder database, you should not be hosting public folders on a CCR Cluster. We ran into issues with this because there are multiple public folder databases in the environment and Public Folders were hosted in the environment (I didn’t do this, it was done before I got there but we ran with it to see what would happen.) Needless to say, we ended up having to remove Public Folders from the CCR Cluster. We also had Public Folders on our Transporter Server which contained the Mailbox Role, Client Access Role, and Hub Transport Role.
So for our Availability Service, we will need to run the following command to force all lookups to domino.shudnow.net to use Public Folders:
Add-AvailabilityAddressSpace –ForestName domino.shudnow.net AccessMethod PublicFolder
In order for the Availability Service to work properly, you need to ensure your Autodiscover Service and WebServicesVirtualDirectory are configured properly. I have written a lengthy article which will guide you through this. You can find this article here.
The Availability Service will make HTTP (not HTTPS) requests against Public Folder data. Because of this, we need to ensure that the /public directory on our CAS does not require SSL. Go into IIS Manager (Start > Control Panel > IIS Manager > Expand Default Website > Right-Click Public > Directory Security Tab > Uncheck require secure channel (SSL))
You will then need to configure your Free/Busy Connector. Follow Neil’s article and/or the Transporter Suite documentation for this. One thing to note is that the Free/Busy Connector does not actually pull the data from the Domino Server and dump it into Public Folders. The Free/Busy Connector only searches for Domino created objects within AD and associates Public Folder messages to represent these objects. The Directory Connector is the connector that will actually pull the Free/Busy data for these users. I will explain how this works in a bit.
Follow the Transporter Suite documentation to configure the Domino Side. I did not follow the names the documentation had you specify though. For our Foreign Domain Document, I used ExchangeFreeBusy.
Now this Foreign Domain Document Domain Name is very important as this is how the Directory Connector knows where to pull Free/Busy Information. When you configure your Directory Connector on your Transporter Server, there is an attribute called ForeignDomain. Because we used the Domain of ExchangeFreeBusy, you will want to run the command using the Transporter Suite Shell:
Set-DominoDirectoryConnector -ForeignDomain ExchangeFreeBusy
Now, when the Directory Sync occurs, the Directory Connector will not only sync over Domino Users as Mail-Enabled Contacts in Exchange, but it will also gather Free/Busy information for the users in which the Free Busy Connector stamped as Domino objects as explained earlier.
On the Mail Information Tab, we will will want to specify the server that hosts ExchangecalCon. You will also want to specify the Gateway mail file name. This doesn’t necessarily have to be mail1.box. It can be mail.box. The Domino Administrator will know what the mail file name is.
On the Calendar Information tab, we will want to specify the server that hosts ExchangeCalCon. ExchangeCalCon is one of the components from the Transporter Suite that is installed on a Domino Server which the Free Busy Connector on our Transporter Server will be talking to. The Calendar system name can be anything you want. I decided to name it ExchFreeBusy.
The notes.ini on this Calendar Server in which you specify in the Calendar server name must have its Notes.ini modified so that you can tell it to launch the ExchangeCalCon. You will see a variable in the notes.ini called ServerTasks. The important part in here is to add the following:
Excalcon ExchangeServerThatHostsFreeBusyConnector CalendarSystem
So let’s say our Transporter Server’s name is Shud-EXC01 and we set the Calendar System above to ExchFreeBusy, we would set this part in the Notes.ini to be:
Excalcon Shud-EXC01 ExchFreeBusy
Sometimes, instead of specifying the Calendar System in the Notes.ini, you will want to specify the Mail File Name we specified earlier instead of the Calendar System name. In our example, we used Mail1.Box. This is largely dependent on your version of Notes. Typically, use the Calendar System name and if that doesn’t work, then try the Mail File name. The following information is taken from the Transporter Suite documentation.
Some versions of the Lotus Notes client will always send Notes RTF meeting requests to the first participant of a meeting. Notes routing then attempts to deliver this RTF message to a database with the same name as the Calendar System on the Calendar Server.
Setting this to “mail.box” causes the message to be delivered to the default Mail Router mailbox, the message is converted and delivered correctly.
There are some additional configuration steps needed to ensure our Free/Busy works.
If the Notes client was not installed in Single User Mode, run the following command:
Set-DominoFreeBusyConnector –Identity ‘Identity of connector’ -NotesINIFile “path_to_Notes.ini”
You will want to ensure that CalCon is started for every server in which users do Free/Busy lookups on the Domino side. The reason why is that when a request from a Notes client does a lookup for an Exchange user, the CalCon task on its home server will use the Notes API and contact the ExchangeCalCon which then knows how to route the request over to Exchange. The end result is that the Notes client will see an Exchange user’s Free/Busy data.
In our migration, we are utilizing Quest Notes Migrator to Exchange. Because of this, we only have one way Directory Sync running. In order for the process to work, we need to modify the personal document of Domino users to contain the text ExchangeFreeBusy when that user is migrated. This is how the CalCon process finds the ExchangeCalCon process in order to route to Exchange. Because of this, when you migrate a user via Quest Notes Migrator for Exchange, one of the options you must enter is the Calendar Domain that we specified above.
As stated earlier, the Directory Connector uses the Foreign Domain to find the Free Busy Domain Document’s domain name to pull free busy data. Similarly, the CalCon process will find the ExCalCon Process by using the Calendar Domain specified in their personal document. This is why the Quest sets the Calendar Domain in a user’s personal document when that specific user is migrated.
Internet Explorer Trusted Sites
We ran into several availability service errors (4003 and 4004). Taking a look at the 4004 error, we can see that the Availability Service cannot find a public folder server for our Exchange 2007 Administrative Group. This is not right as we clearly have a public folder server for our Exchange 2007 Administrative Group. In fact, we have two. This had us scratching our head and required a call to Microsoft PSS. What they had us do is add all FQDNs for our Availability Service to each CAS Server’s Trusted Sites list in Internet Explorer. Sounds crazy, but it worked and I didn’t see it documented anywhere.
To find out what FQDNs we need to add, run the following command:
Get-WebServicesVirtualDirectory | FL Name,Server,InternalURL,ExternalURL
So taking a look at our InternalURL, we have an FQDN of webmail.shudnow.net. Because of this, we will want to add webmail.shudnow.net to all CAS Server’s Trusted Sites list in Internet Explorer. In the case of our production environment, we had several CAS Servers that had the same ExternalURL but every InternalURL was different as it pointed to the FQDN of the Server in which each certificate did have an entry for both webmail.shudnow.net and the FQDN of the server.
So let’s say we had 2 CAS Servers:
- InternalURL – https://SHUD-EXC1.shudnow.net/EWS/Exchange.asmx
- ExternalURL – https://webmail.shudnow.net/EWS/Exchange.asmx
- InternalURL – https://SHUD-EXC2.shudnow.net/EWS/Exchange.asmx
- ExternalURL – https://webmail.shudnow.net/EWS/Exchange.asmx
On the Trusted Sites List for SHUD-EXC1, we will add the following FQDNs to the Trusted Sites list:
On the Trusted Sites List for SHUD-EXC2, we will add the following FQDNs to the Trusted Sites list:
As you can see, the FQDNs are the same. So it’s important that you add all FQDNs for all servers to each server’s Trusted Sites list. You can find guidance on how to add FQDNs to the Trusted Sites list here.
100+ Public Folder Databases/Administrative Groups
If you have more than one hundred administrative groups and 100 public folder databases in Exchange, you will need to modify your Client Access Servers so the Availability Service can properly search through all 100 public folder databases. It consists of modifying the Web.config file located on your Client Access Server and adding the following element:
<add key=”MaximumDatabasesInQuery” value=”250″ />
More instructions for this can be found here.