How to troubleshoot sign-in issues in Lync Online

 Fix user identity and Windows Azure AD issues in Lync 2013  

1. Test: Can the user sign in to the Office 365 portal?
   • No. If the user can't sign in to the Office 365 portal or any other Office 365 services, the problem is directly linked to the user's identity or Windows Azure AD. In this case, the problem isn't caused by Lync Online and must be looked at by Office 365 technical support.
   • Yes. If the user can sign in to the Office 365 portal but can't sign in to Lync Online, go to the next step.
2. Question: Is the user licensed for Lync Online?
   • No. In the Office 365 portal, make sure that the user has a Lync Online license. After the user is assigned a license, wait at least 30 minutes, and then make sure that the user is listed in the Lync Online Administration Center. If the user is listed, it means the Lync Online service has created and configured a Lync Online account for the user.
   • Yes. If the user definitely has a Lync Online license, there may be other reasons that the user can't sign in to Lync Online. Go to the next step.
3. Question: Is the organization synchronizing their on-premises Active Directory schema with Office 365 by using the Windows Azure Active Directory Sync Tool?
   • No. Go to the next step
   • Yes. If the customer previously had a Lync Server or Office Communications Server deployed on-premises, there may be attributes that are preventing Lync Online users from being correctly provisioned. Check the user in the Active Directory schema, look for the msRTCSIP-UserEnabled attribute, and verify that this attribute is set to true. 
     
     For more information, view the following article in the Microsoft Knowledge Base: 
     2705378

     (http://support.microsoft.com/kb/2705378/ )

     Error message when you try to sign in to Lync Online: "Cannot sign in to Lync because this sign-in address was not found"
4. Question: Is the user enabled for enterprise single sign-on (SSO) through an on-premises AD FS 2.0 server?
   
   Hint: One quick way to determine whether the user is enabled for SSO is to have the user try to sign in to the Office 365 portal. Have the user enter their user name, and then press the Tab key to move to the Password box. If the user receives a “You are now required to sign in at <Domain>” message, and if a link to sign in through the company’s AD FS 2.0 server appears, the user is enabled for SSO.
   • No. If the user isn't SSO enabled, follow the steps in the Fix Lync client-side issues section.
   • Yes. If the user is SSO enabled, there may be a problem with the setup of the on-premises AD FS 2.0 server. There are some tests that you can perform to determine whether this is the case. Go to the next step.
5. Question: Can another SSO-enabled user from the same organization sign in to Lync Online?
   • No. This indicates a larger problem with the organization’s identity authentication system. Go to the next step.
   • Yes. This indicates a single user identity issue that must be looked at by Lync Online technical support. If you haven't gone through steps to exclude client issues, see Fix Lync client-side issues.
6. Question: Can a user who isn't SSO-enabled sign in to Lync Online?
   • No. If users who are SSO-enabled and users who aren't SSO-enabled can't sign in to Lync Online, there might be a service-related issue with Lync Online. Check the service health dashboard in Office 365 to see whether there are any outages for Lync Online. If there are no outages, and if no users can sign in to Lync Online, make sure that it isn't a Network- or DNS-related issue, and then contact Lync Online technical support.
   • Yes. Go to the next step.
7. Test: If the user is licensed to use Office ProPlus, try to install and activate a copy of Office 365 ProPlus. If the user is an admin, they can also test rich client authentication by using the Windows Azure Active Directory Module for Windows PowerShell to try to connect to the Office 365 PowerShell service. Can the user sign in to services by using rich client authentication?
   • No. If rich client authentication isn't working for any Office 365 service, there's probably an issue with the company’s setup of AD FS 2.0. The setup should be looked at by Microsoft Office 365 technical support for SSO issues.
   • Yes. If rich client authentication is working for other Office 365 services, go to the next step.
8. Test: Try to access the company’s AD FS 2.0 WS-Metadata Exchange (MEX) document to confirm that rich clients such as Lync can authenticate through the company’s on-premises authentication system. Open Internet Explorer and browse to the MEX URL. The MEX URL usually has a format that resembles the following:
   https://sts.contoso.com/adfs/services/trust/mex
   Is the document successfully displayed in a web browser?
   • No. If the MEX document isn't available through the web browser, the user will be unable to authenticate through any rich clients. This explains why the user can sign in to the Office 365 portal and probably also Exchange Online but can't sign in to Lync Online. The Office 365 portal and Exchange Online both use simple authentication instead of rich client authentication. If this is the case, the issue should be looked at by Office 365 technical support for SSO issues.
     
     For an AD FS 2.0 hotfix that may resolve this issue, view the following article in the Microsoft Knowledge Base: 
     2254265

     (http://support.microsoft.com/kb/2254265/ )

     The "500" error code is returned when you send an HTTP SOAP request to the "/adfs/services/trust/mex" endpoint on a computer that is running Windows Server 2008 R2 or Windows Server 2008
     
   • Yes. If the user can access the MEX document from a web browser, they should also be able to sign in to other Office 365 services by using rich client authentication. Services such as Lync 2013, Office ProPlus, and the Windows Azure Active Directory Module for Windows PowerShell use the Microsoft Online Services Sign In Assistant to authenticate through rich client authentication. Go to the next step.

Back to the top | Give Feedback

Next steps, if the issue isn't resolved

1. Download and then install the Microsoft Online Services Diagnostic and Logging (MOSDAL) Support Toolkit from the following Microsoft website:
   http://www.microsoft.com/download/en/details.aspx?id=626

   (http://www.microsoft.com/download/en/details.aspx?id=626)
2. Run the MOSDAL Support Toolkit, select IM and Online Meetings with Lync Online from the list of Office 365 services, and then click Next.
3. Enter your user ID and password, and then click Next. Your user ID and password aren't saved by MOSDAL and are only used to diagnose potential sign-in problems.
4. On the next screen, restart Lync 2013, and then reproduce the issue by trying to sign in to Lync Online.
5. When MOSDAL finishes collecting data, click Exit and Show Files, and then contact Office 365 tecnical support.

Diagnose authentication issues by using MOSDAL and Snooper

• MOSDAL Support Toolkit
  (http://www.microsoft.com/download/en/details.aspx?id=626)
• Snooper (Snooper is included in the Lync Server 2010 Resource Kit Tools
  (http://www.microsoft.com/download/en/details.aspx?id=21165)
  )

1. Collect data to analyze.
   
   Follow the steps that are described earlier in this article to download and install the MOSDAL Support Toolkit, and then generate a report that's compiled into a file that's named MOSDALREPORT.zip.
2. Examine the Lync log files.
   1. Open the MOSDALREPORT.zip file, and then open the User_Applications\Lync folder.
   2. Use Snooper to open the file that's named Communicator-uccapi-0.uccapilog.
      
      
      Collapse this imageExpand this image

      
   3. On the Messages tab, look for the authentication attempt. This is indicated by "REGISTER sip:contoso.com SIP/2.0."
      
      
      Collapse this imageExpand this image

      
      
      
      Directly under the authentication attempt is the server's response to your authentication attempt. In this example, the server's response is SIP/2.0 401 Unauthorized.
      
      On the right side of Snooper, additional detail is provided from the SIP header. The MS-Client-Diagnostics field will sometimes contain additional information about the failure, as shown in the following example.
      
      
      Collapse this imageExpand this image

      
3. Examine the network diagnostics.
   • Name resolution in DNS
     1. Open the MOSDALREPORT.zip file. Under Network_Tests, locate the NsLookup folder, and then locate the O365_NSLookup folder.
     2. Look for an open a file that's named "nslookup sipdir.online.lync.com.txt" to verify that you can resolve sipdir.online.lync.com in DNS.
        
        
        Collapse this imageExpand this image

        
     3. If the fully qualified domain name (FQDN) is resolvable in DNS, you see the DNS server from which you obtained the response. This is followed by the FQDN and the IP address to which it resolves in DNS. If the DNS server can't resolve the name, contact the IT administrator, because this indicates that there's most likely a configuration issue with the internal DNS server.
   • Ports that are open in the firewall or proxy
     1. Open the MOSDALREPORT.zip file. Under Network_Tests, locate the PortQry folder, and then locate the O365_Port_Queries folder.
     2. Look for and then open a file that's named "PortQry.exe -n sipdir.online.lync.com -p both -e 443.txt" to check the status of port 443. This port must be open for Lync Online to work correctly.
        
        
        Collapse this imageExpand this image

        
        
        
        The file indicates whether port 443 is open to TCP and UDP traffic. Be aware that for Lync Online, we are concerned only with TCP. Next to the line that says TCP port 443 (https service), look for the word LISTENING. This indicates that the port is open from the client computer's perspective.

Back to the top | Give Feedback