Activate SCR Target via EMS script
If you’ve got SCR installed and are using the Database Portability model described in “Standby Continuous Replication: Database Portability“, here’s a useful Exchange Management Shell that scripts the entire activation process. Just change all of the noted fields to match your source and target servers and even add additional storage groups/databases to the script if you like.
Be sure to triple check your entries and TEST IN A LAB ENVIRONMENT before unleashing this production!
Activate-SCRTarget.zip (1.6 KiB, 663 hits)
My “unofficial” Exchange Server 2007 CCR recommendations
Having had Cluster Continuous Replication in place now for about a year, I’ve derived some of my own best practice recommendations that might not be found within the official Microsoft documentation. Of course, it’s been a little while since I last checked that documentation, so this could be duplication of recommendations.
Although these recommendations are based on a very solid and stable production environment…anything bad or job search inducing that happens as a result of implementing them in your environment is not my responsibility.
So, here is the list in order of importance:
- Hub Transport servers should NOT be the location for your File Share Witness. I have found the BEST location in my opinion is in fact Domain Controllers in the same domain as the Exchange servers. This is obviously to be extended to cover other sites and domains as your organization may have them. Of course, you need to set up two FSW locations…one primary and one staged with folders and permissions in place in the event your primary FSW server dies.
- I do know for a fact that the original guidance Microsoft gave was to have the FSW on the Hub Transport servers. The logic was that a Hub Transport is a required role and the FSW needs to be on a server the Exchange administrator controls…a natural fit.
- The servers hosting the File Share Witness (or at least the one server that is the primary FSW host) should NOT be in the same data center as either of the two Mailbox server nodes in the CCR cluster. By using a three data center model (all local and in the same AD site) you provide complete and automatic fail over protection in the event of a data center failure.
- Hub Transport servers should NOT use SAN attached storage for their queue databases. Internal storage, in the Hub Transport server, is preferred. In the event that a CCR lossy failure occurs and Transport Dumpster redelivery is required, it would be best to not have that Transport Dumpster data on the SAN that is possibly out of action now due to a data center failure or SAN failure. If the queue database is located on internal storage in the Hub Transport server, you can simply move that Hub Transport server physically to an operating location (doesn’t even have to be in a data center), put it back on the network and now it can participate in Transport Dumpster redelivery. Cool.
- If possible, Hub Transport servers should NOT be placed on blade server hardware UNLESS you have the capability to place a blade server chassis in another location during a data center failure. This goes along with the previous recommendation about being able to bring that Hub Transport back online in an alternate location.
- At least one Domain Controller SHOULD be placed in each local data center you’ve got Exchange servers placed in. Of course, you should really have a minimum of two data centers to take advantage of CCR and you should always have at least two Domain Controllers per AD site…so one Domain Controller per data center makes perfect sense. If you’re going to use a Domain Controller (as noted previously) for your File Share Witness, this then offers you both AD and Exchange protection in one move.
Do you have anything to add?
OALGen in CCR clusters
Just a heads up if you’re running Exchange Server 2007 CCR clusters. Moving the cluster resources (using Exchange Management Console or Exchange Management Shell) does not update the OALGen registry settings accordingly. So, if you normally run your CCR clusters active the “A” node, when you move them to the “B” node, OALGen will start throwing errors once per day with an Event ID of 9395 as seen below.
Event Type: Warning
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9395
Date: 7/28/2008
Time: 2:12:30 AM
User: N/A
Computer: xxx
Description:
OALGen is running on a cluster continuous replication (CCR) node which does not have registry value ‘SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\CCRCluserName\EnableOabGenOnThisNode’ or it is not set to this node name. Offline address book generation will not be performed.
I don’t know why the cluster move process doesn’t update the registry accordingly, at least it doesn’t in Exchange Server 2007 SP1 UR1. (I wasn’t able to apply UR2 in June due to other maintenance taking a higher priority and now UR3 is out so I’ll just apply that in August during the maintenance window.)
It’s an easy enough fix though as the error itself indicates. Just navigate the appropriate location in the registry of both nodes in the CCR cluster and make the change. I’ll be creating two registry .REG files and just importing them from now on to make the change even faster (and without error).
If you want to perform detailed logging on the next OAB rebuild, which you will want to trigger manually after updating the registry, simply change the logging level for the “OAL Generator” component to Expert by using the following command at the Exchange Management Shell: Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Expert. You can then manually trigger the OAB update by using this command (assuming that you haven’t renamed the Default OAB): Update-OfflineAddressBook –Identity “Default Offline Address List”. You should see a lot of activity in the Application log on that CCR node with an Event ID 9107 being the last entry for OAL Generator.
Event Type: Information
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9107
Date: 7/28/2008
Time: 7:34:24 AM
User: N/A
Computer: xxx
Description:
Offline address list generation finished.
- Default Offline Address List
Don’t forget to set your OAL Generator logging level back down…it’s typically at Low by default, although can check it by using the Get-EventLogLevel “MSExchangeSA\OAL Generator” command. Use the Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Low command to set logging back down.
-
Translator
