Exchange 2013

Exchange 2013

Unleash the “Hidden Magic” in the Exchange Server Role Requirements Calculator


Every Exchange project should use the Exchange Server Role Requirements Calculator. The calculator helps us estimate the hardware requirements for new Exchange Server environments. All it needs is some input about your design requirements, along with the user messaging profiles.

Microsoft updates the Exchange Server Role Requirements Calculator regularly. Before you start designing a new environment, make sure to download the newest version available. You can see the changes in each version on the release notes page. At the time of this writing, the latest version is 9.1.

As you can see in the screenshot above, the calculator is an Excel spreadsheet with several tabs. You fill out the Input tab and the calculator does the rest for us.

The purpose of the calculator is to give us an accurate view of the hardware requirements of the Exchange Server design. But what many people don’t realize is that also provides us with deployment scripts. This is what I refer to as the secret magic of the calculator.

The Deployment Scripts

The deployment scripts generated by the Exchange Server Role Requirements Calculator provide us with several benefits:

  • Speeds up the deployment of the Exchange servers and DAG
  • Provides documentation of the steps taken during the DAG implementation
  • Makes sure you don’t miss some of the vital configuration steps during DAG setup
  • Makes for a reusable process if you work as a consultant in different environments

This is a great tool for you to take advantage of. The days of logging on to each server and manually making configuration changes are over. Instead, we should be scripting deployments so that we achieve predictable outcomes.

So, where do we find these deployment scripts? Well, they’re hiding out on the tab in the calculator named Distribution.

As you can see we have five buttons:

  • Export DB Mount List – creates the Servers.csv file.
  • Export DAG List – creates the DAGInfo.csv file.
  • Export Primary DB List – Creates the MailboxDatabases.csv file.
  • Export Copy DB List – Creates the MailboxDatabaseCopies.csv file.
  • Export Role Calculator Scripts – Generates the PowerShell scripts for deploying the Exchange servers and DAG.

The first four buttons on the Distribution tab generate custom CSV formatted input files. We use these files together with the bundled deployment scripts. The custom CSV files are based the data you entered in the Input tab of the calculator. They also display a pop-up dialog for some extra information.

The last button, Export Role Calculator Script, creates the following script files:

  • DiskPart.ps1 – uses the Servers.csv file for input. This script brings the data disks of the Exchange Server online, formats them, and mounts the volumes. The script will align with the recommendations of the Exchange Preferred Architecture for the volume mount points.
  • CreateDAG.ps1 – uses the DAGinfo.csv file for input. This script creates the Database Availability Group and configures relevant settings such as the File Share Witness, and the number of database copies per volume.
  • CreateMBDatabases.ps1 – uses the MailboxDatabases.csv file for input. This script creates the active databases, specifies the folder paths, and configures settings such as default mailbox quotas.
  • CreateMBDatabaseCopies.ps1 – uses the MailboxDatabaseCopies.csv file for input. This script creates the mailbox database copies, and also configures any lagged database copies.

Providing Naming Information

Before generating the script input files, you should review and edit the Role Requirements Input Factors – Database Availability Group Configuration, found on the Input tab of the calculator. Here we define the server names, DAG name and mailbox database naming prefix.

In the example below, I’m using server names of JN-MBX-1 and JN-MBX-2. Don’t worry about changing all the server names in the list. The CSV file will only use of the same number of names as you set in the Number of Mailbox Servers Hosting Active Mailboxes / DAG field of the Input tab.

Additionally, I want my DAG to be named JN-DAG-1 and the prefix for my Databases set to JN-MDB.

Generating the Script Input Files

Now we can proceed with creating the CSV files to use as input for the deployment scripts. Start by clicking the Export DB Mount List button on the Distribution tab. The following dialog box will appear, prompting for information about where to save the CSV file. It will also ask you if you want to use a different volume/database root and file system format than the recommended values.

It’s very important to specify the correct First DAG Drive. This is the drive from where the scripts start to initiate actions such as formatting disks. You can retrieve the correct disk number by running Diskpart.exe from a command prompt on the server, and then the List Disk command.

Next, click the Export DAG List button. This dialog box is a bit more detailed and requires information about your global catalogs and file share witness server. You’ll notice there are also a series of configuration choices for the DAG itself. Ideally you have already made those design decisions before you get to this stage of your project. If not, you can use the defaults provided, but I do recommend you research each of them so that you understand what they mean.

Next, we can generate the CSV file for the mailbox databases by clicking on the Export Primary Database List button. Again, the input that you provide in this dialog will depend on your design decisions for the environment you’re deploying. The default values align with Microsoft’s recommendations in the Preferred Architecture. As with the DAG configuration, you should research those options to make sure you understand the implications of each of them.

Finally, click on the Export Copy DB List button to create the input file for the mailbox database copies script. For that script, there is only the need to specify the export path for the input file MailboxDatabaseCopies.csv. The script that configures the database copies also uses information in the MailboxDatabases.csv file.

Using the Exchange Deployment Scripts

The deployment scripts themselves are generated by clicking the last button, Export Role Calculator Scripts. You can open each script in the PowerShell ISE or your favorite PowerShell code editor to see help information and instructions for running the scripts.

Before using the scripts generated by the Exchange Server Role Requirements Calculator, we need to have Exchange Server installed onto the servers, and the storage disks present and ready for formatting and mounting.

The deployment scripts are run in the following order:

  • DiskPart.ps1 to configure the storage volumes.
  • CreateDAG.ps1 to create the database availability group and add your Exchange servers as DAG members.
  • CreateMBDatabases.ps1 to create and configure the mailbox databases.
  • CreateMBDatabaseCopies.ps1 – to add copies of the mailbox databases on other DAG members, and configure any lagged copies.

Although this may all seem like more work than just manually installing and configuring your DAG, by investing the time up front you will avoid human errors during the configuration. Also, you now have a repeatable process for sizing and deploying Exchange servers. And if you save the calculator, CSV files, and scripts, you will also have a basis for the documentation of the newly deployed Exchange servers and DAG.

read more
Exchange 2013

March 2018 Updates Released for Exchange Server


Microsoft has released the latest quarterly updated for Exchange Server 2016 and 2013, as well as an update rollup for Exchange 2010.

The Exchange 2016 and 2013 cumulative updates include the following changes and improvements:

  • Full support for TLS 1.2 on supported Exchange versions (i.e. not older CU’s that are already out of support). Refer to the further guidance here.

Microsoft also reminds customers to upgrade to .NET Framework 4.7.1 before the June 2018 quarterly release:

Reminder that customers should be in the process of moving to .NET Framework 4.7.1. .NET Framework 4.7.1 will be required on Exchange Server 2013 and 2016 installations starting with our June 2018 quarterly releases. Customers should plan to upgrade to .NET Framework 4.7.1 after applying March 2018 quarterly release to avoid blocking installation of the June 2018 quarterly releases for Exchange Server 2013 and 2016.

Additional Information

read more
Exchange 2013

You Can Stop Deploying Exchange Server 2013 Now


For some reason I’ve seen a bunch of forums posts and emails about new Exchange Server 2013 deployments in the last week. The timing is notable, because Exchange Server 2013 has entered the “extended support” phase of its support lifecycle as of April 10th (a few days ago).

From Microsoft’s announcement:

With the transition of Exchange Server 2013 to Extended Support, the quarterly release schedule of cumulative updates will end. The last planned cumulative update for Exchange Server 2013, Cumulative Update 21, will be released in June 2018. Microsoft may at its discretion release a future cumulative update to aggregate previously released critical updates or to address unforeseen future O365 Hybrid connectivity requirements. At this time there is no explicit plan to exercise releasing future cumulative updates.

So… that’s the end of Exchange 2013 feature development. It hasn’t received significant new features in a long time anyway, but the transition to extended support pretty much seals the deal. If you’re on Exchange 2013 today, make sure you update to CU21 when it is released in June so that you can continue to receive security updates during the extended support phase.

If you are planning a new Exchange on-premises deployment today, you should deploy Exchange Server 2016. The exception would be if you are still, for some reason, running Exchange Server 2007 in your environment. In that situation, an Exchange 2013 migration must be used as an intermediate step to Exchange 2016, because Exchange 2007 and 2016 can’t co-exist in the same organization.

read more
Exchange 2013

June 2018 Updates Released for Exchange Server


Microsoft has released the latest quarterly updated for Exchange Server 2016 and 2013, as well as an update rollup for Exchange 2010.

Some notes to be aware of:

  • Exchange 2016 CU10 and Exchange 2013 CU21 require .NET Framework 4.7.1 be installed on the server before you install the CU. This requirement was called out as far back as September 2017. If you have a scenario where you can’t see a path to upgrade .NET and Exchange while staying within supported combinations of the two, refer to this article for guidance.
  • The VC++ 2013 runtime is also a pre-requisite for the updates released this month to “provide current and future security updates for a third party component shipped with Exchange Server. The component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016.”
  • Also included in these updates is a critical security patch for the Oracle Outside In libraries, which provide “WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016.” The update is described in MSRC advisory ADV180010. Microsoft has not allocated a severity rating to their advisory (currently it says “None”), but Oracle refers to it as a critical update in their advisory in April. It’s unclear whether that is due to previous critical vulnerabilities patched in the code, or new ones disclosed in April.

Microsoft’s normal practice is to release security updates separately to cumulative updates. In other words, a security update for a supported version of Exchange should always be available as a standalone update, and not require you to install an entire CU to receive the security update. This quarter they have not done that. The security update included in these quarterly updates is not available separately. Microsoft’s statement on this matter is:

The Exchange team has previously stated they will not ship security fixes in a cumulative update not previously released separate from a cumulative update. That goal and official plan of record are unchanged. Shipping the updated third party components in a cumulative update was necessary to integrate a new version of the components and a new product dependency not previously required by Exchange in a manner customers are accustomed to with minimal disruption to the Windows Update process.

New Exchange 2016 and 2013 Cmdlets for Creating and Modifying Remote Shared Mailboxes

A long standing issue with managing shared mailboxes in hybrid environments has been the inability to manage shared mailboxes in Exchange Online by running on-premises Exchange cmdlets. For user mailboxes, the New-RemoteMailbox, Enable-RemoteMailbox, and Set-RemoteMailbox cmdlets can be used. But for shared mailboxes it was necessary to create the shared mailbox on-premises first, then migrate it to Exchange Online. Or alternatively, create the remote mailbox as a user mailbox in Exchange Online, and then convert it to a shared mailbox.

Quietly mentioned in the release notes for the cumulative updates released this quarter are updates to the *-RemoteMailbox cmdlets to add a -Shared parameter, enabling the management of remote shared mailboxes from the on-premises Exchange management shell.

To receive this update you must ensure that you prepare your Active Directory using the setup.exe file in Exchange 2016 CU10 or Exchange 2013 CU21.

If you do not manually prepare AD then setup might not do the preparation automatically for you. This depends on which previous version of Exchange you’re updating from. The safest approach is to manually prepare AD yourself to ensure that it is done.

Exchange Server 2013 Extended Support

Microsoft has included a note in this release that Exchange Server 2013 is now in the extended support phase of its lifecycle. Cumulative Update 21 is the last planned CU for Exchange Server 2013, so you must update to CU21 to continue to receive security updates, and for support in hybrid environments. Microsoft may at their discretion release future CUs if required for security or hybrid compatibility reasons.

Exchange Server 2010 Updates

Exchange 2010 SP3 UR22 adds support for Windows Server 2016 domain controllers. Prior to this update it was necessary to include pre-2016 domain controllers in AD sites where Exchange 2010 is running.

There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

UR22 also fixes an Exchange Web Services (EWS) impersonation issue for 2010/2016 co-existence environments.

Additional Information

read more
Exchange 2013

Exchange Server 2013 Books


As more and more organizations are deploying or upgrading to Exchange Server 2013 I’m seeing an increased number of questions about which Exchange Server 2013 books are the best to read.

I haven’t written any book reviews for Exchange Server 2013 for a couple of reasons. Firstly, I prefer to actually read all (or most) of a book before writing an opinion about it. Secondly, book reviews are quite boring to write, and I suspect equally as boring to read. There is a standard formula to most book reviews and you really don’t need me to tell you what the table of contents for a book already says.

What I think would be more useful is some ideas around which books suit which audiences, so that you can choose what will hopefully be the best book for your needs. There is no one book that is perfect or covers the entire product for all scenarios, so it is possible you will end up with two or three of them to get the coverage you really need in your job.

This page contains Amazon affiliate links. If you make a purchase through one of these links, I earn a small commission at no extra cost to you.

Deploying and Managing Exchange Server 2013 High Availability

ha-guide-coverThis is an ebook written by Exchange Server MVPs Paul Cunningham, Michael Van Horenbeeck and Steve Goodman. As the title suggests this ebook is all about Exchange Server 2013 high availability, and starts off by explaining some high level concepts before diving in to the technical detail of each server role’s specific high availability features and requirements.

Topics covered in this ebook including namespace planning, load balancing, database availability groups, and site resilience, as well as a whole lot more.

Found out more here.

Exchange Server 2013 Inside Out

book-cover-exchange-2013-inside-out-1Inside Out is actually two books written by long-time MVPs Tony Redmond and Paul Robichaux.

Writing about Exchange Server 2013 in enough depth as a single volume would simply be too big a task (and too big a book for us to have to handle, if you’re one of those folks who still likes print books).

book-cover-exchange-2013-inside-out-2Let me just say that these two gentlemen are very well respected MVPs not only due to the length of their tenure, but also because of the depth of understanding they have of all things Microsoft Exchange Server, and their ability to communicate that through books and training sessions. So you can be confident that the Inside Out books are top notch.

I would recommend these titles to anyone who wants to learn not just step by step skills, but also gain a very deep understanding of the features of Exchange Server 2013 and some of the history and reasons that those features have developed the way they are today.

Exchange Server 2013: Design, Deploy and Deliver an Enterprise Messaging Solution

book-cover-design-deploy-and-deliver-exchange-2013As I write this the book has two bad reviews on Amazon, which is surprising because this is an excellent book written by three people who are experts in the field (two work for Microsoft and one is an MVP and MCM).

I honestly think this was a simple misunderstanding about the purpose of this book, which is actually quite clearly stated in the Amazon blurb by statements such as “Focuses on the Exchange ecosystem rather than just the features and functions of the Exchange product” and “Focuses on scenarios facing real customers and explains how problems can be solved and requirements met“.

This is a book about designing and delivering a solution that meets business needs, not just about administering the system post-deployment (though you will clearly learn a lot about that anyway).

So I would recommend this title for those who will most likely be designing, deploying and delivering Exchange 2013 solutions for customers (just as the title suggests :)).

Exchange Server 2013 PowerShell Cookbook – Second Edition

This book is an update to the excellent Exchange Server 2010 PowerShell Cookbook, which I am a big fan of. Even as a second edition there is plenty of new content inside.

I would recommend this title to Exchange administrators who are proficient with Exchange but who stick primarily to the GUI admin tools, as well as administrators who are new to Exchange but smart enough to know that PowerShell is where the most efficient work can be performed.

Exchange 2013 Cookbook

Another “cookbook” style book, this time about Exchange 2013 in general rather than being focussed on PowerShell.

Full disclosure: I was a technical reviewer for this book. However I receive no compensation or royalties for book sales. On the other hand, it also means I have read every single word in the book 🙂

With MVP and MCM Michael Van Horenbeeck as an author you know the content in this book is going to be solid. The “cookbook” style involves demonstrating specific tasks and then explaining in more detail what has just happened. This makes it both a good front to back read as well as a good reference to dip into from time to time.

I would recommend this title for administrators (or “accidental administrators” as the book refers to them) who need a quick reference to help them with ad-hoc tasks, or for someone who is looking for a book that they can work through with a test lab to learn more about Exchange Server 2013 (though I can’t vouch for it either way in terms of suitability for exam preparation).

Other Titles

A year into the release of Exchange Server 2013 we are now seeing a good number of solid titles available for those of us looking to study and learn more about the product.

What about other titles?

There are certainly more Exchange 2013 books available than just those listed above. Either I have not read them yet, or have read them and would not recommend them, or have decided they are not worth reading due to some other factor, and so I have not included them here.

If more good quality titles are released in future I will certainly update this post to include them.

If you’d like to share your own opinions or experience with any Exchange Server 2013 books please feel free to leave a comment below.

read more
Exchange 2013

Installing Exchange 2013 Cumulative Updates


In this article I will demonstrate the step by step process for installing cumulative updates and service packs for Exchange Server 2013.

The steps for installing cumulative updates and service packs on Exchange 2013 are:

  1. Prepare by downloading update files, checking backups, and reviewing known issues
  2. Update mailbox and multi-role servers in the internet-facing sites
  3. Update client access servers in the internet-facing sites (if any)
  4. Update Exchange 2013 servers in any remaining internal sites (if any)
  5. Update Edge Transport servers (if any)
  6. Perform health checks and rebalancing of servers

Preparation Tasks

Before installing any cumulative updates you should:

  • Download the CU or Service Pack setup file from the Microsoft Download Center (do not download from third party sites) and extract it to a folder on each server. You can download the latest cumulative update and upgrade an Exchange 2013 server to the latest version in one update. You do not need to install all of the cumulative updates released between your current version and the latest version.
  • Take a confirmed backup of Active Directory.
  • Take a confirmed backup of your existing Exchange 2013 servers and databases.
  • Have documented any customizations such as OWA, config files on servers, registry changes, Lync integration, or third party add-ons.
  • Review this known issue with receive connectors that can cause upgrades to fail, leaving servers in a non-operational state.
  • Verify that your Exchange SSL certificates have not expired.
  • Check the Exchange Supportability Matrix and verify that you are maintaining the .NET Framework on your servers to remain compatible with Exchange.

Installing Cumulative Updates and Service Packs

Cumulative updates and Service Packs should be installed in the internet-facing site first, before installing in other sites in the organization.

  • The first servers to be updated in a site are the Mailbox servers.
  • The Client Access servers are updated second.
  • Edge Transport servers can be updated last.

If you have multi-role CAS/MBX servers installed then setup updates the roles in the correct order anyway, and you should simply start with the internet-facing servers.

During the deployment of a cumulative update within a site that contains load-balanced Client Access server or Database Availability Group members there will be a period where servers are not at exactly the same version. Although this is expected and supported, it is not supported to stay in that state for a long period of time.

In other words, you should plan to update all DAG members within a short period of time, and not allow them to run at different versions for days, weeks or months.

Updating Mailbox Servers

Mailbox servers in a multi-server environment, whether installed as standalone or as a multi-role server, should be placed into maintenance mode before installing the cumulative update.

Note that the redirect target server must be provided as a fully qualified domain name.

If the server is a DAG member proceed to the next section which contains additional steps for DAG members, otherwise put the server into maintenance mode with the following command.


Exchange MVP Michael Van Horenbeeck has published a script for automating the process of starting and stopping maintenance mode.

Updating Mailbox Servers that are Database Availability Group Members

In addition to placing Mailbox servers in maintenance mode any DAG members also need to have active mailbox databases moved to another DAG member, and be blocked from activation while the cumulative update is being installed.

Suspend the DAG member from the cluster.

Disable database copy activation.

Review the existing database copy auto activation policy, so that you can return it to the same configuration after you’ve completed the upgrade.

Set the auto activation policy to “Blocked”. If the policy is already set to “Blocked” then there is no action required.

Put the server into maintenance mode.


Taking Servers Out of Maintenance Mode

To take the server out of maintenance mode after the upgrade the process is reversed. Make sure that you return the database auto activation policy to the original setting if it was not “Unrestricted”.


Exchange MVP Michael Van Horenbeeck has published a script for automating the process of starting and stopping maintenance mode.

Updating Load-Balanced Client Access Servers

If you are running load-balanced Client Access servers in a site then you should configure the load balancer to remove the server from the pool of hosts, and allow any existing connections to close, before you install the cumulative update.

The exact steps for this will depend on the load balancing solution that you use, and you should refer to your vendor documentation for those.

As each Client Access server is updated join it to the pool again and then repeat the process for the next server.

Active Directory Preparation Tasks

Some cumulative updates will include Active Directory schema changes. In those cases the following steps will be required.

Note: The AD preparation tasks are not required to be run separately to the upgrade of Exchange, unless in circumstances where you need to separate the tasks to different teams with different permissions, or if you have a multi-domain forest and want to control the AD changes.

Before applying the schema update follow the steps provided by Michael B Smith to retrieve the existing Exchange schema version, so that you can compare it before and after the AD preparation steps have been completed to verify that the schema update was applied.

  1. Run setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms (requires Enterprise Admins and Schema Admins permissions, and must be performed in the same AD Site as the Schema Master on a server with the RSAT-ADDS-Tools feature installed – the Schema Master itself would meet these requirements)
  2. Run setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
  3. Run setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms in each domain in your forest that contains Exchange servers or mailboxes

When the Active Directory changes have been applied, on each server run the upgrade.

Upgrading the Servers

Cumulative updates can be applied using either the command line or graphical setup, whichever you prefer. Both options are demonstrated below.

  • Follow the pre-installation processes outlined earlier in this article depending on the server roles installed.
  • Do not run the upgrade from the Exchange Management Shell as this will cause it to fail due to locked files. Run the upgrade from an elevated cmd prompt.
  • If you receive a warning that the Office Filter Pack is not installed this can be ignored, as it is not a required component for Exchange Server 2013.
  • Set the PowerShell execution policy on each server being upgraded to Unrestricted, as this may sometimes cause issues with update. Refer to KB981474.

Caution: a cumulative update is a full reinstall of Exchange Server 2013. If it is interrupted, or fails part way through the installation, you may need to perform a server recovery. There is also no way to uninstall a cumulative update.

Note: Exchange 2013 cumulative updates stop the “Microsoft Exchange FrontEnd Transport” and “Microsoft Exchange Transport” services during the pre-requisites check. If you do not proceed with the installation you will need to manually restart the Microsoft Exchange Transport service.

Upgrading Using the Command Line

In an elevated command prompt run the following command from the location where you extracted the cumulative update files.

The command prompt window will display the progress as the upgrade proceeds. The upgrade itself is a lengthy process so you should allow plenty of time for each server.

After the cumulative update has been install restart the server if prompted to do so.

If you had placed the server into maintenance mode then you can run the commands or the script for stopping maintenance mode after the installation is finished (refer to the notes above).

Upgrading Using the Graphical Setup

From the location that you extracted the cumulative update files run Setup.exe. It is recommend to allow setup to connect to the internet and check for updates.


When the update check has completed click Next to continue.


Setup will begin copying files. This can take several minutes depending on your server’s performance capacity.


Setup will detect that this is an upgrade installation.


You will need to accept the license agreement each time you upgrade a server.


Setup will perform a pre-requisites check. If any pre-requisites are not met setup will stop and warn you about them, otherwise you will be able to proceed with the upgrade.


The upgrade itself is a lengthy process and you may find that some steps appear to have hung with no progress. This may be a bug with the graphical setup, whereas the command line setup will typically show the percentage progress as it goes.


When setup is complete you will be prompted to restart the server if required.


After the cumulative update has been install restart the server if prompted to do so.

If you had placed the server into maintenance mode then you can run the commands or the script for stopping maintenance mode after the installation is finished (refer to the notes above).

Post-Installation Tasks

After deploying an Exchange 2013 cumulative update there are a number of post-installation tasks that may be required.

Rebalance the Database Availability Group

After you’ve updated all of your DAG members there is a good chance that the active databases will not be evenly distributed across the DAG, or won’t be on their first activation preference. This process is the same for Exchange 2013 as it is for Exchange 2010.


Restoring Customizations

After you have completed updating your servers you will need to re-apply any customizations that you had documented during the preparation steps above.

Verifying Server Health

Here are some suggestions for health checking your Exchange 2013 servers after applying updates.

  1. Check the cluster nodes are all up – verify that you have not left any DAG members suspended in the cluster by running the Get-ClusterNode cmdlet on one of the DAG members.
  2. Test service health – use the Test-ServiceHealth cmdlet to verify that all required services are running on each server.
  3. Test MAPI connectivity to every database – use the Test-MAPIConnectivity cmdlet to verify that all databases are mounted and accessible.
  4. Check the database copy status for DAGs – use the Get-MailboxDatabaseCopyStatus cmdlet to verify that all database copies, copy/replay queues, and content indexes are healthy.
  5. Test replication health for DAGs – use the Test-ReplicationHealthcmdlet on each DAG member to verify replication health is good.
  6. Check the database activation policy for each Mailbox server – verify that each Mailbox server that is in a DAG has the correct database activation policy for your environment.
  7. Check server component status – use Get-ServerComponent to verify that you have not left any servers in maintenance mode.
  8. Run Exchange Analyzer to check for best practices compliance.

You can also use Test-ExchangeServerHealth.ps1 to review the health of your environment.


Thanks to Exchange MVPs Tony RedmondJeff GuilletMichael B Smith, and Michael Van Horenbeeck for sharing their notes and experiences with the cumulative update process.

read more
Exchange 2013

Upgrading to Exchange Server 2013


Exchange Server 2013 CU1 or later (not RTM) supports co-existence with the following previous versions of Exchange Server:

  • Exchange Server 2010 SP3
  • Exchange Server 2007 SP3 + update rollup 10

There will be no co-existence support for Exchange Server 2003. If you’re still running Exchange 2003 and are looking to upgrade to Exchange 2013 you’ll need to do an interim upgrade to Exchange 2010 (or 2007) first. I recommend an upgrade to Exchange 2010 instead of 2007, as it makes for a better upgrade experience to Exchange 2013.

Active Directory Requirements for Exchange Server 2013

Exchange 2013  support a Windows Server 2003 Forest/Domain functional level, and Windows Server 2003 SP2 domain controllers.

A schema update will be required as usual, and this is part of the same service pack/update rollup that is required for co-existence support.

The Upgrade Process for Exchange Server 2013

The high level documentation and general guidance for Exchange 2013 upgrades has been published at the Microsoft Exchange Server Deployment Assistant.

For more detail on the Exchange 2013 upgrade process you can follow my article series here:

Many of the challenges in these upgrades come not from Exchange itself, but more from the integration points such as third party software. In that respect you will need to watch for announcements from the vendors for products such as your backup software.

Client Support for Exchange Server 2013

The following clients are compatible with Exchange Server 2013.

For more information on discovery of client versions in your environment see the following article:

There is no support for Outlook 2003. If you’re still running Office 2003 in your environment and intend to upgrade to Exchange 2013 then you will need to upgrade Office first.

read more
Exchange 2013

Exchange Server 2013 Database Availability Group


The high availability feature for Exchange Server 2013 Mailbox servers is the Database Availability Group. Exchange 2013 Database Availability Groups (DAGs) are very similar to Exchange 2010 DAGs, but also deliver a series of improvements and new features for customers. In this series of articles we will walk through an overview of Database Availability Group concepts, demonstrate how to deploy a new Database Availability Group, and explore some of the operational tasks associated with running and maintaining a DAG. See also:

Overview of Exchange Server 2013 Database Availability Groups

A Database Availability Group consists of up to 16 Exchange 2013 Mailbox servers, and optionally one or more additional non-Exchange servers that may be required to act as a File Share Witness (more on this shortly). The Mailbox servers within a DAG are capable of hosting a copy of a mailbox database from another DAG member; up to the Exchange 2013 limit of 100 mailbox databases per server (that includes both active and passive database copies). A simple example of a Database Availability Group would be as follows.

Exchange 2013 Database Availability Group Simple Example
A simple example of an Exchange 2013 Database Availability Group

In the example above the server EXMB1 hosts the active copy of database DB1, and the other DAG members EXMB2 and EXMB3 host passive copies of the database. The DAG members work together to maintain the availability of the mailbox database. If the server that hosts the active database copy experiences a problem, for example a hardware failure, one of the remaining DAG members is able (under the right conditions) to make it’s copy of the database active so clients are still able to connect to their mailbox data.

Exchange 2013 DAG member down
DAG member EXMB1 has failed causing database to become active on EXMB2

A Mailbox server that is a member of a DAG can host a mixture of active and passive database copies for which it participates in replication. Whether a given database is active or passive on a particular DAG member is independent of the active/passive status of other databases that are also hosted on that DAG member.

Exchange 2013 multiple databases in a DAG
Multiple databases within an Exchange 2013 DAG

In the above example a DAG with three members and three mailbox databases is shown with the active database copies evenly distributed across the available DAG members.

Continuous Replication in Exchange Server 2013 Database Availability Groups

Each DAG member hosting a copy of a given mailbox database participates in a process of continuous replication to keep the copies consistent. Database replication occurs between Exchange Server 2013 DAG members using two different methods:

File Mode replication – each transaction log is fully written (a 1MB log file) and then then copied from the DAG member hosting the active database copy to each DAG member that host a passive database copy of that database.

The other DAG members then replay the transaction log file into their own passive copy of the database to update it. File mode replication has an obvious downside in that a transaction log that hasn’t already been copied to the other DAG members may be lost if the DAG member hosting the active database copy becomes unavailable. Although there are other recovery mechanisms to minimise the impact of this scenario, this is a reason why file mode replication is used only during the initial seeding of a database copy.

After seeding is complete the database switches automatically to block mode replication.

Block mode replication – as each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database. As the log buffer becomes full member of the DAG is then able to build their own transaction log file for replay into their passive database copy. Block mode replication has advantages compared to file mode replication when there is a failure in the DAG, because less transaction log data is likely to be lost.

Quorum for Exchange Server 2013 Database Availability Groups

An Exchange 2013 DAG utilizes Windows Failover Clustering and the quorum model. This underlying cluster is managed automatically for you by Exchange, so you don’t need to worry about it much other than to be aware of how quorum works. If the concept of quorum is new to you just think of it as a voting process in which a majority of voting members must be present to make a decision. The decision in the case of a DAG is basically whether the DAG should be online of offline. Because a majority of votes is required for quorum there are two different quorum models used depending on how many DAG members you have. For a DAG with an odd number of members the Node Majority quorum mode is used.

Exchange 2013 DAG quorum example
Impact of failures in Exchange 2013 DAG using Node Majority quorum mode

In the above example a three member DAG is able to maintain quorum during a single server failure, but quorum is lost when two servers are unavailable. For a DAG with an even number of members the Node and File Share Majority quorum mode is used. This mode involves an additional server referred to as the File Share Witness. It is typically another Exchange server located in the same site as the DAG members.

Exchange 2013 DAG quorum example
Impact of failures in Exchange 2013 DAG using Node and File Share Majority quorum mode

In the above example a four member DAG is using an additional server as the File Share Witness (FSW). The DAG is able to maintain quorum with up to two server failures, but quorum is lost when three servers are down.

DAGs deployed on Windows Server 2012 can be more resilient to multiple node failures thanks to a new feature called dynamic quorum. For more information see Improving Resilience of Exchange Server 2013 Database Availability Groups with Windows Server 2012 Cluster Dynamic Quorum

Database Availability Networks

A DAG network refers to a collection of one or more IP subnets that the DAG members are connected to and are used for client and replication traffic.

Exchange 2013 DAG with a single network
Exchange 2013 DAG with a single network

Every DAG has one network for client traffic, and then it can also optionally have a number of networks dedicated to replication traffic.

Exchange 2013 DAG with multiple networks
Exchange 2013 DAG with multiple networks

Dedicated replication networks can help reduce bandwidth utilization on the client-facing network which may prevent network-related performance issues for the clients.

Exchange Server 2013 will attempt to auto-configure DAG networks but may not be able to if the network adapter configurations are not correct. For more info see Misconfigured Subnets Appear in Exchange Server 2013 DAG Network

High Availability and Site Resilience

Exchange Server 2013 Database Availability Groups can be deployed to provide both high availability and site resilience. A DAG deployed for high availability will typically exist within a single Active Directory Site, or datacenter.

Exchange 2013 DAG High Availability
Exchange 2013 DAG in a single datacenter

A DAG deployed for site resilience will span multiple datacenters. The objectives of a Database Availability Group deployed for site resilience are usually to provide availability of mailbox services after the complete failure of the primary datacenter. In other words, a true disaster.

Exchange 2013 DAG in multiple datacenters
Exchange 2013 DAG in multiple datacenters

As such there are a lot more technical and business considerations for a site resilient Database Availability Group. There is also less automation and more administrator attention required for a full site failover scenario. For the purposes of this article series we’ll be focusing on Database Availability Groups deployed within a single datacenter for high availability.

Installing an Exchange Server 2013 Database Availability Group

The next article in this series will begin demonstrating the deployment of a Database Availability Group in Exchange Server 2013.

read more
Exchange 2013

Room and Equipment Mailboxes in Exchange Server 2013


Resource mailboxes have been around for a few versions of Exchange Server, and Exchange Server 2013 brings us a few improvements in how they are managed.

There are two types of resource mailboxes:

  • Room mailboxes are for fixed locations such as meeting rooms or conference facilities
  • Equipment mailboxes are for items that are not fixed to a location, such as laptops or vehicles

Exchange 2013 puts resource mailboxes under their own section of the Exchange Administration Center. Both room and equipment mailboxes are managed in this same section.

One of the immediate improvements is that you are able to set the booking policy or assign delegates during the creation of the resource mailbox, rather than as a secondary task after the mailbox is created.

After the mailbox has been created there are a few additional properties you can customize. The booking options can be further tuned with regards to recurring meetings, booking horizon, and custom replies.

You can also easily configure a MailTip for the resource mailbox.

The text that you place in the MailTip will appear automatically when people add the room or resource mailbox to a meeting request in Outlook. Although in my opinion the MailTip needs some color to draw the person’s attention to it.

Finally, an interesting default setting is the disabling of email address policies. This does make sense as most resource mailboxes are for internal use only, so having email address policies assigning multiple SMTP addresses to resource mailboxes is usually not necessary.

Overall it appears that room and resource mailboxes are a feature that has matured over the previous versions of Exchange Server and now receive just a few minor improvements to make them simpler to manage.

read more
Exchange 2013

Transport Rules in Exchange Server 2013


Transport rules have been a feature of Exchange Server since the 2007 version and have been included in Exchange Server 2013 with a number of improvements.

New Features in Exchange 2013 Transport Rules

Microsoft has published a list of changes and improvements to transport rules on this TechNet page.

Support for data loss prevention policies is one of the major new features in Exchange Server 2013, and this integrates with transport rules.

Exchange 2013 also has a number of new predicates (conditions) and actions for transport rules. A few of the highlights are:

  • Ability to take action on messages that have been sent from specific IP address ranges
  • Ability to take action on messages that have attachments with specific extensions, or that contain executable content
  • Ability to stop subsequent rules from processing a message (this will make the order of rules important for some environments)
  • Ability to generate incident reports to an email address at varying severity levels
  • Transport rule information is now included in message tracking logs
  • Rule monitoring to detect and alert on rules that are delaying email delivery

Managing Transport Rules

Transport rules in Exchange Server 2013 can be managed in two ways. The first is by using the Exchange Management Shell cmdlets:

[PS] C:\>getcommand Noun *TransportRule*
CommandType     Name
Function        DisableTransportRule
Function        EnableTransportRule
Function        ExportTransportRuleCollection
Function        GetTransportRule
Function        GetTransportRuleAction
Function        GetTransportRulePredicate
Function        ImportTransportRuleCollection
Function        NewTransportRule
Function        RemoveTransportRule
Function        SetTransportRule

The second is by using the Exchange Administration Center, in the Mail Flow section under Rules.

Managing Transport Rules in the Exchange Admin Center

Creating New Transport Rules

The New Rule wizard behaves in an interesting way in Exchange Server 2013. If you simply click the + button the New Rule wizard begins and exposes a limited subset of the available conditions and actions in the drop down lists.

Creating a new transport rule in Exchange Server 2013

However, there is also a More options link in the wizard start screen.

Exposing more options for transport rules

Clicking that link expands the options available in the wizard to a much more granular set, as well as the ability to set multiple conditions and actions.

Fine-grain controls for transport rules in Exchange Server 2013

Creating New Transport Rules Based on Templates

In addition to the New Rule wizard behavior shown above you can also create a new rule based on a template of sorts. By clicking the little arrow next to the + icon a menu of common rule types is presented to get you started.

Transport rule templates

For example, choosing the “Apply signature or disclaimers” option from the list the new rule starts with the “Append a disclaimer to the message” action already selected.

Transport rule to append a disclaimer to a message

Other templates present different subsets of actions depending on the general purpose that the rule is for. However in all cases it appears you can still click More options to get access to all of the conditions and actions if needed.

Time-Based Transport Rules

Another useful capability of  Exchange 2013 transport rules is the ability to set specific dates for the rule to be activated and deactivated.

This could be useful for businesses that need to align their disclaimers with specific events such as a marketing campaign, a holiday period, or corporate merger/acquisition.

Transport Rules Audit Mode

Exchange 2013 transport rules also have an audit mode so that they can be tested without impacting message delivery. In the New Rule wizard these options are visible as the two “Test rule…” modes.

Exchange 2013 transport rule test/audit modes

Although they are referred to as “Test” in the Exchange Admin Center the modes are referred to as “Audit” in the New-TransportRule cmdlet parameters.

So in effect a rule can be placed in one of three modes:

  • Enforce – the rule is active and all the actions you have specified will be taken
  • Audit (Test rule with notifications disabled) – the rule is active, and the actions are logged to the message tracking logs, but not actually enforced on the message
  • Audit and Notify (Test rule with notifications enabled) – same as Audit mode except any “Notify…” actions on the rule are taken


read more
1 2 3 4 5
Page 3 of 5