MSI unable to start the SQL instance service

Hi,
I am deploying a SQL on a three node active cluster setup. Each node will
have a SQL instance running in the cluster virtual server context. This is
the baseline setup required for deploying application databases on the three
SQL instances. Application databases are deployed using an MSI which creates
the database, roles, accounts etc.
The problem that I am facing is that when the Application Database MSI
executes, it will first recycle the SQL instance service to ensure that it is
up and running. At that point it is successfully able to stop the service but
fails to start the service giving the below error:
Event Type: Error
Event Source: MsiInstaller
Event Category: None
Event ID: 11920
Date: 10/12/2006
Time: 2:50:05 PM
User: myDomain\sql_account
Computer: SQLSERVER01
Description:
Product: Application Database -- Error 1920. Service 'MSSQL$\VS01'
(MSSQL$\VS01) failed to start. Verify that you have sufficient privileges to
start system services.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
The SQL service account has all the permissions on the machine. It is a
domain admin account with local admin privileges. It also has SystemAdmin
role on the SQL instance.
Can anyone tell me if there are any permissions that are missed that could
cause the above error?
Is there a security setting that I can check to validate permissions?
Thanks,
Mehul
The SQL service exists on all three nodes, but is only supposed to run on
one node at a time and then only under the control and direction of the
Cluster Service. You do not have to cycle the service to determine if it is
running, you can use the cluster.exe application or the WMI application
interface to determine if aclustered instance is running.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mehul" <Mehul@.discussions.microsoft.com> wrote in message
news:6C83D7C2-0514-4195-A46E-FE6D9C0E8831@.microsoft.com...
> Hi,
> I am deploying a SQL on a three node active cluster setup. Each node will
> have a SQL instance running in the cluster virtual server context. This is
> the baseline setup required for deploying application databases on the
> three
> SQL instances. Application databases are deployed using an MSI which
> creates
> the database, roles, accounts etc.
> The problem that I am facing is that when the Application Database MSI
> executes, it will first recycle the SQL instance service to ensure that it
> is
> up and running. At that point it is successfully able to stop the service
> but
> fails to start the service giving the below error:
> Event Type: Error
> Event Source: MsiInstaller
> Event Category: None
> Event ID: 11920
> Date: 10/12/2006
> Time: 2:50:05 PM
> User: myDomain\sql_account
> Computer: SQLSERVER01
> Description:
> Product: Application Database -- Error 1920. Service 'MSSQL$\VS01'
> (MSSQL$\VS01) failed to start. Verify that you have sufficient privileges
> to
> start system services.
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
> The SQL service account has all the permissions on the machine. It is a
> domain admin account with local admin privileges. It also has SystemAdmin
> role on the SQL instance.
> Can anyone tell me if there are any permissions that are missed that could
> cause the above error?
> Is there a security setting that I can check to validate permissions?
> Thanks,
> Mehul
|||Geoff,
The configuration is an Active-Active-Active one. Hence the SQL service will
run on each node.
"Geoff N. Hiten" wrote:

> The SQL service exists on all three nodes, but is only supposed to run on
> one node at a time and then only under the control and direction of the
> Cluster Service. You do not have to cycle the service to determine if it is
> running, you can use the cluster.exe application or the WMI application
> interface to determine if aclustered instance is running.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Mehul" <Mehul@.discussions.microsoft.com> wrote in message
> news:6C83D7C2-0514-4195-A46E-FE6D9C0E8831@.microsoft.com...
>
>
|||Then you have three instances, which will show up as three different
services on each node. You still need to leave them under the control of
the cluster service.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mehul" <Mehul@.discussions.microsoft.com> wrote in message
news:3D1AD5FD-FB0A-4C46-A858-E8523BBB61A4@.microsoft.com...[vbcol=seagreen]
> Geoff,
> The configuration is an Active-Active-Active one. Hence the SQL service
> will
> run on each node.
> "Geoff N. Hiten" wrote:
|||Geoff,
Yes this is correct.
If the SQL instance services need to be restarted, what is the recommended
way?
"Geoff N. Hiten" wrote:

> Then you have three instances, which will show up as three different
> services on each node. You still need to leave them under the control of
> the cluster service.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Mehul" <Mehul@.discussions.microsoft.com> wrote in message
> news:3D1AD5FD-FB0A-4C46-A858-E8523BBB61A4@.microsoft.com...
>
>
|||Use the cluster.exe command-line utility to stop and restart instances from
within a script.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mehul" <Mehul@.discussions.microsoft.com> wrote in message
news:39DD3469-5CEE-49DC-9755-681B5701D0EF@.microsoft.com...[vbcol=seagreen]
> Geoff,
> Yes this is correct.
> If the SQL instance services need to be restarted, what is the recommended
> way?
> "Geoff N. Hiten" wrote:

Msg 3910 Transaction context in use by another session.

We are testing SQL 2005 SP1 in a multi-server environment. Stored Procedure 'A' is executed on server.database 'A'. It calls SP 'B' on server.database 'B'. SP 'B' in turn calls SP 'C' which is back on server.database 'A'. So in essence A calls an SP on B, which calls an SP back on A. Linked servers are present on both servers to enable these cross-server calls. This scenario works in our SQL 2000 environment.

In the SQL 2005 environment, we get the Msg 3910 message stated in the subject. Is this truly a 'loopback server' situation and if so, why does it work in SQL 2000? Did this functionality change in SQL 2005? In SQL 2005 SP1? This may seem to be a klugy way to do things but unfortunately, it is a core part of our application security system and won't be easily undone. Any ideas would be appreciated. Thanks.

The problem was not introduced in SQL 2005 SP1. The error still occurs when run using two servers with the base SQL 2005 install.|||

We have an application that uses link servers and is running into the same error.

Looks like an undocumented feature in SS2005 or a BUG.

Anyone have any ideas on how to get around it?

Eric

|||

We worked the issue through with Microsoft support and I've included their comments and resolution below. The problem with their answer is that if a consistent data view is their goal, then this should also fail when all the databases are on a single server. Perhaps they'll make this consistent in a future service pack. Anyway, such as it is, here's the answer.

Beginning of Microsoft response:

Yes, this is a known problem and we change the behavior for good reason in Yukon. We’d like you to work around this issue.

The reason we change to current SQL Server 2005 behavior is that it can guarantee consistent data view, while SQL Server 2000 behavior may expose inconsistent data if the loopback tries to access the table that is been changed.

other ways to avoid this error:

1. Change the application logic to not use loopback.

2. Separate the INSERT EXEC into two steps -- Run remote EXEC first(which will succeed for loopback) and put it into a remote table and then run a SELECT from the remote table

But in general, SQL Server doesn’t support loopback server, so you are still at risk that you might get impacted in future release. So the best way is to avoid using the loopback.

End of Microsoft response.

Hope this helps.

|||I was facing a similar problem wherein I was using loopback linked servers for synchronizing multiple databases on same server as well as remote servers. The code was generically handling this. Will have to look for alternate way as support for loopback server is not guaranteed.

Thanks

Chandrakant Karale.

Msg 3910 Transaction context in use by another session.

We are testing SQL 2005 SP1 in a multi-server environment. Stored Procedure 'A' is executed on server.database 'A'. It calls SP 'B' on server.database 'B'. SP 'B' in turn calls SP 'C' which is back on server.database 'A'. So in essence A calls an SP on B, which calls an SP back on A. Linked servers are present on both servers to enable these cross-server calls. This scenario works in our SQL 2000 environment.

In the SQL 2005 environment, we get the Msg 3910 message stated in the subject. Is this truly a 'loopback server' situation and if so, why does it work in SQL 2000? Did this functionality change in SQL 2005? In SQL 2005 SP1? This may seem to be a klugy way to do things but unfortunately, it is a core part of our application security system and won't be easily undone. Any ideas would be appreciated. Thanks.

The problem was not introduced in SQL 2005 SP1. The error still occurs when run using two servers with the base SQL 2005 install.|||

We have an application that uses link servers and is running into the same error.

Looks like an undocumented feature in SS2005 or a BUG.

Anyone have any ideas on how to get around it?

Eric

|||

We worked the issue through with Microsoft support and I've included their comments and resolution below. The problem with their answer is that if a consistent data view is their goal, then this should also fail when all the databases are on a single server. Perhaps they'll make this consistent in a future service pack. Anyway, such as it is, here's the answer.

Beginning of Microsoft response:

Yes, this is a known problem and we change the behavior for good reason in Yukon. We’d like you to work around this issue.

The reason we change to current SQL Server 2005 behavior is that it can guarantee consistent data view, while SQL Server 2000 behavior may expose inconsistent data if the loopback tries to access the table that is been changed.

other ways to avoid this error:

1. Change the application logic to not use loopback.

2. Separate the INSERT EXEC into two steps -- Run remote EXEC first(which will succeed for loopback) and put it into a remote table and then run a SELECT from the remote table

But in general, SQL Server doesn’t support loopback server, so you are still at risk that you might get impacted in future release. So the best way is to avoid using the loopback.

End of Microsoft response.

Hope this helps.

|||I was facing a similar problem wherein I was using loopback linked servers for synchronizing multiple databases on same server as well as remote servers. The code was generically handling this. Will have to look for alternate way as support for loopback server is not guaranteed.

Thanks

Chandrakant Karale.

Msg 3910 Transaction context in use by another session.

We are testing SQL 2005 SP1 in a multi-server environment. Stored Procedure 'A' is executed on server.database 'A'. It calls SP 'B' on server.database 'B'. SP 'B' in turn calls SP 'C' which is back on server.database 'A'. So in essence A calls an SP on B, which calls an SP back on A. Linked servers are present on both servers to enable these cross-server calls. This scenario works in our SQL 2000 environment.

In the SQL 2005 environment, we get the Msg 3910 message stated in the subject. Is this truly a 'loopback server' situation and if so, why does it work in SQL 2000? Did this functionality change in SQL 2005? In SQL 2005 SP1? This may seem to be a klugy way to do things but unfortunately, it is a core part of our application security system and won't be easily undone. Any ideas would be appreciated. Thanks.

The problem was not introduced in SQL 2005 SP1. The error still occurs when run using two servers with the base SQL 2005 install.|||

We have an application that uses link servers and is running into the same error.

Looks like an undocumented feature in SS2005 or a BUG.

Anyone have any ideas on how to get around it?

Eric

|||

We worked the issue through with Microsoft support and I've included their comments and resolution below. The problem with their answer is that if a consistent data view is their goal, then this should also fail when all the databases are on a single server. Perhaps they'll make this consistent in a future service pack. Anyway, such as it is, here's the answer.

Beginning of Microsoft response:

Yes, this is a known problem and we change the behavior for good reason in Yukon. We’d like you to work around this issue.

The reason we change to current SQL Server 2005 behavior is that it can guarantee consistent data view, while SQL Server 2000 behavior may expose inconsistent data if the loopback tries to access the table that is been changed.

other ways to avoid this error:

1. Change the application logic to not use loopback.

2. Separate the INSERT EXEC into two steps -- Run remote EXEC first(which will succeed for loopback) and put it into a remote table and then run a SELECT from the remote table

But in general, SQL Server doesn’t support loopback server, so you are still at risk that you might get impacted in future release. So the best way is to avoid using the loopback.

End of Microsoft response.

Hope this helps.

|||I was facing a similar problem wherein I was using loopback linked servers for synchronizing multiple databases on same server as well as remote servers. The code was generically handling this. Will have to look for alternate way as support for loopback server is not guaranteed.

Thanks

Chandrakant Karale.