Script to change Exchange internal URLs

All Exchange consultants will have been through this situation at least once now; a customer is using a split namespace in their Exchange environment with a .local name internally, and due to the new requirements for purchasing SAN certificates, they can no longer purchase certificates with a .local name on them. One way of remedying this is to change all the Exchange internal URLs to use the public name, and add in an internal DNS zone and record to point the public name at the Exchange environment.

Changing the URLs for multiple virtual directories and servers can be a pain. There are many scripts like this out there on the internet, but I frankenstein’ed this one to fit the needs I had. I wanted it to prompt for the server name, public FQDN and autodiscover FQDN and then change the directories on that particular server to reflect the names I had entered. I also love simplicity, so I wanted the most simple script possible. If you wanted to change this to do the external URL’s, then just do a find and replace internal with external! This script will work on Exchange 2010 and 2013.

Also, if you are using a wildcard certificate, be sure to run the below command to force the name match, otherwise you may get certificate errors on your clients!

Set-OutlookProvider -identity EXPR -certprincipalname msstd:*.domain.com

Here is the script I use:

#get variables
write-host "Set Exchange 2010 Internal URLS" –Foregroundcolor Yellow
$urlpath = Read-Host "Type CAS Array FQDN starting with https://"
$autodpath = Read-Hosts "Type Autodiscover FQDN starting with https://"
$CASserver = Read-Host "Type internal server FQDN"
#change urls for all internal directories
Set-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" –internalurl “$autodpath/autodiscover/autodiscover.xml”
Set-ClientAccessServer –Identity "$CASserver" –AutodiscoverServiceInternalUri “$autodpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity "$CASserver\EWS (default web site)" –internalurl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity "$CASserver\OAB (default web site)" –internalurl “$urlpath/oab”
Set-owavirtualdirectory –Identity "$CASserver\OWA (default web site)" –internalurl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity "$CASserver\ECP (default web site)" –internalurl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity "$CASserver\Microsoft-Server-ActiveSync (default web site)" -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"
#get commands to to doublecheck the config
get-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" | ft identity,internalurl
get-ClientAccessServer –Identity "$CASserver" | ft identity,AutodiscoverServiceInternalUri
get-webservicesvirtualdirectory "$CASserver\EWS (default web site)" | ft identity,internalurl
get-oabvirtualdirectory "$CASserver\OAB (default web site)" | ft identity,internalurl
get-owavirtualdirectory "$CASserver\OWA (default web site)" | ft identity,internalurl
get-ecpvirtualdirectory "$CASserver\ECP (default web site)" | ft identity,internalurl
get-ActiveSyncVirtualDirectory "$CASserver\Microsoft-Server-ActiveSync (default web site)" | ft identity,internalurl
Advertisements

Controlling Autodiscover using Group Policy

27/03/2015 – Update: This has turned into my second most popular blog post, and is also one of the first I ever wrote. For that reason, I have given it a major update and hopefully made it more readable and helpful!

Autodiscover is a very important part of any Exchange deployment these days, whether it is a cloud-based Office 365 deployment or an On Premise deployment. It is the primary method by which your clients discover where their Exchange Server is located and what configuration is set. Manual configuration of Outlook profiles is still possible, but is very much a thing of the past.

How does Autodiscover work in Outlook?

When you configure a new Outlook profile, or open Outlook with a profile already configured, the client will go through a series of lookups to discover the correct server to connect to. This process looks something like this:

1. SCP object lookup – Outlook performs an Active Directory query for Service Connection Point (SCP) objects. When an Exchange Server is installed, it registers an SCP object in Active Directory. As this is the first lookup that Outlook does, this means that if your Outlook client can contact a Domain Controller, and you happen to have an Exchange Server installed in your forest, it will find the SCP record and attempt to connect to that Exchange Server.

2. Root domain query based on your primary SMTP address – Outlook uses the root domain of your primary SMTP address to try to locate the autodiscover service, and then tries to connect to that URL to retrieve the autodiscover XML file: https://autodiscover/autodiscover.xml. For example, my Outlook client will look up https://misstech.co.uk/autodiscover/autodiscover.xml. If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

3. Query for the autodiscover sub-domain – Outlook uses the autodiscover sub-domain to try to locate the service. This is the most commonly configured way of deploying autodiscover from my experience. Outlook will attempt to connect to that URL to retrieve the autodiscover XML file: https://autodiscover.domain.com/autodiscover/autodiscover.xml. For example, my Outlook client will look up https://autodiscover.misstech.co.uk/autodiscover/autodiscover.xml. If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

4. HTTP redirect – Outlook uses HTTP redirection if Outlook cannot reach the Autodiscover service through method 2 or 3. This is an unlikely scenario as all Exchange traffic should be going over HTTPS, not HTTP.

5. SRV record query in DNS Outlook uses an SRV record lookup in DNS to try to locate the Autodiscover service. It is not uncommon to use SRV records, is frequently used for providing autodiscover services for customers with multiple Primary SMTP domains. This feature has been deprecated with the launch of the Autodiscover Domain feature in Exchange 2013 and 2010 SP3 RU1. More information on the concept of Autodiscover for multiple domain names can be found in this excellent article: http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html

Why would I want to control this behaviour?

There are many situations in which you may want to control which of these lookups are actually performed. Here are a few examples:

1. You are performing a Cutover migration from Exchange>Office 365. In this case, when you make the switch and move your MX records to Office 365, you will need to do one of two things:

a. Remove Exchange completely from your environment before attempting to configure new Outlook profiles for your users. Doing this will remove the SCP record from Active Directory.

b. Configure your Outlook clients to skip the SCP lookup.

Both of these methods will ensure that your clients discover their autodiscover settings using method 3 (as long as you have your DNS configured properly!). If you don’t do this, your Outlook clients will always discover their Exchange server using method 1 (SCP lookup). Of course, you could manually configure each Outlook profile, but that is way more hassle than it’s worth!

2. You are moving back to an On Premise environment from Office 365 (god forbid!). If you are doing this you must disable SCP lookups before implementing Exchange, as otherwise your Outlook clients will find your Exchange Server before they find your Office 365 autodiscover settings. SCP lookups can then be re-enabled once you have offboarded.

3. You may simply want to optimise your autodiscover experience. For example, if you are using pure Office 365 (no Hybrid), you might aswell disable all types of lookup except for method 3, as that is the only method which will work. This can lead to speed improvements, particularly when launching Outlook.

How do I control Autodiscover?

The best way of doing this is to use the magic of Group Policy! Firstly, if you don’t already have it, download and install the .adm or .admx file for managing your preferred version of Office, be it Office 2007, 2010 or 2013. The Autodiscover settings for Office 2013 are built into the ADMX file for the whole application, whereas Office 2010/2007 use a special Autodiscover .adm file.

Office 2007: http://download.microsoft.com/download/C/5/2/C5252326-202E-4674-A5A2-BC9F5C8F53BE/outlk12-autodiscover.adm

Office 2010: http://download.microsoft.com/download/C/5/2/C5252326-202E-4674-A5A2-BC9F5C8F53BE/outlk14-autodiscover.adm

Office 2013: http://www.microsoft.com/en-gb/download/details.aspx?id=35554

To learn how to install these files, please see the ‘Loading the ADMX templates’ section of this article: https://technet.microsoft.com/en-us/library/cc179081(v=office.14).aspx

You may already have these files installed and have a Group Policy object for managing Office settings. If you do, then edit your existing policy. If not then create a new Group Policy Object and link it to the required OU. Edit your policy and navigate to the following setting:

    • Outlook 2013: User Configuration>Policies>Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange
    • Outlook 2010/2007: User Configuration>Administrative Templates>Classic Administrative Templates>Microsoft Outlook 2010>Account Settings>Exchange>AutoDiscover

As counter-intuitive as it sounds, Enable the ‘Disable Autodiscover’ parameter and select between the options shown in the screenshot below. In this example I’ve just disabled the SCP lookup.

Disable Autodisover GPOYou can confirm what lookups your Outlook client is performing by doing an Autodiscovery test. If you’ve never done this before, here’s how:

1. Go to the Outlook icon in your taskbar, hold Ctrl and right-click on it. You should see a couple of hidden options, select ‘Test E-mail AutoConfiguration’

Untitled

2. Untick ‘Use Guessmart’ and ‘Secure Guessmart Authentication’, enter your e-mail address and password and test.

3. Once the test is complete, go to the Log tab to see which lookups were performed and which was successful.

Hopefully this blog post will help you out, please leave comments with suggestions or feedback. Thanks for reading!

Assosiated TechNet article: http://support.microsoft.com/kb/2612922