High Availability

Exchange Server 2013 Preview – Part 4: Configure DAG, CAS Array and Public Folders

Exchange Server 2013 Preview – Part 4: Configure DAG, CAS Array and Public Folders

In this series of posts, you can read about the fresh release of Exchange 2013 beta/Preview.
The posts are done as “how-to” posts with configuration examples from both Exchange Administration Console (EAC) and Exchange Management Shell (EMS).

Earlier parts can be found below:

Part 1: Installation guide
Part 2: Basic configuration
Part 3: Continue of configuration, URL’s etc.

At the end of the post, I will link to some interesting TechNet articles around High Availability, Disaster Recovery, Site resilience and Public Folder migration.

Note: My posts around Exchange 2013 Preview/beta are based on Beta information and it could be changed before it will be released (RTM).

Database Availability Group (DAG)

If this expression is new to you, here are some background information.
The DAG is the new cluster technology from Exchange 2010 and also included in 2013. It give us the opportunity to have a mailbox database replicated between two or more servers, the DAG can have utilize up to 16 copies of each database (16 different servers). The advantage of this is that if one server fails, it’s easy and very fast for doing switchover/failover to another server.

Some interesting changes around databases are that each database runs under it’s own process in Windows. Store (ESE) is totally rewritten, again.. which means you can’t use databases from older versions of Exchange directly on Exchange 2013. I have also read that IOPS requirements for databases have been reduced with another 50% from Exchange 2010, but I haven’t read it officially so maybe it’s just a rumor. We’ll see what happens when it’s being release and probably Microsoft will release an update mailbox calculator.

DAG is available for both Standard and Enterprise version of Exchange, and supported to run on both Windows 2008 R2 and Windows Server 8. Though all DAG members needs to run the same OS version.

Let’s get ready to create the DAG and add the Databases as copies on each DAG member/node.

Using EAC: It’s time to like the new EAC “console”.

Running “ipconfig” on both mailbox servers, for checking the IP addresses. Both for the MAPI network and the Replication network.



Go into Control Panel and check the network interfaces,


Login to the EAC, go to Servers and select Database Availability Group. Press Add button (+).


Type in DAG name, Witness Server, Witness directory and DAG IP. Press Save.


When the DAG is created, select it and Press Edit. Check the option “Configure database availability group network manually”. Press Save.


It’s now time for adding the mailbox servers into the DAG, this by pressing “Manage membership” button.


Press the Add button (+) and add the mailbox servers.


Add the mailbox servers that should reside in the DAG. Press OK.


Press Save.


The configuration now gets saved, failover clustering was installed on mailbox servers. Press Close.


Next thing to do it the DAG Networks, as you can see in the right bottom corner, a network called “MapiDagNetwork” has been created. I want to have the control over these networks so I will create my own.
Start by pressing “New DAG Network”. I’m about to create two new networks.


I will give the first network a name like MAPI Network, and assign the Subnet to it where the clients are supposed to connect. Press Save.


My second network will be called Replication Network, since that it’s purpose and also assign it to the correct Subnet. Press Save.


Since we now have created those two network, let’s remove the automatic created one by pressing “Remove” button.


Press OK.


The MAPI Network is not supposed to be used as replication network, so let’s disable that function by pressing “Disable Replication” on the MAPI network. Press OK.


The DAG should now show two networks called MAPI and Replication. The MAPI Network should not be enabled for replication.


Final DAG configuration

The last step (just a recommendation) is to enable the DAC mode, this for preventing split brain syndrome. Which means that you end up with having same database mounted on two (or more) different servers. More info about DAC mode can be found on the link in the end of the post.

This can’t be done through EAC (maybe that will change to RTM). So let’s start up Exchange Management Shell (EMC).

Set-DatabaseAvailabilityGroup –Identity DAG01 –DatacenterActivationMode DagOnly


Database copies

On each mailbox database we now need to add a copy to another server for having the redundancy.

In the menu, go to Databases and select one database, then press the Add database copy button.


Specify mailbox server that at the moments doesn’t hold a copy of the database and add it by pressing the browse button. Press Save.

Note: In this menu you also have the option to configure lag time (if using lagging node).


The database now get’s copied (Seeding).


Then do the same procedure on all of your databases.


Press Close, when the operation is done.


Do the same procedure on all of your databases.


The seeding operation is running.


Press Close.


It might take a while (some minutes..) until it get’s Healthy and everything has been checked and verified.
In my test environment it took around 15min to be fine. It should look like the picture below when everything is completed.


Using PowerShell: The Web interface is nice to work with. But I prefer the PowerShell, because I have the full control over what’s going on.

Let’s start with creating the DAG by using the command below:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer TLCAS01 –WitnessDirectory C:\FSW_DAG01 –DatabaseAvailabilityGroupIpAddresses

Configure the DAG so that the networks can be manually configured:
Set-DatabaseAvailabilityGroup –Identity DAG01 –ManualDagNetworkConfiguration $True

Add the mailbox servers into the DAG:
Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer TLMB01
Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer TLMB02

Enable DAC mode for the DAG:
Set-DatabaseAvailabilityGroup –Identity DAG01 –DatacenterActivationMode DagOnly

List the DAG Networks:

Create two new DAG Networks, one for Mapi and one for Replication:
New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup DAG01 –Name Mapi –Description “Mapi Network” –ReplicationEnabled $False –Subnets “”

New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup DAG01 –Name Replication –Description “Replication Network” –ReplicationEnabled $True –Subnets “”

Remove the automated created network, it will not be used:
Remove-DatabaseAvailabilityGroupNetwork –Identity DAG01\MapiDagNetwork




Database copies

On each mailbox database we now need to add a copy to another server for having the redundancy.

Specify a mailbox server that at the moments doesn’t hold a copy of the database and add it by running the following commands.

Add-MailboxDatabaseCopy –Identity DB01 –MailboxServer TLMB02
Add-MailboxDatabaseCopy –Identity DB02 –MailboxServer TLMB02
Add-MailboxDatabaseCopy –Identity DB03 –MailboxServer TLMB02


Verify the replication status on each mailbox server:
Get-MailboxDatabaseCopyStatus –Server TLMB01
Get-MailboxDatabaseCopyStatus –Server TLMB02


Public Folders

The Public Folder databases are now gone, and transferred to “normal” mailboxes instead. The advantage of this is that the mailbox itself can now be replicated using DAG technology. This doesn’t mean that the public folder contents is replicated, it’s still required that you configure the public folder replication for the contents.

With “normal” mailbox I mean that they reside in the mailbox databases, just like user mailboxes does. However they can in someway be compared to shared and room, those are also special mailboxes.

If you decide to use the Public Folders in Exchange 2013, the first step will be to create a mailbox that holds the public folder hierarchy. This will be the writeable copy, you can have copies of the hierarchy. But you can only have one that is allowed to make changes/writeable.

How can the hierarchy mailbox be created?

Using EAC: Go to Public Folders section, this is the first warning/error message you will receive.
It means that you don’t have any public folder hierarchy (mailbox) created yet.


Go to the second public folder selection called “Public Folders Mailboxes”. Add (+), create the first mailbox for the public folders, so it’s hierarchy can be saved.


Give the mailbox a friendly name, example: PF_Hierarchy, place it into an organizational unit and select a mailbox database where it should be saved into. Press Save.


Now when the hierarchy is created, let’s create some test folders too.
Go back to “Public Folders”, press the Add (+) button. Give the public folder a name. Press Save.


If you want to configure any storage quota on the public folder content, press Edit and configure it. Statistics can also be found under Edit selection, which sometimes is valuable.


Just for testing purposes I did mail-enable the folder. By pressing the Enable button.


Press Yes.


Let’s check the properties for the folder again, now we see that we have lots of new settings. Here’s a small example how the Mail Flow settings looks like.


Using PowerShell: Start up Exchange Management Shell, the following commands will be used for creating the public folder hierarchy and contents folder.

Create the hierarchy by running the following command
New-Mailbox –Name PF_Hierarchy –Alias PF_Hierarchy –Database DB01 –OrganizationalUnit Users

This mailbox, like shared/room mailboxes is also disabled by default. This for not having the possibility to logon as this user.

Let’s create the folder named Testlabs
New-PublicFolder –Name Testlabs

Finally, mail enable the public folder
Enable-MailPublicFolder –Identity \Testlabs


We have public folders located in Exchange 2007/2010, what about them?

In the end of this post, you can find a link to a TechNet article, it provides you with a great step-by-step guide. I haven’t tried to migrate public folder contents from earlier versions of Exchange since SP3 for Exchange 2010 is required for having coexistence between Exchange 2010 and Exchange 2013. SP3 is right now under development/testing and no official information can be found.

When I get my hands on SP3, this will be one of the first things to try out.

Client Access Server Array

In my previous blog post I did write about some news regarding MAPI and RPC, where I did mention what changes been made. It can be found here.

The “new” Client Access Server role can now been seen as more of a traditional Front-End server.
It utilize as a front-end connection point and redirects/proxies (depending on method) the clients to it’s correct mailbox server.

After the architectural change around the CAS role, it’s now “stateless” which means there’s no need for the load balancer to configure affinity/sticky session. For example, it means that the clients is not required to have the connection established to the same CAS server for having the OWA to work. This means that all CAS servers now will serve all clients with connections to it’s mailbox endpoint server.

How to create a client access array?

Right now, I don’t see any specific reason for creating the CAS Array, since the traffic will be proxied from the CAS servers to the correct active Mailbox servers.

In an upcoming blog post I will cover how to configure the load balancing for Exchange 2013.

Upcoming topics: load balancing Exchange 2013 using different load balancers, database fail-over, move mailbox reports, disaster recovery etc.

But first it’s time for 3 weeks of vacation, until then. Keep on reading the posts and you’re more than welcome to comment on them.

Thanks for reading, I hope it did gave you some valuable information.

More information:

High Availability

DAC mode

Client Access Server

Public Folder migration scenario

Exchange Server 2013 Preview – Part 2: How to do the Basic configuration

Exchange Server 2013 Preview – Part 2: How to do the Basic configuration

If you haven’t read it already, I did post a complete guide for installing Exchange 2013, it can be found here. That was part 1, now it’s time for part 2. Which of course is the configuration of the server setup.

We have lots of changes between how you configured Exchange 2007/2010 and 2013.
First thing is that Exchange Management Console is gone and replaced by a refreshed ECP called Exchange Admin Center (EAC), built on Silverlight (I suppose). The “old” Exchange Management Shell (EMS) is still there, so I suppose lots of us geeks will use more PowerShell in the near future.

The fact that EMC is replaced will make the administration easier and more portable, but I still like the EMC better. I will like the EAC better after used it for a while. This portable administration together with Remote PowerShell will be awesome.

I will use both methods for the configuration steps, both EAC and PowerShell.

The easiest way to find the URL path to the EAC is to start the Exchange Management Shell and run the command below:

Get-EcpVirtualDirectory | fl *url*

The picture below is my output from my lab environment


So let’s get things started..

Start up an Internet browser and go to the URL output from the command above


Mail Flow

Let’s get the mail flow configured first so we can receive mails from external senders.

In EAC: on the left side (menu) press “Mail Flow”.


Accepted Domains

Ensure sure that your domains that should be used for SMTP is listed in here for making Exchange able to receive mails for these domains. More info about Accepted Domains can be found here.

In EAC: After selecting “Mail Flow” to the left, press “Accepted Domains” at the top menu in the middle.


If your domain is not listed and you need to add it, press the plus mark and fill in the information, like my example below.



Using PowerShell: Since I’m a geek I like to use PowerShell because it gives you the advantage of see what happens, have the full control and easily build scripts.

For listing and adding a domain like above in PowerShell you should write:

New-AcceptedDomain –Name testlabs.com –DomainName testlabs.com –DomainType Authoritative


Email Address Policies

These policies are used to stamp each user mailbox object with an email address/SMTP address.
These policies does not remove any addresses used previously, it just adds new addresses to mail objects.

In EAC: By default after the installation we only have one policy, called Default Policy.

I want to edit this one, by selecting the “Default Policy” and pressing the “pen” icon.


The Default Policy is showing up, in the left menu, press “Email Address Format”.


Since I live in Sweden and we have some special characters that I want to get rid of, I’m using the custom policy, Address type: SMTP and the Email address parameters:


%r means it replaces the character after, in this case åäö. Which it replaces with aao.

When you have done the change press the “Save” button at the bottom of the page.


Check so that the change is correct, then press the “Save” button.


After the changes have been saved, it needs to be applied. This is done by pressing the “Apply” text/button down in the right menu.



Using PowerShell: Let’s start with listing the Policy and the settings in it. As a final step let’s do the same configuration to the “Default Policy” that we did using EAC.

If you want to create more than just alias@domain.com to your policies, then this is done by comma separation. For setting the Primary SMTP address, use capital letters for SMTP, and for additional addresses use small letters for smtp. See the example below:


Get-EmailAddressPolicy | fl

Get-EmailAddressPolicy | Set-EmailAddressPolicy –EnabledEmailAddressTemplates “SMTP: %råa%räa%röo%g.%råa%räa%röo%s@testlabs.se”,”smtp: %m@testlabs.se”

Set-EmailAddressPolicy –identity “Default Policy” –EnabledEmailAddressTemplates “SMTP: %råa%räa%röo%g.%råa%räa%röo%s@testlabs.se”,”smtp: %m@testlabs.se”

Get-EmailAddressPolicy | Update-EmailAddressPolicy

It can easily be checked if the policy has been applied, it will show a True or False value. For checking the value run the command below:

Get-EmailAddressPolicy | fl *appl*

Note: Don’t forget to update the Policy, or else the new addresses won’t be pushed out to the recipients.


Receive Connectors

Since the HUB Transport server role now is gone and the HUB role is placed together with the CAS role, this is the server you should be looking at.

After the SMTP domains have been added into the Accepted Domain tab, some settings could be of value to have a look at before starting to use the servers.

A change has been made to the new version, the default connector now named “Default Frontend servername”. It now allows traffic from Anonymous users by default. I suppose this is due to that the Edge Transport Role also is removed.

In EAC: Go to the “Receive Connectors”, found under “Mail Flow”. Make sure to select your CAS server(s) and the “Default Frontend servername”. Then press the “pen” icon for Edit the selected connector.


The only thing I did change was the “Maximum receive message size” to 30 MB.
When you have done your changes for the connector, press the Save button.


Using PowerShell: Start the Exchange Management Shell, lets view the receive connectors and then make the changes like above.


Get-ReceiveConnector | fl

Set-ReceiveConnector –Identity “TLCAS01\Default Frontend TLCAS01” –MaxMessageSize 30MB

Note: The size can be configured between 64KB up to 2GB.

Verify that the settings was correctly set, using the command below
Get-ReceiveConnector | fl ide*,maxmes*


Send Connectors

When the HUB server role now is gone and after the default installation of Exchange we don’t have any send connectors. So… for being able to send out mails to external recipients, let’s create a Send Connector on the CAS server.

In EAC: Go to the “Send Connectors”, found under “Mail Flow”. Press the “plus” icon for Creating a new send connector.


Give the send connector a friendly name and select what type it should be. Since this one I’m creating now is for sending to external recipients I’m selecting “Internet”. (Seems like we have a typo, see picture below). Press Next.


Select how to route those mails, either by using MX records or through a smart host(s). If you have a mail gateway then you should select smart host and type in it’s IP address. My server is just sending them directly to Internet so I’m using the MX method. Then press Next.


Press the “plus” icon for adding the address space this connector should use. In my case it will be “*”. Then it takes care of all domains. Press Save.


Then Press Next for accepting the settings you’ve just made.

Next screen will show you which source servers that should be used. Let’s add these into the connector by pressing the “plus” icon and selecting the Mailbox servers.


Press Finish button so the connector get’s created.

Note: By default the connector has a maximum message size of 10MB. You can’t configure the maximum send message size when creating the connector, but this can be done by editing the created connector.

Using PowerShell: Start the Exchange Management Shell, lets view the send connectors and then make the changes like above.


Get-SendConnector| fl

This creates a new send connector using the DNS/MX method
New-SendConnector –Name “Outbound” –AddressSpaces ‘*’ –SourceTransportServers TLMB01 –MaxMessageSize 30MB

This creates a new send connector using the smarthost method

New-SendConnector –Name “Outbound” –AddressSpaces ‘*’ –SourceTransportServers TLMB01 –MaxMessageSize 30MB –DNSRoutingEnabled:$false –SmartHosts “”

This creates a new send connector using the smarthost method together with using the CAS server as a proxy server for sending the mails

New-SendConnector –Name “Outbound” –AddressSpaces ‘*’ –SourceTransportServers TLMB01 –MaxMessageSize 30MB –DNSRoutingEnabled:$false –SmartHosts “” –FrontEndProxyEnabled:$True

Note: The size can be configured between 0 Bytes up to 2TB.

Verify that the settings was correctly set, using the command below
Get-SendConnector| fl ide*,maxmes*



As most of you already know we need to request and import a certificate for Exchange. This for having a fully working OWA, ActiveSync etc. certificates needs to be configured so let’s get started.

In EAC: Go to the “Certificates”, found under “Servers”. Select the server and press the “plus” icon for Creating a new certificate request.


I’m using an Internal PKI solution, so in this case I want to “Create a request for a certificate from a certificate authority”. Press Next.


Type in a friendly name for the certificate. Press Next.


If you want to create the request for a wildcard certificate, this is the checkbox you should use.
I don’t want a wildcard certificate, so I just let it be unchecked. Press Next.


Press Browse and select which server you want to store it on. Press Next.


For each service you can here type in the address, and the request will generate the names in the end. When you’re done press Next.


Go through the names in the list and make sure that all names that’s needed are included. Press Next.


Fill in Organization name, Department, Country, City and State. Press Next.


In my example I did type in the path to a share on my domain controller, which also is my Internal CA. Press Finish.
Example: \\tldc01\certificates\certreq.req


When the request is completed, it shows up with the friendly name, together with the status “Pending request”. When the certificate is issued, press the “Complete” button below the status.


Type in the URL path to the .cer file, my file is saved on my DC. Press OK.
Example: \\tldc01\certificates\certnew.cer


It’s now time for assigning the services to the certificates. This is done by selecting the certificate and press the Edit button.


Go to “Services” and add the one’s that should be used. Press Save.


Press OK.


Check so that the services is assigned to the certificate.


Using PowerShell: Start the Exchange Management Shell, lets view the existing certificates and then make a new cert request like above. Finally import the issued certificate.


Get-ExchangeCertificate | fl

This creates a new certificate request and saves it to a share
New-ExchangeCertificate –Server TLCAS01 –GenerateRequest –FriendlyName Exchange2013-PS –PrivateKeyExportable $true –SubjectName “c=SE, s=Skane, l=Malmo, o=Testlabs, ou=Testlabs, cn=mail.testlabs.se” –DomainName  mail.testlabs.se,autodiscover.testlabs.se –RequestFile “\\tldc01\certificates\test.req”


Import-ExchangeCertificate –Server TLCAS01 –FileName “\\tldc01\certificates\certnew-ps.cer” –PrivateKeyExportable $true –FriendlyName Exchange2013-PS

Enable-ExchangeCertificate –Thumbprint A2E6649A22A99BEAB2654BEB403C92BB9D34B404 –Services “IIS, SMTP, POP, IMAP” –Server TLCAS01



Note: Make sure to specify –Server, or else you can have difficulties finding our created request. Mine landed at my Mailbox server even if I did it on the CAS server.

If you haven’t read it already, have a look at Part 1: Complete guide of how to perform the installation

Thanks for reading, I hope that it’s informative and great reading for most of you. It would be awesome if you guys leave some comments, what do you think about Exchange 2013? Maybe you have already installed the Preview/Beta? Which new feature is the best one?

Next part will cover Databases, Outlook Anywhere, Outlook 2013 and MAPI/RPC etc.

Part 3 can be found here

Exchange Server 2013 Preview – Part 1: Complete guide of how to perform the installation

Exchange Server 2013 Preview – Part 1: Complete guide of how to perform the installation

Since Exchange Server 2013 beta was released yesterday I’m glad to announce that my first installation is done and here’s a complete walkthrough.

My setup is basic, using one server as domain controller, Windows 2008 R2.
Initially for Exchange I’m using 3 servers, 1 server for the CAS role and 2 servers for the Mailbox role.

There are some prerequisites that need to be installed/removed before the installation of Exchange can take place.

Note: It’s now recommended to install the Mailbox server first. So I’m starting with that server.

Step 1. Install the administration pack using the commands below, make sure to restart the server before proceeding to step 2.

Import-Module ServerManager
Add-WindowsFeature RSAT-ADDS


Step 2. Install the Windows features that Exchange uses, for Mailbox and CAS server use the command below:

Import-Module ServerManager
Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI


Step 3. When the feature is completed. Continue with the installation of the required components, use the links below to download the components.

.NET Framework 4.5 RC

Windows Management Framework 4.0

Unified Communications Managed API 4.0, Core Runtime 64-bit

Office 2010 Filterpack x64

Office 2010 Filterpack SP1 x64

KB 974405 (Windows Identity Foundation)

KB 2619234 (RPC over HTTP)

KB 2533623 (Remote code execution)

Note: Make sure to uninstall the Visual C++ 11 Beta Redistributable (x64) before starting the Exchange 2013 installation.

You can have a look at the setup.exe parameters using

setup.exe /?
setup.exe /help:install


Step 4. Start the installation using unattended installation for the Mailbox server role

setup.exe /mode:install /roles:Mailbox, ManagementTools /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /OrganizationName:Testlabs /TargetDir:"D:\Program Files\Microsoft\Exchange Server\V15"

The installation process starts up and prepare the organization for Exchange 2013, install the necessary Windows components. The schema prep can also be done manually using setup.exe /preparead, I’ve chosen to go with the default behavior.

When for the Mailbox server role installation is successfully finished it will tell you to restart the server.


Step 5. Start the installation of the Windows features for the CAS server role

Import-Module ServerManager
Add-WindowsFeature RSAT-ADDS
Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

Make sure to restart the server after the Windows features got installed.

Step 6. Start the installation of the CAS server role

setup.exe /mode:install /roles:ClientAccess, ManagementTools /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /OrganizationName:Testlabs /TargetDir:"D:\Program Files\Microsoft\Exchange Server\V15"

Since this is the second server, the schema prep is already done so the installation will skip that step.

When it’s finished it will look like the picture below, a restart of the server is required.


The installation of both servers are now completed.

Next blog post will be around how to configure Exchange 2013.

Thanks for reading, looking forward to your comments about the post and also about Exchange 2013 in general.

More information about the prerequisites can be found here.

What’s new in Exchange 2013

Next blog post, Part 2: How to do the Basic configuration

Quest MessageStats MAPI_E_FAILONEPROVIDER (8004011D)


I was getting an error when connecting to the Exchange Organization.

This is documented by Quest and is a bug and there is an official workaround until next release of QMS (hopefully).
The “KB” at Quest’s place is named “SOL67917”.

This error is happening when trying to connect to an Exchange 2010 Organization without Public Folder database
and the error message looks like below.

DESCRIPTIONMessageStats is unable to connect to an Exchange 2010 organization if that organization does not have at least one
Public Folder database. The error that is associated with the failed connection is MAPI_E_FAILONEPROVIDER (8004011D).


Please download the Hotfix called, MessageStats 6.8.1 Hotfix (TFS138271) for solution SOL67917 from: https://support.quest.com/Downloads.aspx?id=3416166&ver=MessageStats~6.8.1&productid=268435854&productversionid=268454124&category=Patches&SKB=1

Please follow the instructions included in the downloaded file to apply it.


Issue resolved in hotfix

How to install and configure Quest MessageStats in Lab environment


Published: 2010-12-16
Updated: –
Version: 1.0

Background Information

I hope you will find this article helpful and interesting to read.
I just want to mention to everyone that’s reading this article, it’s not any type of best practice, it’s just
a sample of how it could be installed and configured in a Lab environment.
It will not be a how-to guide in depth with every small step but it will provide as much information that
you can be used as a reference.

I’m going to use Quest: MessageStats 6.8.1 (current version when the article is created)
It can be found here: http://www.quest.com/messagestats/

Don’t ask me about licensing, that’s a question for Quest, send a mail to: info@quest.com

Below here is a picture of the server infrastructure used in this scenario

The server AD01 is just a basic Active Directory server with Windows 2003 R2, nothing special.
The Exchange server, is using Windows 2008 R2 and with a typical installed Exchange 2010.
Domino server is based on Windows 2003 and IBM Lotus Domino version 7.0.4
Windows/Quest NME, is used as a SQL Express 2005 server in this scenario
Windows 2008 R2, is used for the Quest MessageStats application and for the reporting parts (IIS).


We need for configure SQL 2005 Express for use of both Windows and SQL Server authentication.
This is done from the NME machine were SQL is installed with SQL Management Studio Express by
right-clicking on the server and select properties and choose “Security” and make sure the “SQL Server
and Windows Authentication mode” is selected. Check the picture below.

We also need to create a SQL user for this purpose; I named it SA-QMS (Server Account-Quest MessageStats)

Then it’s time to start the installation of MessageStats (QMS).
Just want to mention some short prereq’s that need to be in place before starting the installation.

  • IIS with typical installation
    • Verify that “Reports” virtual directory is using Windows Authentication
    • “ASP.NET, ASP and Server Side Includes” needs to be enabled and installed
  • Local administrator to perform the installation
  • MAPICDO needs to be installed, version 6.5.8153.0 or later
  • PowerShell 2.0 needs to be installed
  • At least; Exchange View-Only Management and Recipient Management permissions with the account
    that’s used for collecting data
  • For public folders it should also be member of; Public Folder Management group
  • Local administrator on every Exchange server
  • Read permissions on the folder which have the message tracking logs
  • Share the folder which includes the message tracking logs
  • The mailbox for the collecting account CAN’T be hidden in the GAL
  • It should also have AD permissions and Mailbox permissions
    • Add-ADPermission -id:mailboxName -User:userName -AccessRights:extendedright
    • Add-MailboxPermission -id:mailboxName -User:userName -AccessRights:FullAccess
    • Get-MailboxServer MyServer | Add-ADPermission -User:UserA -ExtendedRights Send-As
    • Get-MailboxServer MyServer | Add-ADPermission -User:UserA -ExtendedRights Receive-As
  • SQL-DMO 2005 Backward Compatibility Pack needs to be installed



Let’s start the installation

Selecting Complete installation

Typing in where the database should be installed; QUEST\SQLEXPRESS
Reporting and Scheduler service should be installed on; QMS

Selecting the default setting

Selecting the default setting

Typing in server name and email address for the service account

Typing in service account and password

Installation is in progress..

SQL Database creation..

Selecting the default setting

Selecting the default setting; “Small”

Selecting the default setting

The creation is completed successfully

After the installation is done, install the license by starting Quest MessageStats Console and right click the servername
then select License information and update the license.

Then it’s time to configure QMS to use SQL Server authentication instead of Windows Authentication, since there
seems to be issues related to the combination of SQL Express and Windows Authentication, that’s why I want to use
SQL Authentication instead of Windows.
Select properties on the server name and Database tab, on the Connection tab change from Windows NT Integrated security
to SQL authentication and type in the appropriate username and password, have it successfully verified.

For connecting QMS into the Exchange Organization, right click Exchange Organization and choose “Connect”.
In my lab I’m using Exchange 2010, typing in the server name (CAS) and the account with the necessary permissions.

The Exchange Organization is now connected.

On the server, right click and select “Properties” and “Tracking Logs”, browse for the share with the message tracking logs.

Right click the “Exchange Organization” and select “Create Task”.

Select task “Complete Exchange Gathering” and give it a friendly name.

Select “Yesterday” for the Tracking Logs.

In my lab I want to run this task every night at 1 AM (01.00).

The wizard is completed.

The Gathering job is currently running..

To complete this post, I just want to show a very basic example of what QMS can provide, this is just a sample.
Of course you can build your own reports, all type of details can be provided.

Hope this article gave you something
Cheers J

Paper: Microsoft Exchange 2010 on VMware vSphere Best Practices Guide


VMware has released a best practice guide for how to deploy Exchange 2010.
This paper hopefully will cover most parts including ESX host best practice, performance etc.

The paper can be found here:

Source: http://virtualization.info/en/news/2010/11/paper-microsoft-exchange-2010-on-vmware-vsphere-best-practices-guide.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Virtualization_info+%28virtualization.info%29

Can’t failover DAG DB


In my Exchange 2010 DAG environment with 2 nodes I received the error that I couldn’t failover a DB to the other node in my DAG cluster.

This was caused by the content index was in failed state, to resolve this error I had to run a script like below:

“C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\ResetSearchIndex.ps1 MDBNAME”


Creating a D.A.G (Database Availability Group)


A little introduction

The HA functions in Exchange have been changed a little bit; LCR, CCR, SCC and SCR are now away and replaced by D.A.G.

I think it’s a very cool and great feature with Exchange 2010, maybe the best J it makes it able to create a copy of the database to a different server(s). You are able to have more than one copy of it, so your server1 holds an active copy of DB1, server2 and server3 can hold this database as passive if server1 is broken, up to 16 copies.

The requirement is to run Exchange 2010 on a Windows 2008 (R2) Enterprise Server because it uses some components/api’s of the failover cluster service.

How to

To create a “DAG”, go to Organization Configuration, choose Database Availability Groups, right click and select ‘New Database Availability Group…’ type in a name for it, specify a Witness Server (usually the CAS/HUB server) and point out the Witness Directory like C:\fsw. It can be used on other servers to, don’t forget to add the Exchange Trusted Subsystem security group to local admins on the server that should act as FSW and allow WMI if the firewall is enabled.

When it’s created, right click the newly created DAG and choose ‘Manage Database Availability Group Membership…’ select Add button and add in the mailbox servers that should be part of the DAG.

The IP address for the DAG cannot be set in the GUI so it has to be done in PowerShell with the following command:
Set-DatabaseAvailabilityGroup DAGNAME –DatabaseAvailabilityGroupIpAddresses IPADDRESS

Now it’s time to add the other server to hold a passive copy of the database, it done by either Management Console or PowerShell. I prefer to do it in GUI.

Go to Organization Configuration and select Mailbox, and choose ‘Database Management’ tab.
Now select the database that you want to make a passive copy of, right click and choose ‘Add Mailbox Database Copy…’ a wizard is shown with a browse button, click that one and select the server that should hold the passive copy of the database.

If you want to change which server that has the active database, just select the database and choose ‘Move Active Mailbox Database’ and a wizard is shown.

A picture is shown below how to move the active mailbox database to another server

OWA/ActiveSync with Exchange 2007 coexist with Exchange 2003


In this scenario when have a single Exchange 2003 standard server installed and installed a new server with Exchange 2007 standard with CAS/HUB/MBX role (multi-role server).

Our problem was that we had too many users that used OWA and ActiveSync so we couldn’t be without this function.

I this case we had 3 different solutions to choose between.
1. Use two different IP addresses; one for the Exchange 2003 OWA/AS and one for the Exchange 2007 OWA/AS
2. Use a front-end firewall like ISA server or something else to publish the correct server
3. Install a new server that act as Exchange 2007 CAS server.

Option 1 was not a good choice because we don’t want to change anything on the end-user’s side like webmail address or ActiveSync settings.

Option 2 was a good idea but the customer didn’t want that type of solution and didn’t got the license for ISA.

Option 3 was the best choice in our solution, with this one we didn’t need to change the DNS record or any settings on the end-users. The only thing to change was the firewall rules.

When we had the Exchange 2003 (2003 Standard) and Exchange 2007 (2007 Standard) in place we did a decision to install a third Exchange server to act as the traditional “Front-end” server, with Exchange 2007 it’s called Client Access Server (CAS).
We imported a 3rd part certificate for IIS service thru PowerShell and configured the OWA to answer on the correct inside and outside web address.
Then we thought it was just to go… But it wasn’t!

We had 2 test users, let’s call them testuser1 and testuser2. They we’re located at different servers to check so everything worked well.
It was checked against the internal webmail address: https://hostname.domain.local/owa (can only be used if the mailbox is located at the 2007 server) so we used instead https://hostname.domain.local/exchange (this should be used if the mailbox CAN be located at the 2003 server). If the mailbox is not located on the 2003 server it will redirect the end-user to the 2007 OWA instead.

After a couple of retries, it didn’t work so well…
I searched the MS newsgroups and other resources like teamblog and google of course J
Almost without any luck!

Until I found out what was the problem, thanks to a colleague of mine that found an article on google on it.

If the original 2007 server was installed with “all” roles CAS, HUB, MBX after an uninstallation of the CAS role the server is not in correct state to support the coexistence.

The solution: In our case was to just disable the ‘Require SSL’ on the Default Web Site on the HUB, MBX server after removing the CAS role and restarted the WWW services ‘iisreset’.

On the link I found they were also running some PowerShell commands, but I didn’t need that.
I will include them to:

Get-OwaVirtualDirectory -server ServerName | Remove-OwaVirtualDirectory

New-OwaVirtualDirectory -Name “Exchange” -owaversion Exchange2003or2000
-VirtualDirectoryType Mailboxes -WebSiteName “Default Web Site”

New-OwaVirtualDirectory -Name “exadmin” -owaversion Exchange2003or2000
-VirtualDirectoryType exadmin -WebSiteName “Default Web Site”

New-OwaVirtualDirectory -Name “public” -owaversion Exchange2003or2000
-VirtualDirectoryType PublicFolders -WebSiteName “Default Web Site”

After this the redirection started to work as it should.

I completed the mission with a redirection in IIS so that the request to the server/site goes straight to /exchange.

Load More