Ambiguous Team Foundation Server (TFS) error 'Source control provider could not be initialized'

Many of you are starting to set up your development areas to TFS online and there is the standard vague error message we are seeing that plays a lot of different roles.  Here is a list of items you can review when you receive the following error "Source control provider could not be initialized".

1. Whitepaper review
We have published a whitepaper that discusses how to use TFS with Dexterity for your source code repository.
It is available at the link below:
http://www.microsoft.com/en-us/download/details.aspx?id=24969

We don’t have documentation specifically for setting up Visual Studio Online. We have typically followed the existing white paper above for TFS and Dexterity.

2. Server VS Local on Workspace
The biggest thing to watch out for is that the workspace MUST be defined as Server instead of Local as this is overlooked often.

Since source code control files are not meant to be user-modified or merged, we enforce a single check-out policy. In order for us to do that on TFS, the TFS workspace needs to be set up as Server. The white paper does mention this in Step 3 of "Configuring Source Control for a Team Project". By changing that setting in the project, new workspaces are set up as a Server workspace by default.

Existing workspaces can be changed to a Server workspace by following these steps:
- In Visual Studio, go to Source Control Explorer.
- In the Workspace drop-down, select "Workspaces..." to open the Manage Workspaces window.
- On the Manage Workspaces window, select the workspace used by DSCCS and push the "Edit..." button to open the Edit Workspace window.
- On the Edit Workspace window, push the button named "Advanced>>".
- Find the Location: field and change it from Local to Server.
- Push the Ok button to save changes and close the Edit Workspace window.
- Close the Manage Workspaces window.
- Restart the Dexterity Source Code Control service. 

3. Dexterity Source Code Control Service (DSCCS)
The Dexterity Source Code Control Service (DSCCS) does not need to be running when connecting with TFS, but it needs to be installed.  There are components that are required to existing when connecting Dexterity with TFS.

4. Supported Versions
The items that are listed in the Provider section drop down in the Options tab are what is supported for the version you are running, such as
Team Foundation Server 2010, Team Foundation Server 2012, etc.

For Microsoft Dynamics GP 2013, you need to be on Dexterity version 12.00.0319 or later (that is when we started to support TFS) and have TFS 2012/ Visual Studio Team Services 2012 or 2010 installed to connect.

For Microsoft Dynamics GP 2015, you need to be on Dexterity 14.00.0072 or later and TFS 2013 is supported.

You also must install Visual Studio locally and connect to the repository in Visual Studio Online. Specifically, you will need either Microsoft Visual Studio Team Explorer or Microsoft Visual Studio on each workstation (where Dexterity is installed) which will be accessing the online TFS source code repository.
Note:  There have been some inconsistent issues with Team Foundation Server 2013/2015.  What seems to work best is Visual Studio 2012 (Update 4/5) in order to be able to use the Dexterity TFS 2012 provider which can still be used with TFS 2015.

5. Why Not??
Reboots are always good right?  If you have been making lots of changes to the machine, a reboot a lot of times magically fixes errors, it is a common cure for our support cases we always throw in :-).

6. Configuration Files
Another item to check and you could compare if you have a working machine is go to this location example:

C:\Users\<USER>\AppData\Local\Microsoft\Team Foundation\3.0\Cache\

Is there a config file there in both machines? We have seen where a non-working machine will be missing the files.

There is also a VersionControl.config file in an example area such as

C:\Team Foundation\5.0\Cache\Volatile, it too should be located in the Users \ AppData location.

7. Process Monitor
Last if none of the above have helped you, what you can do is create a Process Monitor on the working and non-working machine or just non-working if that is the case.  Then filter it by process name of Dex.exe and see if you can tell the difference of the two or what is failing on the machine.

Last but not least you can always submit a support case and a delightful engineer like myself will be ready and waiting to assist you.

Thanks

Terry Heley
Microsoft