Redirection in Exchange 2013 CU6+ and Exchange 2016

Monday, May 2, 2016

Beginning with Exchange 2013 Cumulative Update 6, the Exchange 2013/2016 application itself performs redirection from the default website to the /OWA virtual directory. That means that if a user goes to https://server.contoso.com Exchange will redirect the user's browser to https://server.contoso.com/owa.

This 301 redirect behavior may affect load balancer health checks if your load balancer does not support direct URL health checking. Application-level health checks should normally be made directly to the https://server.contoso.com/<protocol>/healthcheck.htm URL. Citrix NetScaler load balancers, for example, perform healthchecks by connecting first to the default website and then performing a GET /OWA command. Since Exchange 2013 CU6 and later redirect the client (the load balancer) to the /OWA virtual directory this breaks that functionality.

The only reference to this new behavior is in the support article, Load balancer marks Exchange server as down in an Exchange Server 2013 Cumulative Update 6 environment. At the time of this writing, the article says this behavior applies to Microsoft Exchange Server 2013 Standard and Enterprise and that, "Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the 'Applies to' section." I have confirmed with the product team that this is by design, not a problem. It also applies to all versions of Exchange 2016 Standard and Enterprise, as well. Microsoft will be updating the support article soon to reflect this.

Note that this behavior does not redirect HTTP requests to HTTPS. You still need to perform these redirects from the server or the load balancer. My preference is to do this from the server(s).

Here's how I recommend implementing HTTP -> HTTPS redirection on Exchange Servers:

  • Open Internet Information Services (IIS) Manager on the Exchange Server and select the server name.
  • Double-click Error Pages.
  • Click the Add action on the right and create a new error page for status code 403.4 that responds with a 302 redirect to https://server.contoso.com/owa as shown below.


Since the default website on Exchange servers is configured to require SSL, a user who tries to connect via HTTP will then get redirected to https://mail.contoso.com/owa, rather than getting an error page saying, "HTTP 403 Forbidden" and that SSL is required or you are required to log in.

With Exchange 2013 CU6 or later that's all you need to do. With older versions of Exchange you should create a default.htm file in the C:\inetpub\wwwroot folder with the following:
<html>
<meta http-equiv="REFRESH" content="0;url=/owa">
</html>
This will cause anyone who connects to https://mail.contoso.com to be redirected to https://mail.contoso.com/owa, which is now the default behavior with Exchange 2013 CU6 or later.

Read more ...

Exchange Server Troubleshooting Companion Now Available

Wednesday, April 27, 2016
I'm pleased to have been the technical editor of the new eBook, Exchange Server Troubleshooting Companion. It's always enjoyable to work on a strong publication that I can stand behind.

The Exchange Server Troubleshooting Companion does much more than just give specific guidance about solving a particular problem. Any Bing or Google search can do that. This book teaches you the methodology and mindset required to troubleshoot any Exchange problem. It helps you understand the underpinnings of how Exchange works so that you can diagnose a problem quickly and accurately.

The author team includes fellow Exchange Server* MVPs, Paul Cunningham and Andrew Higginbotham. Between them, they have over 29 years of experience deploying, managing, and troubleshooting Exchange Server. You can read more about Andrew's take on the book on Reddit.

Veteran Exchange Server MVP Tony Redmond is the overall editor for the book, This keeps Tony busy with this project, as well as co-authoring Office 365 for IT Professionals. That's a good thing. We don't want Tony having too much time on his hands. ;)

I highly recommend both of these eBooks for your Exchange and Office 365 library. Both books are available in EPUB and Amazon Kindle formats. Please go to the exchangeserverpro website for ordering information.


* Late last year the Exchange Server MVP category has been rolled up into the Office Servers and Services MVP group to align more closely with Microsoft's cloud-first vision.
Read more ...

Congratulations 2016 Microsoft MVP!

Friday, April 1, 2016
I m pleased to announce that I have been given the Microsoft MVP award again for 2016. I have been awarded every year since 2009, so this will be my eighth consecutive year.


About mid 2015 Microsoft revamped the MVP Award program and rearranged the specialties. All Exchange Server MVPs were moved to the Office Servers and Services technical communities to better align with Microsoft's cloud-first offerings. That makes sense, since I work with so many more technologies than Exchange, both on-prem and in the cloud.

I feel great!


Read more ...

Linked Mailbox users will not sync in Azure AD with AAD Connect

Wednesday, March 30, 2016

You may find that some on-premises user accounts will not synchronize with Azure Active Directory using AAD Connect, no matter what you try. Once you rule out the obvious (OU filtering, object filtering, security permissions, etc.) check to see if the problem user has a linked mailbox in Exchange.

"An account with a linked mailbox will never be used for userPrincipalName and sourceAnchor. It is assumed that an active account will be found later."
I can't tell you what that last sentence is supposed to mean, but I can tell you that a linked mailbox cannot be soft-matched or hard-matched, and it will never provision itself in Azure AD. You will not see any warnings or errors in Synchronization Service Manager or the event logs indicating there's a problem -- the user just never gets provisioned in AAD, as if they are being filtered.

If you're handy with Synchronization Service Manager ("C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe"), you'll see that the on-prem user was pulled into the metaverse, but the Connectors tab only shows the on-prem AD connector. It does not show the corresponding tenant connector, as it should.


A linked mailbox is a special type of mailbox that is accessed by a user in a separate, trusted forest. I don't normally see orgs using linked mailboxes except during specific cross-forest migration scenarios. For example, during a merger or acquisition when both forests need to access the same mailbox. I have, however, seen occasions when a normal user mailbox is somehow converted to a linked mailbox during an Exchange upgrade. This usually happens because the source mailbox has some funky* permissions set on it, and by moving the mailbox to the new Exchange Server infrastructure the mailbox is converted from a user to a linked mailbox for some reason.  * Funky is a technical term.

If your environment is a single forest with no trusts or resource forests there's virtually no reason that any mailbox should be a linked mailbox. As a matter of fact, Exchange won't even let you create a linked mailbox unless there's a configured trusted forest in existence.

It is normally safe to convert a linked mailbox to a user mailbox with no ill effects. You cannot use the Exchange Admin Center to convert a linked mailbox to a user mailbox. You must use the Exchange Management Shell.

Use the following EMS command to convert a single linked mailbox to a user mailbox:
Set-User -Identity kljohnson@contoso.com -LinkedMasterAccount $null
Or you can use the following EMS command to convert all linked mailboxes to user mailboxes:
Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'LinkedMailbox')} | Set-User -LinkedMasterAccount $null
Once a linked mailbox has been converted to a user mailbox you can run a delta sync of AAD Connect using the following command and the user object(s) will now be provisioned correctly in Azure Active Directory.
Start-ADSyncSyncCycle -PolicyType Delta
I usually do this twice in a row to make sure both on-prem AD and Azure AD objects are completely up to date.
Read more ...

How to Schedule and Force Sync Updates with AAD Connect 1.1.x

Tuesday, March 8, 2016
Microsoft has made some significant changes to AAD Connect in version 1.1.x. New features include:
  • Automatic upgrade feature for Express settings customers
  • Support for the global admin using MFA and PIM in the installation wizard
  • Allow changing the user's sign-in method after initial install
  • Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all domains are available.
  • Scheduler is built-in to the sync engine and the default schedule is now 30 minutes
  • Plus there's MOAR!

You can download the latest version of AAD Connect here.

Note that the new Automatic Upgrade feature is not enabled unless you install AAD Connect with Express settings. Customized settings require more configuration, so automatic upgrade is not possible in these scenarios (yet).

They also changed the way you manage AAD Connect synchronization schedules and manual syncs (again). I swear sometimes these guys are psychotic.

Scheduling Synchronization

In previous versions, the synchronization schedule was implemented as a scheduled task in Windows. Now it's part of the sync engine and is configured via a PowerShell cmdlet. Previous versions synchronized every 3 hours, now it's every 30 minutes! Run the new Get-ADSyncScheduler cmdlet to view the current synchronization schedule:

Default synchronization schedule in AAD Connect 1.1.105

If you want to adjust the default schedule run the Set-ADSyncScheduler cmdlet. Note that you cannot set the scheduler less than the AllowedSyncCycleInterval of 30 minutes, but you can set it higher. If you try to use a value less than 30 minutes, you will get an error:

Cannot change AAD Connect sync frequency less than 30 minutes

If you DO find a way to adjust the schedule lower, understand that this is not supported by Microsoft.

Set-ADSyncScheduler accepts the following parameters:
  • CustomizedSyncCycleInterval <timespan> -- Used to set the custom sync cycle interval. Must be higher that the Allowed Sync Cycle Interval.
  • SyncCycleEnabled <bool> -- Enables or disables scheduled synchronization.
  • NextSyncCyclePolicyType <SynchronizationPolicyType> {Unspecified | Delta | Initial} -- Specifies how the next synchronization will work. Delta only syncs changes since the last sync. Initial will perform a full resynchronization.
  • PurgeRunHistoryInterval] <timespan> -- The interval when AAD Connect will purge the operation logs for past sync jobs. The default is keep them for 7 days.
  • MaintenanceEnabled] <bool> -- Enables maintenance mode to enable you to update the certificates/keys and purge the operations log.
  • Force -- Makes the setting changes without warnings or confirmation. It does NOT force AAD Connect to accept a custom sync schedule that it is lower than the Allowed Sync Cycle Interval.

Forcing Synchronization

If you want to run a sync sooner than the next scheduled run, you can do it manually using the new Start-ADSyncSyncCycle cmdlet. For example:
Start-ADSyncSyncCycle -PolicyType Delta
This will force a delta sync immediately, as long as a scheduled sync is not running. Use PolicyType Initial to force a full sync.

Read more ...

Important Information about Group Expansion for In-Place Holds

Thursday, March 3, 2016
Exchange 2013, Exchange 2016, and Exchange Online in Office 365 all support In-Place Hold. In-Place Hold allows compliance administrators to retain specific data in Exchange for eDiscovery in an immutable fashion.

In-Place Hold differs from Litigation Hold in a few key ways. Litigation Hold allows you to hold all contents of one or more mailboxes. In-Place Hold allows you to define what data to hold (keywords, specific senders/recipients, and start/end dates, and the types of data, such as emails or calendar items). Both In-Place and Litigation Hold allow you to specify how long to hold this data.

When you configure a new In-Place Hold you have the option to place a group on hold. You need to be aware that group membership is expanded at the time the In-Place Hold is created, and the sources of the In-Place Hold do not automatically adjust if the group membership changes.

For example, I'll create an In-Place Hold for the members of Keith's Group.

Creating a new In-Place Hold for members of Keith's Group
I configure the search parameters, enable the In-Place Hold, and click Finish. Exchange then displays the following warning:
To enable In-Place Hold for the mailbox search, the distribution groups specified in the "Source mailboxes" field must be expanded. The task can expand the group members and save the expanded mailboxes as the source mailboxes of the mailbox search. Do you want to expand the group?
You have to click OK to continue. If you click Cancel it will not save the In-Place Hold.

Warning about group expansion
If you edit the new In-Place hold you will see that Keith's Group has been replaced with the members of the group at the time the In-Place hold was created.

Expanded group
There is no longer any link between Keith's Group and the new In-Place Hold sources. If the group membership changes, you will need to edit the mailbox sources for the In Place Hold manually.

Note that this expansion behavior is the same, whether you use distribution groups, mail-enabled security groups, or dynamic distribution groups.

Read more ...

The Importance of the @ record for Autodiscover

Tuesday, March 1, 2016

Ever since Outlook 2007, Outlook has used the Autodiscover web service to automatically configure itself for Exchange access. Outlook does this by trying to connect to Autodiscover externally using several methods that are hard coded into the product in this order:
  1. HTTPS root domain query (e.g. https://contoso.com/Autodiscover/Autodiscover.xml)
  2. HTTPS Autodiscover domain query (e.g. https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml)
  3. Local XML file
  4. HTTP redirect method (e.g. http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml, expecting a redirect to an HTTPS URL)
  5. SRV DNS record query (e.g looking for an SRV record called _autodiscover._tcp.contoso.com)
  6. Cached URL in the Outlook profile (if a previous Autodiscover URL was found and cached)
It's rather unfortunate that Outlook uses the HTTPS root domain query first. I mean, really, how many companies publish Autodiscover off their root domain?!? I can count how many times I've come across this on NO fingers. Even so, this can cause some real problems, especially when your external DNS is hosted by a third-party service that hosts many many other DNS domains.

If you're having issues with Autodiscover taking several minutes to run and long delays when viewing free/busy information in Outlook, it might be because you don't have a special A record in DNS that redirects the root domain to your company website. Most third-party DNS hosters do not handle this redirection automatically. You can fix this yourself by adding an A record for @ that points to the same IP address used for by your company website (e.g. www.contoso.com).

For example, let's say you ping your root domain (contoso.com) and it resolves to 69.42.215.253, which happens to be the IP address of your DNS hosting provider.

Now you ping your company website (www.contoso.com) and it resolves to 75.25.134.99.

Create an A record in DNS for the host @ that resolves to the IP address of your company website. For example:


Now when users (or Outlook) use contoso.com it will redirect to your company website (www.contoso.com). Outlook will be much happier (it will not take 2 minutes to timeout) and the browser experience will be more consistent. It's a win-win.

Read more ...