post by Zeshawn
While deploying my applicaiton into a locked out enviornment (DR), I ran into an SSO problem (as initially thought). We were using Microsoft’s Application Configuration utility to manage key value in the SSO.
As part of our deployment, we ran into the following problem – with a warning in the event viewer:
======
======
SSO – Error creating the application
Event Type: Warning
Event Source: ENTSSO
Event Category: Enterprise Single Sign-On
Event ID: 10536
Event Source: ENTSSO
Event Category: Enterprise Single Sign-On
Event ID: 10536
Description:
SSO AUDIT
Function: GetConfigInfo (ConfigProperties)
Tracking ID: 764c4b7c-4164-434c-b023-0f8c1f6213bf
SSO AUDIT
Function: GetConfigInfo (ConfigProperties)
Tracking ID: 764c4b7c-4164-434c-b023-0f8c1f6213bf
Error Code: 0xC0002A04, The application does not exist.
======
As I initially thought this to be an SSO problem, the reality was that our “locked-out” enviornment was pointing to the incorrect SSO database !!
As I initially thought this to be an SSO problem, the reality was that our “locked-out” enviornment was pointing to the incorrect SSO database !!
In the Enterprise SSO Admin application, it was connecting to the production SSO database, not to the actual one (DR). Everything else was point to the DR SSO database. This must be a carry over from when we have the BizTalk environment’s linked for transaction logging. When we reconfigiured SSO to point to it’s own database the SSO Admin tool kept pointing to Production.
Problem solved
An interesting question would be : How does the SSO Application Configuration tool determine which SSO database to connect to ?
No comments:
Post a Comment
Post Your Comment...