Wednesday, August 26, 2009

BizTalk 2009/Windows 2008 - Clustering SSO issue

During the clustering and configuration of the Enterprise Single Sign on service we ran into the following issue when trying to restore the master secret.

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig -restoresecret
Password reminder : *Reminder*

Password : ********
ERROR: 0xC0002A0F : Could not contact the SSO server '*PhysicalNode*'. Check that SSO
is configured and that the SSO service is running on that server.
(RPC: 0x800706D9: There are no more endpoints available from the endpoint mappe

I thought it was odd that the *PhysicalNode* was showing up in this error message since I was expecting the virtual server name to show up.

Upon checking the status of SSO I was provided the following information:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig.exe -status

Using SSO server on this computer

SSO server : *PhysicalNode*
SQL Server : *SqlClusterName*\*SQLClusterInstance*
SSO Database : SSODB
Service Account : domain\*SSOUser*
Cluster Name : *ClusterName*
Node Name : *PhysicalNode*
Event Counts (Info/Warning/Error... : 9/11/0
Version :
Password Sync Age (in hours) : 0
Audit Levels (Positive/Negative) : 0/1

Server status : Online
Secret server running : Yes
Password Sync loaded : No
Password Sync from PCNS running : No
Password Sync from MIIS running : No
Password Sync from adapters runn... : No
Allow password changes from PCNS : No
Allow password changes from MIIS : No
Clustered server : Yes
64 bit server : Yes
Using SSL for SQL connection : No
Case sensitive : No
Allow remote lookup : No
Local administrator : No

Having the Physical node being displayed as the SSO Server is a problem. I would have expected that the Cluster Resource group Server name should have been populated in the SSO server field.

Even though we already ran the ssomanage -updatedb XMLFile command I figured that I would run it again. (What is the definition of insanity, running a task over and over again but expecting a different result?) So when we ran this command and included our Cluster Resource group server name in the file, it still did not have an effect even though the command was "successful".

When I went back and ran the ssoconfig.exe -status command it still indicated that the SSO secret server was the phyiscal node and not the Clustered Resource group server name.

After hunting through the online documentation, I ran into the following:

If you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service:
Failed to retrieve master secrets.
Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.

The error messages are different, but it did seem applicable to our situation. I then went into the Failover Cluster Managment MMC and found that the "Use Network Name for computer name had not been checked off".

We also had to add a Network Name and IP Address as dependencies for this configuration to be set.

Upon bouncing the ESSO service and running the ssomanage -updatedb XMLFile and ssoconfig.exe -status commands the proper SSO Secret Server name was being populated. After performing these steps, we were able to restore the Master Secret server on all nodes without issue.


Toronto BizTalker said...

Thanks Kent for sharing this. After a lot of trouble, I stumbled upon this post and this made our day...thanks

Kent Weare said...

Glad to hear...thanks for the comment.


Oran Dennison said...

Your post helped me out as well. Thanks!

Unknown said...

Thanks for the help. My first foray into biztalk has been nothing but smooth, and this post helped me with my final hurdle (I think) with clustering SSO!

Unknown said...

You saved my life! thanks :-)

Matt Milner said...

Kent, another great post that just helped me out in a huge way. nice that the note you found is in the Windows 2003 section, but not in the Server 2008 section! thanks for sharing this vital information.

Kent Weare said...

Thanks for the feedback Matt. Glad this post was beneficial.

bensonius said...

I've hit this exact problem, however, my "User Network Name for Computer name" was already checked. I'm currently stuck and can't restore the secret. Anyone have any other tips?