First of all, if you’re new to Application Insights, check out this link and this link too. In a word, Application Insights offers you deep insight data on your application performance and usage. And it rocks while doing that, too! :)

Application Insights is since last week no longer under preview. However, if you’re trying out Application Insights right now, you have obviously already found out that the corresponding NuGet package is still in beta (version 0.7.x.x) and, should you have tried out Application Insights for a longer time now, you’ve probably realized that there are a lot of changes in the configuration schema too.

One of the things I don’t like about the new schema is the lack of a special component ID (which basically defines a specific Application Insights entry = application) for debugging. This also means that when you debug, you’ll get your debug data mixed with the production data, which is bad.

However, even if the guys at Application Insights (which I’ve just met at Build 2014) have removed this one particular feature (which, I admit, didn’t work out for me as I expected), they’ve added tons of new features which are worth checking out.

Now, to the post subject. How do you collect usage and performance data if you have different cloud projects (for different environments, such as a staging and a production environment) and a single code-base (meaning, a single project containing your code). The question might be tricky, since you’ll have to add the .config file directly inside your project that contains your code (for example, the web project), rather than the cloud project.

For such a scenario, here’s what I did. I created a new folder inside the project folder (e.g. ‘AppInsightsConfigs’) which contains my applicationinsights.config files that correspond for each environment. This basically gives me the option to define a config file for the staging deplyoment (ApplicationInsights.Debug.config) and another file for the production deployment (Applicationinsights.Release.config). Obviously, each .config file has its own ComponentId and ComponentName settings.

What I do next is to create either a pre-build or post-build command that contains this simple command line:

copy  “$(ProjectDir)AppInsightsConfigsApplicationInsights.$(ConfigurationName).config” “$(TargetDir)ApplicationInsights.config”

This command simply writes either the .Debug.config or .Release.config over your output directory, which works fine for me since I want to have the Debug version in a staging enviroment (for remote-debugging scenarios especially) and a Release version in the production environment (who would add the debugging symbols and loose the code optimization feature inside production?!).

One thing worth mentioning out is that if you rung this as a pre-build or post-build command, you will not get the right version of the .config file unless you exclude or change the name of the ApplicationInsights.config file the Visual Studio Application Insights extension automatically adds (or the one you’ve added manually). Moreover, if you decide to run the command as a pre-build command, you also have the option of replacing the $(TargetDir) macro with the $(ProjectDir) macro, which will copy the desired configuration file over your original ApplicationInsights.config from the root directory, so that no exclude or rename is necessary. However, in this case please keep in mind that any change you do inside your ApplicationInsights.config file will be lost the moment you run a build command. I also don’t recommend you to run the command as a post-build command with the $(ProjectDir) macro as the destination folder, because you’ll need to build you project twice for the command to work and I’m sure you’ll almost certainly forget to do so :).


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.