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

The operation couldn’t be performed because object ‘EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)’ couldn’t be found on ‘DC.domain.local’.

A most inventive and amusing title to this post, if I do say so myself!

After installing Exchange 2010 into a legacy Exchange 2003 environment, you may be faced with the following error when viewing the properties of an Exchange 2003 mailbox in the Exchange Management Console. In addition to this, if you attempt to migrate a mailbox to Exchange 2010 from 2003, you may see this error:

Mailbox database “EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)” doesn’t exist.

This is a permissions issue, and the fix is relatively simple:

1. Log into your Exchange 2003 server and open the Exchange System Manager (affectionately known as ESM).

2. Go to the properties of the Mailbox Store mentioned in the error message:

Mailbox Store Properties

3. Go to the Security Tab of the Mailbox Store and select the Advanced option. Tick the box to ‘Allow inheritable permissions’ , and Apply your changes.

Mailbox Store Properties

4. If this doesn’t fix your problem, or if the ‘Allow inheritable permissions’ box is already ticked, then do the same thing (Advanced settings under the Security tab, make sure the ‘Allow inheritable permissions’ box is ticked) but to do this, go into the Properties of the server itself, not the Mailbox Store.

5. If even this doesn’t work, then you should manually add in the Exchange 2010 server into the permissions group for the Exchange 2003 server and give it Full Control.

 

Hope this helps!

Exchange 2010 Update Rollup failed – error 1603

If you’ve never seen this error code before when installing Update Rollups for Exchange 2010, then you haven’t lived. There’s plenty of blogs and articles out there about it, but I wanted to record it for my own purposes so I don’t go trawling for the answer next time!

In a nutshell, the reason this happens is that UAC hates you.

Simple fix to this is to run CMD as Administrator, and use msiexec to install the Update Rollup, like this:

msiexec /update Exchange2010-KB2961522-x64-en.msp

Gotchas? Well the file should be on a local drive (not a network share). If you are still having problems after this, take a gander at the following KB article: http://support.microsoft.com/en-us/kb/2784788/en-us

That’s about it. Happy Update Rollup’ing!

Exchange 2013 CU7 and more!

Today Microsoft have released a new slew of updates for On Premise Exchange environments!

There have been various hotfixes and scripts released to fix a multitude of sins in Exchange 2013 CU6, and Microsoft have rolled these hotfixes and more into their latest CU7 release. This update does require a Schema Update, so please run setup /prepareschema first. See https://support.microsoft.com/kb/2986485 for more information. Additionally there are some UM Language Packs for Exchange 2013 CU7 available.

In other news, the Exchange 2010 CU8 update has been recalled at the time of writing and is not available for download. This is because deployment of said update can lead to Outlook being unable to connect to Exchange :-/ If you have already installed, it is recommended that you rollback the update.

Lastly is the Exchange 2007 SP3 UR15 for all those retro Exchange nerds still running Exchange 2007. See KB here for information http://support2.microsoft.com/?kbid=2996150.

Check out http://blogs.technet.com/b/exchange/archive/2014/12/09/exchange-releases-december-2014.aspx for the full rundown!

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  

Move-DatabasePath error ‘WMI exception occurred on server’

Today I discovered a problem affecting the migration of a database path to a new location in Exchange 2010. After running the Move-DatabasePath cmdlet and specifying the -LogFilePath and -EdbFilePath parameters, I was faced with an error which read:

Failed to connect to target server “DDExch”. Error: WMI exception occurred on server ‘DDExch.DDAD.local’:
Call cancelled
+ CategoryInfo          : InvalidOperation: (DDDB02 Live:DatabaseIdParameter) [Move-DatabasePath], InvalidOperatio
nException
+ FullyQualifiedErrorId : 6C2ED31B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath

It turns out that this error is related to having a large quantity of log files in Exchange 2010. The version I am running is SP3 but I am unsure as to whether this makes any difference. I also tried running this in EMC and had the same result.

To resolve this problem, either perform log truncation using your preferred Exchange backup tool, or enable circular logging to truncate the logs. Remember, after enabling circular logging, you will need to dismount and mount the database for it to take effect. I would recommend that you disable circular logging after this and dismount/mount the DB again.

Hope this helps some folk struggling with a database migration.