The entire DevOps story with the Microsoft Stack is expanding its reach to more and more services and with an ever-growing set of advanced features. During this article, I will cover the benefits and ways to configure Service Endpoints within either Visual Studio Team Services and Team Foundation Service, in order to create a highly coupled ALM story for your apps.

What are Service Endpoints?

Back in the days of Team Foundation Services (2013 and prior to that), everyone was asking for a way to make Release Management expand to other project types rather than .NET and VB/C++. Taken this feedback (along with many other requests) Microsoft rewrote Team Build. Personally, I believe the entire DevOps story using the Microsoft Stack has become more mature than ever and ready to solve the most complex requirements your application has. In order to achieve this type of extensibility, Team Build allows one to add features in two ways: (1) by installing extensions which can either be wrote and uploaded by yourself or by installed from the Visual Studio Marketplace or by (2) taking advantage of the TFX Command Line Interface which allows you to add custom designed tasks. The latter is especially useful when it comes to creating a single-task functionality as an atomic process part of the build or release definition, rather than leverage several tasks individually. This ensures that in the situation of build and release processes which have to do the same tasks over and over again a few times are easily configurable and thus reduces the error-prone nature of a highly-configurable workflow system, such as Team Build.

The beauty of these tasks are that they are not exclusively designed to Microsoft-specific products and services – in fact, most of the tasks which have to deal with external services will specify the external service’s endpoint in the form of a connection setting which is team-project wide. Again, this helps prevent errors related to connection strings and such.

These connection settings are known as Service Endpoints and can be configured from the Settings pane of any team project, both in Visual Studio Team Services and Team Foundation Services, under the Services tab.

Visual Studio Service Endpoints

Read More →

So my previous configuration was this:

  • TFS 2010, running on the same machine with a WSS 3.0
  • SCVMM on the same machine
  • SQL Server 2008 R2 databases on the same machine

Almost everything was running smoothly, except for some people-picker issues that I had on the team project site permission page.

Anyway, I decided to upgrade the TFS server to TFS2012. In order to do that, I first backed-up everything, both using the backup utility that comes along with TFS and also using a mirorring RAID configuration. I did an in-place upgrade for TFS. After upgrading it, everything worked fine. However, since I didn’t like to look and feel of WSS 3.0 sites, I decided to do an in-place upgrade of SharePoint as well, and I upgraded to SharePoint Foundation 2010.

In-place upgrade worked like a charm, except for the fact that I had to manually install a prerequisite because it wouldn’t download it from the web for some perculiar reason. Once the installation was complete, I came across my first error with SharePoint 2010 Foundation, namely a very generic “server error: <help link>”. Unfortunately the help link only suggested I download the updates, so I downloaded and installed SharePoint Foundation 2010 SP1. After installing it, SharePoint services worked, but TFS no longer worked. I found out that the prerequisites installed actually installed .NET Framework 4 as well and that the applicationHost.config file was updated to use specific assemblies from .NET Framework 4 as well. Unfortunately, one of the updated entries from the applicationHost.config file was not correctly updated, meaning that the runtinme version was not mentioned to be v2.0, thus the runtime it was running on was 4.0. I had to manually correct the applicationHost.config file. Afterwards, everything worked like a charm.

This was just a short introduction of some of the problems I ran across when I updated my TFS. Today I came across another strange thing. When I create a new project collection, I apparently cannot create any SharePoint site for the project collection, and thus for any team project. Specifically, I get the following error when I create the project collection: “tf252005: Configuration of SharePoint Products failed with the following error: Server was unable to process request. —> Cannot retrieve the information for application credential key..”

Moreover, I realized that I cannot change any site collection administrators in SharePoint Central Administration either, having returned this error: “No Results matching your search were found.” (which apparently is quite common to SharePoint users).

The things you would want to check out are:

  • check if the TFSService account (whichever that is) is a farm administrator as well
  • check whether the service accounts are domain accounts, rather than local accounts
  • check whether the application pool credentials the TFS’s site collection and Central Administration run under are set to a domain account
  • check if SharePoint 2010 has set an app password (use the stsadm -o setapppassword -password [yourpasswordhere] command)
  • check if SharePoint 2010 Central Administration is configured to search the correct AD forest(s) (use the stsadm -o setproperty -pn peoplepicker-searchadforests -pv “[yourdomain],[yourusername],[yourpassword]” -url http://[yoursharepointserver] command)

I found that the solution for me was to configure the app password. Using peoplepicker-searchadforests command without running the setapppassword command returned this error “Cannot retrieve the information for application credential key”. Moreover, keep in mind to run the setapppassword command on all front web servers before doing anything else, and also keep in mind to use the same password on all front web servers.

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 domaintfslab 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_ROOTCLSIDidHere, 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,