Category Archives: Exchange Federation

Lync / Skype for Business Client Asks for Credentials (“EWS not Deployed”) in an Exchange Hybrid Configuration

BACKGROUND

Consider the following scenario:

  1. You have successfully established an Exchange Hybrid Configuration between your on-premises Exchange Server installation and Exchange Online.
  2. You are using a fully functional Lync / Skype for Business Server on-premises installation for all users.
  3. DNS zones for any of your primary SMTP domains exist in the internal network DNS (split-DNS is used)
  4. Some users are moved to Exchange Online, and some are still residing in the Exchange Server installation on-premise.

The following symptoms occur:

  1. For users that are migrated to Exchange Online, sporadic credential prompts appear from the Lync / Skype for Business (SfB) client, asking users for username and password. Users that still have their mailbox residing in Exchange Server on-premise are not asked for credentials.
  2. The following message is displayed in Lync / SfB Configuration Information (right-click the Lync / SfB icon in the System Tray to find this option): EWS Information: EWS not Deployed

CAUSE

Two ways to update presence information: The Lync / SfB client is by default configured to update your presence based on your Exchange calendar (Personal information manager settings in the Lync / SfB client). Lync / SfB can read your presence information from Exchange by either receiving it through the Exchange Web Services (EWS) API, or by reading it from Outlook (if Outlook is installed and running). The EWS method is dependant on Exchange Autodiscover to be fully functional (details will follow under Resolution).

If, as in the scenario explained above, the Configuration Information indicates “EWS not deployed”, the Lync / SfB client will fail to use the EWS API to update presence information. Instead it will fall back to updating the presence information from Outlook.

But it worked before: The Outlook-method have so far worked fine, and will continue to work fine, for non-migrated users as the Lync / SfB client is running under the same user context as Outlook. When users are migrated to Exchange Online and configure Outlook to run in the Office 365 context (regardless if using ADFS/SSO or not), the Lync / SfB client will no longer be able to update the presence information from Outlook without first having you authenticate in the Lync / SfB client with the Office 365 credentials. Migrated users are no longer running Outlook and Lync / SfB in the same user context. This produces the credential prompt.

To resolve this, the EWS method should be used instead. The “EWS not deployed” error must be repaired.

RESOLUTION

Exchange Autodiscover is key: The Lync / SfB client will use Exchange Autodiscover to resolve the URL for EWS. Exchange Autodiscover is assumed to be working in this scenario as the Exchange Hybrid Configuration is established (which itself have a Heavy dependency to Autodiscover). If Exchange Autodiscover is a new topic for your, I suggest reading this article before continuing.

SCP vs. DNS: Outlook will use Active Directory Service Connection Points (SCP) to find the URL to Autodiscover on the internal network (Active Directory joined machines). Outside the internal network, Autodiscover URLs are distributed using public DNS (looking at the domain in your e-mail address and ask for Autodiscover records in that domain). As internal clients rely on SCP records in Active Directory, there have never been any need to add the DNS records for Autodiscover in the internal DNS zone (the split-zone) for the SMTP/SIP domains.

The Lync / SfB client will not use Active Directory SCP records to retrieve the Autodiscover URL. It will only use the DNS-record method. This differs from Outlook, which can use SCP records to find Autodiscover. Because of this difference, you might have a fully functional Outlook (finds Autodiscover via SCP-records) and a fully functional Exchange Hybrid Configuration (finds Autodiscover via A/SRV/CNAME records in the public DNS zone), but you will not have a functional Lync / SfB client (attempts to find Autodiscover from the internal split-zone for the SMTP/SIP domains).

How to fix it: In order for the Lync / SfB client to be able to find Autodiscover on the internal network, add A/SRV/CNAME records (whatever mirrors your public DNS records) in the internal DNS zone (the split-zone) to mirror the setup for Autodiscover records in the public DNS.

After adding internal DNS records for Autodiscover, the Lync / SfB client will be able to find Autodiscover and thus the URL for EWS. Through EWS, the Lync / SfB client can retrieve your presence information from the Exchange Online mailbox via the Exchange Hybrid Configuration, and users migrated to Exchange Online will no longer suffer from credential prompts appearing in the Lync / SfB client.

Free/Busy not working from Office 365/Exchange Online to On-Premise Exchange / Hybrid Configuration – “The external recipient’s server could not be determined” “No information” (You forgot to iisreset)

BACKGROUND

You have successfully deployed a Hybrid Configuration between your on-premises Exchange 2010 SP3 Organization and Exchange Online. Everything works as it should, except for Free/busy look-ups made from Exchange Online mailboxes to a mailbox that still resides on-premise.

You have verified that the following is OK:

  1. You have run ExRCA diagnostics using https://www.testexchangeconnectivity.com/ , selected the Office 365 tab and then Free/busy tests. You simulate Free/busy lookup from Online to On-premise and it works with all green lights.
  2. You have also followed all the troubleshooting steps presented in this Microsoft Knowledge Base article: http://support.microsoft.com/kb/2555008 – all with successfull results.

Still, when attempting to do Free/busy lookups from Online to On-premise, you get the message in Outlook or OWA saying “No information” with the reason “The external recipient’s server could not be determined”.

CAUSE

Settings made during your Hybrid Configuration and/or extended troubleshooting of this error have not been fully commited to Internet Information Server (IIS). Allthough the diagnostics (ExRCA etc) say that your configuration is right, vital configuration is not yet effective.

RESOLUTION

First step in resolving Free/busy errors is to follow the two steps mentioned in the Introduction to this post (ExRCA diagnostics and following KB2555008 – see above). If that does not work:

Doing iisreset on your CAS server publishing EWS/Hybrid could fix this issue.

Plan for a very short outage in Exchange services (OWA/EWS etc) and open the command prompt on your Hybrid CAS server. Then run the command iisreset

After doing IISReset, Free/busy lookups from Online to On-prem should start working within minutes.

I have seen this in the field where we spent days troubleshooting this issue on Exchange 2010SP3 hybrid configurations after finally solving it with this basic, but classic, method – restarting the services. There could of course be other reasons behind the error (i.e related to how Autodiscover is published to the internet), iisreset should not be considered as a “general cure”, but a necessary troubleshooting step if your configuration is done by the book and it still does not work.