I have a few posts saved, for anyone out there that might be listening…reading….waiting for another exciting post…but in the meantime I wanted to at least get this out since this blog is utilized as my personal knowledge base.
The error our DBD (Database Developer) was running into after we deployed a couple of new virtual database servers (whoa whoa whoa…did he say virtual?…yes ladies, I did…I’ll blog about that later)…anyways, the error was as follows:
OLE DB provider “SQLNCLI” for linked server “totallyAwesomeRemoteDatabaseServer” returned message “The partner transaction manager has disabled its support for remote/network transactions.”. Msg 7391, Level 16, State 2, Procedure myProcRocks, Line 42 The operation could not be performed because OLE DB provider “SQLNCLI” for linked server “totallyAwesomeDatabaseServer” was unable to begin a distributed transaction.
Damn…or not. I’ve run into this once before, and yes it involved all the standard fixes…dcomcnfg -> check some boxes, restart the service, open a port or two, enable the property on the linked server, maybe even change the sp_configure value (google it son), HOWEVER, not this time. No… these fixes were not working? But how?! But why?!…Well kids…stfu and let me tell you.
Naturally like any DBA (or IT Manager) worth their salt, I made a bold and gutsy decision…I looked in the windows application event log. To my surprise there was an error with MSDTC and it goes a little something like this:
The local MS DTC detected that the MS DTC on totallyAwesomeRemoteDatabaseServer as the same unique identity as the local MS DTC. This means that the two MS DTC will not be able to communicate with each other. This problem typically occurs if one of the systems were cloned using unsupported cloning tools. MS DTC requires that the systems be cloned using supported cloning tools such as SYSPREP. Running ‘msdtc -uninstall’ and then ‘msdtc -install’ from the command prompt will fix the problem. Note: Running ‘msdtc -uninstall’ will result in the system losing all MS DTC configuration information.
This makes perfect sense, since I deployed both of these machines from a nifty template we created in VMware. What I really enjoyed is how the error message also gives the fix.
1. msdtc -uninstall
2. check services.msc and make sure the service is gone, for sanity the above command executes with no output and extremely fast (or at least it does on my servers)
3. msdtc -install
4. set the service to automatic and start through services.msc
yeah, my homies still…