MSDTC problem between two IdB servers
I am getting a warning about MSDTC in the IdB log. Full imports work on server 2 but deltas give me no changes (though also no error).
I have followed the instructions in the IdB prereqs to set up MSDTC network permissions through Component Services. The windows firewalls are currently disabled on both servers. The MAs are using server names and tyhey report no connectivity problems.
What else should I check?
Here's the full error:
System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x8004D02B): The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
TicksToUTC.exe
Customer support service by UserEcho
Hi Carol,
Have you enabled network access on both machines, as per IDB307:Configuring Microsoft Distributed Transaction Coordinator?
A tool that we have found useful in the past for diagnosing MSDTC issues can be found at http://support.microsoft.com/kb/293799, I would be interested to know if this helps you, so that I can include the link on the documentation.
Thanks.
Hmmm - how does me saying "I have followed the instructions in the IdB prereqs to set up MSDTC network permissions through Component Services" lead you to believe I have not followed those steps?
Trying out that tool now...
Have you got any idea what test I need to run? All the tester tool tells me is I need to run it lik this:
Usage: dtctester <dsn name> <user name> <password>
Apparently I need to create an ODBC connection which I then reference with that "dsn name" paarmeter - but to what? The Identity Broker database?
As there is a lot on that page, I'm sure it's easy to miss a short statement that it needs to be done on both machines.
I don't think it matters what database you use as it creates a temp table, as long as the account that you are using for the test has permission to the db. Remembering that it's SQL Server Auth. not Windows Auth. To create a dsn, I use the ODBC Data Sources Administrator, which has a shortcut under Administrative Tools in my start menu.
I don't have access to create sql accounts.
Have you made any progress on this Carol?
No - there were more pressing things to look at. I don't know that I'm going to be able to do that SQL troubleshooting you suggested - not without a lot of hassle anyway, it can take weeks to get the SQL team to make changes.
Adam, I was talking to Carol about this when I got the error. Thought it should be noted that Identity Broker 3.0.6.X is being used at this site vs the 3.0.7.5 at
DPS-87.Carol, our issue with a similar message ended up being because the SQL server and Application server had been cloned from a common base and the MS DTC service was using the same unique identifier to distinguish each system. At DPS we resolved it by uninstalling the MS DTC service and reinstalling it on one system. Not sure if that is what you have, but feel free to check
DPS-87. There was an error message that we noticed in the event log at about 1 or 2AM that I've posted on the DPS issue that allowed us to identify the issue. If it is what we had, there should hopefully be an error in the Windows Event log on at least one of the systems (not necessarily both).I still need to get this resolved. Pete Wass has a theory it may be something to do with two FIM adapters on the one IdB Placeholder Connector, and IdB not knowing which adpater to prepare deltas for. Full Import works on both sides and Delta Import gives no imports on both sides.
Further clarification: a Delta Import will return changes just exported through that adapter. This issue is that it does not show me changes just exported through the other adapter.
Are you still getting MSDTC errors? Without those resolved it is pointless chasing other theories as a correctly functioning database is a Prerequisite.
No MSDTC errors. I 'm in the test env now and I did have MSDTC errors until I enabled DTC network access. There are now no errors at all but I still can't do Delta Imports. When I do a Full changes come through.
Once an adapter import has run, the changes are cleared prior to the current time, so it may be that you have already cleared out the changes.
I have attached TicksToUTC.exe to give you the time in ticks, so that you can ensure that there are not changes available in the database. In the Changes table, look for entries against the adapter you are importing against, prior to the current time in ticks.
Then, perform connector imports, that should change the data in the adapter.
Repeat the queries on the database, and again for the adapter that you have said is triggering changes.
Please also attached connector and adapter configuration files and let me know which field you are changing.
Thanks.
It looks like there was a problem in prod - now solved with Shane's help. I thought the DTC changes had to be made between the two FIM servers, but actually it was between the IdB and SQL servers. Network DTC was enabled on the SQL server but the Windows Firewall was also on. DTCPing failed until I turned off the firewall.
Need to run a bunch more syncs now to make sure everything is working.
Yep that was the problem. Thanks for all the help.