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, 662 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?
Ops Mgr agents not discovering Active Mailbox nodes
A while back, when I had first started rolling out Operations Manager 2007, I had a strange issue occur where the agents would not discover that the Active nodes in CCR mailbox clusters actually were actually holding the “mailbox” role. The agents made this discovery correctly on the Passive nodes of the CCR clusters, but not on the Active nodes. In fact, the agent wasn’t discovering any Exchange Server 2007 roles on the Active nodes of the CCR clusters.
The problem ended up being that something (although we never found out what) had a lock on the required portion of the Registry that the Ops Mgr agent was trying to scan. Working with PSS, Ops Mgr tracing per KB 942864 was dialed up and analyzed for the Active nodes of the CCR clusters. A snippet from one of the server’s “TracingGuidsNative.etl” log indicates that the Ops Mgr agent was failing to open the registry key below HKLM\Microsoft\Exchange\v8.0\.
[4]33AC.220C::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[4]33AC.220C::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.1CD8::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0870::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key Software\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[3]33AC.220C::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key Software\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.3114::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[7]33AC.2824::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[7]33AC.2824::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0C18::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0D78::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.0D78::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
Unfortunately, no exact process was found that was locking the Registry. By chance, a reboot neccessitated by the installation of Exchange Server 2007 SP1 Update Rollup 1 freed the lock. After that reboot, the discovery successfully completed.
-
Translator
