This started few years back when one of my migration colleague assured me that he was able to successfully synchronize Free/Busy from Exchange 2010 to Exchange 2003 using Legacy Free/Busy QMM (Quest Migration Manager) sync. I couldn’t believe this at first but his reputation prompted me to dig deeper because I could not explain it with my knowledge of Exchange 2010 logic at that time.
We all know that starting from Exchange 2007 the new Availability service retrieves F/B directly from the mailbox while older Outlook 2003 clients still keep posting into PF (if you chose to deploy PF Database in Exchange 2007/2010). But there was never a logic in Exchange that would be capable of taking Outlook 2003 Legacy F/B PF Calls and rather retrieve F/B directly from the mailbox. Well, not until Exchange 2010 SP1. After at first trying to explain the above colleague’s experience by perhaps having Outlook 2003 Legacy clients posting Legacy F/B into Exchange 2010 PFs and QMM F/B sync picking up Legacy F/B messages and successfully synchronizing it over to Exchange 2003, I finally stumbled upon this Microsoft article:
https://support.microsoft.com/default.aspx?scid=kb;en-US;2535105#survey
“…new feature in Exchange Server 2010 SP1. This new feature uses the Microsoft Exchange RPC Client Access service as a proxy for earlier versions of the Availability service (free/busy information). Therefore, if you have a public folder that is installed on an Exchange Server 2010 SP1 server, the Microsoft Exchange RPC Client Access service intercepts the free/busy information requests.”
The article does not go very deep into explaining this new logic and simply provides a fix for condition caused by its initial introduction when too many of such proxy requests start causing PF access issues. However at the later time some better references started to show up:
https://technet.microsoft.com/en-us/library/ee332317(v=exchg.141).aspx
Microsoft Outlook still connects directly to the Mailbox server to access Public Folder databases. If a client tries to connect to a Mailbox server for public folder access, the RPC Client Access service (MsExchangeRpc) answers the RPC endpoint. If the endpoint is on a server that has the Mailbox server role installed, the RPC Client Access service will only allow public folder logons and will provide a referral to a Client Access server or a Client Access server array. If the endpoint is on a Client Access server or Client Access server array, it will allow only Private folder logons and will provide a referral to a Mailbox server for public folder access.
“RPC Client access service” in the mailbox server is used for none other than public folder access. When the outlook client queries for Public folders, it directly connects to the PF server (You can view it by checking the “Connection status” from outlook). This request is taken care of by the “RPC Client access service” in the mailbox server.
Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache.
I find it especially interesting that it also places F/B message into PF. I tested it in my LAB and indeed confirmed that after scheduling meetings with Outlook 2010 on Ex 2010 SP1 (no Outlook 2003 presence), after few minutes legacy F/B message is also showing up in PF. So the way QMM Legacy F/B sync might still work in the example given in the beginning of this article – “RPC Client Access Service” intercepts QMM Legacy F/B Agent calls into Schedule + F/B and rather works with Availability Service itself. So while there may be NO F/B data in the PFs at first, legacy FB sync will still work in the pure Ex 2010 environments proxied by “RPC Client Access Service” and serviced by Availability service. QCS Legacy F/B sync would do the same. So what does this give us? Below I will try to summarize all possible QMM/QCS F/B Sync combinations including the ones that made it possible with this new Ex 2010 SP1 logic. Here I am only talking about the sync and not including any O365 or Federation scenarios which is actually a future of migration and can make this all work without any F/B or Calendar sync tools.
1. Migrations between Exchange 2007/2010/2013***(the latter is often special case) with Outlook versions 2007+ (native Availability): Use QMM/QCS Calendar Sync. Yes it’s slow but there is no other way around it. Scale out QMM Calendar Sync Agents or implement multi-console QCS.
2. #1 with Outlook 2003 clients (you’ll be surprised how many customers still have Outlook 2003 around Ex 2007/10 environments). This will not be supported in Ex 2013 but with Ex 2007/2010 you can deploy PF database and use legacy QMM/QCS F/B Sync. Calendar Sync will work as well because it also updates F/B message inside PF but beware that it slows down Calendar Sync in QMM and often updating Legacy F/B logic is disabled in QMM Calendar Sync.
3. #2 with the mix of legacy Outlook 2003 and newer Outlook 2007+ clients (except Ex 2013 where Outlook 2003 will not be supported). This will require mix of QMM/QCS Calendar and F/B Sync.
4. #3 with Ex 2010 SP1 can utilize this new RPC Client Access logic and rather sync native Calendar data letting Ex 2010 SP1 to serve Outlook 2003 client F/B calls into PF.
5. Migrations between Exchange 2003 and Exchange 2007/2010: 1) Outlook 2003 – QMM/QCS F/B Sync 2) mix of Outlook 2003 and later clients – both Calendar and F/B Sync
6. #5 with Ex 2010 SP1 – can utilize this new RPC Client Access logic to sync native Ex 2010 availability back to Ex 2003 using QMM/QCS F/B Sync.
Please note that here I mostly consider QMM legacy migration approach where Source and Target environments both have mailboxes. However often in the various F/B coexistence scenarios where new Availability service cannot look inside PF and always defaults to the mailbox, you can still create Mail-Enabled User or Contact instead of mailbox and then redirect Availability F/B lookups into PF via the following command-let:
Add-AvailabilityAddressSpace -ForestName:sourcedomain.com -AccessMethod:PublicFolder
I hope in your migration project you will not have to deal with the Legacy F/B at all! 🙂
