KB979744 re-released to fix issues after installing MS11-028


A quick notice on the Exchange Team re-releasing hotfix KB979744 after identifying the issue which could cause problems on Windows Server 2008 SP2 (not R2). The problem can lead to Exchange Management Shell or Exchange Management Console not starting, MRS crashing or Event Viewer not opening after installing MS11-028 (KB2449742 or KB2449741, depending on your Windows Server 2008 level).

If you didn’t install the MS11-028 hotfix yet:

If you have the MS11-028 hotfix installed and you experience the issue:

VMWare HA/DRS and Exchange DAG support


Last year an (online) discussion took place between VMWare and Microsoft on the supportability of Exchange 2010 Database Availability Groups in combination with VMWare’s High Availability options. Start of this discussion were the Exchange 2010 on VMWare Best Practices Guide and Availability and Recovery Options documents published by VMWare. In the Options document, VMWare used VMware HA with DAG as an example and contains a small note on the support issue. In the Best Practices Guide, you have to turn to page 64 to read in a side note, “VMware does not currently support VMware VMotion or VMware DRS for Microsoft Cluster nodes; however, a cold migration is possible after the guest OS is shut down properly.” Much confusion rose; was Exchange 2010 DAG supported in combination with those VMWare options or not?

In a reaction, Microsoft clarified their support stance on the situation by this post on the Exchange Team blog. This post reads, “Microsoft does not support combining Exchange high availability (DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers.” This meant you were on your own when you performed fail/switch-overs in an Exchange 2010 DAG in combination with VMWare VMotion or DRS.

You might think VMWare would be more careful when publing these kinds of support statements. Well, to my surprise VMWare published a support article 1037959  this week on “Microsoft Clustering on VMware vSphere: Guidelines for Supported Configurations”. The support table states a “Yes” (i.e. is supported) for Exchange 2010 DAG in combination with VMWare HA and DRS. No word on the restrictions which apply to those combination, despite the reference to the Best Practices Guide. Only a footnote for HA, which refers to the ability to group guests together on a VMWare host.

I wonder how many people just look at that table, skip those guides (or overlook the small notes on the support issue) and think they will run a supported configuration.

Updating Exchange 2010 DAG Members


With all the (re-)releases of rollups, the question might rise on how to perform a proper up or downgrade of all DAG configuration members.

Basically, the procedure is straightforward and should be followed per DAG member:

  1. Appoint (next) DAG member;
  2. Move away all active copies on that DAG member;
  3. Prevent copies from activating on that DAG member;
  4. Perform maintenance, e.g. down or upgrade DAG member;
  5. Enable possible activation on that DAG member again;
  6. Optionally redistribute database copies.

Note that in a DAG configuration with 2 members, you need to be aware that during maintenance you have a temporary situation with no fail-over options. If that’s undesirable, consider implementing a 3rd DAG member.

To make the above procedure  easier and automated regarding moves and activation (un)blocking, additional scripts are available since SP1 for Exchange 2010. These scripts are located in the Scripts folder, below the Exchange installation folder. By default the location of the scripts will be C:\Program Files\Microsoft\Exchange Server\v14\Scripts.

Utilizing them, the procedure is quite easy as you can see below. Note that the example uses a DAG named DAG1 with nodes ex2010a and ex2010b as members. They both host 2 databases, ex2010mdb1 and ex2010mdb2; both host 1 active copy and a passive copy of the other database.

  1. Appoint (next) DAG member, e.g. ex2010a;
  2. Run StartDagServerMaintenance.ps1 targeting that DAG member, e.g.:
    .\StartDagServerMaintenance.ps1 –server ex2010a

    image
  3. Perform maintenance;
  4. Run StopDagServerMaintenance.ps1 targeting that DAG member, e.g.:
    .\StopDagServerMaintenance.ps1 –server ex2010a
  5. Repeat steps 2-3 for the other DAG member(s):image
  6. Optionally run RedistributeActiveDatabases.ps1 for the DAG, e.g.:
    .\RedistributeActiveDatabases.ps1 –DagName DAG1 –BalanceDBsByActivationPreference –Confirm:$false

    image

Be advised that when upgrading on major levels (RTM to SP1 or SP1 to SP2), you can’t move a database to a lower level host. This means that when upgrading a node from SP1 to SP2 and moving a database to that SP2 node in the process, you can’t move that database to any SP1 nodes in the DAG. Keep this in mind when planning your upgrade, because it will impact the availability level by limiting your fallback options, albeit temporarily.

Exchange 2010 SP1 Rollup 3 v3


After pulling Rollup 3 for Exchange Server 2010 SP1 after an important Blackberry issue on March 15th, the Exchange team claim to have fixed the issue and and re-released the rollup. So, after re-releasing Exchange 2007 SP3 Rollup 3 after fixing potential store corruption issues, Exchange 2010 SP1 now also gets its own rollup re-release. Note that its officially a v3 release; I don’t know what happened to v2.

Exchange 2010 SP1 Rollup 3 v3 raises Exchange 2010′s version number to 14.1.289.7 (initial release was 14.1.289.3). The related knowledgebase article is kb2529939.

You can download Exchange 2010 SP1 Rollup3 v3 here.

Limiting Exchange 2010 SP1 Database Cache


Some time ago, I blogged about on how to limit the amount of memory Exchange 2010 can allocate for database cache. After the introduction of Exchange 2010 Service Pack 1 this didn’t seem to work anymore, as many people reported.

After some investigation, it turns out you also need to set the msExchESEparamCacheSizeMin value for Exchange 2010 SP1’s cache manager to honor the minimum and maximum limits for allocating database cache memory.

To show you this, I’ll first show Exchange 2010 SP1 where I only set msExchESEparamCacheSizeMax. In this example, I’ll use a value of 1024 which corresponds to 32 MB (1024 * 32kb pages). I then turned on Performance Monitor and started monitoring the following MSExchange Database Cache\Information Store counters:

  • Database Cache Size, the current allocated database cache size;
  • Database Cache Size Min, the minimum database cache size;
  • Database Cache Size Max, the maximum database cache size.

After restarting the Information Store and putting on some load on the Exchange server, you will see that the allocated database cache (green line) rises above the configured maximum (blue line).

image

When you check the database cache minimum size (red line), you’ll see it contains a default value, which can be larger than the configured maximum. So apparently, Exchange 2010 SP1’s cache manager contains different logic compared to Exchange 2010 RTM when the (default) minimum value is larger than the configured maximum.

To get Exchange 2010 SP1 to honor the configured msExchESEparamCacheSizeMax value, we need to configure msExchESEparamCacheSizeMin as well. The location is identical, so consult the initial post on how to perform this step; where it reads msExchESEparamCacheSizeMax, use msExchESEparamCacheSizeMin as well.

When we configure a value of 256 for msExchESEparamCacheSizeMin (8 MB) we get the following result after restarting the information store:

image

As you can see, the reported database cache size now nicely flattens out around the 32MB line when under load. Notice that it may go over it a little bit once in a while, but that may have to do with allocating and releasing memory.

Now only one question remains: is this a fault in Exchange 2010 SP1 or expected behavior. At least, it’s different behavior when compared to earlier Exchange versions.

Note that the above information also applies to Small Business Server 2011 since SBS2011 includes Exchange 2010 SP1.