RippleRock are developing an awesome tool for providing realtime, actionable visualisations of your project data. If you’re wondering why your backlog is such a mess, want to understand how you could improve your Agile/Lean development process or simply want to predict when your project will end, then you should check out SenseAdapt.
SenseAdapt works with Team Foundation Server and Visual Studio Team Services (keep an eye out for a preview on the new VSTS Marketplace soon) and we’re experimenting with a Jira version too.
To develop SenseAdapt, we use our own project data, so SenseAdapt is helping us to improve and adapt the process we use to develop SenseAdapt!
The problem is that we need real data in both VSTS and TFS and as we recently consolidated a VSTS project into our on-premise TFS 2015, we wanted a one-way sync of Work Items between the two systems.
There are options of course:
I wanted something implemented quickly and cheaply so that’s why yesterday I installed the TFS Integration Tools. If you have ever used TIT (they really should have thought about that acronym) then you’ll know that they are……er, interesting?
Last released in March 2012, they know nothing of TFS 2013/2015 and VSO/VSTS was the TFS Service Preview back then. My installation was on Windows Server 2012 R2 with SQL Server 2014 Standard SP1 and TFS 2015 RTM (No update 1 on this instance for testing purposes)
I knew that I needed to install the TFS 2012 Team Explorer so that the Integration Tools could talk to my server using the older object model.
I also knew there was a problem with this setup that needed a little registry change. The error you will see is:
“This tool requires the TFS client object model. Please install Team Explorer 2008, Team Explorer 2010, or Team Explorer Dev11 and run setup again”
An old blog post by Willy Peter Schaub shows that the easiest way to fix this is to paste the following into a .txt file, rename to .reg, and double click.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\InstalledProducts\Team System Tools for Developers]
@="#101"
"LogoID"="#100"
"Package"="{97d9322b-672f-42ab-b3cb-ca27aaedf09d}" "ProductDetails"="#102"
"UseVsProductID"=dword:00000001
I was off and running now so I kicked off the install that I’ve done many times in the past and selected to include the TFS Integration Service
For the database server name, i just put a ‘.’ as I was going to use the default instance (SQL 2014 Standard)
Unsurprisingly, something went wrong but I aborted the install without really paying attention, assuming I messed something up.
So I started the installation again, paying more attention this time but I received a different error:
Database Error: Cannot read TFS Integration Tools database version number
It turns out that the failed installation had created the database Tfs_IntegrationPlatform but had not cleaned it up again during rollback. That helpful message meant that I needed to go into SQL Management Studio and delete the database.
We were off again and everything seemed good until the error message that I received originally showed up again.
Error -2147217900: failed to execute SQL string, error detail: Valid values of the database compatibility level are 100, 110, or 120., SQL key: CreateDatabaseScript SQL string: EXECUTE sp_dbcmptlevel [Tfs_IntegrationPlatform], 90;
This one was trickier. There was an ooooold forum post by Bill Essary at Microsoft saying that they were aware of the issue but didn’t have a fix as yet. A few others suggested that the problem went away when they retried the install. After the 3rd time, I accepted it wasn’t going away.
Making an educated guess, i assumed that the integration tools were not compatible with SQL 2014 so I decided to install a named instance of SQL 2012 Standard SP3 on the same server.
Passing in .\INTEGRATION as the database server\instance meant we were finally installed!
Onto the next problem
I created a new configuration and selected Team Foundation Server\WorkItemTracking.xml as my template.
I didn’t bother reading the docs as I was still sceptical that this was going to work so I just chose Custom workflow, ContinuousAutomatic frequency, Unidirectional direction.
Next, I chose my on-premise TFS 2015 server as the Left Source and my VSTS account as the Right Source.
I had forgotten that the account running the Sync/Migration had to be in the Service Accounts Group. On-premise you have to use tfssecurity.exe to add your account to that group but I suddenly thought, “there’s no way VSTS will let me do that”, so I expected it to be game over.
I tried:
tfssecurity.exe /g+ “Team Foundation Service Accounts” n:my@emailaccount.com /server:https://myaccount.visualstudio.com
and unsurprisingly got
The requested operation is not allowed
Kind of obvious as VSTS is not going to allow me to be a Team Foundation Admin or Service account so I had one last stab:
tfssecurity.exe /g+ “Project Collection Service Accounts” n:my@emailaccount.com /collection:https://myaccount.visualstudio.com/defaultcollection
Amazingly, that was successful
I repeated the process for my on-premise server and I was off.
Now, the tools are installed and running but as usual, it has thrown a hissy fit on the first pass.
Application Error: 0 : A failure occurred while trying to load the C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins\Tfs2008WITAdapter.dll Plugin:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
and
Application Error: 0 : A failure occurred while trying to load the C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins\Tfs2010WITAdapter.dll Plugin:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
and
Application Critical: 0 : [27/01/2016 19:07:38] System.InvalidOperationException: Specified element is already the logical child of another element. Disconnect it first.
After all that, those errors looked like they could be terminal but I found an article that states that removing any files with 2008 or 2010 in the name from the following folder:
C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins
will allow the Integration Tools to progress.
Great source for all things Integration Platform: TOC: TFS Integration Tools Blog Posts and Reference Sites
And we’re off and running with 1-way sync between TFS 2015 and Visual Studio Team Services!
Cheers,
Richard
.