Geeks With Blogs
Simon Emmanuel RIVAS

The Log shipping mechanism implemented in BizTalk works pretty well in a homogeneous environment, but a few details have to be taken care of when production and DR domains differ, or more generally when security groups differ.

Switching to the Disaster Recovery site: the theory

Let’s focus on the SSO part. Here is a basic, macro overview of the steps you would take to switch to the DR site:

  • Restore the production databases on the DR SQL Server
  • Make sure the UpdateInfo.xml is OK (which can be found in the BizTalk install directory, under SDK/Samples/Admin/Sysprep/scripts), with old and new DB names and servers
  • Run the UpdateDatabase.vbs script (same location as UpdateInfo.xml)
  • (In case it wasn’t pre-configured, configure SSO with the BizTalk Configuration Wizard)
  • Run the UpdateSSO.cmd script (idem), which attemps to start the SSO service and change the master secret server
  • Restore the master secret key

In theory, the SSO service should start without any problem.

The reality: SSO fails to start (in some cases…)

When security groups differ, the SSO service may stop immediately when you try and start it. The eventlog contains some errors, ultimately saying:

The SSO service failed to start.

 Error Code: 0x80070005, Access is denied.

 

In practical terms, SSO starts by checking whether it is allowed to start by checking if the service account running the SSO service belongs to the security groups configured in the SSOX_GlobalInfo table of the SSODb, which are still the production security groups since neither the UpdateDatabase.vbs nor the UpdateSSO.cmd scripts update those fields.

In case the service account doesn’t belong to the SSO admin security group, and in order not to mess directly with the tables, which is never a very good option, you might want to use the ssomanage.exe (or ssoconfig.exe? I’m not sure) tool. Unfortunately, it requires the SSO service to be started, and the SSO service needs the security groups to be updated in order to start. Endless loop…

Workaround

In case domains differ, I guess you could set a trust relationship between both domains and put the new service account in the production security group. No need to say this is something you should plan and do in advance, when designing your BizTalk platform.

In case only security groups differ, just put the new service account in the production group.

In both cases, start SSO then update the SSO configuration with the DR security groups.

Of course, you could also just manually update the SSOX_GlobalInfo table of the SSODb, which, after all, is pretty safe since in any event SSO will never work if you do nothing Sourire

NOTE: if you try this as a local admin on a standalone box and with local groups, you won’t see any of this since the configuration wizard will automatically create the missing local groups, thus solving the problem…

Posted on Thursday, December 5, 2013 1:21 PM BizTalk , Log Shipping , SSO , Access denied | Back to top


Comments on this post: BizTalk Log Shipping across different domains: SSO fails to start

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © S.E.R. | Powered by: GeeksWithBlogs.net