Do you get a Login dialog from your client machine when connecting to SSRS using all but the IP-address?


I’ll be leaving my current client soon after been there for more then a year. As a final test the person at the customer that shadowed me during all this time had to install a complete TFS environment including build server without my help.

And he did it, which I personally take as the best compliment as a coach and consultant leaving the assignment. Anyway my job in this final test was to verify that everything was working as expected.


When I reached the verification part in my tests where I finally tried to connect to SSRS from my client machine I got an Login Dialog every time except when I used the IP-address of the SSRS machine.

As a seasoned installer of TFS and SSRS I thought I had seen all the silly errors you can get configuring SSRS so instantly I got the feeling that something was rotten outside the SSRS box. And there was some issues with the DNS that were outside the control of the SSRS box. After almost 1½ days (I kid you not) I stumbled upon the solution…


Someone had added a <RSWindowsNegotiate/> tag to the authentication types section in the rsreportserver.config file (located in your SSRS installation path). As we’re not using kerberos in this installation a quick delete of the <RSWindowsNegotiate/> tag fixed our issue. This is how our authentication types section looked like after the change.


Now this configuration was probably done by the IT-ops that delivered the machine in the first place but investigation will continue to exclude my fellow shadower from blame.



The build process could not be deserialized due to…


At my current customer we’ve upgraded all our builds from TFS 2008 MSBuild tasks to TFS 2010 WorkFlow Activities. I must say that we’ve gone from several common target-files and per-build specific rsp-files to ONE build process template! That says enough about the power of the new build process in TFS 2010.

Following Microsoft’s recommendation here we’re using one Build Controller for our Default Collection and we’ve centralized our custom activities to one Team Project; lets call it Central.

In the Team Project Central the custom activities we’re using a stored at $/Central/BuildComponents and our Build Controller points out this location as the picture shows below:


In our Custom Activities we have some simple serializble objects that we use as part of our process to store some settings that we need in our build process. An of that would be an XCopyFileWrapper that we use to store 3 string properties:


We then use this wrapper in our Meta Data property in our DefaultTemplate.xaml file like the picture shown below:


Then we added the ParamWrapper as an array of XCopyFileWrapper and add it as an argument to DefaultTemplate.xaml like so:


This way we can have the same DefaultTemplate XCopy files depending on the input we add for each unique build definition in this rather nice centralized GUI for your build definitions:



And then in our DefaultTemplate.xaml we have an foreach loop that loops over our array of XCopyFileWrappers and invokes XCopy! This makes our build definitions really sweet, dynamic and expandable right!

The challenge

So the next Team Project comes along we can call it Project B and they want to use our Build Process. So they branch our build process template into their project and they create a new build definition and then KAPOW!


What happen here! Well my initial thoughts was another lesson I learned previously and blogged about here but specifying the assembly in the DefaultTepmplate.xaml didn’t solve this issue.

The solution

The very simple solution to this problem is that you need to give users READ permissions to your BuildComponents folder in our case the $/Central/BuildComponents folder (another way is to solve this is to give other users READ permissions to the Central Team Project).

That’s it!


  • So if I want to centralize my custom build components then I have to give all users that will use these custom build components READ permission to the folder where the components are stored.
  • Or you could have some sort of deployment mechanism that deploys the build components to every Team Project in the Team Project Collection but then you’ll have to have one Build Controller per Team Project.



My first impressions of the Azure hosted TFS 11


Have you downloaded and created your own Windows 8 image yet? If not you should really do that, trust me you will love it especially if have a touch enabled laptop. You can easily do this in about 30-60 minutes if you follow my post here.

So last week was the big launch week during the Build event and Brian Harry announced a lot of great previews such as the Azure hosted TFS 11. You can read more about it in Brian’s post here.

As I’m a frequent reader of Brian’s blog I received the post immediately in my RSS reader and luckily for me I was quick enough create my own hosted instance of TFS 11 in Azure using Brian’s activation code.

The irony here is that I created my first hosted TFS 11 in Azure from my Android smartphone, talk about cloud power!

Metro style makes an entrance

The very first thing that stroke me was the sense of familiarity in the GUI and then of course it struck me, TFS 11 is Metro styled!

The Team Project overview with a nice Metro look and feel:


A work item overview with a nice Metro look and feel:


The Team concept makes an entrance

There is this long sought concept of a team in TFS 11 that I just started to play around with and it basically means that you can distribute work per team as the team have their “own” schedule, work items, backlog and homepage (landing page). You’ve Always been able to do this your self by manipulating Areas and Iterations but now it’s a first class citizen.

Create a team dialog:


Assignment of areas to a specific team:


Assignment of iterations to a specific team:


Iterations with dates enters

As you can see above my first iteration (Sprint1) has a Start Date and an End Date which is also a really nice feature that I’ve been missing for ever. Thank you Microsoft for providing this in the box!

Then I found this Current Sprint folder in the Shared Queries section of Work Items and my guess is that there will be a job that automatically adjusts the Work Item Queries according to your dates. I haven’t been able to prove this yet, but I will update this section with my findings.

Showing Work Items section in the new Team Explorer:


Search Work Items in Visual Studio makes an entrance

If you read my last post about finding stuff in TFS here you can see that I wanted a nice search for Work Items functionality directly in the IDE and now I have it. Great job! The nice thing about it is if you enter a Work Item ID that you know about Visual Studio will open it for you.

Entering a Work Item ID in the search field will get you that Work Item:


Another great feature is that you can turn your searches directly to a Query with the Open as Query option as shown below.

Open as Query enables you to store your searches as queries:


This is how far my explorations have taken me so far and will create more posts as I go along discovering more features.