Lync/Skype for Business client can't connect with Exchange in Office 365 dedicated/ITAR

Symptoms

In Microsoft Office 365 Dedicated/ITAR, a user may experience one of the following issues in the Microsoft Lync/Skype for Business client:

• Features such as the following aren't working as expected:

  • Saving conversation history

  • Presence updating that's based on calendar information

  • Out of Office notifications that are displayed on the user's contact card

• The user may be repeatedly prompted to provide a user name and a password to connect to Exchange.

Additionally, the user may receive one of the following error messages:

Cause

This issue occurs if one or more of the following conditions are true:

• Integration with Microsoft Exchange Server or Outlook is disabled.

• Exchange credentials are incorrect.

• The Exchange Web Services (EWS) service isn't enabled.

• The firewall or proxy blocks necessary traffic.

• The Lync client can't identify the correct autodiscover information.

Resolution

To fix this issue, follow these steps:

1. Make sure that the Lync client has the most recent update. To do this, see Skype for Business downloads and updates.

2. Confirm that the Lync client is configured for Exchange or Outlook integration:

   1. Locate Lync Client > Options > Personal.

   2. Under Personal Information Manager, make sure that Microsoft Exchange or Microsoft Outlook is selected together with the desired features:
      
      
      
      Note If these options are unavailable, they may be restricted by a Group Policy setting or by the client policy that's applied to the Lync user.

3. Validate Exchange credentials by signing in to Outlook Web Access.

4. Make sure that EWS is enabled for the user. To do this, use Remote PowerShell to run the following Exchange command: Get-casmailbox <smtp> | fl EWSEnabled If the value of the EWSEnabled attribute is set to FALSE, Lync/Skye for Business integration will fail.

5. Make sure that there's no proxy or firewall that blocks traffic. Ports 443 to the Exchange environment must be open on the firewall and on proxy servers to let Exchange traffic pass freely.

6. Identify any EWS issues that are being experienced in Outlook (free/busy or Out of Office).

7. Confirm that the EWS URL that the Lync client uses is correct. To do this, follow these steps:

   1. Press and hold Ctrl, right-click the Lync icon in the notification area, and then click Configuration Information. Look for the EWS setting in the EWS External URL field.

   2. Change the value that you found in the EWS External URL setting so that it ends with "Exchange.asmx." For example:
      
      Default EWS external URL: https://mail.outlook.com/EWS/Exchange.asmx/WSSecurity
      
      Changed EWS external URL: https://mail.outlook.com/EWS/Exchange.asmx
      
      Note If there's no value in the EWS Internal or EWS external URL, go to step 8.

   3. Enter the changed EWS External URL address into a browser, and then enter Exchange credentials if you're prompted to do this. You should receive an XML response (in Exchange Server 2010) or a Service page (in Exchange Server 2013).
      
      If the page isn't displayed, this is likely a network or DNS issue that prevents resolution of the URL, and network teams should be engaged.

8. If the EWS external URL and EWS internal URL are blank, it's likely that the autodiscover process is failing.
   
   The Lync/Skype for Business clients don't use Service Connection Point (SCP) to determine the autodiscover URL. Instead, they rely on DNS records. They base this action on the user’s domain suffix of the WindowsEmailAddress or Mail attribute in Active Directory.
   
   At least one of the following DNS records has to be fixed in the Exchange environment:

   • https://<SMTP-Domain>/autodiscover/autodiscover.xml

   • https://autodiscover.<SMTP-Domain>/autodiscover/autodiscover.xml

   • http://autodiscover.<SMTP-Domain>/autodiscover/autodiscover.xml

   • _autodiscover._tcp.<SMTP-Domain> (SRV record)

   
   Test whether the user's computer can fix these URLs by either trying a ping or locating the URL in an Internet browser. A successful response should show an XML response together with error code 600.
   
   If the URLs are still not displayed after you follow this step, this is likely a network issue, and network teams should be engaged to investigate.

9. If the issue still persists, collect Lync logs, a Fiddler trace, and configuration information output from step 7A, and then follow the escalation instructions in the following Knowledge Base article:

   2649420 Troubleshooting basics for Lync Online in Office 365 Dedicated