In all my deployments of SRS up until now, I’ve used are using the same SIP domain and UPN or they’ve 100% Office 365, so not come across this before.
In my scenario I had:
Internal AD domain domain.co.uk - Used for the user’s UPN - in this scenario 100% on-premises so no Azure AD - they saw no need to change users UPN to match SIP domain.
External domain domain.com - Used for SIP domain
Let’s sign in
From the SRS I first tried using the same sign-in address for Skype and Exchange (it defaults to this), with the user account using the internal AD domain:
But as expected, could see that sign in was refused in the Exchange server Audit logs (as domain.com is not the users UPN). SRS also stated, “Cannot Fetch Calendar”.
OK, let’s change the Exchange sign-in address to the UPN and try again:
This time no error, but still no calendar. (The reason for no error is that it hasn’t been refused as it hasn’t had a reply).
Thinking about it, the SRS would be doing an autodiscover lookup (and authentication) against [email protected], which in my case wasn’t set up. At this stage you could do one of two things:
Option 1 - Setup autodiscover for the user’s existing UPN:
You would need to do the following:
- Point autodiscover.domain.co.uk at Exchange Autodiscover service (same as existing autodiscover.domain.com)
- Add autodisover.domain.co.uk to the Exchange certificate assigned to the IIS service
This would work if the UPN is a valid external domain that you own e.g. domain.co.uk. If you are using something that you don’t own or isn’t valid externally e.g. domain.local, you can’t do this as you can’t raise a certificate with a CA.
Option 2 - Change the user’s UPN to match the SIP domain:
By changing the UPN of the user to match the SIP domain, it will now use the existing autodiscover.domain.com
We went with option 1 as the internal domain was also owned and it all started working!