Thursday, 29 October 2015

Exchange 2010 - 2013 Migration: Outlook Client Issue

During an Exchange 2010 to 2013 migration, you may get into a situation where Outlook clients with mailboxes on Exchange 2010 can no longer connect to their mailboxes once the A record for Outlook Anywhere e.g. is changed to resolve to Exchange 2013.


Although there are a number of causes, this may be because the RpcClientAccessServer parameter on the Exchange 2010 mailbox databases is set to the same FQDN as the Outlook Anywhere hostname. This means that once you change the A record to resolve to Exchange 2013, the RPC/TCP clients will attempt to connect to the Exchange 2013 servers using RPC/TCP which won't work as this is no longer supported by Exchange 2013.

Usually Outlook Anywhere is enabled on Exchange 2010 but this is not always the case. If enabled, the clients *should* fail over to using Outlook Anywhere if they cannot connect using RPC/TCP on fast networks. If not enabled then clients will attempt to connect to Exchange 2013 using RPC/TCP and will fail. (Note that enabling Outlook Anywhere on Exchange 2010 is a required step in an Exchange 2010 to 2013 migration)


To resolve this issue, enable Outlook Anywhere on Exchange 2010 and force the Outlook clients to use HTTPS (Outlook Anywhere) on all connections. By default, on fast connections, Outlook will try to use RPC/TCP then HTTP and on slow connections Outlook will try to use HTTP first then RPC/TCP. This can be configured using Autodiscover by running the below commands from the Exchange Management Shell on Exchange 2010:

Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect

Once this is done, all Outlook clients on Exchange 2010 will be using Outlook Anywhere whether they are inside the office or not and you can change the A record to resolve to Exchange 2013 so Exchange 2013 can proxy the request for the Exchange 2010 users.

Any clients that don't support Outlook Anywhere need to be configured to use Exchange 2010 by adding specifying to resolve to the internal IP of your Exchange 2010 servers.

More information:
More information can be found here:

Wednesday, 28 October 2015

How to install Exchange 2016

In this article, we will walk through how to install Exchange 2016.


Exchange 2016 is very similar to Exchange 2013 and is often labelled as Exchange 2013 SP2. As a result, the install is almost identical and the prerequisites are the same.


Before we go ahead and install Exchange, we need to go through a few tasks.

1) Sizing. 

To ensure that we size up Exchange correctly, we should analyse our current infrastructure and use the Exchange sizing guidance to work out how much RAM/CPU each Exchange server requires. If you're virtualizing your Exchange servers, you can always add RAM, vCPU and disks to your VMs after you first install them.

2) System Requirements.

Check that the system you are going to be installing on meets the System Requirements.

3) Release Notes.

Often this is missed out but is usually quite useful. Always ensure that you read the Release Notes as there is useful information which can prevent problems down the line.

4) Windows Updates
Ensure that the server you will be installing Exchange on has the latest Windows Updates.

5) Join to domain
Join the server to the domain in which you will be installing Exchange.

6) Add storage
Add additional disks for storage as required.


Once you've gone through the preparation steps above, it's now time to install Exchange.
The recommendation from Microsoft for Exchange 2013 was to install multi-role servers but with Exchange 2016, the CAS and MBX roles have been merged so installing multi-role servers is no longer possible.

1) Assign correct permissions

For the first Exchange server in the organization, the user that performing the install must be a member of the Enterprise Admins and Schema Admins group in AD and a member of the local admins group on the server you are installing Exchange on. 

If you're not installing the first Exchange 2016 server in the organization and are installing the same version as existing Exchange 2016 servers then you don't need to be an Enterprise Admin or Schema Admin but you do need to be a member of Organization Management role group.

We'll now go on to install the pre-requisites for Exchange in step 2.

2) Install .Net 4.5.2 from here. Accept the license terms and click install:

3) If you are not using Server 2012 R2 then you also need to install the Windows Management Framework 4.0. In our case we are using Server 2012 R2 so this is not required.

4) Install the Unified Messaging Communications Managed API 4.0 Runtime.

5) Install the required Windows features

Use the below command to install the required Windows features. This command needs to be run on a single line and run from a PowerShell window with elevated privileges. Those who can remember extremely long PowerShell strings will note that this is the same list of features required for Exchange 2013.

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation,RSAT-ADDS

The AD tools are included in the above command - this prevents issues with AD operations and the EXSetup program.

6) Download Exchange 2016 from here or the latest Exchange CU. The Cumulative Update includes the entire Exchange package. There is no need to install Exchange then install the CU.


7) Once downloaded, double click to extract Exchange.


Select a location to extract the files to. In this demo, we're extracting to C:\temp\Exchange2013-x64-cu10.



8) Run Setup

Once extracted, open up the location you have extracted to and double click on Setup.exe:















You should then be presented with a window to report a successful installation.

9) Confirm the installation was successful

To do this, run the command below. This will list all the Exchange servers, their roles and version. Check that your new Exchange server is listed with all the required roles.


Also, review the setup log for any issues. This log file is C:\ExchangeSetupLogs\ExchangeSetup.log.

In this post we went through the steps required to install Exchange 2016. In upcoming posts, we’ll look at what needs to be done to migrate from Exchange 2013 to 2016 and other Exchange 2016 configuration steps.

Tuesday, 27 October 2015

Exchange 2016 sizing guidance and system requirements

Exchange 2016 requires essentially the same RAM/CPU/IOPs per mailbox as Exchange 2013 but requires just a little more compute requirements. 

Exchange 2016 only has a single role (MBX role) so the Exchange 2013 guidance needs to be followed for multi role servers.

See here for more information on these changes:

Monday, 26 October 2015

Contacts not appearing in Global Address List/convert contacts to mail contacts

If you are finding that some contacts are not appearing in the GAL then confirm that they are mail contacts and not created using AD. Contacts created using AD Users and Computers are not recognized by Exchange. 

To work out if your contacts have been created using AD tools or Exchange, run the below command to check all contacts in a particular OU:

Get-Contact -OrganizationalUnit "OU=TestContacts,OU=Contacts,,DC=litwareinc,DC=com" | ft Name,RecipientType

Here we can see that AD3 is a Contact (created by AD tools) and AD1 and AD2 are MailContacts (created by Exchange). AD3 is not showing up in the GAL or Address Lists. 

To convert contacts from AD contacts to Exchange MailContacts, run the below command on a single line to convert all contacts in a particular OU:

Get-Contact -OrganizationalUnit "OU=TestContacts,OU=Contacts,,DC=litwareinc,DC=com" -RecipientTypeDetails Contact | % {Enable-MailContact $_.Name -ExternalEmailAddress $_.WindowsEmailAddress}

As per the screenshot, you can now see that your Contact objects are converted to MailContact objects. We now see the missing contacts in our address lists:

Thursday, 22 October 2015

Outlook - Test Autodiscover

Misconfigured virtual directory URLs and certificates can cause problems with Outlook. Common issues include password prompts and certificate warnings.

Outlook uses autodiscover to configure itself with the correct hostname for Outlook Anywhere, the correct URL for web services to set Out of Office and the correct URL for the Offline Address Book download for example.

These URLs and hostnames are set on the Exchange server using cmdlets like Set-OutlookAnywhere and Set-OABVirtualDirectory but these will be covered in a separate post.

To confirm that Outlook is using the correct URLs, use the Test E-mail AutoConfiguration utility which is built into Outlook.

1) Hold down CTRL and right click on the Outlook icon on the system tray (bottom right of the screen)

2) Tick Test E-mail AutoConfiguration and untick Use Guessmart and Secure Guessmart Authentication

3) Click on Test

You can now see the Exchange URLs that Outlook is configured to use. If you find that URLs are incorrect then these need correcting.

If you find that the virtual directories on Exchange are configured to use a different URL than what Outlook has reported, you can wait for Outlook to re-check its settings or you can repair your Outlook profile. If this still shows that Outlook is not using the correct URLs then it's likely that the settings were changed on Exchange quite recently and to make them take effect you need to restart the MSExchangeAutodiscoverAppPool on the CAS servers.

Wednesday, 21 October 2015

SPF PTR Mechanism

The ptr mechanism is at commonly seen in SPF records and there is a reason for this. According to RFC 7208 section 5.5, it 'SHOULD NOT' be used. According to RFC 2119, SHOULD NOT means NOT RECOMMENDED which means that there may still be valid reasons and it is still allowed but the implications should be weighed up before implementing. 

In order to explain why the ptr mechanism shouldn't be used, we'll need a better understanding of how the ptr mechanism works. 

The ptr mechanism is specified using one of the below methods:

  • ptr

How does it work?

When you specify a ptr mechanism in your SPF record, the below process takes place:

  1. The receiving mail server does a reverse lookup on the sending mail server's IP. 
  2. Once a list of domain names is found, a check is done to see if they match the sending email domain or the specified domain if using or are a subdomain of the sending email domain or the specified domain if using
  3. A forward lookup is then done on each domain name to get a list of IPs. The sending mail server's IP is then checked against this list of IPs and if there is a match then the sender is permitted.

Why shouldn't it be used?

The first problem here is that there the receiving mail server needs to do a large number of DNS lookups which takes time and reduces performance.

The second problem is that the IP owner is the one who owns and manages the PTR records which means that the owner of the domain doesn't always have control over the number of lookups that are involved when specifying the PTR mechanism. 

What should be done instead?

Other mechanisms should be used. You can use either ip4, a or mx mechanisms to specify multiple IPs or the subnets of these IPs or you can use include to include another SPF record if you have a large number of IPs that are permitted senders. 

Tuesday, 20 October 2015

Exchange 2010, 2013, 2016 - Set Virtual Directory

When setting up Exchange 2010, 2013, 2016 servers, you will need to configure the virtual directory URLs and Outlook Anywhere hostnames so that the clients receive these correct URLs from autodiscover. 

We need to set the URLs and hostnames for the below:

  • Outlook Anywhere
  • Exchange Control Panel
  • Outlook Web Access
  • Exchange Web Services
  • ActiveSync
  • Offline Address Book
  • Service Connection Point (for autodiscover)

Each of the hostnames that we use need to be configured on the SSL certificate configured on all CAS servers in that particular site otherwise we may see an outlook certificate warning "The name on the security certificate is invalid or does not match the name of the site". To create SSL certificate requests and import them for use on your CAS servers, see here.

Should I set the internal and external names to be the same?

For simplicity and to reduce the number of names required on the certificates, it's recommended to use the same names for internal and external URLs. This may require you to set up split brain DNS if your internal and external domain names are not the same. You should set up internal A records to resolve to the internal IPs of your CAS servers and the external A records to resolve to the external IPs of your CAS servers. 

Current environment

For the purposes of this lab, our setup is below:
  • Single Exchange 2013 server called
  • Internal domain:
  • External domain:

Set Outlook Anywhere hostnames

To set the hostnames used for Outlook Anywhere, use the below command run on a single line. Outlook Anywhere hostnames specify what addresses Outlook connects to.

Get-OutlookAnywhere -Server litex01 | Set-OutlookAnywhere -InternalHostname "" -InternalClientAuthenticationMethod Ntlm -InternalClientsRequireSsl $true -ExternalHostname "" -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl $true -IISAuthenticationMethods Negotiate,NTLM,Basic

Set Exchange Control Panel URLs

Get-EcpVirtualDirectory -Server litex01 | Set-EcpVirtualDirectory -InternalUrl -ExternalUrl

In the above screenshot, we see that we need to make the same change to the OWA virtual directory so we'll do that next.

Set Outlook Web Access URLs

Get-OwaVirtualDirectory -Server litex01 | Set-OwaVirtualDirectory -InternalUrl -ExternalUrl

Set Exchange Web Services URLs

Get-WebServicesVirtualDirectory -Server litex01 | Set-WebServicesVirtualDirectory -InternalUrl -ExternalUrl

Set ActiveSync URLs

Get-ActiveSyncVirtualDirectory -Server litex01 | Set-ActiveSyncVirtualDirectory -InternalUrl -ExternalUrl

Set Offline Address Book URLs

Get-OabVirtualDirectory -Server litex01 | Set-OabVirtualDirectory -InternalUrl -ExternalUrl

Service Connection Point URL

The Service Connection Point (SCP) is an entry made on the CAS server object in the Configuration naming context in AD. It provides an autodiscover URL to internal Outlook clients so they can perform autoconfiguration. To set this, run the below command:

Get-ClientAccessServer -Identity litex01 | Set-ClientAccessServer -AutoDiscoverServiceInternalUri

How do I confirm these settings have applied to Outlook clients?

It may take a bit of time for Autodiscover to apply the new settings but you can force it by recycling the MSExchangeAutodiscoverAppPool app pool in IIS. 

To confirm what settings the Outlook clients are now using, you can use the Test E-mail AutoConfiguration utility which is built into Outlook. Instructions on how to use this are here. This should show your new URLs configured. 

This is the output of the Test E-mail AutoConfiguration utility from before we made the above URL changes:

This is the output after the changes were made and the MSExchangeAutodiscoverAppPool app pool was restarted:

We can now see that Outlook is using the correct URLs.

Monday, 19 October 2015

Outlook 2013 - There is a problem with the proxy server's security certificate

When configuring a new install of Exchange 2013, you may be presented with below the errors in Outlook:

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
Outlook is unable to connect to the proxy server (Error Code 10)

The name on the security certificate is invalid or does not match the name of the site

The cause of these errors is that Outlook is connecting using Outlook Anywhere although it is able to contact Exchange, it is using a name that is not on the certificate.

To resolve the issue, there are two options. Either you need to create a new certificate request and add the name to the certificate (see here for instructions) or you need to configure Exchange not to autoconfigure Outlook with this name and specify a different name that is on the certificate. This autoconfiguration is known as autodiscover. More on that in another post.

In this post, we'll look at how to configure Exchange Outlook Anywhere so that this issue no longer occurs.

1) Confirm current Outlook Anywhere hostnames 

We need to confirm that the Outlook Anywhere hostname includes the hostname in the error, in our case

To do this run the below command:

Get-OutlookAnywhere | fl ExternalHostname,InternalHostname

2) Create DNS records

We need to choose a name that is included on the certificate that is used by the CAS servers and/or reverse proxies. In our case, we will use the same name,, in internal and external DNS as we are using split brain DNS. You can use different names as long as both are included on your certificate. Using a single name is simpler for troubleshooting and means that less names are required on the certificate which can reduce your costs in some cases.

The internal A record needs to resolve to the internal IP of the CAS server or load balancer virtual IP if you are load balancing multiple CAS servers.

The external A record needs to resolve to the public IP of the CAS server or load balancer virtual IP if you are load balancing multiple CAS servers. If you are using a reverse proxy then you need to configure the A record to resolve to the public IP of your reverse proxy.

3) Configure new Outlook Anywhere hostnames

To configure Autodiscover Outlook Anywhere with the internal and external hostnames, run the command below on a single line:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname -InternalClientsRequireSsl $true -ExternalHostname -ExternalClientsRequireSsl $true -ExternalClientAuthenticationMethod Basic

4) Confirm new Outlook Anywhere hostnames

Again, we'll run the same command from step 1 to confirm our settings have changed. See below:

Get-OutlookAnywhere | fl ExternalHostname,InternalHostname

5) Restart the MSExchangeAutodiscoverAppPool

These settings don't take effect immediately so you need to restart the MSExchangeAutodiscoverAppPool.

You can now open Outlook without any issues.