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 :

Since TFS 2008 came out , I have always wanted to find sometime to dive into this. I am pretty slammed these days with many things – work,life, shopping and shoveling the snow- Just kidding

Actually , I hired someone to take care of the shoveling task, therefore I can save sometime to work on other things such as TFS 2008 – what a geeky life man . Anyway, I finally got this up and working and I decided to create a very high-level walkthrough of the things I did. Fortunately,this time Installation process and best practices are fairly well-documented from the beginning so I just linked to them wherever needed.

tfs.pdf

I have installed TFS couple of times, but it has been always in a dual-server mode which basically puts the Team Foundation data and the application tiers on separate computers. Last week, I was asked by a colleague of mine to give him a hand on installing TFS in a single server mode. Well, I am not a TFS expert, but when it comes to a technology that somehow relates to SharePoint somewhere, I step in and learn enough about that technology to protect myself for rainy days in future. As a result, I have been involved in many integration projects that SharePoint is the other end or it is used under the hood. Despite the fact that I am known for 100% SharePoint architecting and dev , I *really* enjoy this type of work a lot more.It is much more fun plus the exposure you can get to other complementary technologies around SharePoint. Obviously, the challenge is always to stay focused and indeed not to be derailed.Okay, back to the issue. I agree wholeheartedly that TFS documentation is really good , but I think it is a bit complicated for many users, definitely lacks some screenshots and a very important tip which is the fact that TFS expects SharePoint configuration database to be called STS_Config_TFS. One other thing that I have found very important (and not emphasized enough in the documentation) is to create and use right user accounts for various steps during the installation process.Having said this , I decided to create a document that describes the installation steps in a more summarized way along with many screenshots of the important steps.