{"id":592,"date":"2008-08-07T00:56:07","date_gmt":"2008-08-07T05:56:07","guid":{"rendered":"http:\/\/blogs.devhorizon.com\/reza\/?p=592"},"modified":"2008-08-07T01:04:41","modified_gmt":"2008-08-07T06:04:41","slug":"fun-with-remote-tfs-connectivity-in-vs-team-suit-2008","status":"publish","type":"post","link":"https:\/\/blogs.devhorizon.com\/reza\/2008\/08\/07\/fun-with-remote-tfs-connectivity-in-vs-team-suit-2008\/","title":{"rendered":"Fun with remote TFS connectivity in VS Team Suit 2008"},"content":{"rendered":"

Yes, the story <\/a>continues and I am having fun!!! \ud83d\ude42<\/p>\n

History<\/strong>: I have my TFS server hosted in US. It was initially provisioned as an standalone server and obviously there was a local administrator account(dhtfs\\administrator). Let’s say , we chose “G@dBle$$America” for admin’s password. Later on , we joint the TFS machine to our domain (dhdc)\u00a0 and exposed it via https to our remote developers for two main reasons:<\/p>\n

1) We (myself and our project manager) could take advantage of TFS notifications sent to our exchange accounts.<\/p>\n

2) Our remote developers can check-in , check out without having to VPN to our network and authenticating against our domain controller (dhdc).<\/p>\n

As I aluuded to in the previous post, we built a base windows 2k8 server and sysprepped it to be able to roll it up on our VM and non-VM machines. Again, we used the same favorite password (G@dBle$$America) for the local administrator account (machinename\\administrator) for the base sysprep image.<\/p>\n

Issue1:<\/strong>\u00a0 In *some* of the virtual machines (x64) provisioned from the same sysprep image (x64 ) . After I took care of the SharePoint issue (see number 4 in this post<\/a>) and when developers tried to connect to our Team Foundation Server source control from the Team Explorer 2008 client installed on each machine., the following error appeared:<\/p>\n

Unexpected error encountered. It is recommended that you restart the application as soon as possible.
\n Error: No such interface supported
\n File: vsee\\lib\\vscommodule\\vscommod.cpp
\n Line number:173<\/p>\n

\"TFSError\"<\/p>\n

Was this a corrupted Team suit installation?Answer is No! because I found this KB article<\/a> , tried the resolution and it solved the issue.<\/p>\n

1. Open a command prompt.
\n 2. Navigate to the following folder:
\n “%programfiles%\\Microsoft Visual Studio 9\\Common7\\IDE\\”
\n Note<\/strong>: in x64 machines (and since VS is still a 32-bit app), “%programfiles% is Program Files (x86)
\n 3. Type this : devenv.exe \/resetuserdata<\/p>\n

Issue2:<\/strong> In *all* of the virtual machines (x64) , developers couldn’t use thier credentials to connect to the TFS.\u00a0 Issue was when they added the TFS server\u00a0 (Tools menu–> Connect to Team Foundation Server…), TFS didn’t challenge them to enter their username and password. Something was being cached , but didn’t I just flush out the current user’s data? We did a sample check-in , check-out and noticed that actions are performed under the “administrator” account , but which administrator account is this? We were not logged in to the domain, so it couldn’t be dhdc\\administrator for sure.<\/p>\n

Changed the TFS machine’s local administrator (dhtfs\\administrator) password and we immediately got the credential prompt on remote clients. So the issue was the NTLM pass-through authentication which was mapping VM’s local admin (spvm2\\administrator) to the TFS’s local admin (dhtfs\\administrator) – as they were using the same password.<\/p>\n

TFS’s local admin (dhtfs\\administrator) was part of BUILTIN\\administrators which in turn was a member of [SERVER]\\Team Foundation Administrators group. That’s how the TFS machine’s\u00a0 local admin (dhtfs\\administrator) ended up as a high privliaged user in TFS. Here is a diagram of how mapping took place :<\/p>\n

\"VisioDiagramSnagit\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Yes, the story continues and I am having fun!!! \ud83d\ude42 History: I have my TFS server hosted in US. It was initially provisioned as an standalone server and obviously there was a local administrator account(dhtfs\\administrator). Let’s say , we chose “G@dBle$$America” for admin’s password. Later on , we joint the TFS machine to our domain […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[],"class_list":["post-592","post","type-post","status-publish","format-standard","hentry","category-team-foundation-server"],"_links":{"self":[{"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/posts\/592","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/comments?post=592"}],"version-history":[{"count":0,"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/posts\/592\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/media?parent=592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/categories?post=592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.devhorizon.com\/reza\/wp-json\/wp\/v2\/tags?post=592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}