Managing Certificates in Exchange Server 2013 (Part 1)

In this article series, the author explains the process how to manage certificates for any new or
existent Exchange Server 2013 deployment.
Since the release of Exchange Server 2007, certificates became an important component of any
new deployment of Exchange Server. In fact, they are a hot topic for administrators in forums
and blogs.
In this series, we will go over the process of helping you to decide which certificate fits best your
environment, and from that point on we will install and configure certificates in a typical
Exchange environment.
Since I mentioned the Exchange Server 2007 release as a turning point for the Certificate topic in
the Exchange world, I would like to point out a couple of changes as follows:

Office 365/Azure is a big driver and it requires certificate(s) for transition and authentication
processes
Exchange Server 2010 introduced a new interface to help us manage certificates
Exchange Server 2013 introduced EAC (Exchange Admin Center) to manage certificates
Exchange Server 2013 has a new architecture which requires less certificates, we can have a
main site and a Disaster Recovery site using just a few names
Due to Security the Internal Names and non-public names on certificates are going away from
most of the Public CA in the near future.
More Information can be found here.

In this first article we are going to give you some information to help you take a decision about
which certificates you have available, and as part of this series we will start simple with a single
server environment. Afterwards, we will give you some hints on how to extend the environment
maintaining the same number of certificates.

What type of certificate?

We have three options to choose from when dealing with certificates: Public CA, Internal CA or
self-signed. Each option has its implications and we are going over the key points of each type of
certificate to help in the decision process.

Public Certificates:
This is the best option for any size of organization for a couple of simple reasons: they work in
the vast majority of clients computers (Linux, Apple and Microsoft joined or non-joined to the
domain); the device configuration is seamlessly for the end-users and the same applies for
mobile end-points such as iPhone, iPad, Android, and Windows Mobile.
Internal Certificates issued by an Internal CA Authority:
They are a possibility but may create issues because any client that does not trust that CA will
have certification issues and it will affect Mobile devices and machines that are not joined to the

domain. An Internal CA requires design and best practices to work in your Exchange Server
environment. It can be used for several other applications.
Self-signed certificates:
They are the worst because they are not trusted by anybody except the Exchange Server 2013
that created them during the installation process. In order to make them less painful for your
internal clients you need to add them to the GPO but you will have the same issues with nonjoined computers and mobile devices. By default, Outlook Anywhere will not work for any client
using this type of certificate and the same applies for mobile end-points besides of the usual
certificate errors that you will get on your Outlook client.

Based on the previous explanations you may have realized by now that our recommendation is to
use Public Certificates! Are you still not sure? If you are going to use Office365, Active
Directory Federation Services and so forth, you can always add the additional name on your
Exchange Certificate and you will be good to go.
The second reason is that they are easy for the end-users. Let us imagine a scenario where one of
the executives is trying to connect his new personal tablet or even a PC from an external
location. Because of the certificate errors a manual intervention is required. Depending on your
executive profile you may have an issue right off the bat for him to waste time in a simple task as
to configure a client.
This article series will use a Public Certificate however, you can continue reading in case you
have decided to use Internal CA because the process will be the same. The only difference will
be the configuration to accept the new certificate on the end-points.

If using a Public Certificate What type of Certificate we are looking for?

I hope you have decided to use Public Certificates, and if that is your decision: Congratulations
you will be a much happier exchange administrator!
We have two options with Exchange Server that makes sense for the vast majority of the
companies, and here they are:

Wildcard certificates: These can be used for the entire domain and they are easy to spot
because they have a format like *.domain.ca We can have unlimited hosts using that certificate
on that domain. The drawbacks are that one single certificate is used for all your servers and in a
larger company you do not want to have several departments with access to the same
certificate, also they may bring some security concerns because their private key can be in
several servers.
In the past, they used to be more expensive than SAN Certificate but that is not the case
anymore.
SAN Certificates (Subject Alternative Names)
This type of certificate allows more than a single name in a single SSL certificate which makes
total sense for the new Microsoft products (Lync and Exchange) because several services are
using names and all of them are underneath the same IIS Web Site. In some Public CA these
certificates are also known as UC Certificates.

In this article series we are going to use a SAN Certificate because we are going to use just 2
(two) names in our certificate to support our Exchange environment.

Exchange Server 2013 and Certificates

When Exchange Server 2013 is installed, a self-signed certificate is created during the
installation process and that certificate is assigned to all services provided by Exchange Server.
If you have servers running different roles in Exchange Server 2013, you just need to worry
about the Client Access Server role since that is the role that is going to be used for the client
communications.
Since we know that all Certificates will be on the CAS portion, it is nice to know that services
using the certificate that we are managing are all services that rely on IIS (OWA, EAC, Web
Services, Active Sync, Outlook Anywhere, Autodiscover and OAB), legacy protocols such as
POP and IMAP, and SMTP for TLS.

Conclusion
In this first article of the series we covered some of the challenges when choosing a certificate
and how Exchange Server 2013 uses certificates in general.

Managing Certificates in Exchange Server 2013 (Part 2)

n the previous article we went over the process of choosing the certificate but for this article we
will use a Public one. Now, we need to decide the names that we are going to use in our
certificate to support our infrastructure.
We are going to use a simple scenario (Figure 01) that can be made more complex later on (by
adding more servers, a DR site, etc.). Our initial scenario has a Domain Controller (BsADC01)
and a single Exchange Server 2013 (BsAEX01) while our Active Directory has an FQDN named
apatricio.local and the SMTP of the future users will be @AndersonPatricio.info.
So from now on, any time that you see AndersonPatricio.info you should replace it with your
external domain name of your lab/environment.
Note:
It is a best practice to avoid a single point of failure which means that 2 (two) Domain
Controllers and at least 2 (two) Exchange Servers in a DAG for a production environment.

Figure 01
Note:
If you do not have the Exchange Server 2013 in place yet, you can check this MSExchange.org
article. This article gives all the steps required to deploy your server.
We are aware that Exchange Server 2013 comes with a self-signed certificate with the NetBIOS
name of the computer and the FQDN. In our scenario the name on the self-signed certificate is:

BsAEX01
BsAEX01.apatricio.local

Well, we do know that those names are not going to fly with external clients and to simplify
things we will be using only two entries in our future SAN/UC Certificate.
Using just two names, we can address all the requirements for the current environment. We will
need a single name for all services (OWA, Outlook Anywhere, OAB, EWS and so forth) and
another one for Autodiscover (there are a couple of methods to get that going but we use the
easiest one which is creating an A record in DNS).
Our initial suggestion for this environment would be the following names:

Autodiscover.AndersonPatricio.info
Webmail.AndersonPatricio.info

The webmail can be replaced for any name that you use to access your OWA, however, the
Autodiscover is not going to be used by the clients explicitly and since that one is hard coded in
the Outlook discovery process we cannot do anything about it.

Now, that we are aware of the names to add in our new certificate we can start working on the
technical side, to prepare our environment to support a Public Certificate and those two names.
In our decision to use just two names (AndersonPatricio.info instead of apatricio.local) you may
have noticed that they are external names. The reason for that is that Public CA will not support
internal names in the near future. However, such a change requires configuration in the internal
DNS by creating a mirror of the Public Zone in our internal network. This configuration is also
known as split-brain DNS.

Configuring the split-brain DNS

Using this technique, we create an internal zone of our public domain name inside our network
and after that, all clients will request information only for that zone which means that we must
make sure that all records that we have on the internet are added to this new internal zone.
Lets say you have an IIS in the internal network and you publish your institutional page on that
server. The beauty of using split-brain is that when an internal computer goes to
www.company.ca the IP used will be the internal one to access the server; when the same client
goes to the internet and accesses the same address (www.company.ca) the page displayed will be
the same but the IP address of the site will be the public one. The entire process is transparent for
computers because the IP is only based on which DNS Server is being used by the client.
In our scenario our Active Directory domain is apatricio.local (and NetBIOS is APATRICIO)
and when we open the DNS Server Manager (Figure 02) we have the following zones under
Forward Lookup Zones.

Figure 02
Right-click on Forward Lookup Zones and click on New Zone... on the first page of the wizard
(Figure 03), leave default settings and click Next.

Figure 03
On the Active Directory Zone Replication Scope page (Figure 04), we can define how this
replication will work where the most common options are the first two: the first replicates to all
DNS in the forest and the second option replicates to all DNS servers in the Domain. Click Next.

Figure 04
On the Zone Name page (Figure 05), type in the public name that in our case is
AndersonPatricio.info and then click Next.

Figure 05
On the Dynamic Update page, by default the Dynamic Update is enabled however, we will
restrict this zone to make sure that only manual entries will be entered by selecting Do not allow
dynamic updates and then click Next. (Figure 06)

Figure 06
On the final page, just click Finish to complete the wizard and our new zone should be listed
under Forward Lookup Zones. Click on View and then Advanced.

Note:
The last step allows the TTL information for any record to be shown in the graphical user
interface.
Lets create our first entry in our split-brain DNS, right-click on the zone that we have just
created and click New Host
In the new window, we are going to add first our webmail host pointing out to the Exchange
Server 2013 IP address. We can also define the TTL (by default is 1 hour) and we may have to
go back here when we increase the complexity of the environment by adding a DR site or
something like that. Then, click Add host. A pop up displaying that the host record was created
successfully will be displayed, just click OK (Figure 07).

Figure 07
Okay, we created the main A record for our Exchange Server deployment however, we have a
split-brain DNS and any host that your internal users access from your public domain must be
created here as well.
Before we go any further, create Autodiscover.AndersonPatricio.info pointing out to our
Exchange Server 2013 as well. Even though this entry is not used by authenticated computers, it
can be useful for ActiveSync devices in your internal Wi-Fi network and workstations that are
not joined to the current Active Directory domain.
Now, you will need some time to complete your new zone however, I would like to point out a
few hints before you start creating records. Bear in mind that when internal zone is mentioned
we are referring to the split-brain DNS that we have just created that reflects your Public Domain
zone.

A good start before trying to remember what your users are using is to get a list of your Public
DNS entries and start going over each entry and accommodating those in your internal zone
MX records shouldnt be added to your internal zone
SPF and TXT records to validate services are not required in your internal DNS
All internal servers that you published through your firewall to the Internet can have their
internal IPs in the internal zone. This way your internal traffic doesnt have to hit the external
interface of your firewall

Time for testing! Just open command prompt and try ping webmail.AndersonPatricio.info and
you should be receiving the IP address of your internal Exchange Server. If we go one-step
further and try to access https://webmail.AndersonPatricio.info you will hit the server but a
certificate error message will be displayed, as shown in Figure 08. Do not worry about the
Certificate error at this point as we will tackle it in the upcoming articles of this series.

Figure 08

Managing UPN (User Principal Name)

That is not a requirement, however it can save time in the future when transition to Office365.
By default, any new Active Directory will have only the FQDN as UPN (in our case
APatricio.local) and the users can use two ways to authenticate which are: APATRICIO\name or
name@apatricio.local when their authentication is requested.
However, if an external user using Outlook requires entering a username and password he/she
probably will try the e-mail address instead of @apatricio.local. In order to create consistency for
end-users we can add a UPN in Active Directory to support the SMTP address (or public
domain).

In order to manage UPNs, we need to open Active Directory Domain and Trusts, and rightclick on the first item on the left and then Properties. In the new window (Figure 09), type in the
SMTP domain that will be used for the users and then click Add and OK.
Note:
Do not add @ in the UPN, it is just the domain name.

Figure 09
When creating a new user in Active Directory Users and Computers or even Exchange Admin
Center, make sure that you configure the UPN properly for the user (Figure 10).

Figure 10

Managing Accepted Domains

A key point is that your users must have the domain that you are configuring in the new
certificate, otherwise most of the tools that we are going to use will fail (especially when testing
the autodiscover component).
In order to configure the SMTP to our end-users, the first step is to create an accepted domain in
our Exchange Organization. Logged on Exchange Admin Center, click Mail flow, and then click
accepted domains.
Click Add, and on the new page type in the name of the domain (without @) on both fields:
Name and Accepted Domain and leave default settings for Authoritative domain and click save.
The results will be similar to Figure 11.

Figure 11
Now that Exchange is able to handle traffic for the new domain that we created, we need to
stamp the new SMTP address on our users. Click E-mail address policies and we should have
just one entry called Default Policy, select it and click Edit, then click email address format
and change the SMTP entry on the right side to use the new accepted domain that we have just
created which matches our future new certificates. Click Save, where you may be asked to apply
the new policy and if that is the case, back to the EAC page, select the Default Policy and hit
Apply which is located on the right side, and confirm by clicking Yes when requested.

Figure 12

Now, any new user will receive the @AndersonPatricio.info as primary SMTP.

Conclusion
In this second article of this series, we focused on prerequisites to reduce the number of
certificates and complexity in Exchange Server 2013. As part of this process we created a splitbrain DNS, UPN configuration (to facilitate the authentication process) and accepted domains.
In the next article, we will be requesting the certificate for our environment and all steps
involved with this task.

Managing Certificates in Exchange Server 2013 (Part 3)

Requesting the Certificate
The first step is to create a Shared Folder that can be used by the certificate process and other
Exchange tasks that require a repository location (PST is a good example).
This shared folder can be created on any server of your network but since the Exchange
Administrator has control of the Exchange Servers, the shared folder is usually created on an
Exchange box.
The folder creation process is a straightforward process. Lets name it ExchUtil$ where the $
means that it is a hidden shared folder and on the permissions at Share Level, make sure that the
existent Everyone entry has full control.

Figure 01
On the Security tab of the same folder we will restrict permissions by disabling the inheritance
and removing Users group, and adding Exchange Trusted Subsystemwith Full Control
permissions to the list as shown in Figure 02.

Figure 02
Now, that we have the requirements in place open Exchange Admin Center
(https://<ExchangeServer>/ECP) and after authenticating, click servers and then certificates. A
list of all certificates in place will be displayed as shown in Figure 03.

Figure 03
Click on the first icon of the toolbar which is New and represented by + icon. On the new page,
we can choose from a new Certificate (which works for either Internal CA or Public CA) or a
self-signed option. Leave default settings and click Next. (Figure 04)

Figure 04

On the second page we need to define a friendly name for the certificate. In this article series we
will name it as <Domain Name> - Public Certificate and then click Next. (Figure 05)

Figure 05
On the following page we can use a wildcard by selecting the option Request a wildcard
certificate, but in the first article of this series we decided to go for the Subject Alternative
Names route, so leave default settings and just click Next.
On this page we can select which server will store the certificate request that we are creating. We
will use the same server to complete the process of the certificate, after that it is just a matter of
export and import certificates for any other servers that share the same names. Since, we have a
single server click Browse and select the desired server, click Next. (Figure 06)

Figure 06
On this page the administrator can go ahead and configure the domain names for each
component that will require a certificate. A new page will allow us to fill the name as shown in
Figure 07. All that work of filling out names will generate the names required on the certificate
request. However, we already defined the names that we want in our certificate, click Next.

Figure 07
Now, we have a summary of all names that will be part of this request. One of them is
configured as common name and should reserve the name that is going to be used by the Outlook
Anywhere. We can manage the entries by clicking the Add/Remove buttons and the result should
be similar to Figure 08. In this article series we will be adding a third name just for ADFS to
show how we can take advantage of the Certificate request in Exchange Server.
Note:
If this certificate will be used for other services, then we can use this opportunity to add names.
These are a couple of examples where you can use additional names: when using Active
Directory Federation Services (ADFS), any IIS application on a different server, SharePoint, or
even a name for your SMTP protected traffic.
Check with your Public Certification Authority but they should allow you to use the certificate
on multiple servers. If they support that, then the certificate being generated here can be exported
and imported on other servers that bring a lot of value for the certificate.

Figure 08
On the following page the administrator has to fill out all the information about the organization,
location, etc. After that, click Next.

On the final page of the certificate wizard, we need to specify the path of the Shared Folder that
we created at the beginning of this article series, plus the name of the request as shown in Figure
09. After filling out all required information click Finish.

Figure 09
If we look at the ExchUtil$ folder a new file with the name that we specified will be listed, and
the content will have something similar to the content being shown in Figure 10. That is our CSR
(Certificate Signing Request) and that is the information that we will use either with our Internal
Certification Authority or with a Public CA.

Figure 10
One last thing, if we look at the certificates on EAC (Exchange Admin Center), a new entry will
be listed and it will appear as Pending Request, as shown in Figure 11.

Figure 11

Time to go to your favorite CA. Make sure that you create an online account and when requested
for a CSR, please paste the content of the file that we have just generated. The processing time of
your new certificate varies depending on your Public CA. They will check if you are the real
owner of your domain and some documentation may be required as part of the process.
Note:
Your next Certificate renewal can be 3 (three) years from now and for that reason you may want
to use a generic account when registering with your Public CA provider. Using generic accounts
for this kind of request can save you time in the future where you dont have to remember who
was working in your company during the renewal process and you dont have to recreate
usernames of people that may not be working in your company anymore.

Deploying the new Certificate...

At this point in the game, we probably received a message from the Public CA with our new
certificate. We need to get that new certificate and place it on the ExchUtil$ shared folder.
In order to install the new certificate go to the EAC, click servers and then certificates. Select
the certificate that started it all which has a Pending Status and click Complete located on the
right side, as shown in Figure 12.

Figure 12
On the new page, type in the UNC location of the file as shown in the Figure 13, and finally click
OK.

Figure 13
Back to the certificates page (Figure 14), we can see that the Status column shows our new
certificate as valid which means that it has been installed and we can assign services to it.

Figure 14
This completes the installation process of the Certificate; however we are not done yet. Our next
step is to assign this new certificate to the services that we are hosting on our new Exchange
Server 2013.

Assigning Services to the new Public Certificate

In order to do that, select the certificate and click Edit (second icon from left to right). On the
first page displayed (general) we can check all the names of the certificate, when it is going to
expire, status and so forth. Click services, IIS (you can select more services if you are going to
use it) and then save. (Figure 15)

Figure 15
After hitting the save button on the previous page, fire up a new Internet Explorer session and go
to webmail.AndersonPatricio.info and the page will be displayed without any certificate
warnings and the padlock icon on the right side of the address will be closed. If you click there,
more information about the Certificate will be displayed and we can see that is a valid certificate
(Figure 16).

Figure 16
Are we done? Not at all, we completed the first task that is - request and deploy the certificate.
Our next task is to make sure that Exchange Server 2013 is configured to use the names that are
being used in the certificate. When completing the other tasks that we will be reviewing in the
upcoming articles, we will be improving end-user experience where they will not receive any
certificate error messages using Outlook or any other Exchange service.
Stay tuned for the next article. We will be configuring Exchange Server 2013 to use the new
certificate by exposing the proper DNS names on all services offered by the Client Access role.

Conclusion
In this article, we requested and assigned the public certificate in our Exchange Server 2013
environment. All these tasks were the result of the planning and design that we worked on in the
first two articles of this series.

Managing Certificates in Exchange Server 2013 (Part 4)

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.

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.

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.

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.

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.
Lets 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).

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.

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: SetClientAccessServer 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.

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.

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.

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

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.

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:

White Paper: Exchange 2007 Autodiscover Service

A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records
to locate the Exchange Autodiscover service

Managing Certificates in Exchange Server 2013 (Part 5)

Introduction
So far, in our series we deployed the certificate and configured the Autodiscover component to
support our internal and external clients. In this article we will be covering the required steps to
update the URLs used by Outlook either internally or externally. The new URLs will match the
entries that we have in our new Public certificate.

Managing External Access...

The external configuration is the simplest of all three components because everything can be
done from a single wizard.
You may have noticed that the new Exchange Server 2013 deployment wizard is simpler than its
predecessors and it does not ask you anymore about the External Access Domain during the
process. Nowadays, we need to configure that after installing the product and that is exactly
what we are going to do in this section.
In order to configure all external URLs we can use a simple wizard that configures everything
related to the external address. Logged on from Exchange Admin Center, click servers and then
Virtual directories. Click on the second icon that has Configure External Access domain as
a description, as shown in Figure 01.

Figure 01
On the new page, we can configure several servers at the same time. Click the Add button which
is presented by the + sign, and select the Exchange Server 2013 (only Client Access Server role
servers will be listed since we have a single server in the current environment). After selecting

the server, we need to specify the external name, which in our article series is
webmail.AndersonPatricio.info and click save (Figure 02), and wait a few moments for the
changes to be applied on the selected server/s. In the new dialog box, just click close.

Figure 02
A restart of IIS using iisreset /noforce would be good to refresh and speed up our testing
process. Lets open an Outlook client and run the Test E-mail AutoConfiguration and on the
HTTP area which is related to external access we will notice that all URLs for all services are
using the new name that we have just specified in the previous wizard, as shown in Figure 03.

Figure 03
Now that we know that the URLs are available for the clients, we can use ExRCA and run a
couple of tests to make sure that everything is working properly from the outside.
Lets run these two tests: Outlook Anywhere (RPC over HTTP) and Exchange Active Sync
because they run the Autodiscover as part of their process as well,. All tests should pass at this
moment, if they do not, please check the information on the ExRCA.com to pin point the issue.
In our article series, we can see the results for the Outlook Anywhere test in Figure 04 and if we
analyze all the steps further, we can see all protocols, connections and so forth.

Figure 04
If you are not sold yet, just create a new account on any device that you may have handy, create
a new Exchange account, and provide your e-mail address and password (Figure 05). As an
exercise we are going to use an iPhone device. After typing in the required information just click
next.

Figure 05
As soon as we hit next in the previous step, a new page will be shown for a few seconds (Figure
06) and the last page of the wizard will appear automatically (Figure 07).

Figure 06
On the last page from the device, the end-user can define which components will be
synchronized, just click save and the user will be able to access e-mail through ActiveSync.

Note:
Based on default settings, if you have changed your ActiveSync policy to block or quarantine
your end-users will not have access to ActiveSync until further changes from the administrator
side.

Managing Internal URLs...

The last piece of the puzzle is to configure the internal URLs to reflect the changes as we have
done with Autodiscover and external access. After completing this section our end-users will not
be prompted by certificate errors and such changes can be done either using Exchange
Management Shell or Exchange Admin Center. Since we have been using Exchange Admin
Center during this entire series, we will continue using it for the rest of this article series and this
step is not going to be any different. Shall we start?
Logged on at the Exchange Admin Center, click servers, and then virtual directories tab, as
shown in Figure 07. On this page, we can narrow down by server (select the server name in the
drop-down Select Server). In our case we have a single server but it does not matter.

Figure 07
In order to change, we just need to select a listed entry, and then click the first button of the
toolbar (Edit). We can then just copy and paste the content from the External URL field to the
Internal URL field. We need to do the same process for the following items:

OAB
EWS
OWA
ECP

If we double click any of the items being listed on the page, we will have a new page where we
can add the information as in Figure 08. We can see the values updated for the OAB Virtual
Directory.

Figure 08
After performing these changes, we can execute iisreset /noforce and start the test on the client
side. If we run the Test E-mail AutoConfiguration tool the URLs will be using the value that we
have just entered (Figure 09).

Figure 09

Conclusion
In this article, we configured the web services to use the proper names supported by our public
certificate and as part of the process we went over the process of testing all settings using
ExRCA (Exchange Remote Connectivity Analyzer) and Active Sync.

Managing Certificates in Exchange Server 2013 (Part 6)

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:
1.
2.
3.
4.
5.

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
6. Change DNS
7. 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:
1. Configure Outlook Anywhere (we covered this topic in the fourth article of this series)
2. Configure External URLs (we covered this topic in the fifth article of this series)
3. 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 dont 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.