WS-AT problem: The MSDTC transaction manager's WS-AtomicTransaction protocol service is disabled

Question

Hello,

I have a very strange problem with the WS-AT controller. I call a simple transactional WCF service once from a WCF client and once from a Java client. When called from the WCF client, everything works fine, but when called from the Java client, I get an exception with the message
"The MSDTC transaction manager's WS-AtomicTransaction protocol service is disabled and cannot unmarshal incoming transactions."
From the service trace log / service message log, I have the headers of the messages sent to the service both from the wcf client and the java client.

Here the headers from the WCF client:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<CoordinationContext s:mustUnderstand="1" xmlns="http://schemas.xmlsoap.org/ws/2004/10/wscoor" xmlns:mstx="http://schemas.microsoft.com/ws/2006/02/transactions">
<wscoor:Identifier xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">urn:uuid:45f80e03-9b23-459b-9621-397f5526161a</wscoor:Identifier>
<Expires>58880</Expires>
<CoordinationType>http://schemas.xmlsoap.org/ws/2004/10/wsat</CoordinationType>
<RegistrationService>
<Address xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://node3058.it.de:10443/WsatService/Registration/Coordinator/</Address>
<ReferenceParameters xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<mstx:RegisterInfo>
<mstx:LocalTransactionId>45f80e03-9b23-459b-9621-397f5526161a</mstx:LocalTransactionId>
</mstx:RegisterInfo>
</ReferenceParameters>
</RegistrationService>
<mstx:IsolationLevel>0</mstx:IsolationLevel>
<mstx:LocalTransactionId>45f80e03-9b23-459b-9621-397f5526161a</mstx:LocalTransactionId>
<PropagationToken xmlns="http://schemas.microsoft.com/ws/2006/02/tx/oletx">AQAAAAMAAAADDvhFI5ubRZYhOX9VJhYaAAAQAAAAAAB8AAAAAP///4LS6HlX0uh5clisZ9oT8nlyWKxnuO0SAEQSWAEQCBUA/OwSAGM4MzhiNTcxLTc0YjgtNDAxOC05MmEwLThkYTBhMmVkYmJhZAAAAAAIAAAAZM1kzSEAAABOT0RFMzA1OAAAAAAUAAAATgBPAEQARQAzADAANQA4AAAAAAABAAAAAAAAABUAAAB0aXA6Ly9Ob2RlMzA1OC5pdC5kZS8AAAA=</PropagationToken>
</CoordinationContext>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://node3053.it.de:1501/ITInformatik.SOA.BDEService.WebServiceFacade/WerksVerwaltungService.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.it-informatik.de/mes/bdeservice/IWerksVerwaltungService/findeAlleWerke</Action>
</s:Header>
</s:Envelope>

And the headers from the Java client:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<wscoor:CoordinationContext xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">
<wscoor:Identifier xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">urn:-3ef69ab6:dc3:45dc7427:5f</wscoor:Identifier>
<wscoor:CoordinationType xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">http://schemas.xmlsoap.org/ws/2004/10/wsat</wscoor:CoordinationType>
<wscoor:RegistrationService xmlns:wscoor="http://schemas.xmlsoap.org/ws/2004/10/wscoor">
<wsa:Address xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://node3058.it.de:8443/xts2/soap/RegistrationCoordinator</wsa:Address>
<wsa:ReferenceParameters xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsarj:InstanceIdentifier xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj">-3ef69ab6:dc3:45dc7427:5f</wsarj:InstanceIdentifier>
</wsa:ReferenceParameters>
</wscoor:RegistrationService>
</wscoor:CoordinationContext>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://node3053.it.de:1501/ITInformatik.SOA.BDEService.WebServiceFacade/WerksVerwaltungService.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.it-informatik.de/mes/bdeservice/IWerksVerwaltungService/findeAlleWerke</Action>
</s:Header>
</s:Envelope>

Comparing both headers, I can see some differences, but not a difference that can explain the completely different behavior regarding transactions.

Has anyone a hint what I do wrong? Or even a solution of my problem?
Regards, Martin

Answer 1

It looks like WS-AT on the Service machine is not configured correctly.  Can you check to make sure that everything on the service's MSDTC is properly setup? (certificate, inbound/outbound settings etc.)

The reason this all works for WCF to WCF is that there's an automatic 'upgrade' path where instead of using WS-AT for the underlying protocol, we can upgrade to our native protocol (the PropagationToken element) providing increased performance and less setup/deployment costs.  This is not possible with the Java client of course, so we skip past the upgrade and actually try to use WS-AT.

 

Answer 2

I've already checked everything.

The wsatconfig tool shows the following output:

WS-AT network support:  Enabled
        HTTPS port:             10443
        Endpoint certificate:   78FFEA3DB8840E81E2602755E1E3546BC31BDAE8
        Authorized ACL:         Jeder
        Authorized certificates:        811118853F82A863747FD9A5937D4A0E629A98C8
                                78FFEA3DB8840E81E2602755E1E3546BC31BDAE8
                                78EAAE569695ECB83BCBDB925E4C2320D727B323
        Default outgoing timeout:       60
        Maximum incoming timeout:       3600
        Trace level:            All
        Activity tracing:       Enabled
        Activity propagation:   Enabled
        PII tracing:            Enabled

DTC Configuration is
Network Access activated, Allow Inbound, Allow Outbound, No authentication required, TIP and XA transactions allowed, and remoteclients and remote management allowed (i.e. all checkboxes are set)

One thing that could possibly be a problem is that we had to call msdtc -uninstall and msdtc-install on the machine, because it had the same sid as a second computer in the network. We did this after installing .NET framework 3.0 and configuring ws-at.
Maybe this could be a probnlem and re-installing .net framework 3.0 could help?

Answer 3

The -uninstall / -install may be an issue but it's hard to say.  If you restart MSDTC on the WCF service machine can you check the eventvwr to see how many events are posted?  You should see 2: one that says MSDTC started up and another that says the Microsoft.Transactions.Bridge initialized correctly.  

Also, just in case you haven't done so, ensure the WCF service itself has been fully recycled after the above step.

Answer 4

Thank you for the fast reply.
We completely uninstalled and reinstalled .NET Framework 3.0.
After reboot, the event log contains the 2 described entries.
But the problem exactly remains the same...

Is there anything else we can do?

Answer 5

There's a few things you can provide to me:

Let's first get an ETW trace session going:

- Add the following registry key so we get even more information: HKLM\SOFTWARE\Microsoft\WSAT\3.0\ServiceModelDiagnosticTracing  REG_DWORD  0x1f

- logman create trace WsatTrace -o c:\logs\msdtc\wsat.etl -p "{7f3fe630-462b-47c5-ab07-67ca84934abd}"
- logman start WsatTrace
- Restart MSDTC

- net stop MSDTC

- logman stop WsatTrace

You can then open up the resulting .etl file produced in c:\logs\msdtc in SvcTraceViewer.exe and look for any Warning or Error level traces produced.

If this does not help, you can try the following:

- Create a file called: %windir%\system32\msdtc.exe.config

- Fill it with the following:

 <configuration>

    <system.diagnostics>

        <switches>

            <add name="Microsoft.Transactions.Bridge" value="4" />

            <add name="GatewayTracing" value="4" />

            <add name="Microsoft.Transactions.Wsat" value="4" />

        </switches>

 

        <trace autoflush="true" indentsize="4">

            <listeners>

                <add name="MSTB Trace File"

                     type="System.Diagnostics.TextWriterTraceListener"

                     initializeData="MSDTC\msdtc.trace.log" />

            </listeners>

        </trace>

    </system.diagnostics>

</configuration>

 

- Restart MSDTC

A file will be produced called %windir%\system32\MSDTC\msdtc.trace.log

In any event, please zip up those 2 files (msdtc.trace.log and the etl file) and send them to me: jessey at microsoft dot com

Note: Please re-enable full mutual authentication security for MSDTC and turn TIP off (as you most likely do not need that).

Note2: The tracing session is available in the MMC UI snap-in (from the WCF SDK) if you don't want to work from the command line

Note3: You'll definitely want to disable the debug tracing by removing msdtc.exe.config once the problem is eventually sorted out. Typically this type of debugging is not needed and we only support ETW tracing.  Based on the outcome of this discussion, however, we may log a bug to improve the ETW tracing to cover this scenario in the future.

Answer 6

Hello Jesse,

with the log created using the msdtc.exe.config diagnostics configuration, we found our problem. The wsat service logged something like "identity certificate not found". The certificate was there, but it was a selfsigned certificate created with makecert.exe and it was not trusted. Adding its root certificate to the trusted ca store solved the problem.

Thanks again for your support.
Martin

Answer 7

Hey Martin, I'm glad that helped.

I verified that this specific error is also traced for our ETW session (in addition to the debug output) so in the future the debug tracing shouldn't be required for this.

Answer 8

Did you check this out?

http://msdn2.microsoft.com/en-us/library/ms733943.aspx

To enable the WS-AT protocol service inside MSDTC using port 443, and an X509 certificate with a private key that has been installed into the local machine store, the WsatConfig.exe tool can be used with the following command:

WsatConfig.exe –network:enable –port:443 –endpointCert:<machine|"Issuer\SubjectName"> -accountsCerts:<thumbprint|"Issuer\SubjectName"> -restart

You should substitute the respective parameters with values relevant to your environment.

To disable the WS-AT protocol service inside MSDTC, the WsatConfig.exe tool can be used with the following command,

WsatConfig.exe –networkisable -restart

the command is under C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation> folder.


Answer 9

Wsatconfig /Show tells Ws-at network support is disabled

I created a certificate using makecert and tried using wsatconfig to enable. but am not getting an error and i dont find WsatUI.dll in the system

Can you tell me the step by step process for enabling WS-Atomic transaction so that WS-AT tab appears in MyComputer properties in Component Services.

Answer 10

you may need to install Microsoft Vista SDK first - http://www.microsoft.com/downloads/details.aspx?FamilyId=C2B1E300-F358-4523-B479-F53D234CDCCF&displaylang=en

Answer 11

Am using Windows XP SP2. Can you please tell wat msut be done to enable WS-AT

Answer 12

Actully window Vista SDK is .NET Framework 3.0 SDK. you can install on XP SP2.

then

1. open CMD Shell

2. run regasm.exe /codebase WsatUI.dll

3. Go to Control Panel/Administrative Tools/Component Services

4. Expand the tree Component Services -> Computers -> Right click on My Computer -> Property

5. You will see the WS-AT Tab on the dialog

Answer 13

I cant wait to get it and get started. Although I have only just got to grips with .NET 2. Lets hope there is a couple of years before .NET 4 arrives .