By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,948 Members | 1,929 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,948 IT Pros & Developers. It's quick & easy.

Cannot escalate to MSDTC when using CommitableTransaction class on

P: n/a
In short: I have an application using the CommittableTransaction class that
works fine when run locally, but does not escalate to MSDTC when deployed to
a Windows 2003 R2 server.

More Specifically:

I have a web service that saves data to a database. This service uses a
CommittableTransaction to decide when to Commit or Abort the underlying
transaction. When this service is run locally, or by someone in the "User"
group on the web server it works fine.

But if the service has been deployed to the web server, the following
happens:

1) If the user is in the "User" group on the web server, it still works fine
(this is not allowed in a production situation).

2) If a transaction does not need to be escallated to MSDTC, then it works
fine.

3) BUT - as soon as a transaction needs to be escalated to MSDTC and the
user is not in the "User" group on the server, the transaction fails

a) A trace on the database revealed that the first stored procedure call
succeeded, but each additional stored procedure call failed with an "Access
Denied to xyz stored procedure" (this is running the exact same stored
procedure that just succeeded)

b) Monitoring the MSDTC logs on the server shows that the transaction is
never actually escalated to MSDTC (no aborts, etc were logged) on the web
server unless the user is in the "User" group on the web server, then it
escalates (and works) as expected.

c) In the security logs, I am seeing Audit Failure's for the user trying
to run the app, there are 2 types: EventID 560, Category "Object Access",
Object Name: MSDTC, Object Type: "Service Object"; the second type is the
same except the Object Name: "ServicesActive". From looking into these, it
looks more like they may be a side effect of the transaction not escalating
to MSDTC rather than the cause.

Does anyone know what permissions (or otherwise) may be preventing
transactions from escalating to MSDTC???

I am using Delegation from a Windows front-end through a web service on a
Windows 2003 server back to a SQL Server 2005 DB.

Any help would be greatly appreciated.

Jun 25 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a

"abayer" <ab****@discussions.microsoft.comwrote in message
news:3F**********************************@microsof t.com...
In short: I have an application using the CommittableTransaction class
that
works fine when run locally, but does not escalate to MSDTC when deployed
to
a Windows 2003 R2 server.

More Specifically:

I have a web service that saves data to a database. This service uses a
CommittableTransaction to decide when to Commit or Abort the underlying
transaction. When this service is run locally, or by someone in the
"User"
group on the web server it works fine.

But if the service has been deployed to the web server, the following
happens:

1) If the user is in the "User" group on the web server, it still works
fine
(this is not allowed in a production situation).

2) If a transaction does not need to be escallated to MSDTC, then it works
fine.

3) BUT - as soon as a transaction needs to be escalated to MSDTC and the
user is not in the "User" group on the server, the transaction fails

a) A trace on the database revealed that the first stored procedure call
succeeded, but each additional stored procedure call failed with an
"Access
Denied to xyz stored procedure" (this is running the exact same stored
procedure that just succeeded)

b) Monitoring the MSDTC logs on the server shows that the transaction is
never actually escalated to MSDTC (no aborts, etc were logged) on the web
server unless the user is in the "User" group on the web server, then it
escalates (and works) as expected.

c) In the security logs, I am seeing Audit Failure's for the user trying
to run the app, there are 2 types: EventID 560, Category "Object Access",
Object Name: MSDTC, Object Type: "Service Object"; the second type is the
same except the Object Name: "ServicesActive". From looking into these,
it
looks more like they may be a side effect of the transaction not
escalating
to MSDTC rather than the cause.

Does anyone know what permissions (or otherwise) may be preventing
transactions from escalating to MSDTC???

I am using Delegation from a Windows front-end through a web service on a
Windows 2003 server back to a SQL Server 2005 DB.

Any help would be greatly appreciated.
So why can't you use a generic user-id and psw in your application that has
the power, instead of using User groups and Windows authentication in both
cases the Web server and SQL server?

Jun 25 '07 #2

P: n/a
That would be nice, but I was given the requirement from high above to use
Windows Integrated security all the way through to the SQL Server.

Andy
"Mr. Arnold" wrote:
>
"abayer" <ab****@discussions.microsoft.comwrote in message
news:3F**********************************@microsof t.com...
In short: I have an application using the CommittableTransaction class
that
works fine when run locally, but does not escalate to MSDTC when deployed
to
a Windows 2003 R2 server.

More Specifically:

I have a web service that saves data to a database. This service uses a
CommittableTransaction to decide when to Commit or Abort the underlying
transaction. When this service is run locally, or by someone in the
"User"
group on the web server it works fine.

But if the service has been deployed to the web server, the following
happens:

1) If the user is in the "User" group on the web server, it still works
fine
(this is not allowed in a production situation).

2) If a transaction does not need to be escallated to MSDTC, then it works
fine.

3) BUT - as soon as a transaction needs to be escalated to MSDTC and the
user is not in the "User" group on the server, the transaction fails

a) A trace on the database revealed that the first stored procedure call
succeeded, but each additional stored procedure call failed with an
"Access
Denied to xyz stored procedure" (this is running the exact same stored
procedure that just succeeded)

b) Monitoring the MSDTC logs on the server shows that the transaction is
never actually escalated to MSDTC (no aborts, etc were logged) on the web
server unless the user is in the "User" group on the web server, then it
escalates (and works) as expected.

c) In the security logs, I am seeing Audit Failure's for the user trying
to run the app, there are 2 types: EventID 560, Category "Object Access",
Object Name: MSDTC, Object Type: "Service Object"; the second type is the
same except the Object Name: "ServicesActive". From looking into these,
it
looks more like they may be a side effect of the transaction not
escalating
to MSDTC rather than the cause.

Does anyone know what permissions (or otherwise) may be preventing
transactions from escalating to MSDTC???

I am using Delegation from a Windows front-end through a web service on a
Windows 2003 server back to a SQL Server 2005 DB.

Any help would be greatly appreciated.

So why can't you use a generic user-id and psw in your application that has
the power, instead of using User groups and Windows authentication in both
cases the Web server and SQL server?

Jun 26 '07 #3

P: n/a

"abayer" <ab****@discussions.microsoft.comwrote in message
news:9A**********************************@microsof t.com...
That would be nice, but I was given the requirement from high above to use
Windows Integrated security all the way through to the SQL Server.
And high above don't seem to know how things work.

3) BUT - as soon as a transaction needs to be escalated to MSDTC and the
user is not in the "User" group on the server, the transaction fails

You're not coming around that. Either the userid of the Windows user has to
be authenticated or you implement a generic userid that can be used by your
application.

Jun 26 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.