But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Workaround to connect to a TFS Lab Environment from outside a TMG firewall

Whist on the road I have had need to access our Lab Management system via our TMG firewall through which we expose our TFS 2010 for remote users (via SSL). When I load Microsoft Tests Manager (MTM) I can connect to the TFS server, as expected, and go into ‘Lab Center’ mode. I can see my project’s environment and can start, stop and deploy them without issue (all communication routed via our TFS server). However the MTM environment viewer fails to make a connection to the test VMs in the environments.

image

MTM environment viewer can connect to an environment in two ways:

  • Host connection – via the Hyper-V management protocols
  • Guest connection – via a RDP session to the VM’s operating system

From outside our firewall a host connection is not an option as the required ports are not open. So my only option was a guest connection. However, our TMG firewall is set to provide a  RD gateway, effectively a proxy for RDP sessions. You have to configure RDP to use this, and have to authenticate with this gateway prior to authenticating with the actual target remote machine.

image

The problem is MTM does not support the use of TMG RD Gateways.

However there is a solution. If I right click on the VM in MTM Environment Viewer you can launch a standard remote desktop session.

image

If you do this you will be prompted to authenticate correctly.Firstly with your domain account to authenticate with the TMG RD gateway, then for other credentials to the test VM.

So a reasonable workaround, if a VPN or TMG Direct Access is not on option for you.

TF30162: Task "BuildTask" from Group "Build" failed – when creating a team project

When trying to create a new Team Project on my test TFS 2010 basic installation I got the error

Time: 2011-07-05T11:43:36
Module: Engine
Event Description: TF30162: Task "BuildTask" from Group "Build" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: Multiple identities found matching workspace name 'TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC)' and owner name 'BLACKMARBLE\fez'. Please specify one of the following workspace specs:
TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC);BLACKMARBLE\fez
TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC);BLACKMARBLE\fez
Stack Trace:
   at Microsoft.VisualStudio.TeamFoundation.Build.ProjectComponentCreator.ExecuteInternal(ProjectCreationContext context, XmlNode taskXml, Boolean validationOnly)
   at Microsoft.VisualStudio.TeamFoundation.Build.ProjectComponentCreator.Execute(ProjectCreationContext context, XmlNode taskXml)
   at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.TaskExecutor.PerformTask(IProjectComponentCreator componentCreator, ProjectCreationContext context, XmlNode taskXml)
   at Microsoft.VisualStudio.TeamFoundation.ProjectCreationEngine.RunTask(Object taskObj)
--   Inner Exception   --
Exception Message: Multiple identities found matching workspace name 'TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC)' and owner name 'BLACKMARBLE\fez'. Please specify one of the following workspace specs:
TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC);BLACKMARBLE\fez
TYPHOONfbb296e15246421e9fc8d25e9d128512typhoon (VC);BLACKMARBLE\fez (type MultipleWorkspacesFoundException)

Exception Stack Trace:    at Microsoft.TeamFoundation.VersionControl.Client.InternalCache.GetWorkspace(Guid repositoryGuid, String name, String owner)
   at Microsoft.TeamFoundation.VersionControl.Client.InternalCache.Merge(XmlNode xmlOnDisk, InternalWorkspaceConflictInfo[]& removedConflictingWorkspaces)
   at Microsoft.TeamFoundation.VersionControl.Client.InternalCache.Save(XmlNode inputXml, XmlNode outputXml, InternalWorkspaceConflictInfo[]& removedConflictingWorkspaces)
   at Microsoft.TeamFoundation.VersionControl.Client.InternalCacheLoader.SaveConfigIfDirty(InternalCache internalCache, InternalWorkspaceConflictInfo[]& conflictingWorkspaces)
   at Microsoft.TeamFoundation.VersionControl.Client.Workstation.UpdateWorkspaceInfoCache(String key, VersionControlServer sourceControl, String ownerName)
   at Microsoft.TeamFoundation.VersionControl.Client.Workstation.EnsureUpdateWorkspaceInfoCache(VersionControlServer sourceControl, String ownerName, TimeSpan maxAge)
   at Microsoft.TeamFoundation.Build.Controls.VersionControlHelper.CheckinFiles(VersionControlServer versionControl, Dictionary`2 localPathsToServerPaths, String checkinComment)
   at Microsoft.VisualStudio.TeamFoundation.Build.ProjectComponentCreator.CheckinFiles(ProjectCreationContext context, VersionControlServer versionControl, List`1 templates)
   at Microsoft.VisualStudio.TeamFoundation.Build.ProjectComponentCreator.ExecuteInternal(ProjectCreationContext context, XmlNode taskXml, Boolean validationOnly)

This turns out to be another version of the local cache refresh issue I blogged about recently. The issue was I had deleted a couple of team projects on my TFS server via the TFS Administration Console, but my local VS2010 copy did not know as the cache had not been refreshed. Unloading VS2010, reloading it so the local cache was refreshed and then the create new project works fine

Speaking at Microsoft UK next week

I will be speaking at Microsoft UK’s ‘Application Lifecycle Management for Independent Software Vendors’ event next Monday. I am one of four speakers, between us well all address a variety of subjects within ALM

  • Modern Software Delivery: The continuous delivery of high quality software - Colin Bird
  • Driving Quality Throughout the Application Lifecycle - Richard Erwin
  • Extending Testing into the Lab - Richard Fennell
  • The Secrets of Repeatable Success - Adam Gilmore

I believe there are still spaces available

More from the ALM Rangers - Lab Management Guide

The Build Customisation project was not the only ALM Rangers release over the weekend. The Lab Management Guide was also shipped. This provides scenario based and hands-on guidance for the planning, setup, configuration and usage of Visual Studio Lab Management, backed by custom VM Template automation for reference environments.

If you work with Lab Management, or would like, this is well worth a read

 

 

 

 

ALM Ranger’s Build Customization Guidance has shipped

I am really please to say that the first ALM Rangers project I have been involved with, the Build Customization Guidance, has shipped.

The project had the primary goal of delivering scenario based and hands-on lab guidance for the customization and deployment of Team Foundation Build 2010 activities such as versioning, code signing, and branching. You can find details at the Rangers blog,the project table of content or the codeplex site

I have certainly learnt a good deal working on this projects, thanks to everyone who made it such a interesting experience. Hope anyone reading the materials find them as useful.

 

 

 

 

 

Using VSTO to access TFS

Have you ever thought ‘I know that you get the Team ribbon in Excel to manage TFS work items, and I can use Excel to as a SQL/OLAP client to run reports from the TFS warehouse but I want to do more….’?

Have you every considered using VSTO to create an ActionPane that uses the TFS .NET API?

image

In this example I have created an ActionPane that allows you to select a Team Project Collection, a Team Project and then a build definition. Press the button and it lists the builds that have run of this type using the TFS .NET API.

The code can be downloaded here, it is fairly basic, could be more exception handling for connection failures, but shows the principle.

Cannot connect to a Lab Management Environment using the MTM Environment Viewer

Today we had a problem that we could not connect to VMs within a Lab Management environment from the Environment Viewer in MTM. We had composed the environment from VMs independently create and tested on the HyperV host. The plan in the end is to have this as a network isolated environment, but for now it is a private domain that exists on our main LAN.

The first issue we had was that as this was a private domain the various hosts were not registered on our DNS, so we got a DNS lookup error for the VM host names. This is best fixed with network isolation, but for a quick fix we put some entries in a local hosts file on the PC we were using to resolve the name to IP addresses.

The next problem was one of concepts. The environment had been composed by one user (and could access everything via a host connection via Hyper-V, with no local host file fixes), but it was to be used by another user, a tester who was not the owner of the environment (yes again I know we should they should be provisioning their own network isolated version). This mean that a Hyper-V based host connection was not possible, as you have to be the owner to get a host connection.

This meant that the new user had to use a guest connection, a Remote Desktop Connection (RDC) created behind the scenes by the MTM Environment Viewer. This worked for the domain controller (a server OS) but failed for the other three VMs in the environment which were all running Windows 7 with a ‘lost connection to virtual machine error’

image

Turns out the issue was the level of security set for RDC connection in Windows 7. We remoted onto the VMs with the problems using the standard Windows RDC client (not MTM) and set the Allows connections from computers running any version of RD.

image

Once this was done the Environment Viewer could make guest connections and all was good in the world.