Elan Shudnow’s Blog

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.

General Information

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

Network Connectivity

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 user@shudnow.net.  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.

Domino Configuration

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.

Additional Configuration

There are some additional configuration steps needed to ensure our Free/Busy works.

NotesINIFile

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”

CalCon

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:

SHUD-EXC1

• InternalURL – https://SHUD-EXC1.shudnow.net/EWS/Exchange.asmx
• ExternalURL – https://webmail.shudnow.net/EWS/Exchange.asmx

SHUD-EXC2

• 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:

• https://SHUD-EXC1.shudnow.net
• https://SHUD-EXC2.shudnow.net
• https://webmail.shudnow.net

On the Trusted Sites List for SHUD-EXC2, we will add the following FQDNs to the Trusted Sites list:

• https://SHUD-EXC1.shudnow.net
• https://SHUD-EXC2.shudnow.net
• https://webmail.shudnow.net

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.

Elan Shudnow :: Feb.23.2009 :: Exchange :: 8908 Comments »http://www.shudnow.net/2009/02/23/exchange-2007-and-domino-freebusy-coexistence/Exchange+2007+and+Domino+Free%2FBusy+Coexistence2009-02-24+04%3A35%3A38Elan+Shudnow

I seem to encounter this issue quite often and felt this topic warrants a dedicated blog post.  The basic point of this post is to explain that you cannot have more than one default gateway on separate NICS on a multihomed server!  Well, technically you actually can, but things won’t work correctly. Now I am not saying that you cannot have multiple Default Gateways on a specific NIC as this is quite possible as Windows will assign metrics so one Default Gateway is given priority over another which provides redundancy.  What I am saying is that you cannot have a Default Gateway on one NIC and then assign a Default Gateway on another NIC.

Any time I have seen Multihomed Servers (OCS Edge, Exchange Edge, ISA, Etc.) malfunctioning, the first thing I’ll do is a  ROUTE PRINT. Quite often, I’ll see several lines that display:

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

That instantly tells me that multiple Default Gateways are assigned.  You should only be seeing one line with 0.0.0.0. The entire point of a Default Gateway is it’s the last resort on where to send a packet.  Now with that in mind, does it make any sense to have multiple last resorts?  No!

So please, put the Default Gateway on only one NIC.  For OCS, I typically put it on the Access Edge NIC.  For Exchange Edge/ISA, I put it on the Internet Facing NIC.  Ok, so you may be thinking, well my external router doesn’t allow RDP traffic…  How am I going to manage my box from the inside since the RDP packets will be blocked at the external firewall?  What I always do on an Edge Server (and you should also be doing this on any multi-homes DMZ/Edge Server including ISA), is create static routes so any internal traffic will go to your internal network from your internal NIC.  It’s essentially creating a fake Default Gateway for only specific subnets (your internal subnets) set on your Internal NIC.

So let’s say you’re setting up an OCS Edge Server and it has 4 NICs:

Access Edge – 10.10.10.100 (DMZ Subnet) – Default Gateway Assigned here

Web Conferencing Edge – 10.10.10.101/24 (DMZ Subnet)

Audio / Video Edge – 10.10.10.102/24 (DMZ Subnet)

Internal NIC – 192.168.200.100/24 (Internal Network)

So how can we get all internal traffic to go out directly through the Internal NIC even though the Default Gateway is assigned to the Access Edge?  As stated before, we’ll create a static route.  So let’s say your internal router is 192.168.200.1, we’ll create a static route using the following syntax

route add 192.168.200.0 mask 255.255.255.0 192.168.200.1 -p

So for anything destined to the 192.168.200.x network (due to mask being 255.255.255.0 it will route to the default gateway of 192.168.200.1.  And Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send it out of.  Problem solved!

Now what if you have a bunch of internal subnets that have similar address ranges?  Simple!  Supernet your internal networks!

route add 192.168.0.0 mask 255.255.0.0 192.168.200.1 -p

This supernet basically says anything that’s 192.168.x.x (only uses 1st 2 octets since you’re using a mask of 255.255.0.0 otherwise known as /16), send it to the 192.168.200.1 gateway.  And again, Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send out of.  So if you have a 192.168.200.x, a 192.168.199.x, or a 192.168.198.x network, all those packets will route to the 192.168.200.1 router which will then send the packet to the appropriate subnet. Problem solved!

And the -p stands for persistent.  It means that the static route will survive a reboot.

All the above applies to ISA as well.  Let’s say you’re doing LDAPS authentication which uses port 636.  Your external router may not allow 636.  So by creating the static route to your internal network, the LDAPS traffic won’t be going through your external router and be blocked. It instead will go through your internal router which would most likely be allowing it as Internal Routers are more relaxed in their restrictions.

One thing to take into consideration is that if you are in an environment where the Default Gateways are assigned to all NICs and you modify your server to be properly configured with a Default Gateway on one NIC, make sure that any services such as remote backup on your server are allowed to access over the internet over the ports required for these services or things such as remote backup will start failing.

Elan Shudnow :: Feb.01.2009 :: Exchange, ISA, OCS, Windows :: 82211 Comments »http://www.shudnow.net/2009/02/01/default-gateways-and-multihomed-boxes/Default+Gateways+and+Multihomed+Edge+Boxes2009-02-02+04%3A53%3A18Elan+Shudnow