We recently ran across an interesting issue with a customer. They are currently divesting from another large healthcare company and they have contracted with us to build their entire net-new computing infrastructure – across the board.
Since this new organization is 100 percent new, there is no existing Active Directory, no existing Exchange, no existing networking, no existing anything.
It’s complete greenfield.
This customer has chosen to utilize an Office 365 E4 Subscription to take advantage of a consistent operation expense (OPEX) for their email (Exchange Online) and Office 2013 Pro/Plus for the desktop. For their phone system, we discussed several options and chose Microsoft Lync Server 2013 as their full Unified Communication (UC) solution for Voice, Conferencing, and of course IM. Having on-premises Lync and Exchange Online only (not Hybrid Exchange) is perfectly acceptable and 100 percent supported and viable. Further, utilizing Office 365 E4 gives CAL Equivalencies for Lync Server, making Lync an even better choice here.
Sidenote: With the death of the .local domain (and associated SSL “certificate cliff”) last fall, we’re finding more and more organization who are looking to greenfield their environments. The time is ripe for exploring Exchange Online (Office 365) – and with the CAL equivalencies, the Lync (and Skype for Business) conversation has never been easier!
Skipping forward, we have a fully functioning environment. Lync is happy. WAC is happy. PCHAT is happy. Federation to Exchange Online is happy and we have successfully tested both Auto Attendants and Voicemail (Unified Messaging) successfully. Directory Sync is set up and functioning. All is well. Nothing is ruined. We have fairly detailed processes and procedures and project plans in place for our installs. We can always make improvements of course!
Two of our favorite TechNet articles we reference are one based on the dreaded MSExchMailboxGUID and the correct utilization of ProxyAddress. We have made appropriate setting changes on the Active Directory Users and have verified that DirSync is properly handling MSExchMailboxGUID.
But – here comes the problem – the Lync Client (including mobile clients) will not: 1) show visual voicemail, 2) conversation history, 3) reference many EWS related errors. Frustrating.
We have many customers now with Exchange Online (some hybrid – most fully EXO now) and Lync Server on-premises. It “just works” usually.
When the PC Client is logged in – the phone tab looks normal minus the “voicemail” features:
When we bring up the Lync Configuration Information – both the EWS Internal URL and EWS External URL entries are blank, and EWS Information either states “EWS not deployed” or “EWS not fully initialized.”
This is clearly an Exchange “autodiscover” issue. Right? The challenge is that DNS is good. All associated “test connectivity” websites show good info. The Lync Connectivity Analyzer does as well. If you login with the Lync iOS Mobile Client – and then “manually” authenticate to Exchange, it works perfectly. Yes. Autodiscover is wonky, but manual setup works. But why?
Well, it turns out that it’s not just “proxyaddress” that matters when it comes to mailbox/Lync connectivity. The challenge is that we cannot find public documentation that shows this in our scenario. We had an escalated support ticket (multiple levels of escalation) and the engineers on the final resolution could not find public documentation either. They shared with me some private communication that I cannot share here, but it appears some TechNet articles need updated.
No, it’s not anything related to “hacking your registry” for things like TrustModelData. No, it wasn’t anything related to SSL. No, it’s not a missing DNS entry – although many problems are DNS related. No, it’s not a missing firewall entry or network issue or mismatch between SIP URI and ProxyAddress email address. It’s nothing on the first 317 pages of a Google Result… or first 250 pages of a Bing Result. Yes. I know these things.
The problem? The “mail” attribute in Active Directory. Duh, right? Not so fast. Remember, this is greenfield. There never has been Exchange – so it wouldn’t be populated automatically. This is not Hybrid. This is purely Exchange Online. We of course “prepped” for Exchange on-premises in order to get proper attributes, but, populating the “mail” attribute wasn’t in the plan for this customer. There are many useful reasons to populate this; perhaps a line of business (LOB) app needs it. Perhaps there is a script you utilize that populates that during user provisioning. In this case though, the “proxyaddress” (with capital SMTP) was utilized based on our experience and TechNet.
Let’s review. We have Lync 2013 On-Premises and Exchange Online. We have correctly configured ProxyAddress and MSExchMailboxGUID and Directory Sync is working. All is well. Lync Client “exchange autodiscover” wasn’t working properly in order to correctly identify, authenticate, and populate EWS and pull useful things like voicemail and conversation history. The on-premises Active Directory attribute “mail” was found to be required, and once entered correctly to match the proxyaddress “primary” mail attribute things worked perfectly… instantly.
It should be important to go back and review one of those TechNet articles I mentioned above, especially the one related to ProxyAddress.
Look at this part here under Deployment:
We have ProxyAddress. Check. We have Directory Sync, so no additional action should be required. But if you expand the Lync Server 2013 without DirectorySync, you’ll notice mention of the “mail” attribute here. Strange, huh? Yes. It’s strange to every Microsoft engineer I discussed this with. One of the escalation engineers I discussed this issue with – as well as the Lync Service Delivery Manager – has promised to review public-facing documentation to clear this particular thing up.
So, there you go. A single on-premises Active Directory attribute was preventing Lync 2013 Server on-premises and Exchange Online from “fully” working properly. Even though functionality was working with Unified Messaging and Exchange Online, the Lync Client presentation (and integration) with Exchange Online Features was degraded.