So I have been saving this post because I couldn’t resolve an issue for on-premise 2003 users accessing free/busy information of O365 users. All other free/busy information was working but this one piece was giving me trouble. Today I finally got the answer I was looking for, and for those of you out there scratching your head or possibly banging your head into a wall, here is the answer.
First a little additional information about the deployment from the first post I did on this build. In addition to it being a relatively complex environment the Exchange organization is actually deployed in a child domain. I don’t have the specifics on what the problem is but the testing included running ExTRA tracing the following tags:
- InfoWorker.Common,
- InfoWorker.RequestDispatch,
- InfoWorker.Availability,
- InfoWorker.RequestDispatch
- InfoWorker.ADProvider
If you have the tools to analyze the subsequent trace logs you are looking for ADFind Tag that looks for something that contains “cn=FederatedEmail”. The result will say:
‘No returns (Last operation took 0 milliseconds, visited:0, returned:0, index:<null>, filter from AD:<null>)’.
Bottom line is, if you have Exchange 2010 in a child domain and run a 2003/2010 Rich Coexistence Environment with Office 365 you will need this patch. Right now it is in the final stages of development, if you experience the issue contact Microsoft and reference this blog, they will be able to help out. When I find out the bug ID number or KB article I will post that as well for your reference. My understanding is the interim patch is going to be distributed on an ‘as needed’ basis and will be included in the next Rollup or Service Pack, whichever comes first.
Now on to the fun stuff!! Let’s ignore the error above since we know there is a solution in the works. Now, the build guide specifically says that the free/busy public folder has to reside on the CAS/HUB server, this is incorrect. If you have a distributed Exchange 2010 environment with back end mailbox server that are separate from your CAS/HUB servers you are fine. You do need to follow all of the other instructions though, including:
- Creating a free/busy replica on 2010 PF
- Wait for replication to fully complete
- Point all 2003 DB’s to the 2010 PF (this step isn’t noted in the documentation either) but if you don’t do this all 2003 free/busy lookups will fail
- Remove your 2003 free/busy replica
Once you are done you should have a single free/busy replica on 1 Mailbox server in your 2010 environment with all databases pointing to that instance. Once you have that continue on with configuring your Exchange federation and Organizational Relationships. The one thing that I found I needed to do in addition to what was on the guide was add a value for the TargetSharingEpr on my Cloud Based Organizational Relationship. To do this:
- Connect to O365 using a remote PowerShell session
-
Type:
- Set-OrganizationalRelationship –TargetSharingEpr ‘https://mail.domain.com/ews/exchange.asmx’
Now, the guide shows /WSSecurity at the end of this value for the On-Premise Organizational Relationship, but after reading many reviews on the Office 365 community forums, this seemed to be the more solid setting. After I added this value I was able to see free busy for my on-premise users from an Office 365 mailbox.
Besides for that the Exchange Build Guides are rock solid, follow their instructions step-by-step and you will be in Free/Busy heaven! If anyone wants additional details on my build or if you are running into issues and want to chat drop me a line at jdiaz@go-planet.com.
