Preserve Cross Forest Free Busy When Migrating to New Forest Feasible?

FreeBusy requires that both old and new Forest needs two unique SMTP domains @newdomain.com and @legacydomain.com. The issue is that since both orgs are also sharing @company.com with @company.com being the primary SMTP domain for both orgs we run into problems with Galsync.

Scenario: For newdomain.dom users to see legacydomian.com user’s FreeBusy

1. Add @legacydomain.com as another SMTP email address to userA in ipcfcdom forest
2. Galsync will create a contact in corp.dom for userA with @company.com being the primary email and @legacydomain.com being secondary
3. User in newdomain.com tries to look up FreeBusy for userA and fails. Although @legacydomain.com is in userA’s contact, userA’s primary email is still @company.com
4. To resolve; Galsync must change what’s known as the targetaddress (foreign email address) to @legacydomain.com on the contact. By default Galsync makes the targetaddress the same as the primary email address @company.com. This is the problem. According to MS you will need to do custom coding on the source code for the GALsync to change this default behavior.

What I implemented:

ForestA has @ADdomainA.com as authoratative accepted domain and Email address policy.
ForestB has @ADdomainB.dom as authoratative accepted domain and Email address policy.

Create respective SMTP send connectors to forward these SMTP domains to each respective HT servers shared SMTP mail flow.

Now internal mail flow between both forests will be based on these internal SMTP domains. FreeBusy will also be based on these internal domains.

Then follow doc
How to Configure the Availability Service for Cross-Forest Topologies
http://technet.microsoft.com/en-us/library/bb125182(EXCHG.80).aspx

You will need to export the SCP of each respective domain and configure the availability address space.

If you do still are not able to see the FreeBusy after you have configured everything, make sure that the Firewall is not blocking HTTPS between the CAS server in 2007 and CAS servers in 2010. HTTPS needs to be open for the respective CAS servers to query each others serviceBindingInformation.

https://outlook.company.com/autodiscover/autodiscover.xml
https://mail.company.com/autodiscover/autodiscover.xml


Then my GALsync contacts in ForestB (new forest) I will need to change the targetaddress to @ADdomainA.com. GALsync created contacts for MB users from FroestA to ForestB but sets the targetaddress on the contacts as the shared primary SMTP of @company.com.

What I did was use good old Admodify, and limit the scope to the OU where the GALsync contacts got created and do a cusom LDAP query for (targetaddress=*@company.com) The reason is I don't want to inadvertently modify the targetaddress for external contacts that may have actual external addresses say @yahoo.com. This query will search for all contacts that have the targetaddress of @company.com. Then I go into the custom tab and set the targetaddress to %'mailNickName'%@ADforestA.com.

Now when you migrate a user's mailbox from ForestA to ForestB, the MB user gets converted to a mail enabled user. You need to ensure that the targetaddress is set to @ADforestB.com. You can append this in the new-moverequest parameter.

New-MoveRequest -Identity "Distinguished name of User in Target Forest" -RemoteLegacy -TargetDatabase "E2K10 Mailbox Database Name" -RemoteGlobalCatalog "FQDN of Source DC" -RemoteCredential $Remote -TargetDeliveryDomain "ADforestB.com"

Note when you run GALsync again, it will overwrite the targetaddress of the contacts back to the shared SMTP namespace @company.com. This will break FreeBusy again. So your options are, don't run Galsync again or you will need to fix again using Admodify to update the targetaddress again.

Also GALsync will create a mail contact even if a matching mailbox enabled user exists on the target forest. Therefore after you migrate a mailbox user, you need to have GALsync exlude those accounts from being synced up. Two methods move the migrated users to a separate OU in the source domain and have Galsync ignore those OUs when it syncs. Or what I did was set up GALsync to ignore all accounts that have attributeextension15 with the work "migrated". You would set this on the attribute flow rule.

As far as autodiscover for externally connected, non domain joined clients for users who get migrated, you have no option. FreeBusy, OOF will not work. You will need to tell your migrated users to use OWA in during the coexistence. This is because externally connected clients will have to use DNS to find the autodiscover. Unless you are willing to publish and use two unique public SMTP namespace you have no other option.



James Chong
MCITP | EA | EMA; MCSE | M+, S+
Security+, Project+, ITIL
msexchangetips.blogspot.com