Lync/SfB Unified Contact Store with Exchange

I came across some strange errors recently with a customer where the setup was as follows Lync/SfB on premise due to Enterprise Voice but had Exchange Online. Whereas the issues being seen were the OWA IM client wouldn’t sign in, on mobile devices the buddy list would not show at all and the mobile client would struggle to resolve names when you received an instant message. Upon further digging this was due to the Unified Contact Store that Lync 2013/SfB 2015 and Exchange 2013/16 use and share.

Now the following is the statement of support-ability from Microsoft referenced here: https://support.microsoft.com/en-gb/kb/2614614#bookmark-more

Supported Lync/SfB Scenarios

Lync and Exchange integration features Outlook integration (EWS, MAPI) Outlook Web App integration (IM/P) Outlook Web App online meetings (scheduling) Unified Contact Store High-resolution contact photos
Skype for Business Online only Supported Supported Supported Supported Supported
Lync Server 2013 only Supported Supported Supported Not supported Supported
Lync Server 2013 hybrid deployment with Skype for Business Online Supported Supported Supported Supported* Supported

*Supported only for Skype for Business Online users in the hybrid deployment.

Now from this you will notice that UCS is not supported when you have Lync/SfB on premise and Exchange Online. Now I should point out at this stage that the UCS store was introduced in Exchange 2013/16 so if you migrated or are running Exchange 2013/16 this will affect you.

To resolve this there are a couple of options available:

  1. Disable the UCS store before you migrate to Exchange Online – As this will back up the contacts and you will not lose your buddy list. (I will discuss the commands later on)
  2. Migrate the users back to on premise and then disable UCS and migrate the user back to Exchange Online
  3. Force disabling the buddy list which will wipe out the contacts from the Lync/SfB Client, however if you have not re pointed your Exchange records to O365 this may allow the back of contacts – However in my scenario I was unable to test.

The PowerShell commands available to this are as follows:

  1. To disable UCS for the user – Invoke-CsUcsRollback ahandyblog@test.com -force -verbose
  2. To create a global policy to disable UCS the following command is available:
    1. Set-CsUserServicesPolicy -Identity global -UcsAllowed $False
  3. To create a policy for individuals you can carry out the following:
    1. Create a policy – New-CsUserServicesPolicy -Identity “DisableUnifiedContactStore” -UcsAllowed $false
    2. Then assign the policy to a user – Grant-CsUserServicesPolicy -Identity “ahandyblog” -PolicyName “DisableUnifiedContactStore”
  4. Alternatively you can block globally and allow some users to still user UCS if there mailbox is on premise which is as follows:
    1. Create a policy – New-CsUserServicesPolicy -Identity “EnableUnifiedContactStore” -UcsAllowed $true
    2. Then assign the policy to a user – Grant-CsUserServicesPolicy -Identity “ahandyblog” -PolicyName “EnabledUnifiedContactStore”

Once you have carried out the commands the mobile client and OWA IM should start to work immediately.

Advertisements

5 thoughts on “Lync/SfB Unified Contact Store with Exchange

  1. There is another possible option: actually make UCS access work for skype for business on premises + exchange online.

    two things have to work to allow use of UCS for S4B/exchange online setup:

    • exchange autodiscover for exchange online must work
    • Server to Server oAuth authentication must be configured for S4B/Exchange online.

    Step 1: Autodiscover
    First, autodiscover as performed by S4B has a problem when working with exchange online. You’ll find an error message in the event log:

    Event 32054
    StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=user@domain.com, Autodiscover Uri=https://autodiscover.domain.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=, WebExceptionStatus=ConnectFailure —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 132.245.55.8:443

    The DNS entry for autodiscover.domain.com is a CNAME pointing at autodiscover.outlook.com.

    To make autodiscover work, the desktop client falls back to HTTP if HTTPS is not available; this is necessary for this configuration as the server pointed to by the cname obviously can’t provide a certificate that countains autodiscover.domain.com,

    The autodiscover done by the S4B server however does NOT do this fallback to HTTP and thus fails.

    since the only thing the HTTP fallback does is returning a redirect to the real https based autodiscovery service of Exchange online, we can create a local web server to provide the same response over https. BTW, this local server can use a certificate from a local CA – just ensure the lync server trusts it.

    so – create a weberver for autodiscover.domain.com that has an https binding and returns a redirect to https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc

    no need for authentication, can run on the S4B Server, can bind to 127.0.0.1.

    the only app that we want to access this server is the S4B server, so we just put an etry in the hosts file (c;\windows\system32\drivers\etc\hosts):
     127.0.0.1 autodiscover.domain.com

    At his point, autodiscovery should actually work; oauth however still needs to be configured,

    Step 2: oAuth. the info here comes from https://ahandyblog.wordpress.com/2015/12/02/configure-lyncsfb-with-office-365-for-server-to-server-authentication/ and worked just fine.

    I got the tenant ID reauired for configuring oAuth from the https://portal.office.com web interface: Admin –> Skype for Business; the dahsboard shows the organisation details including the tenant ID (guid format)

    • on the S4B Server
    • New-CsOAuthServer microsoft.sts -MetadataUrl https://accounts.accesscontrol.windows.net//metadata/json/1
    • Get-CsPartnerApplication microsoft.exchange, remove if exists: Remove-cspartnerapplication Microsoft.Exchange
    • New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full –UseOAuthServer

    • using Azure Active directory Powershell
    • previously: export the Lync oAuth certificate in base64 format
    • $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    • $certificate.Import(“C:\Certificates\LyncOauth.cer”)
    • $binaryValue = $certificate.GetRawCertData()
    • $credentialsValue = [System.Convert]::ToBase64String($binaryValue)
    • New-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 -Type Asymmetric -Usage Verify -Value $credentialsValue -StartDate 2016-03-01 -EndDate 2016-12-31
    o start date should not be earlier that today, validity not longer than 1 year

    This should finish the process; to check, try this at the S4B Server

    Test-CsExStorageConnectivity -SipUri sip:user@domain.com

    $cred = Get-Credential
    Test-CsUnifiedContactStore -UserSipAddress user@domain.com -TargetFqdn skype.pool.fqdn -UserCredential $cred

    Target Fqdn : skype.pool.fqdn
    Result : Success
    Latency : 00:00:00.2444352
    Error Message :
    Diagnosis :

    Debug-CsUnifiedContactStore -Identity sip:martin.bene.test@icomedias.com

    UcsMigrationAttemptCount LastUcsMigrationAttempt SipUri UcsMode
    ———————— ———————– —— ——-
    295 02.03.2016 03:28:00 user@domain.com Migriert

    once these checks work, accessto the UCS from the S4B server should work and contact list on a mobile client should get populated even when using UCS.

  2. Martin, Adam,

    Came across these issues with UCS recently on a customer deployment. They were moving to Exchange Online, currently in a hybrid state, and had Skype for Business on-prem.

    By temporarily pointing the ExchangeAutodiscoverUrl in the SfB global OAuth config at Microsoft’s HTTP autodiscover URL (http://autodiscover-s.outlook.com/autodiscover/autodiscover.svc) instead of the customer’s on-prem autodiscover URL, they were able to perform a non-forced disabling of UCS for SfB on-prem users whose mailbox was in Exchange Online, with no loss of contacts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s