Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 1)

If you would like to read the other parts of this article series please go to:

• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 2)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 3)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 4)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 5)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 6)

Introduction

The original idea for this series was to cover the entire deployment and integration process in a single series, including initial planning, deployment, integration and so forth. However, the decision was to create two separate series: Skype for Business Server 2015 deployment and the current series that we are starting now which will cover only the integration between Exchange and Skype for Business Server.

In this initial article of our series, we describe in some detail the scenario that was used to build this series, and by doing that the reader can compare the settings that we have in production with their own environment. The series is organized in seven (7) articles and each of them will cover one area of the integration (Figure 01).

Figure 01

The word integration nowadays can be deceiving because we can have integration between different products like Exchange/Skype for Business/SharePoint and within the same product when using Office365. The integration between Skype for Business on-premises and Office365 are going to be covered in a future article here at MSExchange.org.

The current scenario…

A new series covering the Skype for Business Server 2015 deployment process will be available here at MSExchange.org for those that want to check all the steps performed to get to this point. If you already have an environment with both products, then you can take advantage and start applying the integration right away, if you are waiting to deploy Skype for Business Server 2015 then you can start familiarizing yourself with the integration that will be required after the initial deployment.

The current scenario (Figure 02) has a single Exchange Server 2013 (TOREX01) and a single Skype for Business Server 2015 (TORSB01), and two domain controllers (TORDC01 and TORDC02), and a server holding the PKI infrastructure (TORCA01).

Figure 02

All servers and users are on the same forest (that is important when integrating Exchange and Skype for Business, because when we have more than one forest, some additional steps may be required for some tasks).

Certificates

The certificates play a key role in the integration and are required to establish the proper security with the clients. Nowadays the vast majority of communication is done through certificates.

In order to avoid headaches, a valid certificate from Public Certification Authority is in use by Exchange Server 2013 (TOREX01), and the type of certificate is the UC/SAN, which accepts multiple names on the same certificate.

The Exchange Organization has a single domain name which is patricio.ca and that is the Primary SIP domain in Skype for Business Server topology. The names that are in use in the Exchange Certificate are listed below:

• Autodiscover.patricio.ca
• Webmail.patricio.ca
• Adfs.patricio.ca
• Smtp.patricio.ca

Note:
The adfs and smtp entries were not required as they were added to the existent certificate and will be used for Active Directory Federation Services and Secure SMTP communications. For a simple environment, only using the first two entries will be enough from the Exchange perspective.

The Skype for Business Server 2015 is using the internal PKI for all certificates, and based on the best practices of the product, only the Edge Server and Reverse Proxy roles will require Public Certificates.

Additional certificates will be required for the integration, and we will cover that in the upcoming articles of this series.

Exchange Web Services configuration…

Just requesting the certificate is not enough in Exchange Server 2013, and after deploying the Public Certificate, the Exchange Server was configured to use the following address https://webmail.patricio.ca on either internal or external URLs.

The Outlook Anywhere was configured to use the same hostname webmail.patricio.ca for either internal or external access.

The autodiscover service was configured to use the same webmail.patricio.ca. Some administrators prefer to configure this entry as autodiscover.domain.ca in the SCP (Service Connection Point) but personally I prefer to have one single name for small deployments because as soon as you change the pointer of that DNS record, all other services go with it. Here is the cmdlet used to configure the autodiscover:

Get-ClientAccessServer | Set-ClientAccessServer –AutoDiscoverURI https://webmail.patricio.ca/Autodiscover/Autodiscover.xml

In order to make sure that everything was working after configuring the web services, a test user was created to test the Outlook auto-configuration, and the result was a new profile being created automatically without end-user intervention. All tests used domain joined workstations located in the internal network.

Note:
In the Managing Certificates in Exchange Server 2013 series here at MSExchange.org, we covered all the steps to request and configure a certificate.

DNS Configuration…

When the Active Directory is created the administrator has the opportunity to define the DNS namespace, and that initial decision will define what steps are required to configure in the Exchange and Skype for Business integration.

Public Certificates are based on the DNS names and they cost money, hence the goal is to reduce the number of names on a certificate, and for that reason, DNS configuration becomes a key point. Since we should not have Public Certificates assigning certificates to non-routable domains, it then becomes crucial to accommodate only public names for all valid certificates.

There are 3 (three) possible scenarios to have the DNS configured (Figure 03) and any of those scenarios will support the integration.

Figure 03

The first one on the left is Public Domain where the valid domain on the Internet is the same on the internal network and that is a no-brainer, the administrator just needs to add the new hosts in that zone. The second option is the split-brain DNS where the internal domain uses a non-routable domain (such as patricio.local) and in that case, the administrator creates the valid domain internally (patricio.ca) and adds all the names on that new zone. The third option is Pinpoint DNS where instead of creating a completely new zone, the administrator creates a zone for each host and configures that accordingly.

In this series, we will be using split-brain DNS, although it requires a little bit of extra work at the beginning by matching the existent hosts/entries in the external DNS with the internal DNS, but at the end of the day, it is easier to manage it.

Firewall configuration…

The goal of this series is to enable the integration and for that reason there is no Firewall configuration, however, in a real scenario, the administrator has to enable external clients to connect on Exchange Server and Skype for Business will require a DMZ and servers (Edge and Reverse Proxy) to support the external access and federation.

Conclusion

In this first article of our series about Skype for Business and Exchange Server 2013 integration, we covered the scenario where we are going to be configuring the integration and covered some of the key areas: certificates and DNS configuration.

If you would like to read the other parts of this article series please go to:

• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 2)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 3)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 4)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 5)
• Integrating Exchange Server 2013 and Skype for Business Server 2015 (Part 6)