Category Archives: Uncategorized

Outlook Rules Are Not Working After Moving a Mailbox From Exchange 2010 to Exchange 2007



Recently had an issue with a customer who was in the middle of an Exchange 2007 to Exchange 2010 migration.  After moving some test users, there was a bug exposed with a separate vendor’s (not Microsoft Exchange) unified messaging system.  The UM vendor needed to apply a patch that had to be scheduled for a later date.  The bug prevented users from receiving Voicemails on their desk phones and being able to call in and check their VM’s.

As a workaround, we moved the users who had been migrated to Exchange 2010, back to Exchange 2007.  After the move, the UM worked fine, but the users rules were broken, all except for Client Side rules.

Turns out it is a bug with Exchange 2007 SP3, that is resolved in Exchange 2007 SP3 RU7 available here:

The workaround (not recommended) is to run isinteg on the specified database that contains users having the issue.  This is ONLY if you do not want to install the update.  Below is the specific KB page regarding the issue:

Creating an Exchange 2010 DAG Fails with “Access Denied–Server Side Error”



Just a quick blurb today.  Was working on setting up a cross site DAG with a customer today.  Kept getting an issue where when we tried to add two existing mailbox servers to the DAG, both would fail with an “access denied” error:


A server-side database availability group administrative operation failed. Error: The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: The Cluster service couldn’t access the Microsoft Failover Cluster Virtual Miniport network adapter. Verify that other network adapters are working and check Device Manager for errors associated with this adapter. If the configuration for this adapter has changed, you may have to reinstall the Failover Clustering feature on this computer. Learn more at Error: 1062. —> Microsoft.Exchange.Cluster.Replay.DagTaskNetFtProblemException:

Turns out, in the past, this customer had wiped out their local administrators on the Exchange servers with a group policy run amuck!  They added things like Domain Admins in, but didn’t add in “Exchange Trusted Subsystem”.  We added that in, DAG creation worked like a charm. 

Exchange 2010 Cluster Loses Quorum and Unexpectedly Fails Over Databases



I was working on a client’s Exchange 2010 setup, working on a specific issue.  The client had a multi site stretched DAG across two datacenters.  One datacenter was the “primary”, and then they had a second disaster recovery datacenter.  In the primary datacenter they had two mailbox servers, MBX01 and MBX02 each with a copy of the database, and the secondary had a single mailbox server, DRMBX03 with a copy of the database.

The client was experiencing an issue where databases would suddenly failover within the primary site from MBX01 to MBX02, and report that the cluster lost quorum. 

I took a look at the cluster log, which can be generated by running the command:

Cluster log /g /copy:LogFolder /span:120

The span entry specifies the amount back in minutes that the log is generated for.  Just a hint, if you run this from the root of the C: drive, it will copy the logs to the C:LogFolder location.

Within that folder you’ll find a separate log for each of the servers in the DAG, in our case MBX01, MBX02 and DRMBX01:


When I opened the logs, I began to see 1226 and 1236 errors in the log:




These errors are specifically handled by the following hotfix for 2008 R2 Failover Clusters (which is what Exchange 2010 runs on top of):

These were recently released and talked about by the Exchange Team, along with these two other hotfixes:

After applying each of these hotfixes to EACH and EVERY single DAG node and rebooting, the issue was resolved.  These hotfixes are recommended to ANYONE running Exchange 2010 on 2008 R2, regardless if your seeing the issues or not.

Issue Adding RDM LUN to Exchange 2010 Server Using VMWare vSphere and NetApp


**UPDATED on January 6, 2012**

Thanks to both user comments and NetApp themselves, we have determined that there is an easier way to add disks to members of a DAG without removing them from the DAG.  You can simply stop the Windows Clustering service (run the command “net stop ClusSvc” from the command line).  Obviously you should move any active mailbox databases on this DAG member to another DAG member before doing this, as stopping the clustering service will cause the databases to dismount and move on their own.  From there, you should be able to add the disk’s, start the clustering service, and your DAG member will automatically return to a normal operating mode, participating in the DAG.

Thanks to all who sent this in!!

**Original Article**

I recently ran into an issue where I was unable to add an RMD LUN to a Windows Guest running on VMWare vSphere.  Here is my setup.

I had a Windows 2008 R2 guest that was running Exchange Server 2010 SP1.  The guest was a Mailbox server that was a member of a Database Availability Group.  I was attaching the LUN’s to iSCSI RDM’s that were based on a NetApp FAS 3140 running ONTAP 7.3.2.  The guest was running version 6.3 of Snapdrive.

The guest had 12 iSCSI RDM’s working properly for month’s, but the issue arose when I tried to add more.  I would be able to select the volume, create the LUN, size, the mounting location of the LUN.  The issue was when in Snapdrive I was presented with where to store the RDM file for the VM.  See the screen below:


The problem was the console starting freezing up, and generally not responding.


After several minutes, I eventually received an error stating there was an “error in fetching number of vmfs datastores”


I tried all the basic’s, re-installing Snapdrive, upgrading to Snapdrive 6.3 PP1, rebooting the host, stopping and starting the service.

Turns out there is a bug in Snapdrive that causes the error above, when the Guest is a member of a Windows Cluster.  Since all DAG members utilize Windows Clustering, this applied to me.   The resolution was easy.

I moved all the databases off of the server in question.  Then, in Exchange Management Tools, I went to Organization Config->Mailbox and selected the Database Availability Tab.  Right click your dag and select Manage Database Availability Group Membership:


Right click the server in question, select Delete and then the manage button.  This will remove the server from the DAG.

[This will not cause any issue with the existing databases as we’ll see below]

Now, go back into Snapdrive and add your LUN’s, all should be working now.

After your done, add the server back to the Database Availability group, almost the same way you removed it, this time select Add, and then select the previously removed server and add it back.

Next, for each MailboxDatabase that the server has copies of, run this command in the Exchange Management Shell:

Add-MailboxDatabaseCopy –Identity MB01 –MailboxServer NYDAGNODE1

Or in the EMC, go to Organizational Configuration->Mailbox and right click each Mailbox Database and select Add Database Copy.  Then select your server.

Since the server still has copies of the Mailbox Databases, it will start to resynchronize with the DAG, and bring itself up to date.  That way you won’t need to reseed your entire DB which can take some time.

Hope someone finds this useful!

Creating a Database Availability Group in Exchange 2010 – Part 4



In part 3 of this series, we configured the replication networks for the DAG, as well as add database copies to the DAG.  In Part 4, the final part of this series, I’ll show you how to move the active copy between different servers, and how this affect’s the end user. 

Remember way back in Part 1 of this series, I mentioned that Outlook client’s now connect to a Client Access Server to connect to their respective mailbox’s, instead of connecting directly to the Mailbox server?  We’ll, part of the reason why, is that in Exchange 2010, Microsoft wanted the failovers to be less than 30 second’s, no matter what.  By moving the Outlook client to connect to the CAS server’s, you can meet this threshold.  Client Access Server’s are notified about a database move, and thus can redirect their client’s accordingly.

Take our user, Paul A. Ponzeka, who’s mailbox is is located on the Accounting database we created in part 3.  The active copy of the database is on NYDAGNODE1. 

32 Jul. 06 20.10

When we create his profile in Outlook, look at the server he connects to:

33 Jul. 06 20.13

34 Jul. 06 20.13

Notice how the Outlook client connects to the CAS server, and not the mailbox server, which in this case would be NYDAGNODE1.  Everything, except public folder connections, are proxies through a CAS server.

Okay, so now let’s move the active copy to the London server, LNDAGNODE1. We can do this through the console, or the shell.  In the console, navigate to Organization Configuration –>Mailbox->Database Management.  Simply right click on the database in question, and select “Move Active Mailbox Database”.  Fill out the menu, with which server you want to move it to.  The override mount dial allows you to specify an override for the amount of data loss your willing to accept.  We don’t have a need to change this, so just leave it be and hit move:

35 Jul. 06 20.17

So now the system will move the database, and if you note, in our example, it took 6 seconds, also note the command shell you could have run to get the same effect:

36 Jul. 06 20.17

Now the accounting database will go to Mounted on LNDAGNODE1 and healthy under copy status on NYDAGNODE1:

37 Jul. 06 20.19

There you go, all set!  Again, the threshold will be 30 seconds according to Microsoft for the failovers!

So in wrapping, I wanted to touch on a couple of the core differences between Exchange 2010 DAG’s, and CCR clusters, both normal and stretched.

First, in 2007 CCR clusters, when you perform the initial seeding, you need to have every transaction log for that particular storage group, otherwise seeding will fail.  This is no longer true with 2010.  You can add a DAG at ANY POINT.  Second, in 2007, once you moved the active copy to the passive node, you had to re-seed the previously active copy from the passive node before that node could ever be brought back on line.  This is again no longer true in 2010.  You can move back and forth without reseeding.

Third, CCR’s were limited to just 2 nodes, you are limited to 16 members of a DAG in 2010!  In 2007, even if you were doing a stretched cluster with 2008, both nodes had to be members of the same AD site.  This had to do with the nodes having to speak to the same set of Hub Transport servers to avoid data loss.  With 2010 and the inclusion of the new Shadow Transport feature, this is not needed.  So you can have any number of DAG members, in any number of different AD sites.  The outlook client’s will just be redirected to a CAS server in the local site of the now active mailbox server copy, again in under 30 seconds!

Another huge difference, is that since the database’s are no longer members of the servers, the failovers are on a per database level.  What this means is if a server in NY, has three databases, and all of them are active, and you have a situation where only one of the database’s go offline, only that database will be activated on another copy in the DAG, leaving the previous two untouched!

In this four part series, we went over the theory of the Database Availability Group feature of Exchange 2010, as well as how to configure and test the DAG.  Overall, it is a great improvement for both the High Availability, and Site Resiliency model for Exchange. 

User’s Receive a Message Stating that “User” Has Forwarded Your Meeting Request to Additional Recipients



I recently ran into a problem where some user’s were beginning to receive email messages from Exchange, informing them that their Meeting Request’s were being forwarded to additional recipients.  The issue popped up during a migration from Exchange 2003 to Exchange 2007:

ScreenHunter_01 May. 20 15.46

So, easy fix right, it has to do with the Mailbox Calendar Setting option “RemoveForwardedMeetingNotifications”, second from the bottom in this screenshot.  You can check this status by running the command

Get-MailboxCalendarSettings user | fl

ScreenHunter_06 May. 20 16.13

So, here it’s false, we want to change it to true.  Do that by running the following command. 

Set-MailboxCalendarSettings user –RemoveForwardedMeetingNotificiations:$true

ScreenHunter_03 May. 20 15.53

Bam, problem fixed right?  Well, in this case, no.  The user was still receiving them.

Well, I started digging a little more.  Here is the basic background.  An admin was scheduling appointment’s for her boss, and the boss was receiving these messages.  She would either create the invitation on behalf of the boss, and invite attendees, in which case the forwarded emails would come, or edit a pre-existing appointment, in which case they would also be sent out.  Needless to say, the boss wanted it fixed!

We had recently moved her mailbox to Exchange 2007, which is when the issue began.  We investigated the issue a little further.  Turns out, she had been given access to the boss’s calendar by the boss right clicking his calendar and changing the share permissions. 

We created a test situation, Paul Ponzeka’s mailbox on Exchange 07, just like the admin, and Adam Smith’s mailbox on an Exchange 03 server, just like the boss’s.  We assigned permissions for Adam Smith’s calendar to Paul Ponzeka by changing the share permissions on the calendar.  Using Paul Ponzeka’s outlook, we opened Adam Smith’s calendar, and created a meeting invite.  Sure enough, we received the following email in Adam Smith’s Mailbox:

ScreenHunter_04 May. 20 16.00

So we have duplicated the issue.  Next, on Adam Smith’s Outlook, we added Paul Ponzeka as a delegate, but just gave him access to the calendar and the same permissions he had before:

ScreenHunter_05 May. 20 16.02

So, now we have the permissions the same, but the user is a delegate.  Again, on Paul Ponzeka’s Outlook, we create a meeting request in Adam Smith’s calendar, NO MESSAGE!  We tested the rest of the ways the admin was creating invites, all resolved.

It seems there is a bug that causes these messages, unless the user is a delegate.  It also seems like the “Remove Forwarded Meeting Notifications” setting in powershell, only applies if the user is a delegate.

Just for thoroughness, we tested with both the “boss’s” mailbox, and the “admin’s” mailbox on an Exchange 2007 server, and the exact same behavior was exhibited.  It seems it doesn’t matter where the boss’s mailbox is, 2003 or 2007.  In this example, the organization was running Exchange Server 2007 SP1 with Rollup 7.

Adding a Custom Global Address List to an Offline Address Book in Exchange 2007



In most organizations, the Default Global Address List, or GAL, more than fits their needs.  However, some organizations like to create custom GAL’s.  This could be either for the use of address list segregation with a hosted solution, or the Default GAL lists service accounts that the users shouldn’t see.  Creating a custom GAL is easy, especially in Exchange 2007. 

However, an issue may arise when after you have created this custom GAL, regarding users in cached mode in Outlook.  When a user is in cached mode, their GAL is actually the Offline Address Book.  By default, the Default Offline Address Book includes the Default GAL as its source.  So this custom GAL you just created isn’t seen by the users in cached mode. 

The trick to this, is to create a new Offline Address Book, and add the new GAL to it.  For this, you will need to use powershell.  So lets say you have a custom GAL called “Test GAL” in Exchange 2007.  You can check what GAL’s you have by running the Get-GlobalAddressList command:

ScreenHunter_05 Apr. 29 11.47

We are going to create a new Offline Address Book, with the “Test GAL” as the included GAL to generate the OAB from.  Also, don’t forget, a specific Mailbox server has to be responsible for generating the OAB, so we are going to use server Test-EX07B.  The command will be as follows:

New-OfflineAddressList –Name “Test OAB” –AddressLists “Test GAL” –Server Test-EX07B

ScreenHunter_06 Apr. 29 11.52 

So you have your new “Test OAB”.  Just a heads up, while in the Exchange Management Console, you’ll be able to edit any item of the new OAB, except the address list.  This means you can change the name, and set the delivery mechanism for public folder distribution or web services distribution, but you can only add address lists through the shell:


ScreenHunter_07 Apr. 29 11.55

Now all thats left to do is add the “Test OAB” as the default Offline Address Book for the database’s in your organization.  You can either right click on each database in your organization, select the Client Settings tab and change to the “Test OAB”:

ScreenHunter_08 Apr. 29 11.59

Or, if you want to do it en masse for every database in your organization, you would run the following command from the shell:

Get-MailboxDatabase | Set-MailboxDatabase –OfflineAddressBook “Test OAB”

ScreenHunter_09 Apr. 29 12.10

Database Cache Size for Hub Transport Servers



A little while back, the Exchange Team released a new recommendation set for the Database Cache Size in Hub Transport Servers for SP1.  The recommendation is to change the maximum database cache size to 512 MB, from the default value of 128 MB, and it should help disk I/O substantially.   This change is recommended for Hub Transport servers with 4 GB of RAM or more, and they have not tested, nor support yet changing the Max Database Cache Size to anything over 512 MB.  Although my testing was done with 4 GB of RAM, I’m sure there would be similar results on a dedicated HT server running 2 GB of RAM or more.

The test they ran, was on a Hub Transport Server that was processing some 21 Messages/Sec.  The reduction they saw was noticeable, lowering the total IOPS/message from 26.71 to 11.67, which is pretty impressive. 

This lead to a discussion between myself and several other colleagues, regarding, not the legitimacy of Microsoft’s claim, but the necessity in smaller environments.  We all worked in much smaller shops at the time, the biggest of us with a headcount of no more than 400 people total.  Although the users are unusually heavy in all of our locations, they can’t meet the message standards set forth in the Exchange Team’s article.  Our question was, would it make any difference in smaller environment’s such as ours?

The discussion settles around the new transport engine used by the Hub Transport role in Exchange 2007.  Hub Transport servers use the same Extensible Storage Engine (ESE) database as Mailbox servers use to store mailboxes, no longer relying on the Windows IIS SMTP service to handle SMTP traffic.  Unlike a mailbox server, which can dynamically grow it’s database cache to use any extra available memory the server may have, the Hub Transport server has a hard coded cap to the amount of memory it can use.  By default in Exchange 2007 SP1, this value is 128 MB.  The limit is controlled by the <add key="DatabaseMaxCacheSize" value="134217728" /> key that’s located in the EdgeTransport.exe.config file.  This file is stored by default at C:Program FilesMicrosoftExchange ServerBin.  Any changes to this value require a restart of the Microsoft Transport Service to take effect.

For the test, in one of my AD sites, I installed a single Hub Transport server.  This server hosted the Client Access, and Hub Transport server roles.  The server was installed as a VM on an ESX host, running a DL Proliant 380 G5 host with 16 GB of RAM.  The VM had 4 GB of RAM, one virtual core, and it’s hard drives (C and D), were both hosted as VMDK files on an iSCSI attached LUN.  Throughout this testing, the VM was the only VM running on the host, and was the only machine with activity on the iSCSI LUN.  The transport DB and Logs were hosted on the same VMDK.

For the test, the HT was set to send TLS encrypted email only to a third party retention site, connecting directly through DNS.  Initially the server was run with the max database cache size at 128 MB.  I monitored the servers for a period of 1 hour using perfmon, and collected the following counters:

Average Disk sec/Read

Average Disk sec/Write

Average Disk sec/Transfer

Disk Transfers/Sec

MSExchange DatabaseDatabase Cahce % Hit

MSExchange DatabaseDatabase Cache Size (MB)

MSExchange DatabaseI/O Database Reads/Sec

MSExchange DatabaseI/O Database Writes/Sec

MSExchange DatabaseI/O Logs Reads/Sec

MSExchange DatabaseI/O Logs Writes/Sec

The results of the test at 128 MB Database Cache Size were:

Log Writes/Sec were 32.33

Database Writes/Sec were 10.8

Database Hit % was 95.27

Below is a picture of the perfmon, with the highlighted value being Average Disk Sec/Write:


You will notice a decent amount of disk activity, as depicted by the various high spikes in disk activity.

For the next test, I changed the Max Database Cache size to 512 MB, restart the Transport service and began the test again.  Again, I monitored the server for an hour, and collected the above listed counters using perfmon.  The results are as follows:

Log Writes/Sec were 10.13

Database Writes/Sec were 2.4

Database Hit % was 98.6.

In the Log Writes/Sec, we saw a 31% reduction, and in Database Writes/Sec, a 22% reduction.  Here is the perfmon shot with the same highlighted value:


You can see by the picture, that the spikes are noticeably lower.  It seems that the value change, gives a very noticeable reduction in I/O used by the Hub Transport server, even in a smaller environment.  Also, the higher database hit % indicates the server did not have to go to disk nearly as much to return cached recipient info.

Overall it seems that in pretty much any environment, the changing of the Maximum Database Cache Size, has  a distinct advantage in the terms of disk I/O reduction.

Installing a Continuous Copy Replication or CCR Cluster Part 4…



We’ll, in the first three parts of this series, we have installed the CCR cluster with one active and one passive node, as well as configure the Transport Dumpster.  We are pretty much home free.  First we need to do some things.  The first of which, is validating the install and DB Seeding:

DB Seeding:

DB seeding is the process where you copy the active node’s up to date database, to the passive node’s blank or not up to data database.  Once seeding is complete, you will be able to let the log copying keep the DB’s up to date.  This happens automatically when the servers are initially installed, so you don’t need to do anything but to check to ensure that the process worked.  You can do this by navigating to Server Configuration->Mailbox.  You should see “Healthy” under the copy status:

ScreenHunter_02 Feb. 15 20.34

So when would you need to reseed?  We’ll, lets say your active node blue screens.  You fail over to the passive node, extremely limited interruption to your end users.  Problem is, that blue screen, has corrupted your exchange DB on the active node.  You can simply re-seed the working copy of your DB from the good node.  We’ll simulate this now.

First, lets assume our active node WAS NYCCRNODE2 and it has failed over to NYCCRNODE1.  We need to replace the copy of NYCCRNODE2’s DB with the working copy on NYCCRNODE2.  First, we will need to stop the copying of the database.  In EMS, run the following command:

Suspend-StorageGroupCopy –Identity:”NYMB01First Storage Group”

Now, NYCCRNODE2 is no longer receiving updates.  Let’s remove the files for the First Storage Group on NYCCRNODE2, simply delete them.  You will need to stop the Exchange Services on NYCCRNODE2 to unlock the files.

Now, what we need to do, is create a new DB by Seeding or copying the DB from NYCCRNODE1 to NYCCRNODE2.  Run the following command:

Update-StorageGroupCopy –Identity:”NYMB01First Storage Group” 

You should receive the following message:

ScreenHunter_03 Feb. 15 20.42

The green bar, is the copying of the database.  Make sure you restart the Exchange Services you stopped earlier.  Now check the copy status of the DB and it should read Healthy again.

In SP1, you can also run the Suspend and Update commands by right clicking on the Storage Group in the EMC.

Testing the CCR Cluster:

We can test the cluster with the Move-ClusteredMailboxServer command, or with the Exchange Management Console.  Be advised, you never want to use Cluster Administrator to move the cluster, always use an Exchange tool to perform that. First, lets get the status of the cluster with the Get-ClusteredMailboxServer command:

ScreenHunter_01 Feb. 15 20.23

As we can see, the active node is currently NYCCRNODE1.  Lets move it to NYCCRNODE2.  Your command should look like this:

Move-ClusteredMailboxServer –Identity NYMB01 –TargetMachine NYCCRNODE2 –MoveComment “Testing CCR Move”

ScreenHunter_02 Feb. 15 20.26

After you confirm, if you run the command Get-ClusteredMailboxServer  you should see NYCCRNODE2 as the active node:

ScreenHunter_03 Feb. 15 20.27

Great!  The cluster fails over without issue.  If your end users are in Cached Mode, they wont even realize the cluster went offline!

Moving the Storage Group and Database Files:

This one is a little tricky to grasp the concept of.  In all previous versions of Exchange, and all Versions of 2007 except a CCR cluster, you could just tell the management console to move the Storage Group Files, or the DB file, and it would do so without issue.  Try that with a CCR cluster, and you’ll notice two things.  One, when you select “Move the Storage Group Path”, that the browse for a new location is grayed out:

ScreenHunter_04 Feb. 15 20.54

Then, even if you try to move, you’ll receive the following error:

ScreenHunter_05 Feb. 15 20.55

The error states you cannot perform this on a remote server (not us) or on a clustered mailbox server (us!) in a CCR environment. Please use the –ConfigurationOnly option and manually move the files.

Ok, so what just happened?  We’ll, lets think about it.  We have a cluster that has two separate sets of Exchange files.  Our cluster though, only has one set of paths configured in Active Directory. If we use ADSIEDIT and drill down to our server object located in:

Configuration->Servers->Microsoft Exchange->Organization Name –> Administrative Groups –> Exchange Administrative Groups (FYDIBOHF23SPDLT) –> Servers –>NYMB01 –> Information Store –> First Storage Group

If we right click on this value and select properties.  Then navigate for an Attribute called msExchESEParamSystemPath, this will tell us the location of where Active Directory thinks they are:

ScreenHunter_07 Feb. 15 21.05 

This is why the path’s for each node HAVE TO BE THE SAME! So, what are we to do?  We follow the error’s suggestion.  We use the –ConfigurationOnly parameter.  What this will do, is update Active Directory with the new path we INTEND to have the files on.  We will then have to move the files ourselves with good old fashion Copy and Paste.  Just like all moves, this will cause the DB’s to be inaccessible.  Unfortunately, having the cluster here doesn’t help as both will have to go offline.  That is why it is better to do this upon the initial install, when there are no users on the server.

So, we want to do the following move:

Storage Group Files  

“C:Program FilesMicrosoftExchange ServerMailboxFirst Storage Group”  -> “E:Storage Group Files”

Database File

“C:Program FilesMicrosoftExchange ServerMailboxFirst Storage Group”  -> “E:DB Files”

First, suspend the replication of the DB’s:

Suspend-StorageGroupCopy –Identity:”NYMB01First Storage Group”

Next, dismount the database:

Dismount-Database –Identity:”NYMB01First Storage GroupMailbox Database”

ScreenHunter_08 Feb. 15 21.13

Now you must change the path of the files in AD, remember, we need to use the -ConfigurationOnly option:

Move-StorageGroupPath –Identity:”NYMB01First Storage Group” –LogFilePath “E:Storage Group Files” –SystemFolderPath “E:Storage Group Files” –ConfigurationOnly

The LogFilePath is the Transaction Logs, and the SystemFolderPath is the Checkpoint file.

ScreenHunter_09 Feb. 15 21.16

Now, on both nodes, copy the files over manually to their new locations.  You are literally copying EVERY file and folder except a file with the .edb extension. If we check the same value in ADSIEDIT:

ScreenHunter_10 Feb. 15 21.18

It’s been changed.  Now, do the same for the Exchange Database File.  You have to move the EDB file PRIOR to running this command.  That’s because you have to actually specify the file itself and the EMS checks this against the active node. 

Move-DatabasePath –Identity:”NYMB01First Storage GroupMailbox Database” –EdbFilePath “E:DB FilesMailbox Database.edb” –ConfigurationOnly

ScreenHunter_11 Feb. 15 21.28

Now, all the files are moved on BOTH nodes.  We can re-mount, and resume seeding.

To mount, its Mount-Database –Identity:”NYMB01First Storage GroupMailbox Database”

ScreenHunter_12 Feb. 15 21.30

To resume seeding its Resume-StorageGroupCopy –Identity:”NYMB01First Storage Group”

ScreenHunter_13 Feb. 15 21.31

And your files have now been moved successfully.  As you can see there is a little bit more work with a CCR cluster than with other Mailbox Server role installs of 2007.  Finish the above steps for any remaining DB’s and Storage Groups you have.

Updating the Cluster:

This one is actually really easy when you think about it.  Let’s say it’s Patch Tuesday, and you have a whole slew of patches for the Base OS, as well as Exchange 2007 to install.  There is a certain process you should follow with a cluster.

***Microsoft Update, the update client that downloads updates for ALL Microsoft products and not just Windows, will NOT recognize nodes of a cluster, as having Exchange 2007 installed.  This means you need to manually download the updates for Exchange 2007 manually and apply them.***

The process is simple.  Always update the passive node.  This means, install all your updates on the passive node, finish all the reboots, and ensure everything is working.  Next, move the CMS over to the freshly updated node with the Move-ClusteredMailboxServer command.  Now, update the node you just moved the CMS off of.  Install all updates, finish the reboots, ensure everything is working.  See, easy!

Word of advice, make sure that each node is at the same patch level for OS and Exchange.

So, it took us four articles to get there, but we are there.  We have covered the theory behind a CCR cluster and how it can give an business the Enterprise level protection without a costly investment such as a SAN, to the installation of the cluster and Exchange 2007, to configuring and testing your cluster. 

Happy Clustering!

Installing a Continuous Copy Replication or CCR Cluster Part 3…



In the last article, we finished setting up the cluster, and the file share for the Majority Node Set cluster.  Before we get to installing the actual Exchange CMS, lets talk a little bit about, and configure, the Transport Dumpster.

First, what is the Transport Dumpster?  It is a feature of Exchange 2007 that only comes into play when a mailbox is located on a CCR cluster.  Remember we talked about how the active node of the cluster, ships the logs to the passive node, and then plays them into its own copy of the database?  Imagine now if you had a situation where the active node went down, hard.  Let’s say the server was pretty busy, and it blue screened, the passive node could be missing a decent amount of transaction logs that should have been shipped over.  Well, we would now have missing data in our mailboxes wouldn’t we?  This is something we like to avoid!

This is where the Transport Dumpster comes in.  When configured, and a mailbox is located on a CCR cluster, and a lossy failover occurs, the Transport Dumpster will attempt to recover lost emails.  The Transport Dumpster is an organizational wide setting, and involves the Hub Transport servers.  What the dumpster actual does is store copies of ALREADY successfully delivered emails in it’s queues.  When the lossy failover occurs, the newly appointed active node of the cluster requests past emails from the Hub Transport servers for an amount of time that would account for most of the data lost.  Now, this wont hold data such as contacts or calendar appointments, but when you get down to it, the emails are the meat and potatoes.  The Transport Dumpster should help you account for almost all of the difference in data.  Now, keep in mind, this means emails that have already been delivered.  For instance, say you have a lossy failover on Tuesday at 10:00 AM.  The newly appointed active node could request all copies of emails that were delivered from Tuesday at 9:30 AM till Tuesday at 10:00 AM to account for any logs it did not receive before the failure.

There are two values that you want to be concerned with.  The first is the total size of the dumpster, and the number of days that the dumpster retains emails.  Run the Get-TransportConfig command to list the current settings:

ScreenHunter_01 Feb. 14 19.06

The total days emails are allowed to stay in the dumpster is marked by the MaxDumpsterTime value, which by default is seven days.  The total size of the dumpster depends on the value MaxDumpsterSizePerStorageGroup which by default is 18 MB.  This means if you have five storage groups, the total size of the Transport Dumpster could get no larger than 5*18MB = 90 MB.  If you added a sixth storage group it would now be 108 MB. 

Microsoft’s recommendation for configuring the Transport Dumpster is to make the maximum size per storage group value to be 1.5 times the size of the maximum message in your environment.  So if you allow messages of 50 MB in your environment, your MaxDumpsterSizePerStorageGroup should be 1.5 * 50MB = 75MB.

So first, lets get the configuration for our enviornment.  Run the Get-TransportConfig command:

ScreenHunter_02 Feb. 14 19.16

We have a 35 MB limit on sending and receiving.  So, we should set the MaxDumpsterSizePerStorageGroup value to be 1.5*35MB or 52.5.  Lets just round up to 53 MB.  We also want to set the maximum number of days that a message can last in the dumpster to be 10 days instead of the default 7. 

Run the command Set-TransportConfig –MaxDumpsterSizePerStorageGroup 53MB –MaxDumpsterTime 10.00:00:00

ScreenHunter_03 Feb. 14 19.18

Run the Get-TransportConfig again to confirm the settings:

ScreenHunter_04 Feb. 14 19.19

Okay, so that takes care of the Transport Dumpster, now on to installing Exchange CMS!!

On the active node, in our case NYCCRNODE1.ponzeka.test, install the Exchange 2007 binaries, ensure you have all of the pre-requisites in place.

For installation, select “Custom”, remember you CANNOT install any roles besides the Mailbox Role in a cluster.

ScreenHunter_01 Feb. 14 19.26

Select Active Clustered Mailbox

ScreenHunter_02 Feb. 14 19.29

Make sure to select Continuous Cluster Replication.  For the Clustered Mailbox Server Name, ensure you put in the name you want clients to be presented with.  In our case its NYMB01.

ScreenHunter_03 Feb. 14 19.30

For the next screen, you will need to enter the IP address that will be presented to the clients, in our case its

ScreenHunter_04 Feb. 14 19.31

Now the system will perform readiness checks to ensure that the CMS role can be installed on this server.  If everything checks out, hit Install.

After the install has been completed, you need to log into the passive node, NYCCRNODE2.ponzeka.test and repeat these steps.  Except this time you need to select the Passive Mailbox Server Role.

All set!  We should now have a fully functional CCR cluster!  In the next article we’ll go over how to seed a DB, update the cluster and test failovers.