I had also found that some of my contacts associations (those connecting Live Contacts with Facebook contacts), had disappeared. It appears my phone had resynchronized my contacts overnight.

After reapplying the associations, everything seemed good again except for the fact my girlfriend was completely missing from my phone. I logged into Facebook and confirmed I was still listed “in a relationship” with her and indeed she was listed in my friends list.

I logged into Windows Live Contacts (which I also synchronizes with Facebook), and found that she was missing from there too. My feeling was that some communication was broken between Facebook and other applications (e.g. Windows Live and WP7).

My troubleshooting took me down the privacy root, and although I made no recent changes I checked each of the privacy settings in my Facebook and Windows Live profiles. Still no luck!

Given that it was a Saturday and I had lots to do. I grabbed her details of my very old phone and manually added her as a contact through Live contacts. Unfortunately then I still didn’t get any Facebook connectivity for her on my WP7.

A couple of weeks later I have found the problem. She had changed her privacy settings, and although her profile appears no differently to me through Facebook, I had not been able to use any other applications to view the same data.

When she changed her “App Settings” privacy to allow “All Platforms”, or the specific platforms I use, the problem was completely resolved.

In conclusion Facebook seems to use privacy settings of my individual friends rather than those from my profile to determine if I can see their information from my other connected applications.  This means if you want to tighten up this specific Facebook privacy setting, you should consider whether any of your friends use connected Facebook applications.

You could be encountering this problem if:

·         You are using an application calling the API “DTCGetTransactionManagerExW” from a thread impersonating a different user to that which the process is running as;

 ·         The application is running and failing on the MSDTC passive node of an Windows 2003 Cluster (and it is working when run on the MSDTC active node);

 ·         You have configured the MSDTC network name property to “Enable Kerberos Authentication”;

 ·         You have configured the MSDTC CM to use “Incoming caller authentication required”.

The Cause

The “DTCGetTransactionManagerEx” API called from a ‘client process’ is being run from a thread that is impersonating the ‘Thread User’. The thread subsequently created which is making the request to the MSDTC service is still running as ‘Process User’. This request is then sent across to the MSDTC service encrypted by a ticket for the ‘Process User’.

When the ‘MSDTC process’ is then sending the message back to ‘client process’, it is assuming it can encrypt it using the same ticket, however the thread on which the ‘client process’ actually receives the call is different to the outgoing call’s thread and running as the ‘Thread User’.

Since this ‘Thread User’ does not match the ‘Process User’, it is not permitted to decrypt the message and therefore is failing.

The problem is caused because the incoming and outgoing requests should both be run from threads in the same user context and currently they are not. This is a problem within the MSDTC Proxy code.

The Workaround

To workaround the issue you can use one of the following options:

1)      Set the MSDTC security setting for the communication manager authentication to “no authentication required”.

2)      To recreate the MSDTC cluster group with a network name that does not have “Enable Kerberos Authentication” set.

3)      Do not call the DTCGetTransactionManagerEx API from an impersonated thread.

The Fix

Currently there is no fix for the problem in Windows 2003 however the problem is fixed in Windows 2008 and above.

A common reason for this is due to the errors shown below:

For example:

The COM+ Event System detected a bad return code during its internal processing.  HRESULT was 800700e6 from line 45 of d:\longhorn\com\complus\src\events\tier \eventsystemobj.cpp.  Please contact Microsoft Product Support Services to report this error.

The COM+ Event System detected a bad return code during its internal processing.  HRESULT was 80080005 from line 45 of d:\longhorn\com\complus\src\events\tier1\eventsystemobj.cpp.  Please contact Microsoft Product Support Services to report this error

To address this issue without reinstalling the OS, consider reviewing the registry key:

                “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem”

If, after making a comparison to an identically versioned machine the key is found to be mismatched, you could try to backup and overwrite to bad key to see if it assists in resolving the errors.

Chris Forster

There is however a problem which causes this supported scenario to fail.

Let us take for scenario where MSDTC is running in a SQL (Service or application) group and this SQL group was originally configured as part of the SQL Server setup process. The resource name of Network Name resource is probably called something like "SQL Network Name (MyClusterSQL1)" (where MyClusterSQL1 is the actual DNS name and the name used in the network name properties). Due to a problem in MSDTC this mismatch between the resource name and the network name itself causes the authentication (whether incoming caller authentication or mutual authentication) to fail.

If you are facing this scenario we can recommend the following change which will rename the "SQL Network Name (MyClusterSQL1)" network name resource to “MyClusterSQL1”. Below is an example of how to make this change:

This problem is not limited to a SQL Server Resoruce group, and a similar MSDTC problem can be experience in any resource group where the "resource name" of the network name resource is different from the network name itself.

Chris Forster

The simplest way to reproduce the problem was to open “regedit”, and from the file menu “Connect Network Registry” using the SQL network name as the remote registry. If this problem is being seen, this step will fail.

During the SQL installation, SQL can set the following resource key to true (1): “KEY_LOCAL_MACHINE\Cluster\Resources\%ResourceGUIDFORSQLNETWORKNAME%\Parameters\RemapPipeName”, when by default it is false (0). This is why it only affects SQL Cluster groups. On its own this should not cause the problem, however it seems when the above key is set and the following key is missing then we can encounter this issue:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters:

Name: NoRemapPipes

Type: REG_MULTI_SZ

Data: winreg

                      svcctl

                      eventlog

The best way to resolve the issue is to add the three exceptions (winreg, svcctl and eventlog) to the latter “NoRemapPipes” key as above.

Chris Forster

Chris Forster

The MSDTC representing the machine where the transaction is begun is normally referenced to as the superior MSDTC. The MSDTC representing further machines involved in the transactions are normally referred to as subordinate MSDTC’s.

In Microsoft Windows there is a limit to the amount of subordinate MSDTC’s that can participate in a single transaction and this is set to 64.

During a transaction, usually we will enlist one or more Resource Managers (RM's). An example of an RM would be Microsoft SQL Server. In many scenarios it is the responsibility of the subordinate TM to enlist the RM it represents. In Microsoft Windows we have a limit in which each MSDTC involved in the transaction (each subordinate) can each enlist a maximum of 32 RM’s.

Chris Forster

This statistical transaction information should be a duplication of what you would normally see locally, and instead of the information being sent from the MSDTC Transaction Manager on Server A to the Component Services UI on Server A it is sent from the MSDTC Transaction Manager on Server A to the Component Services UI on Server B.

In most scenarios this functionality works very well however there is a scenario where you will find a inconsistency. If Server A is for example a 64-bit version of the Microsoft Windows operating system and Server B is a 32-bit version of the Microsoft Windows operating system then you will see an inconsistency in the results displayed for the transaction statistic which could cause alarm. Likely from Server B, you will see a very large number of “Unknown” and “Total” transactions outcomes under the aggregate section; whereas from Server A you will not see the large number of unknown transaction outcomes and therefore the “Total” number of transaction will be less.

The cause of this issue is a problem in structures used when this information is passed back from the 64-Bit OS to the 32-Bit OS. It is simply a user interface issue and the underlying functionality of MSDTC is not affected. In conclusion, if you face this scenario you should trust the statistics shown from the user interface on the local machine where MSDTC is running over the results shown from the remote administration user interface.

Chris Forster

If your configuration is to have one clustered instance of MSDTC in its own resource group and for any of your SQL server instances to be in their own separate resource groups, then there is a potential for MSDTC and SQL Server to be active on different nodes at a given time.

Primarily the SQL Server process loads the MSDTC Proxy in order to communicate with the MSDTC Service. When this is on the same node there will likely be no problems, however if they are active on different nodes and you have the Windows 2008 Firewall enabled you may encounter problems. The communication between the MSDTC Proxy (loaded in to SQL) and the MSDTC service is done through RPC. The obviously symptom of such a problem will be that you cannot flow a transaction from your application towards the SQL Server instance in question, however more specifically if you connect to the SQL Server instance using the management studio and run a query “Begin distributed Transaction” it will fail.

If you examine the exception rules (for the MSDTC exceptions) within the “Windows firewall and Advanced Security” you will see the following rules:

Inbound Rules:

-Distributed Transaction Coordinator (RPC) -> Limited to SVCHOST Process communication

-Distributed Transaction Coordinator (RPC-EPMAP) -> Limited to SVCHOST Process communication

-Distributed Transaction Coordinator (TCP-IN) -> Limited to MSDTC Process communication

Outbound Rules:

-Distributed Transaction Coordinator (TCP-Out) -> Limited to MSDTC Process communication

As can seen there is no “TCP-IN” or “TCP-Out” for the SQL Server process. This is important as it is the SQL Server process initiating the contact with MSDTC. In order to keep security as tight as possible, instead of disabling the firewall, you can create these rules and ensure endpoint addresses must be within the cluster boundary. When creating these new rules, select the SQL Server process executable in the options (remember each is instance specific) and add all virtual and physical IP ranges within the cluster to the rules scope properties.

There are already configured DTC rules (named above) to MSDTC traffic from any application server to the Database Cluster so there is no concern about this for now.

Once these rules are enabled, repeat the “Begin Distributed Transaction” query when MSDTC is on a different node to SQL Server and it should now be successful.

Chris Forster

In order to configure MSDTC on the cluster a shared disk is required. This disk is where the MSDTC log file is held. The log file contains details and states of open transactions. This means if the MSDTC service was to stop for any reason, it can be restarted and the transaction could continue without being lost.

As stated in the KB article 301600 you cannot use a MNS disk as the disk for the MSDTC log file.

From the article https://technet.microsoft.com/en-us/library/bb123996.aspx we also state: “In Windows Server 2003, the MSDTC cluster resource requires the use of shared storage in the cluster.”

I have come across a number of scenarios whereby we did not meet these requirements yet still require MSDTC. An example of such a scenario is a Microsoft Exchange Cluster containing only an MNS disk with no shared disk installed. On these cluster you may need MSDTC to install certain updates or even to use some custom written COM+ add-on's.

First we must specify that MNS (Majority Node Set) is not a shared disk it is more a replication method and as stated above it cannot be used for the MSDTC log file.

In order to get this working in a Microsoft supported manner there are only two solutions:
 - Install a shared disk; or
 - Consider moving to Windows 2008 (Windows 2008 supports an active-active MSDTC configuration).

If these solutions are really not possible for your particular case there is one other possible option. I must explicitly state that this is a non-supported and not a fully tested workaround.

The method means that MSDTC would not be highly available on the cluster. It uses a local quorum disk and means MSDTC will be allowed to come online on a single (statically defined) node.

Even though the same node is the only place MSDTC will ever come online this is still a clustered resource, meaning a call from a passive node or active node to use MSDTC should work.

In order to try such a workaround, you should create a new cluster group. Within this cluster group create a regular IP Address and Network Name Resource.

The next step is to create a Local Quorum resource, the wizard to undertake this will present you the option of which nodes this resource can be used on. Ensure you select only the one node (e.g. Node A). Once completed then a “Distributed Transaction Coordinator” resource should be created and again only be allow to come online on the same single node (e.g. Node A). The dependency of this final resource should be the three resource named above. If this has been done correctly, you will arrive at drop down box where you will be given the drives available for the MSDTC log file; the local quorum should be listed.

(I must re-iterate that in the above description MSDTC will only come online on Node A, however can be utilised by other cluster nodes when Node A is online. If Node A goes offline or fails then MSDTC would not move to another node and MSDTC would not be available until Node A is back up and running.)

Chris Forster