locked
Clustered SSO database connection error on server startup RRS feed

  • Question

  • Hi

    We've implemented a Clustered SSO resource on our SQL cluster and created a separate BT 2009 server pointing at this. This appears to be working fine in general.

    But on BT server restart, we get an ENTSSO connection error (The SSO service failed to start. Error code: 0x800710D9, unable to read from or write to the database)

    However, if we now manually restart the service it connects without error. Or if we set the service to manual, and start the service after the server has come up, it starts fine. So it appears to be a service dependency issue - ie SSO is trying to start before it should. Has anyone experienced this before? We are running Win2003, so don't have an option in the services applet to delay service startup by a set interval .

    I've googled this and changed some of the suggested settings - in DTC, I've set the security to require No Authentication. TCPIP is the first protocol in the SQL Client List.

    Anyone have any insight on this?

    Thanks

    Ewan


    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Wednesday, November 25, 2009 10:32 AM

Answers

  • Hi Vishnu

    As I said earlier, all we needed to do was restart the service and it all worked, so the security is all fine. In fact, I've removed the service account from the BT Admins, since the SSO service complains that it has too many rights... Anyway, I've found a workaround. Not hugely satisfactory, but it works.

    The fix is to create a SQL client alias on the server pointing to the SSO database server. For whatever reason, this name resolution is failing on server startup, perhaps as a timeout issue.

    The workaround works if you define the alias as either a Named Pipes or TCP/IP alias, but using Named Pipes means you don't have to use a fixed IP port on the database server. So that's what we're going to use.

    Thanks for the suggestions anyway Vishnu, much appreciated.

    Regards

    Ewan



    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    • Marked as answer by Ewan Thursday, November 26, 2009 12:14 PM
    Thursday, November 26, 2009 12:14 PM

All replies

  • HI,

    Looks like You need to enable 'Log on as service' rights.

    For each of the service accounts created, add the ‘Log on as a service’ user rights assignment to the domain group policy. Once the domain group policy has been updated, run ‘gpupdate’ from a command line on the BizTalk Server to refresh the group policies on that server.


    Regards
    Vishnu


    Vishnu
    Wednesday, November 25, 2009 11:01 AM
  • Hi Vishnu

    But if we start the service manually it works. I can't see how this can be the problem.

    Ewan

    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Wednesday, November 25, 2009 11:10 AM
  • Once you enable log on as service, starting of host instances takes care of starting of ENT SSO otherwise you need to come to services and start ENTSSO and then only you are allowed to proceed.

    Regards
    Vishnu
    Vishnu
    Wednesday, November 25, 2009 11:28 AM
  • Hi Vishnu

    Thanks for your help on this.

    I'm still not sure if I understand what you're proposing though. If the Log On As A Service right was missing, wouldn't that mean that it could never work? Because all we need to do is restart the service and it does work. Is there something I'm missing?

    Ewan

    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Wednesday, November 25, 2009 11:45 AM
  • Hi Ewan,

    I faced the similar problem couple of weeks back. In order to resolve that I added the ENT SSO Service group to BT Administrator Group. Under the properties I set the startup as Automatic and I also looked at the dependecies and made sure that those are getting stated at the startup. This solves the problem. Looks you have done everything except your ENTSSO service group is not part of BT Admin.

    Regards
    Vishnu


    Vishnu
    Wednesday, November 25, 2009 12:17 PM
  • Hi Vishnu

    Thanks for that - I'll give that a try and let you know.

    FYI, we use the same service account for BT and SSO, but the service account isn't in the BT Admins group.

    Ewan

    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Wednesday, November 25, 2009 12:25 PM
  • Hi Vishnu

    We've changed the group membership which unfortunately hasn't fixed the problem.

    It still looks to me like a timing rather than a purely security-driven event. If anyone has any other suggestions, they would be gratefully received!

    Regards

    Ewan

    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Thursday, November 26, 2009 10:51 AM
  • Hi Ewan,

    Since your SSO service account should be under BT admin, can you check and verify does this group has dbo access to SSO DB on one of the server where your SSO DB is installed.

    Regards
    Vishnu
    Vishnu
    Thursday, November 26, 2009 12:01 PM
  • Hi Vishnu

    As I said earlier, all we needed to do was restart the service and it all worked, so the security is all fine. In fact, I've removed the service account from the BT Admins, since the SSO service complains that it has too many rights... Anyway, I've found a workaround. Not hugely satisfactory, but it works.

    The fix is to create a SQL client alias on the server pointing to the SSO database server. For whatever reason, this name resolution is failing on server startup, perhaps as a timeout issue.

    The workaround works if you define the alias as either a Named Pipes or TCP/IP alias, but using Named Pipes means you don't have to use a fixed IP port on the database server. So that's what we're going to use.

    Thanks for the suggestions anyway Vishnu, much appreciated.

    Regards

    Ewan



    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    • Marked as answer by Ewan Thursday, November 26, 2009 12:14 PM
    Thursday, November 26, 2009 12:14 PM
  • I've also created a connect item on this if anyone needs to follow this up:

    https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=514808&SiteID=65

    Ewan

    If you have found this post helpful, please click the 'Vote as Helpful' link (the green triangle and number on the top-left).

    If this post answers your question, click the 'Mark As Answered' link below. It helps others who experience the same issue in future to find the solution.
    Friday, November 27, 2009 10:19 AM