Lab Management is a great piece of software that takes great use of virtual machines in order to create virtual labs where you, your team and your testers can test out an application in a clean environment. Lab Management integrates with Team Foundation Server 2010 and thus enables you to create the lab environements out of Visual Studio with ease.
So I started upgrading our TFS 2008 with the not-so-brand-new TFS 2010, on a completely different new machine. Besides the hassle regarding upgrading the databases, prepairing the user accounts, the shared folders, the services etc. I got to the point where I had everything working (except SharePoint Services 3 integration; will talk about that later) and was getting ready to install the Lab Management stuff.
Before starting of with the real subject of this post, let me tell you, in short, the environment topology: Active Direcotory with several domain controllers running WS2003, one WS2008R2 machine running two instanced of SQL Server 2008 R2 (one for TFS 2010, one for SCVMM 2008 R2 –> it is important not to use the first instance for SCVMM), System Center Virtual Machine Manager 2008 R2, Team Foundation Server 2010 and SharePoint Services 3. Also, for running SCVMM that machine has the Hyper-V role activated.
First things are first, so I installed the Hyper-V role on my Windows Server 2008 R2 machine and afterwars System Center Virtual Machine Manager 2008 R2, because Lab Management works with SCVMM. After putting everything up and creating the SCVMM configuration to work with Hyper-V, I got the the final (and, in the end, not so final after all) point where I would configure the Lab Management in Team Foundation Server Admin Console.
So I put in the machine’s fully qualified domain name and click Test, but then suddenty a dialog box pops up requesting a user account. So I enter the user account I created for the Lab Management stuff (TFSLAB), insert the password and click Test. The credentials are fine, so I click Ok. Boom! I get this error:
TF260078: Team Foundation Server could not connect to the System Center Virtual Machine Manager Server: servername. More information for administrator: You cannot contact the Virtual Machine Manager server. The credentials provided have insufficient privileges on servername.
Ensure that your account has access to the Virtual Machine Manager server on servername, and then try the operation again.
Right. Now what? I double-check the password. Password’s fine. I double-check the username. Username’s fine. Obsiously this doesn’t have anything to do with the credentials. I check the Configuring Lab Management for the First TIme article on MSDN (here). Scroll down the site, and come across a Troubleshooting link. Click the link and come across a short text that basically tells me to check some blog or the forums. Check the blog. Nothing there about 260078. Check the forums. No similar error.
Obsiously, I’m special! Search the Web some more. After about an hour or so, I decide to post in the MSDN forums: maybe a wise man does have an answer after all. Post the error in the forum. Wait for two hours. I’m notified on my phone that someone has replied to my post. Don’t really have the time to check the post in that moment, so I’ll leave it for a couple of minutes, but than another notification alerts me! Surely I must have found gold! Two replies one after the other? Problem is as good as solved. Check the thread and find out only that someone else if trying to figure out the same thing.
Ok, enough with the introductory chit-chat.
What I did:
1. (don’t really know if it helps, or not, but this was required for similar errors) Added TFSLAB (and eventually TFSSERVICE – the account Team Foundation Service runs under) to these AD groups Pre-Windows 2000 Compatible Accessand Windows Authorization Access Group.
I tried running the Lab Configuration again, but still no luck.
2. Changed the accounts the Virtual Machine Manager and SQL Server (this is absolutely required) and Virtual Machine Agent run under to the TFSLAB account. Restart the services, but Virtual Machine Agent doesn’t start. The Service Manager posts some extremely generic error message (The Virtual Machine Manager Agent service terminated with service-specific error %%-2147217405.), so I check the Event Viewer and find this: The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {9C38ED61-D565-4728-AEEE-C80952F0ECDE} and APPID {5364ED0E-493F-4B16-9DBF-AE486CF22660} to the user domain\tfslab SID (S-1-5-21-1004336348-790525478-1801674531-15332) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
As the message suggest, VMM Agent cannot start because of a component. My suspicion is that TFSLAB doesn’t have priviledges to that component, so I immediately open Component Services. However, the components are only listed by their friendly name, so I open the registry editor in order to find the component’s friendly name: Virtual Disk Service Loader. Sounds promising. I go back to Component Services, search for Virtual Disk Service Loader, right-click it in order to configure the security permission and find that everything is grayed out, as it were disabled. I check whether DCOM is enabled (right-click on the computer in the Component Services list) and find that it is.
Search online books some more and find that for Windows Server 2008 R2 Microsoft, for some “security” reason decided that Administrators, no matter their level of godness, are no longer permitted to configure anything in the Component Services and instead, a user called TrustedInstaller has acces (not even the godlike SYSTEM accound is no longer permitted acces there –> WHY?!).
Some article on the Web stated that going back to registry editor, back to HKEY_CURRENT_ROOT\CLSID\idHere, clicking on the permissions option in the CLSID’s context menu (replace CLSID with that long ID your’s looking for 9C38…) and configuring the FULL CONTROL permission for the Administrator should solve the problem. However, it didn’t. What I did though (as a temporary resort, because it was getting frustrating) was to add the TFSLAB account to the local admin accounts group.
So, in conclusion:
- add the TFSLAB account to the local admins
- add TFSLAB to the AD built-in groups I mentioned earlier
- run SQL Server instance service with the TFSLAB account
- run the VMM service with the TFSLAB account
and you should have everything up and running (after finishing the configuration, of course).
Till next time,
A
Alex's space 