1

I have been having constant issues with the OpsHub Migration Utility erroring at different stages in setting up a migration, but when I finally get a migration going it fails after 15 minutes or so with the following error:

"Unable to get prject map for system : {my on-premise TFS url} to {my VSTS url}| TFS Source 1462312056714 Source TFS 1462312056719 due to :

OpsHub-014301: Error in getting project metadata for system :

TFS.OH-TFS-Connector-0048: Failed to login to Team Foundation Server : {my on-premise TFS url} with user : null.

Server Error : TF400324: Team Foundation services are not available from server {my on-premise TFS url}. Technical information (for administrator): The underlying connection was closed: An unexpected error occurred on a receive.. You may have given wrong credentials or are not valid now..."

I previously tried doing migration with ~6500 Changesets (our main project) and got a similar error after an hour, except that none of the changesets had passed. So, I tried migrating a smaller Team project with 182 changesets and it failed after 72 changesets.

Failure at 72

This smaller migration then restarted on its own and was able to get to 148/189 changesets before failing again for the same error.

Failure at 148

Eventually I was able to complete all 189 changesets, but it took a long time to do so (2 hours). I can't even begin to hope that a migration of 6500 will complete in a reasonable amount of time. It seems I shouldn't be having credential issues after starting a migration so why is this error happening intermittently? Why is the user null?

I will add that prior to starting the smaller migration, I did clear the following:

1)%localappdata%\Microsoft\Team Foundation\3.0\Cache

2)%localappdata%\Microsoft\Team Foundation\4.0\Cache

3)%localappdata%\Microsoft\Team Foundation\5.0\Cache

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Isaiah Nelson
  • 2,450
  • 4
  • 34
  • 53
  • 1
    The credential is "null" according to the logs, did you clear the IE cache during the migration? The credential information is stored in IE cache. – Eddie Chen - MSFT May 04 '16 at 03:15
  • Yep, seems like the IE cache is being clearing periodically/automatically. – OpsHub Inc. May 04 '16 at 04:22
  • @OpshubInc. By "IE" you mean Internet Explorer? If so, I actually use Firefox and had VSTS open the whole time in FF. I also didn't deliberately clear the browser's cache while doing the migration, I just let it do its thing and continued with other things. So why then would the user be null? – Isaiah Nelson May 04 '16 at 04:26
  • @OpshubInc. I updated my post above: I did clear the localappdata cache prior to running the smaller migration - the 189 records. But I didnt clear anything else during the actual migraiton. – Isaiah Nelson May 04 '16 at 04:32
  • Regardless of the browser that you use. Visual Studio stores the endpoint authentication info inside the IE's cache. If that is being cleared due to some reason (by some setting), there can be problems. Another possibility can be connectivity to the source TFS Machine. You could try performing a continuous ping to the source TFS machine and see if there is any breakage in the connection there. – OpsHub Inc. May 04 '16 at 04:34
  • 2 hours :) You're lucky. I've had migrations take weeks. – jessehouwing May 04 '16 at 07:39
  • You may also have issues connecting to your AD server or your AD server has a very short lifetime configured for auth tickets. The fact that it reports `with user : null.` is fishy. – jessehouwing May 04 '16 at 07:41
  • Since I work at home and in another state from where our on-prem TFS instance is hosted, pinging the connection the box wasn't possible because of our firewall. But I did run another migration and it succeeded without any problems. It just took an hour to complete. I decided to RDP into our TFS server and run the migration from there as well. It also ran without a problem and was completed in 7 minutes. So the problem seems to have corrected itself. Its definitely better to run it on the box that TFS is hosted! :) – Isaiah Nelson May 04 '16 at 19:35
  • Glad to know it worked that way. :) Most likely the cache clearing was the issue for the tool losing authentication info leading to the error. – OpsHub Inc. May 05 '16 at 06:16

0 Answers0