Managing Certificates in Exchange Server 2013 (Part 4)

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

Introduction

So far in our series we defined the certificate type, and prepared the server and environment to support it. In our last article we requested and installed the certificate while, in this article we will start configuring the URLs of Exchange services to match those two names that we defined in our Certificate.

Configuring Exchange Server 2013 to use the new Certificate…

Our first step is to configure Outlook Anywhere for internal and external clients. Using Exchange Admin Center, log on to ECP (at this point we can type in https://webmail.AndersonPatricio.info/ECP), click servers on the left side and then select the server and click edit.

On the new page, click Outlook Anywhere on the left and type in webmail.AndersonPatricio.info in both fields and use Negotiate since we have only Exchange Server 2013 running in our forest. Click save, and we will receive a warning informing us that negotiate authentication only works when all servers are Exchange Server 2013, click OK (Figure 01).

Note:
If you are using this article series with legacy Exchange Servers in the same Exchange Organization, use the NTLM or Basic authentication methods.

Image
Figure 01

Just to be on the safe side, we can run  iisreset /noforce to refresh the settings just applied. At this point if we log on a client machine and create a new profile we are going to get some certificate errors however the profile creation will work just fine. The certificate errors are related to webservices and autodiscover and we will tackle that in our next section of this article.

Managing URLs to support the new certificate…

Right now, we have our new Public Certificate installed on Exchange Server 2013 but our current Outlook clients are getting at least the same amount of certificate error messages and that is true because we have not configured Exchange Server to use the new certificates based on our design.

In order to adjust Exchange Server we need to configure three major sections of the Client Access Server role, as follows:

  • Autodiscover
  • External URLs
  • Internal URLs

Before configuring these sections, we will very quickly go over two great tools that will help us from now onwards: Test E-mail AutoConfiguration and Exchange Connectivity Analyzer (for external tests).

For all internal testing, we will use the Test E-mail AutoConfiguration tool. This tool comes with any Outlook client, and in order to use it just hold the Ctrl button and right-click the Outlook icon on the systray. Then, click Test E-mail AutoConfiguration as shown in Figure 02.

Image
Figure 02

The tool (if we can call it a tool) is a single window (Figure 03) where the e-mail address of the user is filled out automatically and to test the Autodiscover, you need to make sure that the options Use Guessmart and Secure Guessmart Authentication are unchecked. Then click Test. The tool also offers three tabs where we can see the results being received by the clients (Results tab); in the Log tab, we can check the Autodiscover process. The XML tab shows the content of the information received from the Autodiscover.

Image
Figure 03

For all external access, we are going to use www.EXRCA.com which is the Microsoft Remote Connectivity Analyzer (Figure 04). This tool allows the UC administrator to test not just Exchange Servers but also Lync and Office365.

Image
Figure 04

Configuring Autodiscover…

The Autodiscover component is a vital one because this service is able to provide Outlook configuration for Outlook 2007, 2010 and 2013, and other end-points (ActiveSync devices) as well. The Autodiscover has two parts to configure: the internal one that affects domain-joined machines. This type of clients will use SCP (Service Connection Point) which is stored in Active Directory to find their information. All external clients and ActiveSync will use DNS to connect to the service.

The Autodiscover service, besides of the automatic Outlook profile configuration will also provide OAB, Web Services and Unified Messaging information to the clients.

Let’s step back a little before configuring this service. At this point of this article series we replace the default certificate for a public certificate and if we try to configure a new Outlook profile we will get an error similar to the one in Figure 05. The reason is that the names listed in our new certificate do not have the names configured in the SCP object (in Figure 05 we are using a domain-joined computer).

Image
Figure 05

In order to configure your internal network domain-joined machines you can run the following cmdlet to retrieve the current information: Get-ClientAccessServer | ft Identity,*uri* -AutoSize, as shown in Figure 06.

Image
Figure 06

Remember that in our internal DNS zone of the Public domain we created two entries pointing to the same IP (since we have a single Exchange Server so far) and those were autodiscover.AndersonPatricio.info and webmail.AndersonPatricio.info. So, at this point it does not matter which one we use but for the sake of personal organization, I will go ahead and use the autodiscover.AndersonPatricio.info.

Note:
You should use the same information for all servers on the same Active Directory site; you will remember this note when you add a new server where it will require the same configuration to avoid certification errors on the client side.

To configure the Autodiscover internally, we need to run the following cmdlet: Set-ClientAccessServer –Identity <Exchange-Server> -AutoDiscoverServiceInternalUri https://<Name-that-exists-on-the-certificate/Autodiscover/Autodiscover.xml. In Figure 07, the cmdlet lists the values to make sure that the settings were applied and that we have not made any mistakes when typing in the URL.

Image
Figure 07

In order to test, we just need to go to any domain-joined machine and create a new profile. We should not receive any certificate warnings during the Outlook profile creation and the results will be similar to those shown in figure 08.

Image
Figure 08

Well, my curiosity goes beyond that first test so I will use the Outlook tool to make sure that the changes that we have done are being used. After logging on to an Outlook client we can use the Test E-mail AutoConfiguration tool and hit the test button. We can check the results on the Log tab and the name listed there should be the name that we have just configured in the previous step, as shown in Figure 09.

Image
Figure 09

For external users the Autodiscover has several options. When we try to configure a new Outlook profile on a computer outside the network, the client will search the following addresses to retrieve Autodiscover:

  • https://AndersonPatricio.info/Autodiscover/Autodiscover.xml
  • https://autodiscover.AndersonPatricio.info/Autodiscover/Autodiscover.xml
  • http://autodiscover.AndersonPatricio.info/Autodiscover/Autodiscover.xml
  • Retrieve SRV information from _autodiscover._tcp.AndersonPatricio.info

There are plenty of options to choose from when the topic is Autodiscover; however in our scenario we will be using a simple one that is the autodiscover.AndersonPatricio.info. This one requires just a single entry in your Public DNS pointing to the Exchange Server and we will be good to go.

Note:
The suggestion in this article is based on a simple scenario. If you have multiple SMTP domains or any other requirements, a link with the official documentation from Microsoft is listed at the end of this article.

Logged on to your external DNS, just create a new A host for Autodiscover and point to the Public IP (Figure 10) that Exchange will be using (by this time your firewall should have Exchange published using port 443).

Image
Figure 10

Give some time for the DNS replication to take place, and then use ExRCA.com and select the Outlook Autodiscover test from the main page. Fill out the information of a test account, and the results should be similar to those shown in Figure 11.

Note:
Use a test account for security reasons; make sure that this test account has the SMTP address of the domain that we are testing the Autodiscover. Another interesting point is that the ExRCA will test first the https://<domain>/Autodiscover/Autodiscover.xml and it will fail because we do not have that information in our DNS which is okay. Just make sure that all tasks listed underneath https://autodiscover.<domain>/Autodiscover/Autodiscover.xml do not show any errors or warnings.

Image
Figure 11

Conclusion

After installing the public certificates, we focused on Outlook Anywhere and Autodiscover components to use the new certificate.

More Information about Autodiscover is available here:

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top