With Windows 10 we’ve gotten a lot of nice little features which help us modifying the theme. There is however 1 option which the team hasn’t implemented (yet). The option to select different wallpapers for all of your connected displays.

I’m working with a triple monitor setup at home and at work most of the time with a dual or also a triple setup. Of course I don’t really need different wallpapers on all of my monitors, but it’s a nice feature.

Luckily we are still able to do this, using the ‘old’ control panel pages which are still available in Windows 10. If you type in the following command inside a Windows Explorer address bar or the Run command window you’ll be able to get there.

control /name Microsoft.Personalization /page pageWallpaper


On this screen you are still able to select your wallpaper for every connected display.


Just a little tip, hope it helps.

While I was setting up a VPN connection to my Azure Virtual Network I wanted to uncheck the option to use the Default Gateway of the connected network. Normally you’d do this by clicking on the `Properties` button of the selected protocol.


However, there appears to be a bug in Windows 10 and VPN connections for this button which causes the Properties window not to appear.

I have solved this with the help of Todorovic Dragan’s post about this matter. Over there he states you can change the `Default Gateway` setting manually.

Just navigate to the folder `C:\Users\[YourUsername]\AppData\Roaming\Microsoft\Network\Connections\Pbk` and open the file rasphone.pbk file in your favourite text editory.

This file contains all configuration settings of your dial-in connections, like VPN’s. Search for the configuration block of your connection. For me it’s [janhome_manual] and change the option IpPrioritizeRemote to 0.

Changing this setting will disable the checkbox for using the gateway of the remote network.

One of the reasons for me to create an Azure virtual network is being able to connect to my development machines in the Cloud from anywhere, without exposing them to the public. In order to do so, all machines have to be added to the virtual network. You also have to select the option to set up a point-to-site VPN connection to the virtual network.

Setting up a point-to-site VPN connection to an Azure virtual network is documented quite well on the Azure documentation pages. Still, I have come across a couple of problems which I’d like to share.

The first problem I had was executing the `makecert` program via the Visual Studio Command Prompt on my machine. This tool is really useful when creating a self-signed certificate.

d:\Temp\vpnblog>makecert -sky exchange -r -n "CN=RootJanHome" -pe -a sha1 -len 2048 -ss My "RootJanHome.cer"
'makecert' is not recognized as an internal or external command, operable program or batch file.

Apparently the `makecert` program isn’t installed by default on your machine when installing Visual Studio 2015. You’ll have to install the Windows 10 SDK and tools in order to get it. To fix it, just Modify your Visual Studio installation and select the option which installs these bits.


It takes some time, but when the installer is finished, you can start creating your certificates. First you’ll need a root certificate which will has to be uploaded to your virtual network.

# Root certificate
d:\Temp\vpn>makecert -sky exchange -r -n "CN=RootJanHome" -pe -a sha1 -len 2048 -ss My "RootJanHome.cer"

# Client certificate
d:\Temp\vpn>makecert -n "CN=ClientJanHomeUbook" -pe -sky exchange -m 96 -ss My -in "RootJanHome" -is my -a sha1

The second statement creates a client certificate, using the former created root certificate, which will be used for authentication when setting up the VPN.

These certificates will get stored in the `Current User/Personal` store.


I’ve created several other client certificates for my other machines as well which have to be exported in order to install them on the corresponding clients.


Make sure you are also exporting the private key of the certificates, otherwise they will be quite useless for authentication.

After having created all necessary certificates it’s time to upload the self-signed root certificate to your Azure virtual network.


The management portal provides a nice button to upload these type of certificates.

Having finished this initial setup you are ready to download the VPN client from the virtual network dashboard. Select the correct one matching your bits of the OS.


This application, which isn’t signed, creates a VPN connection for you which, in theory, you should be able to use.


Pressing the `Connect` button for this VPN connection will prompt you with a pop-up having another `Connect` button.


When pressing the `Connect` button a warning will be shown telling you the assembly `cmroute.dll` wants to update the routing table. As this software came from Microsoft I’d say it’s fairly safe to let the assembly modify your routes.


Pressing the `Continue` button will show the next problem I encountered. The connection can’t be established:


A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798)

When this happens, it’s possible there are some errors with your certificates. In my case I am sure the certificates are correct, so something else is up.

I’m not sure why this error occurs, but do have a solution: Create the VPN connection by yourself!

The tool already created a VPN connection which has the gateway address in it.


Copy these settings to a new VPN connection, for example janhome_manual.


Make sure the Security settings of this VPN connections uses a Smart Card for authentication.


You can also specify in the IPv4 properties not using the gateway of the virtual network. This is especially useful if you still want to use the internet when connected to the VPN.

If you have set this up correctly a connection can be made to the virtual network using your client certificate.


The first time I was connecting to the virtual network I received the following error message:

The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.

The reason for this error was on my behalf. While troubleshooting the problems I had, I had created and uploaded a new root certificate, but hadn’t uploaded this to the virtual network yet.

I do hope you are able to set up a VPN connection with a bit more ease as I had.

Nowadays it’s possible to create virtual networks within your Azure subscription. This can be very useful for managing your Azure resources within a specific network or setting up a point-to-site or site-to-site connection to expand your current on-premise network.

To me creating a virtual network sounds like a great way to manage my virtual machines and services for development purposes which I’m running within Azure. It will also let me connect to them without exposing stuff to the public internet. I can imagine a virtual network can also be useful for adding multiple build agents, private nuget repositories, a source control server, domain controller, DNS, etc. By moving all of your machines to the cloud, the only thing you’ll need on-premise is a proper router for connecting to the cloud.

In order to create a new virtual network, you’ll have to navigate to the management portal. This feature is available within the classic and new portal. As I prefer the classic portal all screenshots in this post are from within this portal.

The management portal has a menu option called Networks from where you can manage your virtual networks. The image below shows a virtual network called janhome.


If you want to create a new virtual network by yourself, just select the option from the New menu.


The first thing you are asked to fill out is the name and location of the new virtual network. For the sake of this post I’ll add a second network called jan_home.


Normally you’ll choose a datacenter location nearby, for me this is West Europe.

The second step will give you an opportunity to specify a DNS server and the type of VPN you might want to use for this virtual network.


I don’t have any DNS servers set up at the moment, so this will stay empty.

As I want to use this network to connect to my Azure machines via VPN, the option Configure a point-to-site VPN option has to be checked. If all company servers are migrated to the cloud, the point-to-site option is also a great solution for remote workers. With this point-to-site option they’ll be able to securely connect with the company network from everywhere.

If you want your on-premise network (site) to connect to the machines within the virtual network (site), you’ll have to check the site-to-site VPN option. This will make your current network somewhat of a hybrid-network, both in the cloud and on-premise. To me, this looks like the preferred way of working with a virtual network. It gives you both the benefits of having local servers and the scalability + services of the Azure cloud. For a site-to-site VPN connection you do need a compatible internet router in order to set up the secure connection. I’d like to use this option, but the router of my internet provider isn’t ready to set up a VPN.

The next step in the wizard gives you an option to create extra subnets if you want/need them. I’m not an IT Pro guy, so I don’t see any reason to add extra complexity to my simple network, but I’m sure others will disagree on this matter.

The last step gives you an option to add the gateway subnet.


For my simple network I haven’t changed the default options, but you can if you want to.

Creating this virtual network will take some time.
Once the virtual network is created you can start adding virtual machines to it. The region dropdown is extended with the created virtual network(s).


A virtual network works much like the (deprecated) affinity groups. It will make sure all your machines are deployed within 1 datacenter to maintain the least possible latency between the machines.

Next post will be about setting up a VPN to this Azure virtual network from my development machine, in order to manage all my development virtual machines in Azure.

In my previous post I’ve talked about creating new projects in Octopus Deploy in order to deploy projects to different environments. In this post I’ll explain a bit on how to create Octopus Deploy packages for your Visual Studio projects via Teamcity.

To enable packaging for Octopus you’ll need to include the Octopack NuGet package to the project you are packaging. In my case this will be the Worker project since I’m only working with Microsoft Azure solutions at the moment.

Once this package is successfully installed you will have to modify the project file also to enforce adding files in the Octopus package.

The following line will have to be added to the propertygroup of your build configuration


For reference, a complete propertygroup:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

Your project is now ready to start packing. In my case I had to add a nuspec file also, because the worker project contained an application which has to be deployed to on an Azure Cloud Service.

A nuspec file for Octopus Deploy looks exactly the same as one you would create for NuGet itself. Mine looks like this:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
		<authors>Jan de Vries</authors>
		<owners>Jan de Vries</owners>
		<title>Jan de Vries his cool product</title>
		<description>The cool product used by the Jan de Vries software.</description>
		<copyright>Jan de Vries 2015</copyright>
		<!-- Add the files (.cscfg, .csdef) from your Azure CS project to the root of your solution  -->
		<file src="..\MyCustomer.Azure.MyProduct\ServiceDefinition.csdef" />
		<file src="..\MyCustomer.Azure.MyProduct\ServiceConfiguration.Dev.cscfg" />
		<file src="..\MyCustomer.Azure.MyProduct\ServiceConfiguration.Acc.cscfg" />
		<file src="..\MyCustomer.Azure.MyProduct\ServiceConfiguration.Prod.cscfg" />
		<!-- Add the files .wadcfg file to the root to get the diagnostics working  -->
		<file src="..\MyCustomer.Azure.MyProduct\MyCustomer.Azure.MyProduct.WorkerContent\*.wadcfg" />
		<file src="..\MyCustomer.Azure.MyProduct\MyCustomer.Azure.MyProduct.WorkerContent\*.wadcfgx" />
		<!-- Add the service/console application to the package -->
		<file src="..\MyCustomer.Azure.MyProduct.Worker\Application\*.dll" target="Application"/>
		<file src="..\MyCustomer.Azure.MyProduct.Worker\Application\*.exe" target="Application"/>
		<file src="..\MyCustomer.Azure.MyProduct.Worker\Application\*.config" target="Application"/>

Keep in mind, the nuspec file name should be exactly the same as the project name. If you fail to do so, the file will be ignored.

This is all you’ll have to to in Visual Studio. You can of course create your packages via the commandline, but it’s better to let Teamcity handle this.

In order to use Octopus Deploy from within Teamcity you’ll need the teamcity plugin which can be downloaded from the Octopus Deploy download page. After installing the plugin, three new runner type features will be available when creating a new build step.


I’m just using the Create release option, since this one is also capable of deploying a release to an environment. We don’t use the Promote release option as we want this to be a conscious, manual, step in the process.

There’s also a new section in the Visual Studio (sln) runner type which enables you to run OctoPack on the solution/projects.


If you want to use this for a build step, just enable the checkbox and be sure to set a proper build number in the OctoPack package version box.

On the image below you can check out the settings I’m using to create a new release with Octopus Deploy.


As you can see, I’ve added an additional command line argument telling the deployment timeout to be set on 30 minutes.


This is because the current builds take about 12 to 17 minutes to be deployed to a Cloud Service and the default (configured) Teamcity build timeout is set lower amount. Therefore all deployment builds will be marked as failed if you don’t add this argument.

I’ve also marked the Show deployment progress. This will make sure all Octopus Deploy output will get printed into Teamcity. If something fails, you’ll be able to check it out within Teamcity, assign someone to the failed build and he/she will have all information necessary to fix the failure.

Well, that’s about it on creating a nice starter continuous deployment environment. You can expand this in a way of your liking of course, but these are the basics.