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:

.

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*

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

.

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.

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

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

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

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’.

• 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 -AuthMetaDataUrl ‘https://fe.jdskype.net/metadata/json/1′ -ApplicationType Lync"

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

iisreset

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.

• 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"

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

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.