Exchange and Skype for Business Integration

September 14, 2015 by · 41 Comments 

This edition in a series of deployment articles for Skype for Business Server 2015  addresses the integration of an existing Exchange Server 2013 installation with a recently installed Skype for Business Standard Edition server.  The article outlines establishing the prerequisite partnership between each platform, allowing the Skype for Business server to leverage the Exchange Server database engine for storage of some types of data

Further configuration of additional features provided by this integration will be covered in later articles, as in Unified Contact Store, Exchange Unified Messaging, and Outlook Web App with Skype for Business Server 2015.  For each of these additional integrations the following Partner Application relationship must first be enabled in the environment.  An updated listing of only the articles specific to Exchange Server integration with Skype for Business Server 2015 can be found using this link

The sections in this article are outlined in the following configuration steps:

image.

Configure Autodiscover

In the event that Exchange Autodiscover is not correctly configured this could prevent the Skype for Business server and clients from being able to locate the Exchange server and thus cripple the ability to complete this integration.  The steps in this first section are optional and may not be required in all environments, so long as Autodiscover is correctly deployed.

In event that the existing autodiscover URL will be used then skip to the next section to configure OAuth.

Validate Configuration

  • Using the Exchange Server Management Console run the following Get-ClientAccessServer cmdlet to view the current Autodiscover configuration.  The Identity parameter cab be either the Exchange server’s hostname or the Fully Qualified Domain Name (FQDN).

Get-ClientAccessServer -Identity EXCH | Select-Object AutoD*

image

In this example environment the default configuration is still applied whereas the server name is utilized in the internal autodiscover URL.  This will be updated to use the well-known autodiscover record format which is generally an Exchange Server deployment best practice.

Most likely when the Exchange Server was originally deployed the Autodiscover option was selected which would have included the proper FQDN in the certificate request.  To validate this the following commands can be used to identify and parse the server certificate currently assigned to Exchange Server roles.

  • Using the Exchange Server Management Console run the following Get-ExchangeCertificate.

Get-ExchangeCertificate | Select-Object Subject,Services,CertificateDomains | fl

image.

As seen in the example above the desired certificate should be the entry with a FQDN in the Subject which is also assigned to at least the IIS service.  This example snows that the Subject Alternative Name (SAN) field of the certificate in use by IIS already includes the desired FQDN of autodiscover.jdskype.net.

Create DNS Records

If the following two DNS records do not already exist in the environment then they need to be created before modifying the Exchange configuration.  These are the two well-known DNS records that mostly autodiscover-aware clients will query when attempting to locate an Exchange Server.

  • Create a new Alias (CNAME) record in the proper SMTP/SIP namespace forward lookup zone, pointing to the Exchange Server FQDN.

image

  • Create a new Service Location (SRV) record using the following parameters, pointing this record to the CNAME record created in the previous step.

image

To validate the records were created successfully and are functional run the following two test commands from a command shell.

nslookup -q=srv _autodiscover._tcp.jdskype.net

_autodiscover._tcp.jdskype.net  SRV service location:
          priority       = 0
          weight         = 0
          port           = 443
          svr hostname   = autodiscover.jdskype.net

nslookup autodiscover.jdskype.net

Name:    exch.jdskype.net
Address:  192.168.0.101
Aliases:  autodiscover.jdskype.net

Update Autodiscover URL

  • Using the Exchange Server Management Console run the following set-ClientAccessServer cmdlet to update the configuration to use the new FQDN.  The Identity parameter should be the Exchange server FQDN, while the new Autodiscover FQDN replaces the server FQDN in the internal URL.

Set-ClientAccessServer -Identity EXCH -AutoDiscoverServiceInternalUri "https://autodiscover.jdskype.net/autodiscover/autodiscover.xml"

  • When the process completes perform a reset of Internet Information Server to immediately apply the change using the following iisreset shell command.  (If performing this in a production environment with active connections then it is recommended to use the /noforce switch.)

iisreset

Attempting stop…
Internet services successfully stopped
Attempting start…
Internet services successfully restarted

Configure OAuth

The Partner Application pairing provides the ability for the Skype for Business and Exchange servers to communicate with each other via an authenticated secure connection that does not require any third party system to negotiate or establish the session.

OAuth is the server-to-server authentication mechanism used between the Skype for Business and Exchange servers to establish secure communications.  During the initial SfB server deployment in this article an SSL certificate was created specifically for OAuth.

Before defining Exchange Server as a partner application Skype for Business needs to know about the Exchange Autodiscover configuration.

  • Using the Exchange Server Management Console run the following Get-ClientAccessServer cmdlet to query the existing internal autodiscover URL.  This is either the existing or newly defined value, depending on whether the previous section was skipped or not.

Get-ClientAccessServer -Identity EXCH | Select-Object AutoDiscoverServiceI*

AutoDiscoverServiceInternalUri
——————————
https://autodiscover.jdskype.net/autodiscover/autodiscover.xml

Pay special attention to the fact that the retrieved autodiscover URL points to an .xml file; this will be important in a few steps.

  • On the SfB server open the Skype for Business Server Management Shell and enter the following Get-CsOAuthConfiguration cmdlet.

Get-CsOAuthConfiguration

image

The ExchangeAutodiscoverUrl parameter should be blank as it has not yet been defined.

  • Enter the following Set-CsOAuthConfiguration cmdlet to define the Exchange autodiscover location as shown below.

Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl https://autodiscover.jdskype.net/autodiscover/autodiscover.svc

In contrast to what was pointed out earlier the path provided above must end with .svc and not .xml.  This is a minor detail not specifically called out in the TechNet documentation but can easily be missed, especially if cutting and pasting these strings between steps.

  • Run the Get-CsOAuthConfiguration cmdlet again to verify the new parameter value is applied as intended.

Get-CsOAuthConfiguration

image

Configure Exchange Server

Enabling the partner application relationship requires that some configuration is performed on both side.  Starting with the Exchange Server configuration pre-packaged script will be called while passing a few parameters.  Before executing the script

  • Identify the proper path for the Skype for Business server authentication metadata document.  This URL should be identical to the following format, utilizing the SfB Front End server FQDN.

https://fe.jdskype.net/metadata/json/1

  • Connect to this URL in a web browser from the Exchange Server to validate connectivity which should result in a prompt to open or save a file simply named ‘1’.

image 

  • Open the file using Notepad to view the contents, which should start with a x509 certificate string and end with the OAuth realm.

{"issuer":"00000004-0000-0ff1-ce00-000000000000@jdskype.net","keys":[{"keyValue":{"type":"x509Certificate","value":"MIIF2TCCBMGgA…

…xSTGd1KHw=="},"usage":"signing"}],"realm":"jdskype.net","serviceName":"00000004-0000-0ff1-ce00-000000000000"}

  • Open the Exchange Server Management Console on the Exchange Server and change to the Scripts directory by  using the following command.

cd c:\’Program Files’\Microsoft\’Exchange Server’\V15\Scripts

  • Then execute the Configure-EnterprisePartnerApplication.ps1 script using the following command.

.\Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrlhttps://fe.jdskype.net/metadata/json/1′ -ApplicationType Lync"

image

  • To complete the changes restart Internet Information Services using the iisreset command.

iisreset

image

Configure Skype for Business Server

To complete the pairing a new partner application will also need to be defined on the Skype for Business side.

    • Identify the proper path for the Exchange server authentication metadata document.  This URL should be identical to the following format, utilizing the SfB Front End server FQDN.

https://autodiscover.jdskype.net/autodiscover/metadata/json/1

    • Connect to this URL in a web browser from the Skype for Business Server to validate connectivity, which should look similar to the results the previous section.

image

  • Using the Skype for Server Business Management Shell enter the following New-CsPartnerApplication cmdlet to define the other half of the association.

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.jdskype.net/autodiscover/metadata/json/1"

image

Verify Connectivity

To validate that the partner application relationship has been successfully established a simple cmdlet can be run from the SfB Server.

  • Enter the following Test-CsExStorageConnectivity cmdlet, providing the SIP address of a user account which has already been enabled for Skype for Business.  (The -Verbose parameter is optional and is used here to display additional information about the test process.)

Test-CsExStorageConnectivity -SipUri "sip:jeff@jdskype.net" -Verbose

image

image

If the test cmdlet fails to return a successful result of “Test Passed”  then here are a couple of the most common issues.

  • In the event that the Skype for Business OAuth configuration was previously defined with an incorrect ExchangeAutodiscoverUrl parameter, as could happen by accidentally using .xml instead .svc for example, then the following error may occur.  In fact if this parameter is null or invalid in any way then this error can occur.

Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=50043,

To resolve the above error define the proper ExchangeAutodiscoverUrl in Skype for Business server using the Set-CsOAuthConfiguration cmdlet as outlined earlier in this article.

  • If the AD user account which is used to execute the test cmdlet does not have the correct permissions then the process will fail with the following error being reported.

Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=5,

To resolve this issue follow the directions outlined in this TechNet article to add the account to the RTCUniversalUserAdmins universal security group.

Now that Exchange Server has been successfully integrated with Skype for Business Server then additional features can now be deployed.  An updated list of articles covering other Exchange Server integration options can be found here.

About Jeff Schertz
Site Administrator

Comments

41 Responses to “Exchange and Skype for Business Integration”
  1. CypherBit says:

    Great series. Would you be so kind to outline what features are available and which are missing if using Exchange 2010.

  2. Andrew Exley says:

    Hi Jeff,

    Great blog! Recently discovered it as we are establishing a new Skype for Business with Polycom handsets environment and I’m finding some great material here.

    One thing I’m trying to find out is I have two users who jobshare a desk with a VVX500. They find the having to enter email, domain and password credentials each time the switch a reasonable overhead. Is there a smarter way to simplify this that you know of?

    Kind regards,
    Andrew

    • Jeff Schertz says:

      Not currently as only a single user account is supported. When Hotdesking support is added to the VVX then one user will be able to sign-in over the other when needed.

      • AUR says:

        We have just deployed a number of LRS systems. One system and only one system will not accept meeting requests unless it initiates the request first. This is the same for lync meetings booked on outlook calendars or if we use the “meet now’ from the console. Any idea what we should look at to try to resolve this issue? The csmeetingroom info is the same for this room as our other rooms. The exchange client looks the same.

        Ideas?

  3. ABK says:

    This is another great post, thanks Jeff.

    Quick question, Have written any instruction on Skype for business (on-prem) with Exchange (online) you can point me to or a summary differences in configuration between the two (exchange online or on-premises and S4B on prem.)?

    Thanks Jeff

    • Jeff Schertz says:

      If Directory Sync is being used in the environment and the user’s credentials are identical for both the on-premises SfB and Exchange Online servers then just use the UPN as the username (not DOMAIN\username) and that should work. I have not tested this scenario myself yet though.

      • Off2w0rk says:

        Hi Jeff and thanks for great post. We have Exchange online and Lync server 2013. With this setup it worked fine, we just had to add CShostedprovider to Exchange online. It have been working fine until we did in place upgrade to SFB. Now Test-CsExStorageConnectivity fails for users in Exchange Online, but for users with mailbox On-Prem it works fine. I have removed everything and created it from scratch , but still it only works for On Prem mailboxes.
        We had a case with Microsoft, but they say it is nothing they can do and we have to contact Exchange Online support.
        Contacted them and they threw us back to Skype support.
        I have therefor given up Microsoft support and have to find a way to fix it. All test according to your guide works fine (can browse both autodiscover and FE pool svc).
        When we run Test-csexstorageconnectivity for Exchange online mailboxes it fails with 50043.
        Does Skype for Business require another Autodiscover ?

        thanks!

        • Jeff Schertz says:

          I’m not aware of this issue but MS support should not be bouncing you back and forth between groups. I suggest that you push back on them for a resolution. If it’s only the test cmdlet that does not work but the actual user functionality is there then I would not worry about it. I’ve seen scenarios where only the test cmdlets do not function as designed.

        • Chris says:

          I’m having the same issue with Exchange online and SfB on Premise. Did you find a solution?

          Thanks

        • Tyler Largin says:

          Actually, I know what this is.

          See when you run Test-csexstorageconnectivity, you use the OAUTH connection. What you need to do, is take your oauth certificate in your lync on-prem server, Export it into Exchange online and tada it should work. As long as you have your on-prem and you online setup to work together.

          This is also the same process you use to make outlook.office365.com’s web lync sign in actually function.

          The process is similar to this

          https://support.microsoft.com/en-us/kb/2614242

          and this

          https://technet.microsoft.com/en-us/library/dn594521(v=exchg.150).aspx

  4. Curious Skype Admin says:

    Hi Jeff,

    I’ve been searching all over for information regarding the 2016 Client and GAL searching.

    I’m building a POC for a 2010 Exchange and 2015 Skype for business server and while I can manually add approved Skype users in my environment, I cannot “discover them” by going to add users. I only get my local outlook contacts.

    What’s the easiest route to getting pre-populated AD users in my Skype client? Is there a way to do it without exchange integration or is that the only way to do it?

  5. Ricardo says:

    This is another great post, thanks Jeff.

    I was trying to configure the step “Configure Skype for Bussiness Server”, and I can validate connectivity in a SFB Wer Browser, but the IE get Certificate Invalid… and I click on “Continue to this Web Site (note recommended)” and the results is similar the previous section.
    when I tried to create an New-CsPartnerApplication, it got this error:

    PS C:\Users\Administrator.TECNOPUTER> New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl “https://autodiscover.tecnoputer.com.br/autodiscover/metadata/json/1”

    New-CsPartnerApplication : Cannot bind parameter ‘MetadataUrl’ to the target.
    Exception setting “MetadataUrl”: “The metadata document could not be
    downloaded from the URL in the MetadataUrl parameter or downloaded data is not
    a valid metadata document, error: The underlying connection was closed: Could
    not establish trust relationship for the SSL/TLS secure channel.”
    At line:1 char:86
    + … l -MetadataUrl
    “https://autodiscover.tecnoputer.com.br/autodiscover/metadata/jso …
    +
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : WriteError: (:) [New-CsPartnerApplication], Para
    meterBindingException
    + FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Rtc.Management.
    Internal.NewPartnerApplicationCmdlet

    Do you know how to fix that?

    Rgds,

    Ricardo.

  6. Milan says:

    Hi Jeff,
    love reading your posts. It helped me a lot in past.
    I have one problem and I cannot figure out what the issue is.
    I have Exchange 2016 Lync 2013 environment and I have issue with SfB 2016 Client. I cannot establish MAPI connection with 2016 client and 2015 works without any flaws. I was wondering if you could get any pointers where I should be looking.

    Thanks

    Milan

  7. Han ten Hage says:

    Great post thanks.

    We have Exchange 2013 and Lync 2013.
    The integration works fine.

    We are now upgrading to Skype for Business 2015 (using a new pool, not inplace upgrade).

    However what do I do with the Exchange 2013 servers?
    In the Skype topology I can move them to the new pool.
    But what do I run on these Exchange 2013 (we have 5) servers?

  8. krishnaDas says:

    Great post Jeff..Thanks a lot

  9. John Murray says:

    Hi Jeff – you information has been invaluable to us.

    We’re stuck at the exchange script:

    .\Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl ‘https://fe.jdskype.net/metadata/json/1′ -ApplicationType Lync”

    is that trailing quote correct? we’ve tried it both ways and also added the -domaincontroller parameter (shown in the image) as well, we just end up with a:

    >>

  10. Sagir says:

    Hi Jeff,

    Very well explained
    Just FYI…there is something wrong in the command because I also encountered and was stuck as “John Murray” post entered .\Configure-EnterprisePartnerApplication.ps1 without parameters and filled in prompts – worked fine me as well.

    Many thanks,

  11. Great article Jeff. Really helpful.

  12. Jeff V says:

    We are having an issue that nobody seems to understand how to correct. We are using a telco hosted Lync 2010 server with Lync 2013 clients. We are in the process of upgrading to Office 365 and installed Skype for Business using the Lync completeuc.com credentials to get phone presence. We are unable to see in call or meeting presence on any of the new users migrated over to the Skype for Business client however have a few that are still working correctly. We deleted all the old SIP profiles and did not solve the issue. Have you seen this before and does anything come to mind?

  13. John says:

    One thing that’s not obvious (to me) is that when the script is run on the Exchange server, it shows entering the FQDN of “the” front end server. Does it matter if we have multiple FE servers? Or even multiple pools? Do I run the command for each FE server? Or is adding one of the FE servers just a starting point for the script to load everything it needs?

    Also, does this script need to be run on each Exchange server? Or do I just need to run it once for the environment? If I run it once do I need to do the iisreset on each Exchange server?

    Thanks for the great information.

  14. Mohamad says:

    Dear Jeff Schertz

    thank you very much for your training . Im mohamad From iran And test your Step. I get at the end of test “” Test Passed”” & now im very happy .with the best wishes for you And we are waiting for your next training.

    Good luck
    mohamad

  15. Howie says:

    Hey Jeff,
    Redid my enviorment upon trying to integrate skype for biz with exchange 2013.
    when I try to go to my front end
    l”https://lrs-s4bfe.domain.com/metadata/json/1″ -ApplicationType Lync
    I get a cert error when I go to it in a browser it does download “1”
    Cannot acquire auth metadata document from ‘https://lrs-s4bfe.domain.com/metadata/json/1’. Error: The
    underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel..
    cert issue?

  16. Steve says:

    Hey Jeff,
    Great article. We are deploying Exchange 2016, and we are looking at Skype For Business online and sharepoint online. Is there any way to integrate this that you are aware of? From what I have been able to find it appears we can’t integrate S4B online (365) with on prem exchange 2016. Is this correct? any work around to make it work?

    Thanks

  17. LyncAdmin says:

    Hi Jeff,
    Was there a purpose why Lync FE FQDN and realm was written with the same colour even they were not the same? How these things are actually working, if you have multiple SIP domains?

  18. Ramin says:

    This is another great post, thanks Jeff.

    I was trying to configure the step “Configure Skype for Bussiness Server”, and I can validate connectivity in a SFB Wer Browser, but the IE get Certificate Invalid… and I click on “Continue to this Web Site (note recommended)” and the results is similar the previous section.
    when I tried to create an New-CsPartnerApplication, it got this error:

    PS C:\Users\Administrator.TECNOPUTER> New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl “https://autodiscover.tecnoputer.com.br/autodiscover/metadata/json/1”

    New-CsPartnerApplication : Cannot bind parameter ‘MetadataUrl’ to the target.
    Exception setting “MetadataUrl”: “The metadata document could not be
    downloaded from the URL in the MetadataUrl parameter or downloaded data is not
    a valid metadata document, error: The underlying connection was closed: Could
    not establish trust relationship for the SSL/TLS secure channel.”
    At line:1 char:86
    + … l -MetadataUrl
    “https://autodiscover.tecnoputer.com.br/autodiscover/metadata/jso …
    +
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : WriteError: (:) [New-CsPartnerApplication], Para
    meterBindingException
    + FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Rtc.Management.
    Internal.NewPartnerApplicationCmdlet

    Do you know how to fix that?
    Pleeeeeeeeeeeease Answer

  19. Russell Allen says:

    Jeff great post. I am having some issues at this point. I get all the way through to the test of the Test-CsExStorageConnectivity -SipUri “sip:jeff@jdskype.net” -Verbose and it fails. The error says the certificate has validation failed.

    My environment is as follows

    Skype 2015 for Business with latest updates (standard with cert issues from local CA)

    Exchange 2016 with latest update (self signed cert)

    Should I be able to integrate with these?

  20. Jessie says:

    I cannot access https://Pool FQDN/metadata/jaon/1 on either SFB server or the Exchange server, it returns HTTP 404 not found. Would you pls help?

  21. Hi,

    I’m trying to execute the new-cspartnerapplication and get an error that it cannot bind metadataurl. I think that the issue come from the fact that i’m using the self signed exchange certificate. Am i supposed to get a trusted certificate when i open the url autodiscover.mydomain.com/… ?

    Right now i only have the three defaul certificate and nothing with the autodiscover url.

    Thanks for your help.

    • Jeff Schertz says:

      Yes you must use a server certificate issued by a jointly trusted CA to allow SfB and Exchange to communicate via TLS, self-signed certificates are not valid for this integration.

  22. Dan A says:

    Hi, I assume the process is the same for connecting to Exchange 2010. Are the commands in this guide valid for that, or can you point me to a resource for integrating Exchange 2010 and SfB 2015? I realized some features will not be present.

    Thanks

    • Jeff Schertz says:

      Dan, the process for Exchange 2010 is slightly different due to changes on the Exchange side more than on the Lync/SfB side. I’d suggest using both of my articles together, side-by-side, to achieve this. I have not attempted it and haven’t even looked to see if it is supported either. There would only be a few differences at most though.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!