A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 7)

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


In part six of this article series we looked at various items that I needed to configure within the Exchange 2007 environment. An example of which would be the transport dumpster and CCR availability configuration parameters. In part seven we are going to start looking at one of the new key areas of Exchange 2007, namely certificates. Let us begin by taking a look at what has changed regarding certificates on the Exchange 2007 Client Access Servers by going over the certificate creation process.

Client Access Server Certificates

By default, Exchange 2007 installs self-signed certificates that are acceptable for use on the Hub Transport and Edge Transport server roles in most situations. There are however one or two exceptions, such as using Edge Transport server features, namely domain security. However, the self-signed certificates are not suitable for Client Access Server features such as Outlook Anywhere and long-term use of Outlook Web Access. As a result, the self-signed certificates installed on Client Access Servers should be replaced. In my project scenario, the Client Access Server role and the Hub Transport server role coexisted on the same servers, so in effect, I also replaced the Hub Transport server certificate too.

Within the customer’s Active Directory environment there was an internal Windows-based Certificate Authority (CA) that was capable of issuing the required certificates. This was good to see, since there are many Microsoft products other than Exchange 2007 that require the use of certificates, such as Office Communications Server 2007 for example. Once the Windows CA had been set up, it was obviously free in monetary terms to create certificates using this method rather than purchasing them from a public CA. Of course, certificates issued by a public CA are required on the ISA Server since it was accepting public requests for services such as Outlook Web Access, Outlook Anywhere and so on.

To create new certificates for the Client Access Servers, the first thing that needs to be done is to generate a new certificate request using the New-ExchangeCertificate cmdlet. It is very important to understand the various names that this certificate will require. Since the certificate requires multiple names, the Subject Alternate Name attribute is used. On my certificates I ensured that the following names were present:

  • The FQDN of the server, such as hubcas1.neilhobson.com or hubcas2.neilhobson.com.
  • The NetBIOS name of the server, such as hubcas1 or hubcas2. This is not strictly required, but I always add it anyway as quite often I like to test and use Outlook Web Access simply by entering https://servername/owa. Adding the server’s NetBIOS name to the certificate makes sure that you do not get a certificate warning prompt when using the server’s NetBIOS name.
  • The accepted domain name for the organization (such as neilhobson.com) which in my example, only a single accepted domain name is in use. However, in cases where additional accepted domain names are present you need to cater for them. An easy way to do this in Exchange 2007 Service Pack 1 is to use the –IncludeAcceptedDomains parameter of the New-ExchangeCertificate cmdlet which ensures that all accepted domains that you have defined are included in the certificate request.
  • The autodiscover domain name, such as autodiscover.neilhobson.com. In fact, I used the new –IncludeAutodiscover parameter of the New-ExchangeCertificate cmdlet for this purpose. Like the –IncludeAcceptedDomains parameter, this ensures that the autodiscover name for any additional accepted domain names is included in the certificate request. You do not have to use this parameter. If you do get into the habit of using it you will not forget any additional domain names that might be required.
  • The name that users will use to access email remotely, such as email.neilhobson.com.

Had I been using a certain technology such as Windows Network Load Balancing (NLB), it would have been a requirement to include the NLB name in the certificate too if it was different to the remote access name, but this was not the case in my project. Just to elaborate on this a bit further, imagine that users externally typed email.neilhobson.com to access Outlook Web Access when working remotely. It makes sense, from a training perspective, to allow the users to type the same address into their browsers when working on the internal network. If using NLB, you could therefore make sure that the NLB name was set to email.neilhobson.com, to give users a consistent naming experience when accessing Outlook Web Access. However, if you had decided to implement a different name for Outlook Web Access via NLB internally, such as nlb.neilhobson.com, you would need to make sure that the name nlb.neilhobson.com was also included in the certificate names.

Creating The Certificates

To create the certificate request, I ran the New-ExchangeCertificate cmdlet with quite a few different parameters. The full cmdlet I used was similar to this:

New-ExchangeCertificate –GenerateRequest –Path c:\hubcas1.txt –SubjectName cn=hubcas1.neilhobson.com –DomainName email.neilhobson.com, hubcas1, hubcas1.neilhobson.com –IncludeAcceptedDomains –IncludeAutodiscover –PrivateKeyExportable $true

Let us now go through each parameter and discuss what it allowed me to do.

  • GenerateRequest: This allowed me to create a certificate request file rather than a self-signed certificate.
  • Path: Here I specified the file that was to contain the certificate request generated, namely c:\hubcas1.txt.
  • SubjectName: This parameter links the certificate with a server name and is in the style of an X.500 distinguished name. In my case, the certificate was issued to hubcas1.neilhobson.com.
  • DomainName: You will note that I ensured that the DomainName field contained the external access name, the NetBIOS name and the Fully Qualified Domain Name (FQDN). This means that all these names were present on the certificate.
  • IncludeAcceptedDomains: As I discussed earlier, I usually add this parameter to ensure that any additional domains defined as accepted domains within the Exchange 2007 configuration are added to the certificate.
  • IncludeAutodiscover: Like the accepted domains, I usually add this parameter to ensure that additional autodiscover domain names are added appropriately.
  • PrivateKeyExportable: This is useful tool to allow you to export the certificate, such as when you copy the certificate to an ISA Server.

Once I ran this command it completed and informed me of the certificate thumbprint and subject name. An example of this can be seen in Figure 26.

Figure 26: New-ExchangeCertificate Cmdlet

Running this cmdlet also created the file c:\hubcas1.txt on the Client Access Server. This is the familiar certificate request file, the contents of which will look similar to that shown in Figure 27.

Figure 27: Contents of a Certificate Request File

As I mentioned earlier, in my project, an internal Windows CA was present and was able to be used to create the certificates for the combined Hub Transport and Client Access Servers. To create the certificates I used the following process:

  1. I first navigated to the web interface of the CA by bringing up a browser and going to http://server/certsrv. Here, ‘server’ should be replaced with the name of the server running the Windows CA. This brought up the welcome screen that you can see in Figure 28.

Figure 28: Windows CA Welcome Screen

  1. From the welcome screen I chose the option to Request a certificate. This action brought up the Request a Certificate screen that you can see in Figure 29.

Figure 29: Windows CA Request a Certificate Screen

  1. From the Request a Certificate screen, I chose the option to submit an advanced certificate request. This action brought up the Advanced Certificate Request screen that you can see in Figure 30.

Figure 30: Windows CA Advanced Certificate Request Screen

  1. From the Advanced Certificate Request screen, I chose the option that starts with Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file. This action then brought up the Submit a Certificate Request or Renewal Request screen that you can see in Figure 31.

Figure 31: Windows CA Submit a Certificate Request Screen

  1. In the Saved Request field, I pasted the contents of the certificate request file hubcas1.txt. I then made sure that the Certificate Template field was set to Web Server. The completed screen can be seen in Figure 32.

Figure 32: Windows CA Completed Submit a Certificate Request Screen

  1. Once completed, I clicked the Submit button which resulted in the Certificate Issued screen that you can see in Figure 33. From here, I ensured that the DER encoded option was selected and then chose the Download certificate link that you can see on the same screen. I then saved the resulting certificate file, certnew.cer, locally onto the Client Access Server.

Figure 33: Windows CA Certificate Issued Screen


This completes part seven of this article series, where we have seen the initial steps of the process in replacing the self-signed certificate that is installed as part of the overall Client Access Server installation routine. This certificate generation process simply involves running an Exchange Management Shell cmdlet and creating the certificate via the Certificate Authority website. In the next part of this series we will import and enable the certificate.

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