Exchange 2013

Using OWA and Internet Explorer 11

Now Windows 8.1 RTM is available via Technet and MSDN it is installed by several ITpro’s. And then it is just a matter of time befor someone finds  an issue. This because the code of Exchange doesnt recognize Internet Explorer 11 correctly and this will result in OWA to be displayed in light mode. As you may know OWA light doesn’t connect all the options which are available in the full blown OWA. Microsoft will probably fix this in a future update so you can use Internet Explorer 11 in full blown mode. This is confirmed by something I discovered when using Office 365. It looks like my tenant is already upgraded because Interne Explorer 11 works OK for me. The on-premise environments will need to wait till Microsoft releases an update which contains the correct code to recognize Internet Explorer 11.


A few weeks ago the Exchange 2013 version of the Powershell Cookbook was published by Packt Publishing. This version also introduced a additional writer for the book: Jonas Andersson. A frequent Exchange blogger with quality articles so before I started reading I was convinced the book should be from high quality also. The second writer is the one who was also responsible for the first part Mike Pfeiffer. Those who missed the first part and are working with Exchange 2010, please read the book it contains very usefull info.

Enough about the writers and the first part . Let’s start reviewing the secondary part which is mostly decicated to Exchange 2013. The book starts from the beginning so if you are not familiar with Powershell the book will introduce how Powershell will work and you can benefit from it. And trust me I also found some nice tips for future use my scripts although I use Powershell almost every deployment.

Once the writers discus some basics which you really want to know they describe the abilities Powershell will give your per part of Exchange. For example they discuss which Powdershell cmdlets you can use for managing the Exchange Transport part. Per Exchange part a very clear description is given including some really nice examples.

As last and bonus part the writers describe how you can use EWS via Powershell which extends Powershell again. For those who are familiar with basic Powershell this is a must read chapter.

So what’s my conclusion about the book: a really nice book both for Exchange Powershell starters but also for people that are more experienced with Powershell for Exchange.

You can buy the book via the site below:

Packt Publishing

Deploy Exchange 2013 CU’s

This weeks the second version of the second cumulative update has been released for Exchange 2013. As you may already know Microsoft has changed his update process completely with the introduction of Exchange 2013. No more rollups and only cumulative updates (CU’s).

A pretty big change as the CU’s require you to make changes to the AD also as step of the update process. For those not familiar with rollups of Exchange 2010, the rollups where just bit updates and did not include AD changes. In Exchange 2010 the AD changes where only included in service packs.

CU’s are a complete install of Exchange 2013. So if you plan to install Exchange 2013 in the future you will only need to install the latest CU and you’re done.

But what has changed from deployment standpoint? Well pretty much because we now have to think of the Managed Availability feature of Exchange 2013. This feature will continually monitor the environment and takes action if necessary.

You can compare it with placing a node in maintenance mode in a load balancer. Although with placing a node in maintenance mode in a load balancer only ensures that it doesn’t offer any traffic anymore to the specific server.

Managed availability goes steps further, it can do this because the monitors contain knowledge about the product something load balancers don’t have.

For changing the status of the components on a server you will need to use the Set-ServerComponentState cmdlet. Using this cmdlet with the necessary parameters you can influence the components of a server.

Which components are active on a server depends on which roles are deployed to  server. To find out which components are available on a server you can run Get-ServerComponentState. In the example below you will see an output example of a multi-role Exchange 2013 server:


As you can see all components are up and running. Let’s assume that we have prepared our AD and are now ready to deploy the bits on our Exchange 2013 servers.

Our environment consists of two Exchange 2013 multirole servers. A third server is used as the File Share Witness (FSW) to maintain quorum.

get-servercomponentstate serverwideoffline

The first step will me to ensure that the transport queues will be empty before continuing the process. Using the Set-ServerComponentState cmdlet we can set the status of a component. Besides the status we will need to provide the requestor. In this case the requestor we are going to use is maintenance.

Set-ServerComponentState –identity ex02 –component –state draining –requestor  maintenanceget-servercomponentstate serverwideoffline


By using the cmdlet above we will put the transport component in draining state. This means it will take care of the messages which are currently in the queue but will not accept any new messages.

You can speed up the process by moving the messages to a transport component hosted on another server. To do this you will need to use the move-messages cmdlet:

Redirect-Messages -server ex02 –targetserver ex01.corp.local


To check if the queues are empty we can use the good old get-queue cmdlet:

Get-Queue –server ex02


If all queues are clean we can continue with disabling all the other components which are active on the server:

Set-ServerComponentState –identity ex02 –component serverwideoffline –state inactive –requestor maintenance

set-servcomponentstat serverwideoffline restore hub

To verify if all components are set to the status inactive we could run the Get-ServerComponentState cmdlet again:

get-servercomponentstate serverwideoffline

Now all components are inactive it’s time to handle the database availability group (DAG) part.

There are a two ways to put a DAG member in maintenance mode. Those who are familiar with Exchange 2010 will remember the start-dagmaintenance script which will help you in putting s DAG member in maintenance model Well good news the script is still available and can be found in the same location as in Exchange 2010, the Exchange scripting directory.

Another method to put  DAG member in maintenance mode is to set the status of the cluster component using the Suspend-ClusterNode, for example:



Once the cluster node has been stopped you will need to prevent the databases from being moved d on the member:

Set-MailboxServer  -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

set-mailboxserver activation

And as final step we want to set the auto activation policy temporarily to blocked:

Set-MailboxServer  -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked

Now all prerequired steps have been taken it is time to kick of the setup. In this blog we will use the cmdline to update our Exchange 2013 server. To update the server start the setup using the following parameters:

Setup.exe /m:upgrade /IacceptExchangeServerLicensing

This will start the upgrade to CU2 as you can see below:

setup.exe /m:upgrade

Once the setup has finished you might decide to reboot the server. Once the server is back online it is time to restore the services.

To restore the services we will need need to perform the steps mentioned earlier only then in reverse order.

So we will start with putting the DAG member back online:

First we will make the DAG member and active of part of the cluster again:


Once this has been done we need to remove the limits for database failovers which we configured earlier:

Set-MailboxServer  -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

Set-MailboxServer  -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked


Now our DAG member is back online we need to change the component states to active:

Set-ServerComponentStatus –identity ex02 –component serverwideoffline –status active –requestor maintenance

set-servcomponentstat serverwideoffline restore

When running the Get-ServerComponentStatus cmdlet you will see that the status of the transport component is still draining.

To stop the draining process for the transport component we will need to run the Set-ServerComponentStatus cmdlet again only using a different action parameter:

Set-ServerComponentStatus –identity ex02 –component transport –status active –requestor maintenance

set-servcomponentstat serverwideoffline restore hub

Now when running the Get-ServerComponent cmdlet again the status of each component should show active.


Here ends the blog about how to install a CU on an Exchange 2013 server. If you hate to type the cmdlets manually then have a look at this script from Michael van Hoorenbeeck:

Micheals script: open

The script will perform the same cmdlets only with less typing for your and will simplify the proces of putting a server in maintenance and restore the services again.

The Exchange Virtual Conference

Colleague Exchange MVP and The UC Architects member Paul Cunningham launched the idea to organize an Exchange Virtual Conference in January 2013. He asked several people who are active in the Exchange community to attend this conference among them me.

The last couple of months I have been pretty busy to get my presentation ready and to record the sessions. All the presentations are prerecorded and starting from yesterday every day a presentation will be available

Besides me the following speakers attend the conference:

  • JP Bruzzese
  • Serkan Varoglu
  • Jaap Wesselius
  • Michael van Hoorenbeeck
  • Paul Cunningham

The topics discussed are both Exchange 2013 and Office 365, although most of the presentations do focus more on Exchange 2013

Below an overview of the presentations:

The sessions are available via the links above but you can also take a look yourself at the site

Remark: not all sessions are available, as soon as a session is available I will update the list above.

One of the most important subjects in an Exchange design is the correct sizing ofthe enviroment. Microsoft has defined several guidelines which need to be used which are described on TechNet. Since today the Server Role Requirements Calculator has been added.

Exchange 2013 Server role requirements calculator

The first thing which had changed is the name, no it is not incorrect, you can also size the CAS role with it. In Exchange 2010 the Mailbox Role calculator was available to size your Mailbox server. But the new tool can be used to size both your CAS and Mailbox servers.

One remark must be made the tool can only be used to size an Exchange 2013 environment. For Exchange 2010 you will need to continue to use the Mailbox calculator.

If you would like to use the new calculator you can download it via the link below:


In the first part of this blog we looked at the theory and some examples. In this blog we will continue with configuring and managin the DAG.

In this case we have an environment which consists out of two multirole Exchange 2013 servers. Because this is not an odd amount we will need to use a file share witness. Ideally this fileshare witness is placed on another Exchange server (for example your CAS) but it can also be located on an generic server.

First step is to prepare our FSW. It is important the Exchange Trusted Subsystem is a member of the local administrators group of the server. This because Exchange uses this account under the hood to perform the needed actions.

If the server doesn’t contain the File Server feature add it by using the following Powershell cmdlet:

Add-WindowsFeature FS-FileServer

Once these actions have been performed we can continue with configuring our DAG.

If you are familiar with DAG’s from Exchange 2010 pay attention to the next step. You will need to pre-stage the Cluster Name Object (CNO). Open ADUC and create a computeraccount which matches the name you want to give to the DAG, for example DAG01. After creating the object disable the account and get the properties of the object. Select the security tab and add the computeraccount of the computer which will be the first member of the DAG. Repeat this last step for the Exchange Trusted Subsystem security group.

Of course you can also script the creation of this object. Fellow The UC Architects member Michel de Rooij has created a script which can be found here.

Next step is to create the DAG, we will use the Exchange Management Shell for this:

New-DatabaseAvailabilityGroup -Name Exchange_DAG01 -WitnessServer FS01 -WitnessDirectory C:\Exchange_DAG01  -DatabaseAvailabilityGroupIpAddresses

By using the cmdlet above we will create a DAG which has the name DAG01 and assign FS01 as the witness server. On the FS01 a directory will be created called Exchange_DAG01. As last step we will assign an IP address to the DAG

Now we have created the DAG it’s time to add the mailbox servers to it. This can be done by using the Add-DatabaseAvailabilityGroupServer cmdlet:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX01

Remark: If the Windows Failover Clustering components are missing the cmdlet will install then automatically. Keep in mind that this might require a restart of your Exchange Server. The cmdlet will in that case only install the components and will not add the server to the DAG. So if the server is rebooted run the cmdlet again to add the server to the DAG. However it may not be required to reboot the server in that case the server will be added to the DAG directly.


Once the first server is completed repeat the same step for the other server:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX02

To finish the configuration of the DAG we will need to add the additional copies of the databases. For adding a copy you will need to use the Add-MailboxDatabaseCopy cmdlet:

Add-MailboxDatabaseCopy -Identity MBDB01 -MailboxServer EX02 -ActivationPreference 2


After the copy is added you will need to restart the Microsoft Exchange Information Store service on the target server. This has to do with the “Managed Store” as introduced in Exchange 2013. Collegue Exchange MVP Tony Redmond published a nice blog. So if you want to know the indept details I recommend to visit this page.

This will add a copy of the database called MBDB01 to mailboxserver EX02 and will set the activation preference to 2.

Repeat the step for the database hosted by EX02:

Add-MailboxDatabaseCopy -Identity MBDB02 -MailboxServer EX01 -ActivationPreference 2

Once the cmdlets have been ran you can use the Get-MailboxDatabaseCopyStatus cmdlet to verify the status of the databases and its copies:


In the example above the first copy is mounted and the content index state is healthy. However for the second copy of the database the content index is FailedAndSuspended. In case of a *over this results in users who will start to have issues when searching their mailbox.

To fix this issue we need to run the Update-MailboxDatabaseCopy cmdlet like this:

Update-MailboxDatabaseCopy -Identity MBDB01\EX02 –CatalogOnly

After the confirmation the catalog will be updated on the second copy:


Let’s look at another issue:


In this case the second copy failed completely so we do have to update both the database and the catalog:

Update-MailboxDatabaseCopy -Identity MBDB02\EX01


After confirming the reseed is performed and both the database and catalog should be healthy again.

If we want to perform maintenance on the DAG members we will need to put the member in maintenance mode. This can be done by using the StartDagServerMaintenance script which can be found in the default script directory of Exchange.


By adding the Server parameter we can specify a server which we would like to put in maintenance. Once this is done it will check if the PAM role and which databases are currently activated on the server and will try to move them to another DAG member.

Once we have performed some maintenance on EX02 we will need to take it back in production. This can be done by using the StopDagServerMaintenance script:

.\ 1 –Server EX02

Once this script has been executed verify if the databases are healthy using the Get-MailboxDatabaseCopyStatus cmdlet. The script will not re-balance the databases so we will need to do this manually. To move the active database we need to run the Move-ActiveDatabase cmdlet:

Move-ActiveMailboxDatabase MBDB02 –ActivateOnServer EX02


After confirming the activation on the other server the database will be moved to EX02.

Here ends the second part of the Exchange Alphabet about Database Availability Groups. In this part we had a look how to create a DAG and perform several operations

Exchange 2013: e-Discovery tasks stay queued

During some testing in a lab environment which contained Exchange 2010 SP3 and Exchange 2013 I found a strange issue. The e-discovery tasks all got stuck in the queue.

Let’s start with some background information. Since Exchange 2010 SP3 and Exchange 2013 CU1 it’s possible to install an Exchange 2013 server in an Exchange 2010 environment. This will give you the ability to migrate from Exchange 2010 to Exchange 2013. Before doing this it is recommended to perform some testing in a test environment.

The e-discovery functionality can be used to search for messages with for example specific keywords in specific or all mailboxes in an Exchange environment. Back to the issue.

After testing the same functionality on the Exchange 2010 SP3 server I found out that it worked correctly on that side. After some research the solution was pretty easy. As you might know Exchange contains a few special mailboxes. These mailboxes can’t be seen in the GUI and can only be found using the Get-Mailbox cmdlet and using the -arbitration option.

get-mailbox -arbitration

When you have implemented Exchange 2013 in your current Exchange 2010 environment it is important to move the mailbox SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} to a database hosted on an Exchange 2013 mailbox server.

The mailbox can be moved by using the New-Moverequest cmdlet:

New-MoveRequest SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}  -TargetDatabase dbname

Once the move request has migtrated the mailbox it might be necessary to restart the search. When looking at the status of the e-discovery now you will see that it proceeds and finally gets the status completed:


In the Technet documentation you will find a small description about this functionality. Using the e-discovery functionality in a coexistence scenario it is important to know that the mailbox search created on the Exchange 2013 environment can only be used to search Exchange 2013 mailboxes. If you would like to search the Exchange 2010 mailboxes you will need to perform a seperate e-discovery.

For more information about the e-discovery functionality you can have a look at the site below:

Technet: In-Place eDiscovery

Redmond: where’s my Exchange Admin Center


Since CU1 is available it is possible to implement Exchange 2013 in an environment which contains Exchange 2010 SP3. This will create the option to migrate your resources to Exchange 2013. As you may now the Exchange Management Console (EMC) is replaced by the  Exchange Admin Center (EAC) a web based admin tool.

The EAC is accessible via the url https://fqdn/ecp for those who are familiar with Exchange 2010 will see this is the same url as for the  Exchange 2010 Control Panel. When Exchange 2013 is implemented you would like to check somethings and maybe configure several things via the EAC.

To do this go to https://fqdn/ecp and you will see the following screen:

Exchange 2013: EAC login

Provide the username and password and login:

Exchange 2010: ECP

But what you will see is the Exchange Control Panel. But how can you get to the Exchange Admin Center?
To do this you will need to add an additional parameter to the url https://fqdn/ecp?ExchClientVer=15. The loginpage will be displayed again but after you have provided the login details you will see the EAC:

Exchange 2013 EAC

A simple solution but which can take pretty long before you have found this specific thing.

In an earlier blog we had a brief look at the Database availability Group (DAG) of Exchange 2013. In this blog we will have a closer look how it works and how you can create it.

The DAG functionality was introduced in Exchange 2010 to replace all the other cluster methods Exchange 2007 contained. Using a DAG it is possible to create multiple copies of a database within the DAG. This is limited to 16 copies per database which I personally have never seen during implementations.

Database Copies can have several statuses which are displayed in the table below:

Status Description
Active The database is active on the specific server and handles requests
Mounted (passive) The database is in sync and waits till it needs to come in action
Failed The database copy is in failed state and might require a full reseed
Suspended The database copy has been suspended and new logs will not be replayed

When looking under the hood of the DAG you will discover that is uses windows clustering. These components are automatically installed when adding a server to a DAG. One import remark that must be made is that this requires an enterprise edition when deployed on Windows 2008 R2.  For Windows 2012 is doesn’t matter anymore because the failover feature is available in both standard and datacenter. Although it uses the failover feature of the OS it is not recommend to make changes via the failover cluster manager.

Within the DAG one server has the primary active manager (PAM). This server will make the decisions which copies are active and passive. When an issue occurs with the active copy the PAM is responsible for getting the topology change notifications and reacting to the failure. The server which hosts the PAM is always the owner of the cluster quorum group. If the server hosting the PAM will fail it will automatically failover to one of the DAG members who has survived.

Besides the PAM role there is an additional role called the standalone active manager (SAM). This role is active on all servers within the DAG but on the server which contains the PAM role the PAM will perform the actions of the SAM. The SAM role is responsible for detecting local database and local Information Store failures and acting on actions initiated by the PAM.

As you may have noticed we talked about the quorum. This is pretty important to understand. If you are familiar with clustering this must sound familiar to you. Because the DAG is a kind of clustering it also uses quorum to prevent issues like split-brain. In a DAG there are two options for this. Either implement an odd amount of DAG members, for example 3. Or decide to implement a Failover Witness Share. In this last case a shared folder is created on another server which is not a part of the DAG. For example if you have two DAG members we will need to add the failover witness share to get quorum.

To calculate how many at least need to be online to we can use the following formula (n / 2) + 1 where n is the number of DAG nodes within the DAG. For example we have 3 DAG members which makes (3/2) +1=2.5. Since halves do not count we need to round this down to 2. This means that at least 2 members will need to be online to leave the DAG running.  Members can be either the mailbox servers or a mix of one mailbox server and the server containing the FSW. Another example, let’s say we have 6 DAG members which makes (6/2)+1=4 which is equal. In this case at least 4 members of the DAG will need to be online.

We already talked about the multiple copies of a database but how does this work? Well each copy of a database has an activation preference. The initial database gets an activation preference of 1. All additional copies will get a unique ID assigned. For example the second copy gets 2 as activation preference etc. This preference is used as one of the parameters when the PAM needs to select a copy which needs to be activated if a failover is initiated.

Some examples

OK enough theory let’s have a look at some examples. The easiest example is a DAG within a datacenter which contains 3 multirole Exchange 2013 servers. Each server contains a copy of each database. The preferences of the databases have been configured in a way that during normal operation each server will only host one active copy:


Let’s assume one of the nodes has an issue and would need to be taken down for maintenance. No problem just put the node in maintenance and the PAM will ensure the database will be moved to another server.

After the maintenance has been performed on the server just stop the maintenance. The other servers will see that the node is back and will ensure the copies hosted on the server will be brought up-to-date. A manual action however is needed to move the database originally active on this server.

In the next example we will have our DAG members spread across two different datacenters. Each datacenter is defined as an AD site. We are still having 3 multirole servers in our Exchange 2013 environment. The only difference with the first example is that two of them are located in the primary datacenter and the third one in the secondary datacenter. The second data center is used for disaster recovery purposes:


Let’s assume the WAN link goes down in this scenario. Think of the formula what do you think will happen? Right the users can access their mailbox. Let’s use the formula (3/2)+1 = 2.5 which can be rounded down to 2. Which means at least two mailbox servers of a combination of one FSW and one mailbox server should be online. But if the complete primary data center burns down we will need to follow the procedure as described next.

A DAG can be either created within one AD Site or across two AD sites. In this last case it is pretty important in which site you locate the file share witness (FSW). In most cases this will be the site which you want to survive which might be primary site. In this case if the WAN link between the two sites goes down the site containing the quorum will survive. To bring the DR site online again we will need to introduce an alternate FSW and then bring the DAG online again.

Here ends the first part of the blog about database availability groups. In this article we looked at the theory behind the DAG and looked at some example configurations. In part two we will start building a DAG.

Exchange 2013 CU1 has been release and now?

Last week Exchange 20130 CU1 was released by Microsoft. It was a little bit later then originally planned but cudo’s for Microsoft to announce it publicly that the first CU for Exchange would arrive later then expected.

CU1 contains several fixes and enhancements. If you would like to know more about those have a look at the following blogs::

Exchange 2010 RTM CU1 released

High Availability Changes in Exchange Server 2013 Cumulative Update 1

Now CU1 is available it’s supported to migrate from Exchange 2010 SP3 to Exchange 2013. The organizations who are still running Exchange 2007 will need to run at least Rollup 10 for SP3.

But now Microsoft has “finished” his job it’s time for the other vendors in the Exchange eco-systeem to come with support. Because this is sometimes forgotten I decided to do some research. The results are that some vendors are already supporting Exchange 2013 while others are in the middle of a beta or even have planned a beta a few months from now.

I split the software up in three categories:

  • antivirus
  • backup
  • overige utilities

In the tables below an overview per category:


ESETMail security 4.5supported
McAfeeSecurity for Microsoft Exchange 8supported
SophosPuremessage expected July/August 2013
Trend MicroScanmail for Exchangecurrently in beta


AcronisBackup & Recovery 11.5 for MS Exchange Serversupported
EMCNetworkerexpected Q1 2013 but some sources reported Q3/Q4
IBMTSMexpected Q2/Q3 2013
MicrosoftSystem Center 2012 - Data Protection Managersupported
SymantecBackup Execexpected Q1 2013
QuestRecovery Manager 5.0supported
VeeamExplorer v 7currently in beta


BinaryTreeCMT for Coexistencesupported
E2E Completesupported
BlackBerryEnterprise Server 5.0.4supported
ExclaimerMail Disclaimers 1.0.60227.0supported
Priasoft Migration Suite for Exchange 6.5supported
Stellar Phoenix EDB to PST converterlater this year
SymantecEnterprise Vault 10.0.3supported
QuestGroupwise Migrator 4.2supported
Notes Migrator 4.6.1supported

As you could see not all vendors are ready for Exchange 2013. So verify every software which you are using against Exchange if the vendor does support it.