If you would like to read the other parts in this article series please go to:
- Managing Certificates in Exchange Server 2013 (Part 1)
- Managing Certificates in Exchange Server 2013 (Part 2)
- Managing Certificates in Exchange Server 2013 (Part 3)
- Managing Certificates in Exchange Server 2013 (Part 4)
- Managing Certificates in Exchange Server 2013 (Part 5)
In our series we went over the creation process of the certificate, and how to configure Exchange Server to take full advantage of the new certificate using just a couple of names. In this article, we are going to increase the complexity of the existent environment by adding a new Exchange Server to the mix and configuring a DAG between those two servers. All changes required to add this new server and configure fault tolerance on the Certificate side will be covered in this article.
In Figure 01, we can see the proposed changes with the new server (BsAEX02) and the names that are already in the certificate that will be shared between those two servers.
Figure 01
What does it change for the Public Certificate? Well, it is not a matter of a completely new design but we need to prepare well for such a change. For any new server we need to perform the following main tasks:
- Configure Autodiscover on the new server
- Plan the DNS Changes
- Export the certificate from an existent server
- Import the certificate on the new Exchange Server
- Configure Exchange Services
– Outlook Anywhere
– Outlook External URLs
– Outlook Internal URLs - Change DNS
- Test the new solution
Configure Autodiscover
We had this issue at the beginning of this series when we changed the certificate, and any new Exchange Server 2013 will provide its default address for the SCP which is similar to this: https://<Server-FQDN/Autodiscover/Autodiscover.xml. That may create some certificate warning on your clients if a new client gets that information from the new server.
To reduce the changes of that happening, after finishing the installation of a new server, just run the following cmdlet:
Set-ClientAccessServer –Identity <New-Server-Name> -AutoDsicoverServiceInternalUri https://Autodiscover.AndersonPatricio.info/Autodiscover/Autodiscover.xml where AndersonPatricio.info should be replaced by your domain.
When running Get-ClientAccessServer | ft Identity,*Uri –AutoSize the output should be similar to the one shown in Figure 02.
Figure 02
Note:
There is no requirement to have the certificate installed and configured to perform the cmdlet above. The cmdlet just updates the SCP object for this server to send the same information that has been configured on all production servers. When this new server is moved to production by changing the DNS settings then the certificate will become a requirement.
Planning the DNS Changes…
It all boils down what kind of solution our company will use to Load Balance the traffic among the servers. Since we have only two servers, we have a couple of options, as follows:
- Add a Load Balancer in front of this new DAG and that server will be responsible to balance the traffic among those servers
- Use DNS round-robin and when a server goes down the client will have a brief disconnection and after a few seconds the connection will be re-established
The recommended and neat solution is the Load Balancer, but some companies can live with a failure for a few seconds and that is going to be the procedure that we will be working on in this article.
If your company decided to go for a Load Balancer then in theory after going through steps 2 to 5 from the previous list you just need to point out your two names (Autodiscover and webmail) to the VIP (Virtual IP) of the Load Balancer and all your clients will be taking advantage of the Load Balancer.
If you decided to use DNS the process is simple, just create a second A record for both Autodiscover.AndersonPatricio.info and webmail.AndersonPatricio.info on your internal DNS pointing out to the new Exchange Server and you will have the fault tolerance in place, however we are going over more details in a little bit further on.
Managing a Public Certificate among Exchange Servers
In this section we are going over the process to import and export certificates in Exchange Server 2013. First, logged on to Exchange Admin Center, click on servers and then certificates. From the selected server we are going to select the first server and a list with all certificates will be displayed, click on the Public Certificate that is in use and then click … (more options) and Export Exchange Certificate (Figure 03).
Figure 03
On the new page, we are going to use the same Shared Folder that we created in the third article of this series (ExchUtil$), and in the same field we are going to specify a name for the exported certificate and a password, as shown in Figure 04.
Figure 04
The result of this process is a new file created in the shared folder and we can use the file to import the Public Certificate of different servers.
Time to import the certificate to the new server (BsAEX02.apatricio.local), click … and then Import Exchange Certificate, as shown in Figure 05.
Figure 05
On the new page we need to specify the location of the shared folder for that initial exported certificate and the same password used in that process, after that click Next (Figure 06).
Figure 06
On the following page, we can click the Add (+ icon) and add one or more servers that will have this certificate imported and installed locally. In our scenario, we are going to add in just one new server and then click finish. (Figure 07)
Figure 07
Configuring the Certificate on the new server…
Now, that we have the certificate up and running on the new server, we need to perform some of the tasks that we have already done in the previous articles. In order to refresh your memory we listed the steps and in which article we covered such topic, as follows:
- Configure Outlook Anywhere (we covered this topic in the fourth article of this series)
- Configure External URLs (we covered this topic in the fifth article of this series)
- Configure Internal URLs (we covered this topic in the fifth article of this series)
Configuring DNS
This is the easy part… initially we had BsAEX01 (IP 10.60.99.225) in the environment and all clients were using it just fine. After introducing BsAEX02 (IP 10.60.99.227) we went over the previous steps and we configured the certificate and URLs for that new server which means that the new server is ready to move into production.
In order to move this new server into production we need to create another set of autodiscover and webmail entries in the internal DNS pointing out to the new server. The result of this operation will be similar to Figure 08.
Figure 08
Testing the solution….
We have an Outlook client connected to the system just fine. Since we are sharing the same name with both servers we don’t know for certain which server the workstation is communicating to and to identify it we can run netstat –an | find “:443”.
The results can be seen in Figure 09, and it is clear that the workstation is connected to 10.60.99.227 which means BsAEX02 server at this moment. In order to test it, we are going to bind down the server BsAEX02 to test our fault tolerant solution (logged on to the server, just type in Stop-Computer in PowerShell to shut down the server).
Figure 09
Our server went down and with it the connection of the Outlook client, as shown in Figure 10. However that status will stay like that until the client times out and after that a new connection will be established with the remaining operational server.
Figure 10
We can see the SYN_SENT when the connection was lost, and then after a few seconds I ran the same command and the connection was established with the remaining operational server. Then, Outlook client just went back online as shown in Figure 11.
Figure 11
Conclusion
In this final article of our series, we covered the process to manage the certificate among Exchange Servers to support high availability and fault tolerance scenarios.
If we look back at our 6 (six) articles we had a simple environment using default settings and we designed public certificates, and from that point on we installed the certificate, configured all the main Exchange Services for a single server and afterwards we stretched the same configuration for a high available scenario.
Is that it for Certificates in Exchange Server 2013? Definitely not, we only went over the main features using public certificates, but we also have POP/IMAP/SMTP/ADFS services that can take advantage of Public Certificates but that is going to be topic for another series or perhaps an extension of this one.
If you would like to read the other parts in this article series please go to:
Great useful article . Thanks !
Many Thanks!
Really a good topic, i hope you continue publish a interesting things like hybrid connection with Exchange 365
troubleshooting certificate issue .. etc