“TF31002: Unable to connect” error from Visual Studio 2013, Visual Studio 2012, & Visual Studio 2010

by

I recently ran into a strange problem while doing an upgrade from Team Foundation Server to Azure DevOps Server 2020 for a client. Everything upgraded smoothly but users running older versions of Visual Studio couldn’t connect. They were getting the dreaded “TF31002: Unable to connect to this Team Foundation Server” error if they tried to connect using Visual Studio 2013, Visual Studio 2012, Visual Studio 2010, and some older versions of the Eclipse plug-in.

The dreaded TF31002 error

My first thought was to check if these clients were still supported. According to the Azure DevOps / Visual Studio version support matrix, everything should be working. We tried all the usual stuff like deleting the local Visual Studio / Team Explorer cache but nothing worked.

As part of my effort to solve the problem, I created a bunch of virtual machines in my test environment (including installing Visual Studio 2013 for the first time in nearly a decade). Everything worked just as expected. So that started pointing towards some kind of problem with the customer’s servers or networking environment.

Narrowing in on the Cause of the Problem

After a ton of digging around, it was suggested that perhaps we were having problems with SSL and/or TLS settings in Windows Server. These settings live in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. When I compared the problem server’s SCHANNEL settings to the default settings from Microsoft on my server, I found that there were a ton of custom settings in Ciphers and in Protocols. The default settings for SCHANNEL have both of these registry “folders” as empty.

Custom SCHANNEL & Protocol settings

When I applied the problem settings to my test server and rebooted, I immediately had the same problems connecting using Visual Studio 2013.

The Solution

The solution was mercifully simple. All we needed to do was to reset the SCHANNEL settings back to their defaults. Here’s a registry script that resets the SCHANNEL SSL TLS settings back to their defaults.

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

The first line of the script deletes all the SCHANNEL registry entries entirely. (Curious on how to delete a whole bunch of registry keys at once? Just add a dash ‘-‘ before the name of the key.) The rest of the script recreates the default values.

If you want to run this script, copy it into a text file and name the file with the ‘.reg’ extension. Then log in to your Azure DevOps application tier server as an administrator and run the script. After you run the script you MUST reboot the server for the changes to get picked up.

I hope this helps.

-Ben

Need help with a tricky Azure DevOps upgrade or migration? Want some help with your Azure DevOps Build & Release Pipelines? Looking for help getting your remote Scrum teams working smoothly and efficiently with Azure DevOps or GitHub? We can help. Drop us a line at info@benday.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: