Change Internal Names in Exchange for Upcoming SSL Requirements

Updated 21 October 2015

NOTE: The following has been tested with Exchange 2010 and Exchange 2013, and may not work with Exchange 2007 or older. If Exchange 2007 is installed in your environment, my recommendation is to transition to Exchange 2010 or newer.


In the past, internal names were added to SSL certificates for Exchange because that is what Microsoft’s guidance was to eliminate certificate warnings in Outlook–and public certificate authorities (CA) permitted them. Those names covered the bases with every possible connection scenario that might come up but exposed internal server names that could potentially cause security issues.

The requirements have changed more recently and this subject has become an increasing concern (for me) over the past 6 or 9 months as the 1 Nov 2015 deadline approaches. Exchange and SSL customers will need to make sure their certificates are modified to use external and internal FQDNs (i.e. Therefore, NetBIOS names will need to be removed from certificates as well as names with contoso.local (all non-routable names) will need to be updated to

The certificate, unfortunately, will not be the only item for Exchange that will need to be changed to ensure continued functionality as the deadline approaches. The internal URLs (virtual directories) on the client access server (CAS) settings will need to be changed using the following cmdlets…

  • Set-ClientAccessServer
  • Set-OABVirtualDirectory
  • Set-WebServicesVirtualDirectory
  • Set-ActiveSyncVirtualDirectory
  • Set-OWAVirtualDirectory
  • Set-ECPVirtualDirectory
  • Set-OutlookAnywhere


If certificate and client access settings are not changed, Outlook users will receive pop ups warning of untrusted certificates, invalid names in the certificates, etc.

Fortunately for us, DigiCert has helped to lessen the stress of such an effort through providing a tool called the DigiCert Internal Name Tool for Microsoft Exchange.

I was able to test this tool against my lab environment that consists of two (2) Exchange 2013 servers with internal URLs and an SSL certificate containing FQDNs with internal server names.

NOTE: For Exchange 2010 servers, the DigiCert tool will issue a warning if invalid certificates exist and if Exchange 2010 SP3 (at a minimum) is not installed on all of the client access servers.

After registering for (and receiving) the tool from DigiCert, it is fairly straight-forward to run. Log into one of the Exchange Client Access servers (CAS) and run it to perform an analysis of the environment. It will check existing settings as well as read the names from the installed certificate. The tool also provides the ability to update the settings immediately or create scripts to be run at a later time. I chose to have the scripts created to run at later time.

NOTE: If a client access array has been deployed, the DigiCert tool will display a warning if the CAS array name is configured with a publicly, non-routable FQDN (i.e. outlook.domainname.local). In my estimation, the ClientAccessArray and RpcClientAccessServer settings shouldn’t need to be changed but will update if testing proves otherwise.

Before running the script, I had to see what it was going to do. In a nutshell, the script will modify the internal URLs to something that resembles a publically routable URL. In other words, it will set the internal URLs and AutodiscoverServiceInternalUri to something similar to the external OWA URL (i.e. Once I knew what commands were going to be run in the script, I could then either run the commands myself or edit the settings manually via EAC or run the script.

Again, I chose to have the script make the changes for me. The process of the changes (in my lab) using the script took several minutes.

After the script completed and recycled the IIS application pools on each server, I confirmed the changes took affect and tested OWA and Outlook access. Once I was happy with the results, I created a new certificate request using and as the only names in the certificate, submitted to my public CA, and finally applied to my Exchange servers. Once again, I tested OWA and Outlook access.

OWA worked as expected, however, Outlook did not.

After changing the certificate on both servers, for good measure, I restarted both servers. Then using a workstation, opened Outlook (Office 2010) using an existing profile and received the following message but was still able to connect to the mailbox.

There is a problem with the proxy server's security certificate.
The name on the security certificate is invalid or does not match the name of the target site ex2.domainname.local.

Outlook is unable to connect to the proxy server. (Error Code 10)


The information in the error message lead me to look at the Exchange proxy settings in the Outlook profile. Sure enough the proxy server URL and the principal name were incorrect because those names did not exist in the certificate anymore. At this point, I was a bit confused because I expected the script from DigiCert to modify all of the settings needed for a seamless change. I then looked at the Outlook Anywhere (OA) settings on each Exchange server (via EAC and Get-OutlookAnywhere) to confirm the internal host name was not changed and still needed to be set properly.

Looking for clarification, I contacted DigiCert support to confirm the script does not update the OA internal host name; and won’t in the immediate future. For me, this is good information to know because I honestly thought I overlooked something or missed an instruction in using the DigiCert processes.

I then proceeded to update the OA settings for “InternalHostname” on both servers using a command similar to this…

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname -InternalClientsRequireSsl $true


Now, all internal URLs and host names are set to the same values as the external URLs and host names. Again, I restarted both Exchange servers (I probably could have just run iisreset) but I wanted to ensure the servers were refreshed completely.

Finally, I tested with Outlook again and was presented with the same error initially. However, after about five minutes, I closed and reopened Outlook with no further problems. I also confirmed that the proxy server URL and the principal name were automatically reset to the correct values within the Exchange proxy settings of the Outlook profile.

Let me know what your experiences have been like or if you have a simpler/easier process to address this growing concern as the SSL deadline approaches.





36 thoughts on “Change Internal Names in Exchange for Upcoming SSL Requirements

  1. You really make it seem so easy with your presentation but I find this matter to be really something that I think I would never understand.
    It seems too complicated and extremely broad for me.
    I’m looking forward for your next post, I will try to get the hang of it!

  2. Excellent site you have got here.. It’s hard to find excellent writing like yours nowadays.
    I seriously appreciate individuals like you! Take care!!

  3. Todd – Thanks for the walkthrough. I’m just now facing this issue, with an upcoming certificate renewal on our main production servers. May I ask a bit of clarification on one point? Were you testing OWA and Outlook from *within* your LAN or remotely connecting in from outside?

    I read DigiCert’s write up on the testing tool, and this line confused me:
    “Set up a DNS record for the external domain you will secure with your certificate. The DNS record should return the private IP address that will be used by clients to access Exchange.”

    As I read that, it means that I need to have a DNS record *within* my network that returns an internal IP address for a hostname that would normally return an outside address. Am I understanding that correctly?

    • You are understanding it correctly. Most customer environments I’ve worked in have split DNS. The internal DNS zone is to address internal DNS requests for faster response times and more flexibility.

      Regarding your first question, initially I tested from within my lab but then tested externally. This specific article was written after it was implemented in a customer environment—with split DNS.

      Hope that adds the clarification you were seeking.

  4. Hi, excellent your document, actually i’ve the same problem, and i try to executre the command in my Lab and i receive the message

    To configure the Outlook Anywhere feature with an InternalHostname you must also specify the InternalClientsRequireSsl parameter to indicate whether SSL is required.

  5. So, just to clarify – nothing needs to be done to rename the AD name of the email server? It can still remain, its just the exchange config that is changing on that server?

    Also, curious about Henry’s comment about InternalClientsRequireSsl. Is this another command that needs to be run, along with Set-OutlookAnywhere -InternalHostname?

    Curious why digicert would not include these commands as part of the tool.

    • The changes made are only to the Exchange configuration.

      I have not needed to make any changes with Set-OutlookAnywhere other than what I’ve documented when specifying the InternalHostname switch with Exchange 2010. But that’s not to say there won’t be in other environments.

      FYI…InternalClientsRequireSsl is an optional switch and the default value appears to be set to true; but is required for Exchange 2013. I will update my post.

      Not really sure why DigiCert wouldn’t include it other than the fact that it may not be required in all environments. However, their support is great and are open to suggestions.

      • Great. So, my current SSL certificate already has the public facing URL in it, along with all the internal names. My plan is to use this tool to rename this server to the external name. Essentially, my existing cert should still remain valid right?

      • Correct.

        Basically, what is being done, is the internal URLs in Exchange are being updated to a valid “routable” FQDN that already exists in your certificate–equivalent to the existing external URL values. IMO, the internal URL value should always be the same as the external URLs.

      • I ran this tool last night, and it seems to have worked, for the most part. This morning, my Outlook clients receive a certificate error for the old .local server name, which of course no longer exists in my new certificate. In the Outlook connection status, the “server name” field still has the internal name of the server. Is this pulling RPCClientAccessServer? If I test the autoconfiguration, all the settings are correct except for:

        Protocol Exchange RPC
        Server: myserver.corp.local

        Shouldn’t this be returning the new name instead of .local?

        I ignored the SSL error a few times, and now it does not seem to be popping up, so perhaps it Outlook just needed time. This seems to be happening on everyone’s machine, I was hoping to avoid end-user certificate errors.

      • The RPC setting I believe referenced here has to do with OutlookAnywhere (OA) and not the RPCClientAccessServer value. The RPCClientAccessServer value doesn’t make reference to the names in the SSL cert.

        If you run “Get-OutlookAnywhere | fl” what is the value for ‘InternalHostname’ set to? Should be an FQDN that is found in the SSL cert.

        Also, did you restart the server(s) after making the changes? This step helped in my environment.

        Let me know.

      • There is no InternalHostname field, just ExternalHostname, which is showing the correct URL. Should there be one?

        Also, I realized I had not deleted the old cert, so it was still enabled for IMAP, POP, SMTP. I removed the certificate, maybe it was still pulling from the old one?

      • Are you running Exchange 2007 in your environment?

        InternalHostname is a parameter setting for Exchange 2010, 2013, and 2016; but not in Exchange 2007.

        If the old SSL cert wasn’t removed and the services were not set on the new cert, then, yes, that could have been the issue you were experiencing.

      • Yes, Exchange 2007.

        I removed the old cert, but users today returning from vacation still receive the SSL error upon first launch of Outlook. Goes away after close/reopen. Guess I can live with it, pretty small environment.

        I even tried to avoid this issue by configured all versions of Outlook in my environment to ignore SSL errors for my old server name. This also did not work, as I still receive the SSL errors.

      • What is the value for AutoDiscoverServiceInternalUri when you run “Get-ClientAccessServer | fl identity, autodiscoverserviceinternaluri”?

        Does it contain an FQDN that exists in the cert?

      • Does the value resemble “” or “”?

      • This morning, a user received the SSL popup error again. So yeah, it looks like I still have an issue with it using the old name somewhere.

        When I ctrl-click the Outlook task bar icon, choose Test Email Auto Configuration, I still see my old servername in the Exchange RPC section. I also see it as the server name in the Outlook Connection Status. Here are pictures of both:

        Is this causing the issue? That old server name is the one the SSL error is complaining about, as it does not exists in my new certificate. If so, how do I change this, as it does not seem to have been a part of the domain rename tool?

  6. Todd, thank you for the article. Just want to make sure that there is no issue in having multiple servers with the same name/FQDN for internal URL. In other words, I don’t have to use, and just have same internal and external URLs i.e.
    Currntly, my exchange servers in a CAS array and Load Balanced have same external URL for Autodiscover. OAB and EWS, but different internal ones.

    your response would be appreciated.

    • There aren’t issues with having both the internal and external namespaces identical. If there are concerns, each server can be assigned a different FQDN for the internal URL–just as long as they resemble a publicly routable FQDN. However, that configuration will require more names in the certificate–potentially increasing costs.

  7. Great writeup! We also use Digicert and noticed the same behaivor w/ the InternalHostname. Unfortunately we get errors when running the command to change the internal hostname to our external domain. We get “a positional parameter cannot be found that accepts argument ‘-InternalHostname’. Thoughts?

    • Can you reply with the command you are running that is giving the message?

      I’m not familiar that Get-OutlookAnywhere and Set-OutlookAnywhere in Exchange 2010 or 2013 would give such a response.

  8. Hi Todd, Im using the same command mentioned in the post: Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname -InternalClientsRequireSsl $true ***but with my own server domainname of course***

    The error is: “A positional parameter cannot be found that accepts argument ‘’.”

    • How many Exchange servers do you have and what version is installed on each?

      You can run this similar command against an individual server to set the value…

      Set-OutlookAnywhere “SERVERNAME\Rpc (Default Web Site)” -InternalHostname -InternalClientsRequireSsl $True

      Also, if OA is not enabled, you might get that message.

      Unfortunately, if you have an Exchange 2007 server, there is no “InternalHostname” parameter for Set-OutlookAnywhere.

      Lastly, if you are copying and pasting the example from the blog, try typing it manually instead.

      Let me know.

  9. Hello Todd! I ran across your informative post while looking for steps to troubleshoot our issue.

    We’re making the big switch from internal name to external on our Exchange 2007 server. We too used digicert. Ran the tool, everything looks great but our outlook clients will not point to the new name no matter what we do. Everything looks to point to

    I see you mention outlook anywhere several times in your replies. We have never configured ours. Even “Get-Outlookanywhere | fl” returns nothing. Do you think that is our issue here? I thought Outlook anywhere was for connecting outlook to exchange from external sites.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s