Next you use OneGet to install the latest version of Docker.Install-Package -Name docker -ProviderName DockerMsftProvider

At this point, you get an error that "The docker installer requires update KB3176936". What is that about?!? Weird. What you need to do is to run sconfig, then choose option 6 and then A and A to install all updates. It might take a few minutes to download and install updates, so be patient.

This works for Server 2016 in no-desktop installs as well as with the UI.

After this you need to restart your server using UI or using Restart-Computer -Force command.

No you're ready to try to use OneGet to install the latest version of Docker.Install-Package -Name docker -ProviderName DockerMsftProvider

After this you need to restart your server using UI or using Restart-Computer -Force command.

Now, you're ready to use Docker. For example, download a pre-created .NET sample image from the Docker Hub registry and deploy a simple container running a .Net Hello World application by running the following command:

docker run microsoft/sample-dotnet

This command will use Docker run to deploy the .Net container. It will take a few minutes to download the container image though.

There is a great Codeplx project that allows you to update Portal Settings for multiple team projects at the same time: https://features4tfs.codeplex.com/. Whenever you upgrade TFS, and have to re-enable and re-point team projects in your upgraded TFS project collections. If you have a lot of team projects to update, it becomes very tedious task. Feature4TFS tool allows you to update all of those items in one step. Very handy tool. The only issue with this tool is that it does not work with TFS 2015 Update 3 (only Update 2 or earlier.

I have downloaded the source code and updated the solution to make it work with TSF 2015 Update 3. You can download updated solution from https://1drv.ms/f/s!AoNW-kvNWJ9ygsNWPA5LHTJ5fYREXQ. There two files: binaries only and source code and binaries.

Remote PowerShell on Target Machines task in TFS/VSTS is awesome. Easy to use and it works. The only things that bugs me about that task is that I don't see the output of the script on the build console output. Luckily, this can be easily fixed. All you have to do that is to use Write-Verbose -verbose instead of Write-Output command inside your PowerShell script.

I have the following scenario. The client currently has multiple build definitions, which are very similar (not identical, but similar), but have different triggers. For example, nightly builds run more/different tests, while gated or CI builds run less tests and perhaps run less steps. And, they want to combine/merge those build definitions into one. With TFS 2015 you can create multiple triggers on the same build definitions, so we should be able to merge those build definitions into one. The problem is that the build steps must be the same, or we need to figure out the way to update those steps on the fly somehow. Having the same steps is not an option, since we want gated/CI builds to be smaller/faster. So, we need to figure out a way to modify build steps on the fly. Somehow. PowerShell to the rescue.

I wrote a small PowerShell script that checks if the running build is gated build and update certain build variables (in my case, I used a variable called TestFilterCriteriaToSet) in memory, which are later consumed by next steps in the build definition.

Next steps: Save the script. Check it in. Add this script as a step in the build definition. Consume TestFilterCriteriaToSet variable in the next step as such $( TestFilterCriteriaToSet). For example, in Visual Studio Test step. That's it.

I've seen quite a few clients who have SQL Server Enterprise Edition installed, but even though they don't use any of the enterprise features of SQL Server. For example, TFS does not require SQL Server Enterprise Edition, unless of course you need encryption or compression or SQL clusters. It works just fine with SQL Server Standard Edition. So, if you're not using enterprise features, having SQL Server Enterprise Edition installed seems like an overkill. An expensive overkill. Fortunately, this can be fixed. If you need to downgrade SQL Server database from Enterprise Edition to Standard Edition.

First, let's check what edition of SQL Server you're running. To do that open SQL Server Management Studio, connect to your SQL Server and create/run new SQL query:

SELECT @@version

Let's assume that you're running SQL Server Enterprise Edition. To downgrade database from Enterprise Edition to Standard Edition, we need to disable compression on that database. Before we do that we need to make sure we do the following:

BACKUP your database because you know… it's smart thing to do

Make sure that your SQL Server has enough disk space available to accommodate larger database sizes. Remember that uncompressing a database might/will increase the size of the database.

To disable compression, create/run the following script against the database where you want to disable compression.

If any of the tables in the database have compression enabled, this script will generate more SQL scripts as an output. When that happens, copy the generated SQL scripts and execute those scripts against the same database to disable compression. Do that for all the databases that have compression enabled. That's it.

Since Windows 8.1 I have had Hyper-V installed on my machine. As an MVP I do a lot of demo’s so this is wonderful. I used to have a spare machine running Windows 2008 just for this.

One thing I have found difficult to do, is share files between my VM and the host machine. All the solutions I was coming across were just not as simple as I would like. Until now. I came across this Blog which outlines 5 ways to achieve this.

Below is, in my opinion the easiest way to share files between a host and VM.

I have been creating a lot of Build Tasks for the new TFS 2015 Build and Release.

I have discovered a few tricks that were not simple to find. I thought I would Blog about them for my own record and anyone who happens by.

This Blog post makes the assumption that you have already been creating your own build tasks. If not, and you want some background take a look here first.

In this example I created a Release task to perform a DACPAC deployment. The script calls SQLPackage.exe which can do several things. Deploy the changes directly to a Database or generate a Deployment Report, a Drift Report or the SQL that needs to be run to update the target, amongst others.

So I figured I would make my Build Task smart enough to let the end user select which action they would they would like to perform. To do that I need the user to select which action and have that passed into my Powershell script.

The input value that is defined in my task.json file looks like this.

{

"name": "action",

"type": "pickList",

"label": "Action",

"defaultValue": "Publish",

"required": true,

"helpMarkDown": "Select the Action to perform",

"options": {

"Publish": "Publish Changes",

"Script": "Script Changes",

"DeployReport": "Generate Deployment Report"

}

}

The type needs to be “picklist”. I also needed to define options. Each option is comprised of two strings seperated by a semicolon. The string before each semicolon is the value to be returned and the string after the semicolon is the display name. Notice I set one of the values to be the defaultValue.

Once published to TFS the build task inputs will look something like this.

Now the selected value will be passed into my Script and I can change my call to SQLPackage.exe accordingly.

In my career I have created Automated builds for many different technologies. TFS never lets me down. The old XAML build did a good job however the new TFS 2015 Builds are awesome. First of all I love PowerShell, which makes my life much easier. I can just call out to a script sitting in source control or better yet create my own Build Task and upload it to the server.

I recently had to create a build for a development tool that generates documents from various system data. This tool has it’s own editor, version control, release management everything. It’s kind of a closed eco system.

So how do we get the rest of the team involved in it’s builds and deployments. How do I trigger a build and have this system drop a deployable package for me, that I can deploy to different environments without having to ask the developers? Letting QA be responsible for their own environment.

After talking with an expert in this tool. It turns out, it also has an automation component. The developers can write scripts to perform builds and deployments. However we want this to be part of a larger eco system with our other applications.

It was decided that we would create a file share on the network where I could drop a file to let the other system know I wanted a new build dropped. This way TFS would still generate a build number the testers can deploy to the QA environment and reference from their test plan so we get the full end to end traceability.

So I wrote a script that would drop a file (Build.txt) in a known location on the network. Said products automation tool watches for my file and triggers a script to perform a build when it sees it and then drops that build package back for me to turn into a build artifact. I will put the build number in this file so the other system can use that as a label in it’s own Version Control system.

Then the build waits and watches for a file named BuildComplete.txt to be placed back in that working folder. When my build sees it I know the built package is there and I can create a build artifact. By the way the BuildComplete.txt either contains the word successful or an error log if something went wrong. I will pull that out and toss it up into the build console.

My build has two tasks one to Drop the file that triggers the other system and one to create a build artifact. The second one is already built into TFS “Copy and Publish Build Artifacts”. The first step is one Powershell script. See below with Comments:

The Powershell script takes two arguments The WorkingFolder and a timeout.

The comments in line explain how it works.

1:param()

2:

3:#This is how we do parameters in a custom build task

4: Trace-VstsEnteringInvocation $MyInvocation

5: try {

6: Import-VstsLocStrings "$PSScriptRoot\Task.json"

7: [int32]$timeout = Get-VstsInput -Name TimeOut

8: [string]$WorkingFolder = Get-VstsInput -Name WorkingFolder

9: }

10: finally

11: {

12: Trace-VstsLeavingInvocation $MyInvocation

13: }

14:

15:#Start the Timer at zero

16: $timesofar = 0

17:#This is the file we are looking for to know the package is complete