A few days in and I have solved the few problems I have had Can apply update Security Update for Windows 10 for x64-based Systems (KB3074683) My system tried to apply the KB3074683 patch a couple of time, rolling it back each time. A search of the forums found the answer to this one. As in the forum post I have an Nvidia video card, in fact it caused the problems during the update, so the fix was to delete the UpdatusUser registry entry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList. ...

I have just done an in place upgrade on my Lenovo W520 from Windows 8.1 to Windows 10. Something I had not tried during the beta programme, sticking to running Windows 10 in VMs (mostly on Azure). I have to say the process was pretty smooth. I only hit one issue, and this was the usual NVidia Optimus problems I saw installing Windows 8 and 8.1. This is what happened With Windows 8.1 running mounted the Windows 10 Enterprise ISO ...

If you are using basic PowerShell scripts as opposed to DSC with Release Management there are a few gotcha’s I have found. You cannot pass parameters Lets look at a sample script that we would like to run via Release Manager param ( $param1 ) write-verbose -verbose "Start" write-verbose -verbose "Got var1 \[$var1\]" write-verbose -verbose "Got param1 \[$param1\]" write-verbose -verbose "End" In Release Manager we have the following vNext workflow ...

With the release of Visual Studio 2015 there are some significant changes to Visual Studio and TFS licensing, you can find the details of Brian Harry’s blog. These changes can make a serious change in what you need to purchase for different roles, so it could well be worth a look.

If you are providing a path to a custom test adaptor such as nUnit or Chutzpah for a TFS/VSO vNext build e.g. $(Build.SourcesDirectory)packages, make sure you have no leading whitespace in the data entry form. If you do have a space you will see an error log like this as the adaptor cannot be found as the command line generated is malformed 2015-07-13T16:11:32.8986514Z Executing the powershell script: C:LRMMSServicesMmsTaskAgentProvisionerToolstasksVSTest1.0.16VSTest.ps1 2015-07-13T16:11:33.0727047Z ##\[debug\]Calling Invoke-VSTest for all test assemblies 2015-07-13T16:11:33.0756512Z Working folder: C:a549426d 2015-07-13T16:11:33.0777083Z Executing C:Program Files (x86)Microsoft Visual Studio 12.0Common7IDECommonExtensionsMicrosoftTestWindowvstest.console.exe "C:a549426dUnitTestDemoWebApp.TestsScriptsmycode.tests.js" /TestAdapterPath: C:a549426dUnitTestDemoChutzpah /logger:trx 2015-07-13T16:11:34.3495987Z Microsoft (R) Test Execution Command Line Tool Version 12.0.30723.0 2015-07-13T16:11:34.3505995Z Copyright (c) Microsoft Corporation. All rights reserved. 2015-07-13T16:11:34.3896000Z ##\[error\]Error: The /TestAdapterPath parameter requires a value, which is path of a location containing custom test adapters. Example: /TestAdapterPath:c:MyCustomAdapters 2015-07-13T16:11:36.5808275Z ##\[error\]Error: The test source file "C:a549426dUnitTestDemoChutzpah" provided was not found. 2015-07-13T16:11:37.0004574Z ##\[error\]VSTest Test Run failed with exit code: 1 2015-07-13T16:11:37.0094570Z ##\[warning\]No results found to publish.

I have been using Pester for some PowerShell tests. From the command prompt all is good, but I kept getting the error ‘module cannot be loaded because scripts is disabled on this system’ when I tried to run them via the Visual Studio Test Explorer I found the solution on StackOverflow, I had forgotten that Visual Studio is 32bit, so you need to set the 32bit execution policy. Opening the default PowerShell command prompt and and setting the policy only effect the 64Bit instance. ...

I have been doing some work on vNext Release Management; I managed to waste a good hour today with a stupid error. In vNext process templates you provide a username and password to be used as the Powershell remoting credentials (in the red box below) My Powershell script also took a parameter username, so this was provided as a custom configuration too (the green box). This was the issue. Not unsurprisingly having two parameters with the same name is a problem. You might get away with it if they are the same value (I did on one stage, which caused more confusion), but if they differ (as mine did in my production stage) the last one set wins, which meant my remote Powershell returned the error ...

I will be speaking at Leeds DevOps on the 21st of July on the subject of Desired State Configuration (DSC). ‘In the Windows world, due to its API based architecture, deployment is too often not as simple as copying an EXE and updating a text configuration file. Desired State Configuration is an attempt to ease the pain we suffer in this space. Providing a set of tools that can be leveraged by any set of deployment tools whether in a Windows or heterogeneous environment. In this session we will look at what DSC is, what resource are available and how to write your own’. ...

Update 21 Aug 2015 - This post contains all the basic information, but there is an improved PowerShell script discussed in Using Release Management vNext templates when you don’t want to use DSC scripts – A better script Many web sites are basically forms over data, so you need to deploy some DB schema and something like a MVC website. Even for this ’bread and butter’ work it is important to have an automated process to avoid human error. Hence the rise in use of release tools to run your DACPAC and MSDeploy packages. ...

With the help of the Release Management team at Microsoft I now have a working REST based automated TFS Build to Release Management pipeline. Previously we were using a TFS automated build and then manually triggering our agent based Release Management pipeline. When we moved to a vNext PS/DSC based RM pipeline I took the chance to automate the link using REST via a PowerShell script to trigger the initial deployment. However, I hit problem, first with a stupid 401 permission error and later with a much stranger 500 internal server error. ...