Blog  >   Best Practices   >   Replace Your Certificates for Internal Names: Part 2
Best Practices 07-11-2015

Replace Your Certificates for Internal Names: Part 2

Flavio Martins

Internal name and reserved IP address certificates will expire by October 31, 2015. If you are reading this blog because you are knee-deep in replacing your publicly trusted internal name certificates, you have come to the right place. If you are just learning about replacing your internal name certificates, see our previous post Replacing Your Internal Name Certificates.

This post will cover how to reconfigure your Exchange server to use a publicly registered domain name. This process will only affect your Exchange Autodiscover settings, so mail clients will know to connect to Exchange using your registered domain name rather than an internal name. This will not actually change your server name or AD domain.

We recommend subscribing to this blog. We will keep it updated if additional information or changes are required. Also, please feel free to leave comments or questions. We will answer questions as they are received.

Prerequisites Internal Name Tool Exchange Management Shell (EMS)

Prerequisites for Reconfiguring Your Exchange Server

Before you reconfigure your Exchange Autodiscover settings to use a publicly registered domain name, you must complete the following prerequisites:

  • Install and Enable Your Reissued Certificate

Install and enable your reissued certificate on all of your CAS servers. Below are links to instructions that can help you get your certificate installed:

  • Verify Exchange Server Has Client Access Server Role

    • The server must have the Exchange Client Access Server role. Your custom Exchange setup may have multiple servers with this role.

    You only need to run the Internal Name Tool or Exchange Management Shell (EMS) commands on one CAS server, and it will update the configuration for all of them.

    In the Exchange Management Shell, run the following commands to check which servers are CAS servers (servers with CAS role):

    • To see a list of all CAS Servers, run the following command:
      Get-ClientAccessServer
    • To see the server name and a list of its roles assigned to it (e.g., Mailbox, ClientAccess), run the following command:
      Get-ExchangeServer | fl Name, ServerRole


      The output will look something like this:

      Name : WIN-B8H99E6AN82 ServerRole : Mailbox, ClientAccess
  • Verify the User Has the Organization Management Role

    • To ensure access to the required commands, the user who runs the Internal Name Tool or EMS commands must have the Organization Management role.

  • Set Up a DNS Record

    Set up DNS records to resolve the external domain names to the internal IP address that clients will use to access Exchange.

    For example, let’s say your internal clients connect to Exchange with an internal name, mail.internaldomain.local, which resolves to the private IP address 192.168.0.1. For clients to connect using a public domain name, like mail.domain.com, you will need to set up an internal DNS record to resolve mail.domain.com to the internal IP address 192.168.0.1.

  • Set Up Client Access Array

    If you plan to use a Client Access Array, we recommend that you set this up in advance with the domain name you are using when reconfiguring Exchange.

After you’ve completed all the prerequisites, you are ready to use the DigiCert Internal Name Tool or the Exchange Management Shell to reconfigure your Exchange server.

Internal Name Tool Exchange Management Shell (EMS)

Internal Name Tool: Reconfigure Your Exchange Servers to Use Registered Domain Names

To reconfigure your Exchange Autodiscover settings, we recommend using the DigiCert® Internal Name Tool. We designed this tool specifically to make your move from internal names to registered domain names easy and less painful.

Using the Internal Name Tool to Reconfigure Exchange Autodiscover Settings OutlookAnywhere Setting How to Roll Back to Your Previous Autodiscover Settings Troubleshooting

Using the Internal Name Tool to Reconfigure Exchange Autodiscover Settings

  1. Verify that you have completed all the prerequisites.
  2. On your Exchange Client Access Server (CAS), download the DigiCert Internal Name Tool to a location where you have write access, for example on your desktop.

    Click here to download tool.

    Note: The Internal Name Tool will generate a log file and two scripts in the same location from where you run the tool.
  3. Right-click on the Internal Name Tool and select Run as administrator.

  4. In the DigiCert Internal Name Tool section on the Welcome page, carefully read the explanation of what the tool will do, and then click Next.
  5. On the License Agreement page, carefully read the agreement, check I accept and agree to the license agreement, and click Next.
  6. On the Prerequisites page, verify that you have completed all the requirements and then click Next to begin analyzing your current Exchange server configuration.
  7. On the Analyze Exchange page, wait for the tool to finish analyzing our server (green checkmarks) and then click Next.
    Note: If any of the items fails, see Troubleshooting.
  8. On the Configure Setting page, in the drop-down list, select the registered domain name from the certificate that you want configure the Exchange Autodiscover to use.

    The drop-down list is populated with the names found in the certificate currently enabled on the IIS role of the CAS servers. If you don’t see your registered domain name in the list, you may need to check that the certificate is correctly installed and enabled on all your CAS servers.

    Note: This domain name should be the domain name that clients will use to connect to Exchange.

 

  • Next, review your client access servers and their settings, uncheck components that you don’t want updated with the domain that you selected, and then click Next.
  • On the Run Options page, review the PowerShell scripts that the tool will create, select Update my Exchange settings for me and save the scripts as backups, and then click Next.

  • On the Run page, review the steps that the tool will complete and when you are ready to reconfigure your Autodiscover settings, click Execute.
    Note: If any of the items fails, see Troubleshooting.
  • On the Completion page, please note the following:
    • Outlook clients may have to wait up to an hour to see the changes. • A RollbackExchangeInternalNameScript.ps1 was created that you can use to roll back to your previous Autodiscover settings. • The UpdateExchangeInternalNameScript.ps1 was created for your records. • The DigiCertINTTool.log file contains all the operations performed by the tool.
  • You are done!

    Your clients will connect to the Autodiscover service, learn the new settings, and connect to the Exchange server using the external name.

    No more certificate name mismatch error!

    •  

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  • If you run into any problems that cannot be resolved, see Troubleshooting.
    1. Run the following command:
      Get-OutlookAnywhere -Identity "HostNameRpc (Default Web Site)" | fl InternalHostname, InternalClientsRequireSsl
    2. The output from this command that you want to record may look something like this:
      InternalHostname : internaldomain.local

      InternalClientsRequireSsl : True

      3.  

    3. If the InternalHostname is blank, if the InternalHostname is a publicly registered domain name, or if InternalClientsRequiredSsl is False, you probably don’t need to reconfigure this setting (i.e. run the “set” command for that setting).
    1. After verifying and recording your OutlookAnywhere setting, run the following command to reconfigure it to use your server’s registered domain name:
      Set-OutlookAnywhere -Identity "HostNameRpc (Default Web Site)" –InternalHostname mail.yourdomain.com -InternalClientsRequireSsl $true
    2. You are done!

      No more "The settings for OutlookAnywhere could not be read" errors!

      3.  

    1. Run Windows PowerShell as administrator.

    2. In the command prompt, run the following command:
      RollbackExchangeInternalNameScript.ps1
    3. You are done. Your Autodiscover settings should be rolled back.
    1. If you had to update your OutlookAnywhere setting, you need to run the following command to roll back this setting:
      Set-OutlookAnywhere -Identity "HostNameRpc (Default Web Site)" –InternalHostname InternalHostname -InternalClientsRequireSsl $true

      Change "InternalHostname" to the name you recorded when running the Get-OutlookAnywhere command.

      2.  

    2. Recycle IIS Application Pools

      Finally, to force these commands to take effect, you must make IIS push your changes by recycling the application pools.

      1. Open IIS Manager and run as administrator.

        In the Windows Start menu or from the Start screen, type inetmgr.

        2.  

      2. In the Connections tree, expand “Your server name” > Application Pools.
      3. In the Application Pools center pane, right-click on MSExchangeAutodiscoverAppPool and then click Recycle.

    3. You are done. Your OutlookAnywhere setting should be rolled back.
    • The settings for OABVirtualDirectory could not be read.

      If you encounter a “settings could not be read” error message, do the following:

      1. Check your permissions. Specifically, check to make sure that you have the Organization Management role assigned to you. See Prerequisites for Reconfiguring Your Exchange Server.

      2. Rerun the Internal Name Tool, making sure that you run it as administrator. See Using the Internal Name Tool to Reconfigure Exchange Autodiscover Settings.

    • Prerequisites page failures

      If any of your items fail and your problem is not covered in this Troubleshooting section, do the following:

      1. Click the more info link to determine the cause.

      2. If all else fails, use Google to research the error/warning.

      3. Correct the problem.

      4. Rerun the Internal Names Tool.

      •  

    • Cannot resolve issues with the DigiCert Internal Name Tool

      If you run into any problems that cannot be resolved, please try using the Exchange Management Shell to reconfigure your Exchange servers.

    •  

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    OutlookAnywhere Setting

    In many Exchange environments, the OutlookAnywhere InternalHostname setting is not configured or does not need to be changed. If the above steps fixed your Exchange client certificate warnings, don’t worry about updating this setting.

    For those who don’t know if the setting is needed in your environment, you can run a command to check and/or record the setting in case a roll back is needed.

    Verify and Record
    Reconfigure OutlookAnywhere Setting

    How to Roll Back to Your Previous Autodiscover Settings

    If necessary, after you use the DigiCert Internal Name Tool to reconfigure your Exchange servers, you can use the RollbackExchangeInternalNameScript.ps1 to roll back Autodiscover to your previous settings.

    Roll Back the OutlookAnywhere Setting

    Troubleshooting

    Exchange Management Shell (EMS): Reconfigure Your Exchange Servers to Use Registered Domain Names

    If for some reason you cannot use the Internal Name Tool, you can use Exchange Management Shell (EMS) to reconfigure your Exchange Autodiscover and other settings.

    Using the EMS to Reconfigure Exchange Settings How to Roll Back to Your Previous Settings


    Using the EMS to Reconfigure Exchange Settings

    1. Verify that you have completed all the prerequisites.
    2. On your Exchange Client Access Server (CAS), open Exchange Management Shell (EMS) and run it as administrator.
    3. Verify and Record Your Settings

      Before you begin reconfiguring your Exchange server’s settings, you need to run some “get” commands so you can verify which settings actually need to be changed. This also gives you the opportunity to record your settings should you need to roll back to them for some reason.

      Note: If any command returns blank or with a publicly registered hostname, you probably don’t need to reconfigure that setting (i.e. run the “set” command for that setting).
      Run these commands:
      1. Get-ClientAccessServer -Identity HostName | fl AutodiscoverServiceInternalUri
         
      2. Get-WebServicesVirtualDirectory -Identity "HostNameEWS (Default Web Site)" | fl InternalUrl
         
      3. Get-OabVirtualDirectory -Identity "HostNameoab (Default Web Site)" | fl InternalUrl
         
      4. Depending on your environment, you may need to run some additional commands:
      5. Get-ActiveSyncVirtualDirectory -Identity "HostNameMicrosoft-Server-ActiveSync (Default Web Site)" | fl InternalUrl
         
      6. Get-OwaVirtualDirectory -Identity "HostNameowa (Default Web Site)" | fl InternalUrl
         
      7. Get-EcpVirtualDirectory -Identity "HostNameecp (Default Web Site)" | fl InternalUrl
         
      The output from these commands that you want to record may look something like this:
      1. AutoDiscoverServiceInternalUri : https://internalname/Autodiscover/Autodiscover.xml
      2. InternalUrl : https://internalname/EWS/Exchange.asmx
      3. InternalUrl : https://internalname/OAB
      4. InternalUrl : https://internalname/Microsoft-Server-ActiveSync
      5. InternalUrl : https://internalname/owa
      6. InternalUrl : https://internalname/ecp
      Note: If any command returns blank or with a publicly registered hostname, you probably don’t need to reconfigure that setting (i.e. run the “set” command for that setting).
      OutlookAnywhere Setting

      In many Exchange environments, the OutlookAnywhere InternalHostname setting on your Exchange server is not configured. So if you didn’t configure it, don’t worry about updating this setting.

      For those of you who did configure it or for those of you who don’t know if the setting was configured, you can run a command to check and/or record the setting (in case a rollback is needed).

      1. Run the following command:
        Get-OutlookAnywhere -Identity "HostNameRpc (Default Web Site)" | fl InternalHostname, InternalClientsRequireSsl
      2. The output from this command that you want to record may look something like this:
        InternalHostname : InternalHostname

        InternalClientsRequireSsl : True

      3. If the InternalHostname is blank, if the InternalHostname is a publicly registered domain name, or if InternalClientsRequiredSsl is False, you probably don’t need to reconfigure this setting (run the “set” command for that setting).

    4. Reconfigure Your Exchange Server Settings


      After verifying and recording your Exchange settings, run the following commands, as needed, to reconfigure your settings:

      Note: If any of the “get” commands returned blank or with a publicly registered hostname, you probably don’t need to run the “set” command for that setting.

      Run these commands:
        1. ClientAccessServer
          Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml
        2. WebServicesVirtualDirectory
          Set-WebServicesVirtualDirectory -Identity "HostNameEWS (Default Web Site)" -InternalUrl https://mail.yourdomain.com/ews/exchange.asmx
        3. OABVirtualDirectory
          Set-OABVirtualDirectory -Identity "HostNameoab (Default Web Site)" -InternalUrl https://mail.yourdomain.com/oab
      Depending on your environment, you may need to run some additional commands:
      1. ActiveSyncVirtualDirectory
        Set-ActiveSyncVirtualDirectory -Identity "HostNameMicrosoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://mail.yourdomain.com/Microsoft-Server-ActiveSync"
      2. OWAVirtualDirectory
        Set-OWAVirtualDirectory -Identity "HostNameowa (Default Web Site)" -InternalUrl "https://mail.yourdomain.com/owa"
      3. ECPVirtualDirectory
        Set-ECPVirtualDirectory -Identity "HostNameecp (Default Web Site)" -InternalUrl "https://mail.yourdomain.com/ecp"
      4. OutlookAnywhere
        Set-OutlookAnywhere -Identity "HostNameRpc (Default Web Site)" –InternalHostname mail.yourdomain.com -InternalClientsRequireSsl $true
        *Note: Depending on their configuration, you may not need to update this setting.

    5. Recycle IIS Application Pools


      Finally, to force these commands to take effect, you must make IIS push your changes by recycling the application pools.

      1. Open IIS Manager and run as administrator.

        In the Windows Start menu or from the Start screen, type inetmgr.

      2. In the Connections tree, expand “Your server name” > Application Pools.
      3. In the Application Pools center pane, right-click on MSExchangeAutodiscoverAppPool and then click Recycle.

    6. You are Done!

      Your clients will connect to the Autodiscover service, learn the new settings, and connect to the Exchange server using the external name.

      No more certificate name mismatch error!

    How to Roll Back to Your Previous Settings

    If necessary, after you reconfigure your Exchange server settings, you can roll back to your previous settings.

    1. On your Exchange Client Access Server (CAS), open Exchange Management Shell (EMS) and run it as administrator.

    2. Roll Back Your Exchange Server Settings


      After verifying and recording your Exchange settings, run the following commands, as needed, to roll back your settings. Refer to the details you recorded when running the "get" commands.

      Run these commands:
        1. ClientAccessServer
          Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://internalname/autodiscover/autodiscover.xml
        2. WebServicesVirtualDirectory
          Set-WebServicesVirtualDirectory -Identity "HostNameEWS (Default Web Site)" -InternalUrl https://internalname/ews/exchange.asmx
        3. OABVirtualDirectory
          Set-OABVirtualDirectory -Identity "HostNameoab (Default Web Site)" -InternalUrl https://internalname/oab

      Depending on your environment, you may need to run some additional commands:
      1. ActiveSyncVirtualDirectory
        Set-ActiveSyncVirtualDirectory -Identity "HostNameMicrosoft-Server-ActiveSync (Default Web Site)" -InternalUrl "https://internalname/Microsoft-Server-ActiveSync"
      2. OWAVirtualDirectory
        Set-OWAVirtualDirectory -Identity "HostNameowa (Default Web Site)" -InternalUrl "https://internalname/owa"
      3. ECPVirtualDirectory
        Set-ECPVirtualDirectory -Identity "HostNameecp (Default Web Site)" -InternalUrl "https://internalname/ecp"
      4. OutlookAnywhere
        Set-OutlookAnywhere -Identity "HostnameRpc (Default Web Site)" -InternalHostname internalname -InternalClientsRequireSsl $true
        *Note: Depending on their configuration, you may not need to roll back this setting.

    3. Recycle IIS Application Pools


      Finally, to force these commands to take effect, you must make IIS push your changes by recycling the application pools.

      1. Open IIS Manager and run as administrator.

        In the Windows Start menu or from the Start screen, type inetmgr.

      2. In the Connections tree, expand “Your server name” > Application Pools.
      3. In the Application Pools center pane, right-click on MSExchangeAutodiscoverAppPool and then click Recycle.

    4. You are done. Your settings should be rolled back.

    Related Stories

    Setting Global Standards for Secure Email Certificates

    CA/B Forum Update on EV Certificate Improvements

    1-Year Certificates are Here: What Now?

    UP NEXT
    PKI

    3 Surprising Uses of PKI in Big Companies and How to Ensure They Are all Secure

    5 Min

    Featured Stories

    07-03-2024

    What is a CA’s Role in delivering digital trust?

    Mike Nelson
    11-19-2024

    Why certificate automation is an absolute must

    Timothy Hollebeek
    11-15-2024

    4 steps to secure the IIoT device lifecycle

    Alex Deo

    • DigiCert Logo

      The most-trusted global provider of high-assurance TLS/SSL, PKI, IoT and signing solutions.