Recently I ran into an issue that is specific to certain hosting scenarios (Office 365 or other), or in some circumstances on-prem environments also for Lync Room Systems (LRS).
An LRS system cannot connect to a Lync environment if the top level domain of the LRS account, for example, LRS@domain.com is not present in the SSL cert on either the Edge, for external connectivity, or the Director or Front End Pool for LRS systems deployed internally.
In nearly all scenarios you will ensure your SIP domains are in your certificates, but some companies don't add all of them accepting functionality caveats, and for Lync Online and Lync Hosting Pack v2 you simply cannot add all tenants domains to certificates, so redirection of tenants domains to a hosting access edge is inevitable.
Taking a look at the SMART LRS setup documentation (as I had a SMART system to setup!) here you can see on page 72 that it is necessary to modify the registry with a TrustModelData key to allow LRS to connect to a Lync deployment where indeed the top level domain (TLD) for the LRS account is not in the cert.
If this key is not added the LRS system sits on a blank screen, whilst the certificate warning is hidden behind the LRS walled garden, never allowing you to go any further. What certificate warning you say? Well one like this:
Adding the key and restarting the LRS system tells LRS that the TLD from the certificate, even though it does not match the TLD for the LRS account, is trusted and this certificate warning does not appear. Therefore the LRS can start successfully and can log into Lync via the LRS console without issue. (If you are wondering how to get the registry up on LRS, check the screenshot from the SMART documentation I have pasted above, this is the same procedure for all LRS systems).
But what I found once LRS was rebooted was that the Exchange Calendar would not load.
I checked that the LRS system could actually contact the autodiscover service by manually authenticating directly on the LRS system against EWS (Exchange Web Services) with the LRS account in question.
I was stumped. A quick PSS call confirmed there's an LRS bug, and that you have to give 'Everyone' 'Full Control' on the HKLM\Software\Microsoft\Office\15.0\Lync registry entry to get the Exchange calendar to show..
Once this was applied and the LRS rebooted the Exchange Calendar still wouldn't show, so I went to verify that I had indeed set the permission correctly. It was during this time that I noticed another TrustModelData key – prepopulated with Lync Online – but more specifically Exchange Online TLDs:
So I added the hosted Exchange TLD (in my instance the Lync Edge TLD and Exchange TLD matched) of the certificate to this key and restarted LRS.
When LRS restarted I again received the dreaded loading symbol for approximately 20 seconds, before the calendar showed in full glory!
Conclusion
This isn't going to affect all customers that deploy LRS systems, if you included all SIP domains in all certificates (Edge and internal) this isn't going to affect you. But this will affect Office 365 LRS deployments and any customers that use multi tenant Hosted Lync and Hosted Exchange deployments.
For Office365 customers it appears all TrustModelData registry entries have been pre-populated through the LRS update program (ensure you are up to the latest LRS update, I was), however you will have to perform the permission change to allow everyone full control for it to work.
For other hosted environments you will have to ensure the TLD is added to the TrustedModelData key as well as performing the permission change to allow everyone full control.
LRS should then login and also show the associated Exchange calendar just fine.
On a side note I'll post the full end to end deployment and configuration steps for Exchange 2013 hosting guidance and Lync Hosting Pack v2 in the coming days. Watch this space!