Windows 8 store applications need to be built on a TFS build agent running in interactive mode if you wish to run any tests. So whilst rebuilding all our build systems I decided to try to have all the agents running interactive. As we tend to run one agent per VM this was not going to be a major issue I thought.
However, whilst testing we found that any of our builds that use the Typemock build activities failed when the build agent was running interactive, but work perfectly when it was running as a service. The error was
Exception Message: Access to the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TypeMock’ is denied. (type UnauthorizedAccessException)
Exception Stack Trace: at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
at Microsoft.Win32.RegistryKey.CreateSubKeyInternal(String subkey, RegistryKeyPermissionCheck permissionCheck, Object registrySecurityObj, RegistryOptions registryOptions)
at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey, RegistryKeyPermissionCheck permissionCheck)
at Configuration.RegistryAccess.CreateSubKey(RegistryKey reg, String subkey)
at TypeMock.Deploy.AutoDeployTypeMock.Deploy(String rootDirectory)
at TypeMock.CLI.Common.TypeMockRegisterInfo..ctor() at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
So the issue was registry access. Irrespective of whether running interactive or as a service I used the same domain service account, which was a local admin on the build agent. The only thing that changed as the mode of running.
After some thought I focused on UAC being the problem, but disabling this did not seem to fix the issue. I was stuck or so I thought.
However, Robert Hancock unknown to me, was suffering a similar problem with a TFS build that included a post build event that was failing to xcopy a Biztalk custom functoid DLL to ‘Program Files’. He kept getting an ‘exit code 4 access denied’ error when the build agent was running interactive. Turns out the solution he found on Daniel Petri Blog also fixed my issues as they were both UAC/desktop interaction related.
The solution was to create a group policy for the build agent VMs that set the following
- User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode – Set its value to Elevate without prompting.
- User Account Control: Detect application installations and prompt for elevation – Set its value to Disabled.
- User Account Control: Only elevate UIAccess applications that are installed in secure locations – Set its value to Disabled.
- User Account Control: Run all administrators in Admin Approval Mode – Set its value to Disabled.
Once this GPO was pushed out to the build agent VMs and they were rebooted my Typemock based build and Robert Biztalk builds all worked as expected
I have been trying to script the installation of all the tools and SDKs we need on our TFS Build Agent VMs. This included BizTalk. A quick check on MSDN showed the setup command line parameter I need to install the build components was
So I ran this via my VMs setup PowerShell script, all appeared OK, but when I tried a build I got the error
C:\Program Files (x86)\MSBuild\Microsoft\BizTalk\BizTalkCommon.targets (189): The “AddBizTalkHiddenReferences” task failed unexpectedly.
System.ArgumentNullException: Value cannot be null.
Parameter name: path1
at System.IO.Path.Combine(String path1, String path2)
at Microsoft.VisualStudio.BizTalkProject.Base.HiddenReferencesHelper.GetHiddenReferencesNotAdded(IList`1 projectReferences)
The strange thing is, if I run the BizTalk installer via the UI and select just the ‘Project Build Components’ my build did not give this error.
On checking the Biztalk setup logs I saw that the UI based install does not run
Once this change was made to my PowerShell script the TFS build worked OK
Had an interesting issue during and upgrade from TFS 2012 to 2013.2 today. The upgrade of the files proceeded as expect and the wizard ran. It picked up the correct Data Tier, found the tfs_configuration Db and I was able to fill in the service account details.
However, when I got to the reporting section it found the report server URLs, but when it tried to find the tfs_warehouse DB it seemed to lock up, though the test of the SQL instance on the same page worked OK.
In the end I used task manager to kill the config wizard.
I then re-ran the wizard, switching off the reporting. This time it got to the verification step, but seemed to hang again. After a very long wait it came back with an error that the account being using to do the upgrade did not have SysAdmin rights on the SQL instance.
On checking this turned out to be true, the user’s rights had been removed since the system was originally installed by a DBA. Once the rights were re-added the upgrade proceed perfectly; though interestingly the first page where you confirm the tfs_configuration DB now also had a check box about Always On, which it had not before.
So the strange things was not that it failed, I would expect that, but that any of the wizard worked at all. I would have expected a failure to even find the tfs_configuration DB at the start of the wizard. Not have to wait until the verification (or reporting) step
Having installed my TFS Alert DSL today onto a client’s TFS 2013.2, I have realised some of the documentation was a little unclear. So I have have just updated the download page to provide an easy means to get
- The actual DSL implementation (without rebuilding the source)
- A command line tool to create an event source in case you want log to the Windows event log
Hope this helps