The Windows Cluster service encountered and error during function OpenCluster.

Article
01/21/2009

When users attempt to use Exchange Management Shell (PowerShell) to perform management tasks against an Exchange 2007 SP1 Cluster on Windows 2008, certain functions return "The Windows Cluster service encountered an error during function OpenCluster".

In the following example I am using a new account I created in active directory. This account is a member of Domain Administrators and a member of Exchange Organization Administrators. The user account is logging onto a machine where the Exchange 2007 SP1 RU5 management tools are installed as well as the Windows 2008 Failover Cluster Management tool.

Using the account, I attempt to create a mailbox on the clustered exchange instance. Below is a copy of the verbose output of this command:

[PS] C:\Windows\System32>New-Mailbox -Name Test -Database 2008-MBX3\2008-MBX3-SG1-DB1 -UserPrincipalName test@exchange.msft -Verbose

cmdlet New-Mailbox at command pipeline position 1
Supply values for the following parameters:
Password:

The information here is not overly helpful in actually determining the reason why the open cluster failed. To further determine the reason we can dump the message associated with the exception.

To get the exception information, type the following in the Exchange Management Shell: $error[0].exception.stacktrace. The output of this command is:

[PS] C:\Windows\System32>$error[0].exception.stacktrace
   at Microsoft.Exchange.Common.ExCluster.GetActiveCmsOnNode(String nodeName)
   at Microsoft.Exchange.Data.Directory.NativeHelpers.GetLocalComputerFqdn(Boolean throwOnException)
   at Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.ReadLocalServer()
   at Microsoft.Exchange.Data.Directory.Recipient.RecipientUpdateService.FindE12RusServer()
   at Microsoft.Exchange.Data.Directory.Recipient.RecipientUpdateService.LocateServer()
   at Microsoft.Exchange.Configuration.Tasks.RecipientTaskHelper.ApplyRusPolicy(RecipientUpdateService rus, ADRecipientSession recipientSession, ADRecipient recipient, PolicyType[] policyTypes, TaskVerboseLoggingDelegate logHandler, TaskWarningLoggingDelegate writeWarning)
   at Microsoft.Exchange.Configuration.Tasks.RecipientTaskHelper.ApplyRusPolicy(ADSystemConfigurationSession configurationSession, ADRecipientSession recipientSession, ADRecipient recipient, Fqdn domainController, String serverName, TaskVerboseLoggingDelegate logHandler, TaskWarningLoggingDelegate writeWarning)
   at Microsoft.Exchange.Configuration.Tasks.RecipientTaskHelper.ApplyRusPolicy(ADSystemConfigurationSession configurationSession, ADRecipientSession recipientSession, ADRecipient recipient, Fqdn domainController, String serverName, TaskVerboseLoggingDelegate logHandler, TaskErrorLoggingDelegate writeError, TaskErrorLoggingDelegate throwTerminatingError, TaskWarningLoggingDelegate writeWarning)
   at Microsoft.Exchange.Configuration.Tasks.NewRecipientObjectTask`1.PrepareDataObject()
   at Microsoft.Exchange.Configuration.Tasks.SetTaskBase`1.InternalValidate()
   at Microsoft.Exchange.Management.RecipientTasks.NewUserBase.InternalValidate()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()

The stack information, although helpful, is still not showing us exactly why we were unable to complete our open cluster call. To further determine the reason we can dump the inner exception.

To get the inner exception information, type the following in the Exchange Management Shell: $error[0].exception.innerexception. The output of this command is:

[PS] C:\Windows\System32>$error[0].exception.innerexception
Access is denied

Between the stack trace above, and the inner exception, we can reasonably determine that we are receiving access denied when we attempt to open a connection to the cluster. (Note: It did require slightly more code review then just looking at the above to determine this...but for now we'll agree that that's what this information says).

On the surface it does not appear that there should be any reason we receive an access denied. The account in question is a Domain Administrator and an Exchange Organization Administrator. One important note though is that the account is NOT the built in administrator. Since the user is a domain administrator, and domain administrators are members of local administrators, and local administrators have full control of a Windows 2008 cluster for management purposes it appears we should not be receiving an access denied. To view the permissions assigned to a cluster:

Open failover cluster managment. If necessary, select manage a cluster from the right task pane and connect to a cluster.
Right click on the cluster name in the left task pane, select properties.

Select the cluster permissions tab.

The reason that the user account is receiving access denied is due to User Account Control (UAC). Earlier in the post I pointed out that the account we were using was not the built in administrator account. When we use the built in administrator account UAC is disabled by default. Without UAC enabled administrator groups are included in the users security token. In this case we are using a Domain Administrator that is not the built in administrator. When we do this, UAC is enabled by default for this user so administrator groups are not automatically added to the users security token (unless running elevated). Therefore, when this user makes the open cluster call, the cluster returns access denied.

In order for this account to be able to complete cluster functions, they will have to run Exchange Management Shell elevated. There are two ways to handle this:

Right click on the Exchange Management Shell shortcut and select Run As Administrator:

Get the properties of the Exchange Management Shell shortcut. On the short cut tab, select the advanced button.

Select the "Run as administrator" checkbox and press the OK button. (Note that you will be prompted for administrator rights and to save the changes.)

Next time that the Exchange Management Shell is launched, you will receive the dialog to from User Account Control requesting permissions to continue. Select continue to proceed.

Attempt to run the same command as before. This time the command should end successfully.

[PS] C:\Windows\System32>New-Mailbox -Name Test -Database 2008-MBX3\2008-MBX3-SG1-DB1 -UserPrincipalName test@exchange.msft -Verbose

cmdlet New-Mailbox at command pipeline position 1
Supply values for the following parameters:
Password:

VERBOSE: New-Mailbox : Beginning processing.
VERBOSE: New-Mailbox : Searching objects "exchange.msft/Users" of type "ExchangeOrganizationalUnit" under the root "$null".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: New-Mailbox : Searching objects "2008-MBX3\2008-MBX3-SG1-DB1" of type "MailboxDatabase" under the root "$null".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: New-Mailbox : Administrator Active Directory session settings are: View Entire Forest: 'False', Default Scope: 'exchange.msft', Configuration Domain Controller: '2008-DC1.exchange.msft',
VERBOSE: New-Mailbox : Searching objects of type "ADRecipient" with filter "(|((SamAccountName Equal test)))", scope "SubTree" under the root "exchange.msft".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: New-Mailbox : Searching objects of type "ADRecipient" with filter "(|((Alias Equal test)))", scope "SubTree" under the root "$null".
VERBOSE: New-Mailbox : Previous operation run on global catalog server '2008-DC2.exchange.msft'.
VERBOSE: New-Mailbox : Applying RUS policy to the given recipient "exchange.msft/Users/Test" with the home domain controller "$null".
VERBOSE: New-Mailbox : The RUS server that will apply policies on the specified recipient is "2008-MBX3.exchange.msft".
VERBOSE: New-Mailbox : Processing object "exchange.msft/Users/Test".
VERBOSE: New-Mailbox : Searching objects of type "ADRecipient" with filter "(&((|((UserPrincipalName Equal test@exchange.msft)))(Id NotEqual exchange.msft/Users/Test)))", scope "SubTree" under the root "$null".
VERBOSE: New-Mailbox : Previous operation run on global catalog server
'2008-DC2.exchange.msft'.
VERBOSE: New-Mailbox : Searching objects of type "ADRecipient" with filter "(&((|((SamAccountName Equal test)))(Id NotEqual exchange.msft/Users/Test)))", scope "SubTree" under the root "exchange.msft".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: Creating Mailbox "Test" on Database "2008-MBX3\2008-MBX3-SG1-DB1" with UserPrincipalName "test@exchange.msft", Organizational Unit "exchange.msft/Users".
VERBOSE: New-Mailbox : Saving object "exchange.msft/Users/Test" of type "ADUser" and state "New".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: New-Mailbox : Setting password for the created user "exchange.msft/Users/Test".
VERBOSE: New-Mailbox : The properties changed are: "{ PasswordLastSetRaw='-1', UserAccountControl='NormalAccount' }".
VERBOSE: New-Mailbox : Saving object "exchange.msft/Users/Test" of type "ADUser" and state "Changed".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.
VERBOSE: New-Mailbox : Reading new object "exchange.msft/Users/Test" of type "ADUser".
VERBOSE: New-Mailbox : Previous operation run on domain controller '2008-DC1.exchange.msft'.

Name Alias ServerName ProhibitSendQuo
ta
---- ----- ---------- ---------------
Test test 2008-mbx3 unlimited

VERBOSE: New-Mailbox : Ending processing.

(I want to thank Brad Hughes and Ben Winzenz for their contributions to this post.)

The Windows Cluster service encountered and error during function OpenCluster.

Additional resources