Exchange Server Pro » DAGs

Exchange 2010 Error: Registry key has subkeys and recursive removes are not supported by this method.

Paul Cunningham — Wed, 13 Oct 2010 13:16:13 +0000

When an Exchange Server 2010 Database Availability Group has been upgraded to Exchange 2010 SP1 you may encounter an error when adding or removing database copies on a DAG member.

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00

Mailbox Database 02
Failed

Error:
Registry key has subkeys and recursive removes are not supported by this method.

Warning:
An unexpected error has occurred and a Watson dump is being generated: Registry key has subkeys and recursive removes are not supported by this method.

Exchange Management Shell command attempted:
Add-MailboxDatabaseCopy -Identity ‘Mailbox Database 02′ -MailboxServer ‘EX2′ -ActivationPreference ’2′

Elapsed Time: 00:00:00

An event log entry is also logged on the Exchange server.

Log Name: Application
Source: MSExchange Common
Date: 10/13/2010 10:47:19 PM
Event ID: 4999
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: EX2.exchangeserverpro.local
Description:
Watson report about to be sent for process id: 3372, with parameters: E12, c-RTL-AMD64, 14.01.0218.015, RemotePowershell, mscorlib, M.W.RegistryKey.DeleteSubKey, System.InvalidOperationException, 829, 02.00.50727.4952.
ErrorReportingEnabled: False

The error will occur for both adding and removing database copies. When removing a database copy from a DAG member the action is still successful despite the error, however when adding a database copy to a DAG member the action is not successful.

This is a known issue with Exchange 2010 SP1 upgrades as reported by the Microsoft Exchange Team. The error occurs because of a registry key on the server that you are trying to add or remove the database copy from.

To locate the registry key you first need to know the GUID of the mailbox database. From the Exchange Management Shell run the Get-MailboxDatabase command to view the GUID.

[PS] C:\>Get-MailboxDatabase "Mailbox Database 02" | fl guid

Guid : ccfd3c4a-6187-4253-aa31-99a15c33546c

Once the GUID is known you can remove the offending registry key.

[PS] C:\>Remove-Item HKLM:\Software\Microsoft\ExchangeServer\v14\Replay\State\ccfd3c4a-6187-4253-aa31-99a15c33546c\DumpsterInfo

Note: substitute your own GUID in place of the one in the above command string.

Repeat the command on any additional Exchange 2010 DAG member servers that you also want to add the database copy to.

After you have removed the registry key you can retry adding the database copy to the Exchange server, and it should now be successful.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 DAGs and VMware High Availability

Paul Cunningham — Mon, 23 Aug 2010 09:00:13 +0000

If you are planning to deploy Exchange Server 2010 Database Availability Groups, and you virtualize your Exchange environment, then it is important to understand the supported scenarios.

Microsoft makes it very clear in their system requirements for Exchange Server 2010:

Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (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. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

In short, DAG members should have any virtualization high availability options disabled.

This is in slight contrast to the advice from VMware themselves:

While the use of database availability groups on top of hypervisor based clustering is not a formerly (sic) supported configuration, internal VMware tests have shown that the two technologies can co-exist and can be a viable solution to ensure maximum recoverability in the case of a host failure.

To paraphrase, it isn’t supported but we think you’ll be fine.

You might get some push back from customers or managers who have been sold on the idea of VMware HA for everything, or who take the line from VMware as implied support for the configuration. But in the real world I prefer to go with what is supported over what is possible.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 Database Names

Paul Cunningham — Wed, 06 May 2009 20:00:06 +0000

As with earlier versions of Exchange Server when you first install Exchange Server 2010 it configures the first mailbox database for you. In Exchange Server 2007 this database was placed in a Storage Group called “First Storage Group” and was simply named “Mailbox Database”.

This was not a problem in earlier versions of Exchange. Databases were always named relative to the server they were hosted on and the storage group they were contained within, so a database named “Mailbox Database” on SERVER01 had a unique name such as “SERVER01\First Storage Group\Mailbox Database” which would not conflict with another database named “SERVER01\Second Storage Group\Mailbox Database”, even though they are both named “Mailbox Database”.

When you look at the first mailbox database on your Exchange Server 2010 server you’ll notice the naming is different. Here is an example.

The first database name has a random number appended to it that is designed to be unique to that Exchange organisation. That seems strange until you consider it in the context of the new Exchange Server 2010 database concepts. Here it is explained by Paul Robichaux:

Here’s the deal: in Exchange 2007 and earlier, mailbox and public folder databases are children of server objects. That means that you can uniquely identify a database by a combination of its name (which may not be unique throughout the forest) and its server name (which is guaranteed by AD to be unique). In Exchange 2010, the database is no longer “owned” by a particular server. Instead, it’s a member of a DAG, and it may actually become active on any server in the DAG at any time. That means that your database names shouldn’t include the name of the server. DAGs can span AD sites, too, so guess what: don’t use the AD site name (or the name of the physical datacenter) either. Otherwise the name of the database may not correspond in any way to where the database is actually active.

To learn more about Database Availability Groups check out this Technet article.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » DAGs

Exchange 2010 Error: Registry key has subkeys and recursive removes are not supported by this method.

Related posts:

Exchange Server 2010 DAGs and VMware High Availability

Related posts:

Exchange Server 2010 Database Names

Related posts: