Yesterday two new ALM Ranger projects shipped, practical guidance on the use of Microsoft Fakes (which I worked on) and for Team Foundation Server (TFS) Disaster Recovery avoidance, planning and step-step recovery walkthroughs for the worst case scenarios.
Also updates for the Coded UI test tooling guide and the TFS Upgrade guide were released..
For more details see below to follow the links to the Ranger blogs and CodePlex to download the materials.
Better Unit Testing with Microsoft Fakes v1 eBook
|Contains practical guidance for migrating to and unit testing with Microsoft Fakes. Walk-throughs allow you to navigate basic and advanced concepts, giving you a comfortable and confident start in implementing Microsoft Fakes as a mocking solution. The eBook PDF format will be complimented with other eReader formats, i.e. MOBI, in an upcoming update as part of our new content and style dog-fooding adventure.
Team Foundation Server Planning Guide v1.1
featuring new sections on Disaster Avoidance and Recovery Planning, allowing you to spot the “smoke” before you are confronted by a “raging fire”.
Test Tooling Guide (Coded UI) v1
Team Foundation Server Upgrade Guide v2.1
We have recently been upgrading our TFS 2012QU1 Lab Management system from SCVMM 2008 to SCVMM 2012 SP1. This has not been the nicest experience, we are preparing at least one joint blog post from Rik, Rob and myself on the joys, yes it did take everyone, a lovely cross skill problem.
We are now in the process of sorting out the state of running environments transferred between the systems. I thought I would start with an easy one, a single non-domain joined VM.
So after the upgrade this VM appeared as a running VM on one of the Hyper-V hosts, I could add it to a new environment, which I did. All appeared OK, the environment was created but Lab Management could not upgrade the Test Agents. If you tried the ‘reinstall agents’ option in Test Manager you got the error ‘cannot install test agent on these machines because another environment is being created using the same machines’
All very confusing and a hunt on the web found nothing on this error.
The fix I found (might be another way) was to
- Connect to the VM via MTM
- Uninstall the TFS 2012 RTM Test Agent.
- Install the TFS 2012 QU1 test agent from the Test Agents ISO (which I had unpacked to network share so I could run the vstf_testagent.exe easily)
- When the install was complete the configuration wizard ran, I set the agent to run as the local administrator and pointed it at one of our test controllers
Once the Test Agent configuration completed and the agent restarted it connected to the test controller and the environment reported itself as being ready.
So one (simple) environment down, plenty more to go
Whilst at the MVP Summit in Redmond last week there were MVP2MVP sessions, these are much like DDD conferences we have in the UK, sessions delivered by MVPs on their experiences and products they offer.
One of the most interesting I saw last week was VS Anywhere. This is an extension to Visual Studio that allows distributed pair programming. This far more than desktop sharing in Skype or Lync, think more like the concurrent document editing in Office 365.
Why not have a look at the promo video or sign up for a free trial. If you have distributed teams, or the need to support a client’s developers remotely might be just the thing.
I recently wrote a post that discussed how the contributor rights had been stripped off areas in TFS 2012 server when QU1 was applied, this included details on the patches to apply the manual steps to resolve the problem.
Well today I found that it is not just in the area security you can see this problem. We found it too in the main source code repository. Again the [Team project]\contributors group was completely missing. I had to re-add it manually. Once this was done all was OK for the users
FYI: You might ask how I missed this before, most of the users on this project had higher levels of rights granted by being members of other groups. It was not until someone was re-assigned between team we noticed.
The Git support was not the only announcement for TFS at the ALM Summit last week. On Brian Harry’s blog you can see more on the new features either in the TFS/VS 2012.2 (Update 2) CTP or planned to appear in later CTPs. The list is long, but the ones that caught my eye beyond that of Git support are
- Microsoft Fakes moves from the Ultimate SKU to Premium, thus making it a ‘free’ option for many corporate developers as they already have that SKU
- Easier customisation of the Kanban board
- Tagging of workitems to allow flexible filtering
- Testing visibility in the web admin pages
… and many other improvements. Have a look at the blog posts, or even better pull down the CTP for a look. Also remember if you want to see new TFS features why not try them via a Team Foundation Server account?
At the ALM Summit yesterday Brian Harry made some major TFS and Visual Studio announcements
- Git support for the hosted visualstudio.com, this allows you to choose if you want a centralised (existing TFS) source control repository or DVSC (using Git). There is also new tools with VS2012 to make using Git easier. Read more as to why Microsoft have made this addition to their offering in his blog. For those of you using on premises TFS you will have have to wait for the next major release of TFS, don’t expect to see this in a quarterly update.
- Also he outline what is to be in Visual Studio 2012 Update 2, loads of tool enhancements.
Have a look the posts to find out more
[Updated 4 Fe 2013 See http://blogs.msdn.com/b/bharry/archive/2013/02/01/hotfixes-for-tfs-2012-update-1-tfs-2012-1.aspx for the latest on this ]
One of the side effects of the problems we had with TFS 2012 QU1 was that when we created a new team within a team project contributors had no rights to the teams default Area. The workaround was that we had to add these rights manually, remembering to add these as you would expect is something you forget all the time, so it would be nice to fix the default.
The solution it turns out is straight forward, any new team gets the area rights inherited from the default team/root of the team project.
- Open the TFS web based control panel
- Select the Team Project Collection
- Select the Team Project
- Select the ‘Areas’
- Select the root node (has the same name as the Team Project)
- Using the drop down menu to the left of the checkbox, select security
- Add the Contributor TFS Group and grant it the following rights
These settings will be used as the template for any new teams created with the Team Project.
[Updated 4 Feb 2013 See http://blogs.msdn.com/b/bharry/archive/2013/02/01/hotfixes-for-tfs-2012-update-1-tfs-2012-1.aspx for the latest on this ]
I posted earlier in the week about my experiences with the post TFS 2012 QU1 hotfix. When I posted I thought we had all our problems sorted, we did for new team projects, but it seems still had an issue for teams on our team projects that were created prior to the upgraded from RTM to QU1. As I said in the past post we got into this position due to trying to upgraded a TPC form RTM to QU1 by detaching from the 2012 RTM server and attaching to a 2012 QU1 server – this is not the recommended route and caused us to suffer the problem the KB2795609 patch addresses.
The problem we still had was follows:
- I have two users a Team Project called ‘BM’ who are in the team called ‘Bad TP’
- Richard (the Team project creator and administrator)
- Fred (a Team Project contributor)
- All is fine for Richard, he can see the team’s product backlog and add items to it.
- Fred can get to the team backlog page in the web client, but cannot see any work items and gets a TF237111 error if they try to add a new work item
- The quick fix was to make Fred a team project administrator, but not a long term solution
- We checked the following rights
- Richard was a member of basically all the groups on the ‘BM’ team project (he was the creator so that was expected), the important ones were [BM\Project administrators, [BM]\contributors and ‘Bad TP’
- Fred was a member of the [BM]\contributors and ‘Bad TP’ team
- The ‘Bad TP’ team had the following permissions
So all these permissions looked OK as you would expect. What I had forgotten was that the team model in TFS 2012 is build around the Area’s hierarchy. This has security permissions too. To check this
- Go to the Admin page for ‘Bad TP’
- Click the “Areas” tab
- Right click the “default area” for the team and select “security”
- We had expect to see some like this
- However there was no entry at all for the Contributors group.
- I added this in and had to explicitly set the four ‘inherited allow‘ permissions to ‘allow’ and everything started to work.
So the problem was that during the problematic upgraded we had managed to strip off all the contributor group entries from area in the existing Team Project. The clue was actually in the TF237111 error as this does mention permissions are the area path.
So now we know we can fix the issue. It should be noted that any new teams created in the team project seem to not get this right applied, so we have to remember to added it when we create a new team.
By default the TFS server uses http://localhost:8080/tfs as it’s Server URL, this is the URL used for internal communication, whereas the Notification Url is the one TFS tells client to communicate to it via. Both these Urls can be changed via the Team Foundation Server Console, but I find you do not usually need to change the Server Url, only the notification one.
I hit a problem recently on a site where if you tried to edit the Team Project Collection Group Membership (via the web or TFS admin console) you got a dialog popping up saying ‘HTTP 400 error’. Now this you have to say looks like a URL/binding issue, the tools cannot find an end point.
Turns out the issue was that there had been a IP addressing schema changes on the network. The different services on the network had been assigned their own IP addresses (as well as the host having its own IP address) e.g. On our TFS server we might have
- 10.0.0.1 – physicalservername.domain.com
- 10.0.1.1 – tfs2012.domain.com
- 10.0.1.2 – sharepoint.domain.com
This is all well end good, but a mistake had been made in the bindings in IIS during the reconfiguration.
The HTTPS bind was correct the hostname matched the IP address, this has to be the case else SSL does not work. However, the HTTP port 8080 should have been bound to all IP Addresses (i.e. no hostname and the * IP address as above). On the site, HTTP was bound to a specific IP address. This was fine if a client connected to http://tfs2012.domain.com:8080/tfs (which resolved to the correct address), but failed for http://loclahost:8080/tfs as the binding did not match.
Once the edit was made to remove the hostname all was OK (the other option would have been to alter the server Url to match)
So problem fixed, the strangest thing is that this issue only appeared to effect setting TPC group membership, everything else was fine.
Brian Harry posted last week about a hotfix for TFS 2012 QU1 (KB2795609). This should not be needed by most people, but as his post points out does fix issues for a few customers. Well we were one of those customers. When upgrading from 2012 RTM to 2012 QU1 we had attempted what with hindsight was an over ambitious hardware migration too. This involved swapping our data tier from a SQL 2012 instance to a new 2012 availability group and merging team project collections from different server as well as applying the QU1. Our migration plan contained some team project collection detach/attach steps hence getting into the area this hotfix addresses.
The end point was we ended up with a QU1 upgraded server, but we could only get users connected if we made them team project administrators, a valid short term solution, but something we needed to fix.
We therefore applied the new KB2795609 patch, but hit a gotcha that you should be aware of
- We ran the patch EXE on our TFS server that was showing the problem.
- This ran without error, taking about 5 minutes
- We tried to connect to the patched TFS server via the web client and VS2012, we could make a connection to TFS but could open any TPCs
- On checking the TFS admin console we saw the TPC was offline and reporting that the servicing had failed (but this had not been reported back via the patch tool)
- We reran the servicing job (via the TFS admin console) but it failed in the core step we saw in the logs
[Error] TF400744: An error occurred while executing the following script: TurnOnRCSI.sql. Failed batch starts on the line 1. Statement line: 1. Script line: 1. Error: 5069 ALTER DATABASE statement failed.
- Our TFS DBs are now stored with a SQL 2012 availability group, during the upgrade to QU1 we had seen problems applying the upgrade unless we removed the DBs from the availability groups. So we removed the tfs_configuration and tfs_[mytpc] from availability groups and re applied the servicing job and all was OK
- Once the servicing of the TPC was completed it went online as expected.
- We then put the DBs back into the availability group
- We could then remove the users from the team project administrators group as their previous rights were working again.
So we now had a patched and working TFS 2012 QU1 server. Lets hope that QU2 is a little smoother and we don’t need the direct help of product group, who I must say have been great in getting this problem addressed. I really like the openness we see in Brian’s blog of both the good and the bad.