Reza Alirezaei’s Blog

Yes, the story continues and I am having fun!!! 🙂

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 (dhdc)  and exposed it via https to our remote developers for two main reasons:

1) We (myself and our project manager) could take advantage of TFS notifications sent to our exchange accounts.

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

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.

Issue1:  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) 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:

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

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

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

Issue2: In *all* of the virtual machines (x64) , developers couldn’t use thier credentials to connect to the TFS.  Issue was when they added the TFS server  (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.

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.

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  local admin (dhtfs\administrator) ended up as a high privliaged user in TFS. Here is a diagram of how mapping took place :