none
Can't log in Skype for Business Online since enabling AADC RRS feed

  • Question

  • Hello.

    I have an Office 365 tenant with about 8 x Skype for Business Online licenses and 3 x E5 licenses.  The users were setup in the portal with their email address authenticating with Office 365.

    Now that I have enabled seamless sign on nobody can log in to SfB, internally it just says:

    "The server is temporarily unavailable,  If the problem continues, contact your support team".

    and externally it says:

    "Skype for Business couldn't find a Skype for Business Server for mydomain.com.  There might be an issue with the Domain Name System (DNS) configuration for your domain".

    Do I need to reconfigure anything now that I have configured this?  Could something have been reset in O365 since enabling AADC?  Nothing has changed DNS-wise and I can use the connectivity test tool to confirm that is all OK.

    I can't even log in to https://sched.lync.com so it's almost as if the SfB settings have been wiped.  Maybe I need to add some AD attributes on-premise now for it to sync to Azure AD?

    Any help appreciated please, I need to get this working ASAP.

    Thanks.



    • Edited by Ted Curly Monday, November 25, 2019 5:29 PM
    Monday, November 25, 2019 4:27 PM

Answers

  • Hi Sharon.

    No, it's not a licensing issue, I have the SfB licenses.  I used to work, it just broke when I enabled AADC.

    However, since working with Microsoft Support the issue is now resolved and it was indeed caused by the following attributes being synchronised from on-premise to Azure, as we once trialled SfB on-premise:

    • msRTCSIP_DeploymentLocator
    • msRTCSIP_PrimaryHomeServer
    • msRTCSIP_PrimaryUseAddress
    • msRTCSIP_UserEnabled
    • msRTCSIP_UserPolicies
    • mDBUseDefaults

    Thanks everyone for their suggestions.

    Monday, December 2, 2019 3:20 PM

All replies

  • Just to clarify, AADC was NOT installed prior to this? If so, chances are you've overwritten user's attributes with those from your on-premises environment, potentially causing the issue. That's the best guess without having access to troubleshooting data - best open a support case.
    Monday, November 25, 2019 7:20 PM
  • That's correct, AADC was not installed prior to this issue.  Everything was working fine until I used AADC to sync with AD.  Is there an easy way to put the attributes back? Can I edit them in Azure AZ like I can on-premise?  I've had a look but can't see them.
    Monday, November 25, 2019 8:12 PM
  • OK, I can now see what's going on - from looking in the SfB logs (%LOCALAPPDATA%\Microsoft\Office\16.0\Lync\Tracing) I can see that it's trying to resolve an internal server that doesn't exist.  A year or so ago we created an on-premise SfB server to trial it, but chose Office 365 instead.  That server has been decommissioned but the user attributes are still in AD.  This is what I need to fix but don't know how (maybe ADSIEdit?)
    Monday, November 25, 2019 8:56 PM
  • Hi Ted Curly,

    Do you mean you want to change the default configuration of AADC?

    Note that if you make changes to the default out-of-box sync rules then these changes will be overwritten the next time Azure AD Connect is updated, resulting in unexpected and likely unwanted synchronization results.

    The default out-of-box sync rules have a thumbprint. If you make a change to these rules, the thumbprint is no longer matching. You might have problems in the future when you try to apply a new release of Azure AD Connect.

    For the details about how to change AADC configuration, please refer to:

    https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-change-the-configuration


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, November 26, 2019 2:53 AM
    Moderator
  • I don’t know what I need to do. Since enabling AADC with the default configuration has broken my SfB Online I guess something needs changing. What could it have broken? I assume it has sync’d some attributes that don’t work for SfB Online.
    Tuesday, November 26, 2019 6:01 AM
  • OK, I can now see what's going on - from looking in the SfB logs (%LOCALAPPDATA%\Microsoft\Office\16.0\Lync\Tracing) I can see that it's trying to resolve an internal server that doesn't exist.  A year or so ago we created an on-premise SfB server to trial it, but chose Office 365 instead.  That server has been decommissioned but the user attributes are still in AD.  This is what I need to fix but don't know how (maybe ADSIEdit?)

    You probably need to remove the internal DNS entries. Alternatively, you can "instruct" the client to connect to SfBO by manually populating the server settings:

    Options -> Personal > Advanced > Manual configuration. Enter the address sipdir.online.lync.com:443 in both the Internal and External server fields, and then press “OK”:

    Image

    Tuesday, November 26, 2019 8:10 AM
  • Thanks for the reply.  I tried changing to manual configuration but it didn't help.  Now it just says "We're having trouble connecting to the server.  If this continues, please contact your support team".

    I've looked in the logs again but can't see anything useful hints as to what is wrong.

    Is this normal behaviour for enabling AADC?  Is it known to trash the services in Office 365 or should I have done something beforehand to stop this happening?  I just assumed it would let us log in to Office 365 with our on-premise AD credentials.

    Tuesday, November 26, 2019 8:32 AM
  • So we're back to the initial suspicion of having the attributes overwritten. Check the values of the SIP address and msRTCSIP-PrimaryUserAddress for any of the affected users in AD.
    Tuesday, November 26, 2019 6:32 PM
  • Hi Vasil.  Looking in my on-premise AD I don't see a SIP address attribute, but the msRTCSIP-PrimaryUserAddress is set to sip:me@mydomain.com (but with my real email address).

    Can I see the attributes in Azure AD?

    Also, would enabling the Exchange Hybrid option in AADC have any bearing on this?  I enabled it in AADC but haven't run the wizard in Exchange to configure hybrid.

    Tuesday, November 26, 2019 8:56 PM
  • You don't need the Hybrid option, it will cause some attributes to be written back on-premises, potentially overwriting their values.

    The SIP address is found under proxyaddresses.

    Wednesday, November 27, 2019 8:11 AM
  • The SIP address is all OK, nothing wrong there.

    I've managed to get one user working by deleting their account from Azure AD, letting it resync and assigning the SfB license.  Now they can log in.  Worst case I'll have to do this for all users, it's not that many.

    I was thinking I'll need Hybrid mode at some point as we plan to get everyone E5 licenses next year for Teams and SharePoint, but keep Exchange on-prem (at least initially), so won't I need it for those applications to access our mailboxes and calendars, etc?

    Wednesday, November 27, 2019 10:48 AM
  • Hi Ted Curly,

    Do you mean you wan to use E5 license? It includes Exchange online. Maybe you need to migrate your Exchange on-premises to Exchange Online.


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Friday, November 29, 2019 10:03 AM
    Moderator
  • Hi Sharon.

    No, it's not a licensing issue, I have the SfB licenses.  I used to work, it just broke when I enabled AADC.

    However, since working with Microsoft Support the issue is now resolved and it was indeed caused by the following attributes being synchronised from on-premise to Azure, as we once trialled SfB on-premise:

    • msRTCSIP_DeploymentLocator
    • msRTCSIP_PrimaryHomeServer
    • msRTCSIP_PrimaryUseAddress
    • msRTCSIP_UserEnabled
    • msRTCSIP_UserPolicies
    • mDBUseDefaults

    Thanks everyone for their suggestions.

    Monday, December 2, 2019 3:20 PM
  • Hi Ted Curly,

    Do you have any further issue on this topic?

    Meanwhile, if there is no issue, please remember to mark helpful reply as answer to close the thread. Your action would be helpful to other users who encounter the same issue and read this thread.

    Thanks for your understanding.


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Thursday, December 5, 2019 9:22 AM
    Moderator
  • Here I will provide a brief summary of this post. This will make answer searching in the forum easier.

     

    <Issue Symptom>:

    I have an Office 365 tenant with about 8 Skype for Business Online licenses and 3 E5 licenses.  The users were setup in the portal with their email address authenticating with Office 365.

    Now that I have enabled seamless sign on nobody can log in to SFB, internally it just says:

    "The server is temporarily unavailable. If the problem continues, contact your support team".

    and externally it says:

    "Skype for Business couldn't find a Skype for Business Server for mydomain.com.  There might be an issue with the Domain Name System (DNS) configuration for your domain".

     

    <Cause>:

    It is related to some attributes being synchronized from on-premises to Azure.

     

    <Solution>:

    It was indeed caused by the following attributes being synchronized from on-premise to Azure:

    msRTCSIP_DeploymentLocator

    msRTCSIP_PrimaryHomeServer

    msRTCSIP_PrimaryUseAddress

    msRTCSIP_UserEnabled

    msRTCSIP_UserPolicies

    mDBUseDefaults

     

    <Reference Links>:

    https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-change-the-configuration


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, December 26, 2019 7:56 AM
    Moderator