I'm having some trouble wrapping my head around an issue I'm running into:

I have a 3 node exchange 2007 CCR environment running Version 8.1 (Build 240.6). Verified just now via command line. We're having a number of issues, and for obvious reasons (the dreaded 9667 being one of them).

I intend to install HeaderFilterAgent to fix this moving forward, and while I'm at it I want update to SP3, because I know it needs to happen. I've been reading the MS KB on this (https://technet.microsoft.com/en-us/library/Bb676320%28v=EXCHG.80%29.aspx) and I have a few questions:

1) While upgrading I see that I shutdown my clustered mailbox services and move them from my active node to my passive node after upgrading the active node. Doesn't the process of upgrading the active node disrupt the log file copy (get-storagegroupcopystatus)? If so how is my mailbox cluster going to move from my running passive node to my out of date node and come online after update without problems/corruption?

I just don't understand the situation/process. I'm trying, but it's illusive for me at the moment.

2) What does this mean " stop any services that have open handles to performance counters"?!

3) When I go to update my CAS/HT/UM, isn't that going to take my mailbox cluster offline (and possibly cause corruption if I don't shut down the cluster first)?

• Edited by KTAAdmin 11 hours 13 minutes ago

All CAS role holders need to be upgraded before you touch the mailbox servers. Otherwise you can get problems with accessing the mailboxes through OWA.

So service pack the CAS/Hub and reboot them. Then install the rollup and reboot. Only then consider the CCR nodes.

For your third question - that usually means any monitoring tools that are monitoring Exchange via the perfmon counters. The services mentioned are a good start, but if you are using a third party tool you should probably stop any agents. I would also stop and disable any AV software on the server that you are upgrading as well.

When you stop the cluster services the replication stops. When you bring the server back online, the cluster resumes. You will not be able to failover the cluster to the newly updated node until it is up to date.

Simon. 

Thanks for the information on the CAS/HT/UM box.

Regarding the Clustered Failover: This is where I get confused. I get that replication will stop when I stop the cluster services. But if my active node is Server2 and I go about updating Server3, then take my cluster offline, move it to Server3 then run /upgradecms how does it not cause problems with the MDB? Does it move the files from Server2 to Server3 prior to upgrading/updating the CMS? I'm asking because that's the only thing that makes sense in my mind, and our First Storage group is big (on the active node our Mailbox Datastore is 606G and on the passive node it's taking up 600G according to the files sizes. A discrepancy that scares me alone.).

Much appreciated all who try to help me understand!

• Edited by KTAAdmin 11 hours 2 minutes ago

You should definitely do both the service pack and the rollup. It will do no harm to do those for the CAS role as soon as possible, as Exchange will downgrade quite happily.

If you think that your CCR isn't working properly, then you should probably investigate that first. Is that a single database or multiple databases?

Simon.

Just the two you'd expect to find (public folder db and our Mailbox db). I have no reason to think CCR isn't working, it reports as healthy from get-storagegroupcopystatus. This just so happens to be the first CCR node I've had to work with, and it was dumped on me by a guy who never updated it. Ever.

And regarding updating the CAS:

If I leave the Mailbox servers alone, and run the updates on the CAS server won't it cause problems with the storage groups? Do I take the databases offline before updating the CAS? What's the process for this part of it? This documentation seems to have left this bit out.

I would strongly recommend that you look at splitting the database up. There is no need to have a single database of that size, which would cause you problems if you ever need to reseed.

You can have four storage groups each with four databases in them, so there is plenty of scope to split the data up.

It is something I would consider doing before the upgrade - that way you can be sure the databases are smaller in case a reseed is required, and can be sure the CCR is working correctly.

On Exchange 2007 the best practise was considered to be somewhere around 250gb max, which provided a good trade off between database size and recovery/reseed speed.

Simon.

Looks like continuous replication only allows for one database per storage group.

Looks like I'll be making some more storage groups.

• Edited by KTAAdmin 9 hours 46 minutes ago

I forgot that limitation. It has been a very long time since I designed Exchange 2007 database layouts.

No storage groups in Exchange 2010 and higher, so much easier to manage.

I would still split the data up.

Simon.

And regarding updating the CAS:

If I leave the Mailbox servers alone, and run the updates on the CAS server won't it cause problems with the storage groups? Do I take the databases offline before updating the CAS? What's the process for this part of it? This documentation seems to have left this bit out.

Missed this, as I think we cross posted.
The CAS has no effect on the mailbox role. Hopefully you have multiple CAS role servers.

Therefore you just run the setup.exe and leave it to get on with it. The first one will take a while as it has to prep the domain and forest.

On Exchange 2007 the clients connect directly to the mailbox role, so CAS is only used for web services (ActiveSync, Outlook Anywhere, POP/IMAP etc).

The reason the documentation left that out is that with the CAS there is no difference to a regular service pack installation. No special measures required.

Simon.

Unfortunately, and this gives you and idea how silly built this thing is, there's only ONE CAS! So we're sooooooo redundant </snark> with our Exchange Environment, as long as our CAS doesn't have any issues.

I would be tempted to take one of the CCR nodes out and use the licence for a second CAS.

Single point of failure and all that.

Simon.