Connecting to TFS from any version of Visual Studio


I've written a couple of blog posts on this subject before and thought it would  be nice to consolidate them into one big post now that Visual Studio 2013 is about to be released. There are 3 major things to consider when connecting to TFS from an older version of Visual Studio.
  • The version of TFS you want to connect to
  • The version of Visual Studio you're connecting from
  • The version of Windows you're running
In this blog post:
  1. Connecting to Team Foundation Server 2015, 2017, 2018 or Visual Studio Team Services.
  2. Connecting to Team Foundation Server 2013.
  3. Connecting to Team Foundation Server 2012.
  4. Connecting to Team Foundation Server 2010.
  5. Configuring the MSSCCI provider for Visual Studio
  6. Connecting from Visual Studio 2005, 2008 or the MSSCCI provider
Since writing this post, Microsoft has produced an updated piece of documentation (which is already behind in some aspects) that describes most of the client/server combinations. One thing it adds which I haven't described, is the list of features that are available depending on your version of Visual Studio/TFS.

If you're having issues connecting after updating, it might be required to clear your local client cache to clear up certain issues like this one. Either the official way or the hard way.

If you also want to install the Team Foundation Server Power tools to match your Visual Studio/TFS version, check out this separate post.

Update: Updated download links to the final version of Team Explorer 2013.

Update (13-11-2013): Updated download links to the final version of Visual Studio 2012 Update 4.
Update (25-11-2013): Added information on client cache and feature docs.
Update (6-1-2014): Added update for VS2010 for Windows 8 and Visual Studio 2012
Update (21-1-2014): Added update 1 for Visual Studio 2013
Update (25-8-2014): Added update 3 for Visual Studio 2013
Update (21-7-2015): Added update 5 for Visual Studio 2013 and Visual Studio and TFS 2015. Since Visual Studio 2013 Update 5 contains updates to handle TFS 2015 Team Project Renames, it's recommended for anyone connecting Visual Studio or MSSCCI 2013 to TFS 2015.
Update (22-7-2015): Added update 5RC for Visual studio 2012.Since Visual Studio 2012 Update 5RC contains updates to handle TFS 2015 Team Project Renames, it's recommended for anyone connecting Visual Studio or MSSCCI 2012 to TFS 2015.
Update (26-8-2015): Replaced Visual Studio 2012 Update 5 RC with the final version.
Update (30-8-2015): MSSCCI 2013 now also supports Visual Studio Team Foundation Server 2015. But it still depends on Team Explorer 2013.
Update (27-10-2015): IntelliJ IDE's support added
Update (8-1-2016): logging on using Azure Active Directory is no longer supported on Windows XP/2013 and systems with IE8 or older.
Update (4-7-2016):Added Visual Studio 2015 update 3
Update (16-11-2016): Added TFS 2015 (same as TFS2015)
Update (04-10-2018): Added TFS 2017 and TFS 2018 and Visual Studio 2017

Crafting complex Release Gate conditions in VSTS


A recent addition to VSTS is the ability to run a quick check prior to triggering a release to an environment. These checks can be used to check that there are no new customer complaints, no mad users on twitter, no important jobs running in the environment etc.

I wanted to make use of this feature as part of the CI/CD Tasks for Extensions. With the recent introduction of validation of the extension, it's possible that your newly uploaded extension isn't immediately available. So before kicking off tests for your extension, you may want to wait for the validation to succeed.

This resulted in two tasks, the first is a Server Gate task that can wait for the extension validation to finish before triggering a release. The second does the same thing, but runs on the build agent. They both rely on the Marketplace REST API.

Disambiguate MSA and AAD accounts


Microsoft is finally closing the loophole that allowed you to create an MSA account (LiveId) with the same unique name as your AAD (Azure Active Directory) account. While it has been very useful in many cases to use the same ID for both the MSA and the AAD account, most services that relied on only MSA are finally shipping updates to also support AAD.

I've always had my MSA and AAD account share the same identity ever since I created my Microsoft Account almost 15 years ago. And every since Microsoft introduced Azure Active Directory I've had to choose between a "work and school account" or a "personal account". It helps that I have a pretty good understanding of the difference, so for me it never really posed more than a minor inconvenience, but I see a lot of clients confused and frustrated by the, in their eyes, useless question:

Because of it's age a lot of profiles were associated to it, and changing the sign-in address of my MSA felt a bit scary. Just to give you an idea of the services linked to my MSA (

  • Microsoft Certification Portal
  • Microsoft Most Valuable Professional Portal
  • Microsoft Partner Portal and Partner link to Xpirit
  • Microsoft Visual Studio Marketplace Publisher account
  • XBox Live account
  • Windows Phone Marketplace
  • Windows Developer Account
  • MSDN subscription (from MVP)
  • Azure Subscription (multiple)
  • Visual Studio Team Services (multiple)
  • Visual Studio Enterprise license in Visual Studio 2017 (through MSDN)
  • Azure AD Guest user in a number of partner directories
  • Windows Store
  • Groove Music
  • Family Office 365 subscription
  • OneDrive
  • Windows Insider
  • Skype
  • My personal laptop
  • My work laptop
  • My personal Xbox
At the same time a number of things were associated to my AAD account sharing the same identity (
  • Microsoft Visual Studio Marketplace Publisher account
  • MSDN Subscription (from work)
  • Azure Subscription
  • Visual Studio Team Services (access to Microsoft owned accounts)
  • Azure AD Guest in the Microsoft directory
  • Work Office 365 subscription
  • Ondrive for Business
  • Skype for Business
  • Windows Insider
  • My work laptop
I'd switched identities on my Microsoft account before, when I left my previous employer and joined Xpirit, so I was accustomed to the process of re-associating in the Microsoft Partner Portal and switching the primary identity in my MSA account, but I'd always hit a few problems and over the years the number of additional devices and services has steadily grown.

To start the disambigiation process I first added a new secondary identity to my MSA account ( This option is pretty hard to find if you don't' know what you're looking for. You can find it in the Microsoft Account portal:
Click the "Manage your sign-in email or phone number" link and there you can add additional sign-in addresses to your account. In my case I added a secondary sign-in address for my gmail account:
After confirming you own this address through your chosen method of security, you can now sign in to most services using either address. A few won't work through, as I found out:
  • Visual Studio Team Services won't allow to sign in with a secondary identity. It will however automatically swap you to your new identity once you make it primary. Account ownership will also be updated automatically nowadays. That was a great relief.

Form there I clicked the "Make Primary" link on my new primary identity and after that I checked whether I could still access all my accounts. Switching my primary identity had a few unexpected side-effects:
  • I had to update my MSA account information on my windows devices.
  • I had to sign into my Xbox again
  • I had to restore my Windows Insider details
  • I had to uninstall the Windows Feedback app and install it again (should be fixed in a later version)
  • I had to sign out fo Visual Studio completely and sign in again so refresh my license and to connect to Visual Studio Team Services.

After confirming I could still access all my services I crossed my fingers and went on to remove my old primary identity.

After clearing all cookies in my browsers I am now no longer greeted by disambigution prompts, which makes me very happy. I'd still love it if Microsoft would make this process simpler and if they'd be able to remove the issues I encountered, but the process was a lot easier than I had been dreading.

Ohh and while you're at it, you may as well update your security preferences, enable 2-factor authentication and set a stronger password ;).

If you're wondering whether a company could solve this problem for their users, the answer is no. There is no way for an organisation to query which users have the same ID for their AAD and their MSA account and there is no way for a company to change the primary identity on behalf of their employees. The MSA account is owned by the individual and privacy and legal reasons prevent Microsoft from solvign this on behalf of a company.

Most Reading