Failed to Start Docker Service on Windows 10 AE

So, pretty much the first thing I did when the Windows 10 Anniversary Edition was installed onto my primary development machine was to installer the Windows Container Service and Docker on it.

I used the Windows Containers on Windows 10 Quick start guide to perform the installation. This is the same method I’d been using on my secondary development machine (running Insider Preview builds) since it was first available in build 14372.

Note: The Windows Containers on Windows 10 Quick Start guide doesn’t mention the Anniversary Edition specifically, but the method still works.

Unfortunately though, this time it didn’t work. When I attempted to start the Docker Service I received the error:

start-service : Failed to start service 'Docker Engine (docker)'.


So, after a bit of digging around I found the following error in the Windows Event Log in the Application logs:


Basically what this was telling me was that the Docker Daemon couldn’t create the new virtual network adapter that it needed – because it already existed. So a quick run of Get-NetAdapter and I found that the docker adapter “vEthernet (HNS Internal)” already existed:


So what I needed to do was uninstall this adapter so that the Docker Service could recreate it. I’m not actually aware of a command line method of doing (except for using DevCon) so I had to resort to using Device Manager:


You’ll need to use the output of the Get-NetAdapter to find he right adapter uninstall. Once it has been uninstalled you should be able to start the service again:


This time the service should start successfully. A quick call to docker ps shows that the container service is indeed working. So now I can get onto the process pulling down the base container images.

Hopefully if anyone else runs into this problem in Windows 10 AE this will help them resolve it.





Windows 10 Build 10586 – PowerShell Problems

PowerShell Direct Broken

Unfortunately my Sunday afternoon of planned study has been slightly derailed, as last night I just upgraded my primary work machine to Windows 10 Build 10586. Everything went fine with the upgrade and seemed to be working just perfectly. However, when I started to get to work with my Hyper-V lab machines today I ran into a significant bug with PowerShell on this build:

PowerShell Direct no longer connects to any of my VMs. It pauses for approximately 30 seconds and then reports a rather mysterious error:

An error has occurred which Windows PowerShell cannot handle. A remote session might have ended.
But it was working yesterday!

But it was working yesterday!

Passing credentials that are correct or incorrect for the VM have no effect – the error message is always the same.

Fortunately connecting via plain old PowerShell Remoting still works fine, but I have many scripts that are dependent on using PowerShell Direct that are no longer functioning – including my LabBuilder project, which I use every day to get my Hyper-V lab up and running for my studies.

I’ve logged this issue in Windows Connect right here. So if you’re being affected by this issue please go and vote it up to see if it can’t be resolved quickly. This was a fantastic feature that was only added recently and it is sad to see it being broken so soon!

Encrypting Credentials in DSC MOF Files

Anyone who has put properly encrypted credentials in DSC configuration files knows that they need to be encrypted using a certificate that was issued to the Node that will be reading the configuration. This is usually fairly straight forward, but some care needs to be taken when generating the certificate for the Node to use.

I have an automated process designed for my Lab where any new VM’s that get built are automatically issued with a self-signed certificate that will be used to encrypt the DSC config files. This certificate is automatically downloaded to the host (via PowerShell Direct of course) and then used to encrypt the DSC config files for that node. All completely seamless and automatic. Until build 10586, when these certificates are no longer able to be used to encrypt the MOF file. Instead I get this error:

ConvertTo-MOFInstance : System.ArgumentException error processing property 'Password' OF TYPE 'MSFT_Credential': Certificate '8E474886A6AA72859BDC3C2FBEEFAAD7E089A5DD' cannot be used for encryption. Encryption certificates 
must contain the Data Encipherment or Key Encipherment key usage, and include the Document Encryption Enhanced Key Usage (

Ok, so this isn’t the end of the world and it is pretty clear what has changed here. After looking at my existing self-signed certificates they didn’t include the EKU (Enhanced Key Usage) of Document Encrpytion.

My previous certificates - now useless because the Document Encryption EKU is missing.

My previous certificates – now useless because the Document Encryption EKU is missing.

It seems this is now required to encrypt credentials in MOF Files. I guess this makes sense and I’m sure not that many people are going to run into the problem. But in case you do, you’ll need to reissue these certificates including the following EKU:

Document Encryption (

You also need to ensure the Key Usage contains either Data Encipherment or Key Encipherment.

Finally, I have one strong recommendation related to the topic of encrypting DSC credentials: Don’t use the built in PowerShell cmdlet New-SelfSignedCertificate to create self-signed certificates for this purpose. It creates certificates that are not compatible for other reasons (I won’t go into detail but you can look the issue up I’m sure). Instead I strongly recommend you use this script on MSDN Script Center.

Decryption Failed

Update 2015-12-18: Installing Windows Management Framework (WMF) 5.0 RTM on the DSC node resolves the Decryption Failed error described below. So if you’re experiencing this issue, install this update on any DSC nodes experiencing this problem.

Edit: Karl in his comment on this post mentioned a problem he was having where the DSC node was failing to decrypt any credentials provided in DSC MOF files created on the build 10586. He was receiving a Dercyption Failed error when the MOF was being applied to the node:


I hadn’t noticed this issue because I hadn’t been working on DSC for a week, but when I tried to apply a rebuilt MOF file I experienced the same issue.

It was also reported that the password property format of the MSFT_Credential object in the MOF seems to have changed in one of the recent releases from:

instance of MSFT_Credential as $MSFT_Credential2ref
  Password = "...Base64Password...";
  UserName = "LABBUILDER.COM\\Administrator";


instance of MSFT_Credential as $MSFT_Credential2ref
  Password = "-----BEGIN CMS-----\n...base64Password...\n-----END CMS-----";
  UserName = "LABBUILDER.COM\\Administrator";

After a full day of investigating this issue, I can confirm it has been caused by a change the Microsoft has made in the PSDesiredStateConfigration module supplied with this build (specifically the Get-EncryptedPassword function, in case you’re interested). This issue has been reported to Microsoft on PowerShell Connect here. Please go an upvote it if you’re having this problem (even if you’re not). Karl has posted this issue on Stack Overflow.

In the mean time I have posted a work around (roll back to a previous version of the PSDesiredStateConfiguration module on the Stack Overflow page) – so if you want to work around this problem, go and take a look.

DSC is Practically Broken in 10586

Update: After finishing this last post I’ve run into some critical problems with DSC on build 10586. Specifically, when I build a DSC configuration on this machine and include the PSDesiredStateConfiguration resource (by way of Import-DSCResource cmdlet) the MOF file that is created references a 1.0 version of the module – which doesn’t exist:

Version 1.0 isn't on the machine!

Version 1.0 isn’t on the machine!

Applying the MOF file to any node immediately throws an error because of course this module doesn’t exist (1.1 is the earliest version of this module that are on any of the nodes).

However, if I force the module version to 1.1 in the Import-DSCResource cmdlet then the MOF file that is created has the correct module version and can be applied to the node without any issue:

Forcing the Module Version.

Forcing the Module Version.

But of course going around all my config files and forcing the module version to 1.1 is a very unsatisfactory solution. Also, I’m not sure if it is just the PSDesiredStateConfiguration resource that has this problem or all modules. I haven’t had the time to investigate this further yet.

If you are suffering from any of these issues in build 10586, please let me know.

Thanks for reading!

NAP, DHCP and Windows 10 – Nope!

I just spent a good hour trying to figure out why my Windows 10 clients were not getting assigned an IP Address from my DHCP servers once I enabled NAP integration on the scope. The reason of course is obvious: NAP was deprecated in Windows Server 2012 R2.

The NAP client is not available on Windows 10 computers. You can’t even see the Network Access Policy node when you edit a GPO using Windows 10 RSAT:

NAP on Windows 10? Nope.
So if you’re wanting to configure your Windows 10 computers with DHCP and you’re using NAP, you’ll need to disable it or create a special scope without NAP enabled with a DHCP Scope Policy for your Windows 10 clients. As this technology has been deprecated you’re probably better off removing NAP entirely. Pity I’m having to spend time studying it for my 70.411 exam.

How to fix “Your account settings are out of date” in Windows 10 Universal Mail App

The Problem

Update: This problem is a very long running issue that I’m surprised hasn’t been resolved by Microsoft yet. The fix below does work for some people, but based on the comments on this post and those on the Microsoft Forums this solution doesn’t always work and many other fixes have been suggested (see the forum for a large number of other suggested solutions). Some folk have reported that the fix below can prevent the Mail and Calendar apps from working at all, so I’d recommend that you use this process with care and recommend strongly that you back up the comms folder before deleting the content.

Recently I noticed on my Windows 10 desktop that I have been using to test all the Windows 10 Insider Preview releases the Windows 10 Universal Mail and Calendar app is was no longer working with my Outlook mail account. Every time the app loaded or I clicked on the Outlook account it would show a message at the top of the mail list stating “Your account settings are out of date” and giving me the option to fix or dismiss the problem. Clicking fix just flashed up a black window for a brief moment (too fast to see any details) and the message remained. I messed about with the account settings and everything I could find for the account in Mail settings but couldn’t figure out how to fix it. I tried various suggested “fixes” I found online, but none of them worked for me.

My Gmail account worked fine in the Mail app as well and my outlook account also worked fine in the Windows 10 Universal Mail and Calendar app on my laptop. Unfortunately I didn’t think to screenshot the problem before I managed to resolve it so I can’t post an image of the error message here. After a lot of investigation and lots of messing around I found out where the Windows Universal Mail app stores its account data – as I thought this is probably where the problem probably was. The Windows 10 Universal Mail and Calendar seems to store all information in the folder %LOCALAPPDATA%\Comms\ I thought perhaps if I could get rid of (back it up just in case) this folder the app might recreate it.

The Solution

  1. Open an Administrator PowerShell prompt (enter “powershell” in the start menu search and then right click the Windows PowerShell icon and select Run as Administrator, you might need to confirm a UAC prompt).
  2. Uninstall the Windows 10 Universal Mail and Calendar app by entering the following command in the PowerShell window:
Get-AppxPackage | Where-Object -Property Name -eq 'microsoft.windowscommunicationsapps' | Remove-AppxPackage
Uninstall the Windows 10 Universal Mail and Calendar App

Uninstall the Windows 10 Universal Mail and Calendar App

3a. @Stephen has suggested that restarting your computer at this point allows the next step to proceed with better success. So restart your computer.

3. Delete the %LOCALAPPDATA%\Comms\ folder by entering the following command in the PowerShell window (back the folder up first if you want):

Remove-Item -Path "$Home\AppData\Local\Comms\" -Recurse -Force
Deleting the Comms folder - some files can't be deleted - this is OK

Deleting the Comms folder – some files can’t be deleted – this is OK

Note: You’ll probably find that some of the files are in use and can’t be deleted – this is OK.

4. Reinstall the Windows 10 Universal Mail and Calendar app from the app store (click here to open the app up in the store or search for it).

Reinstall the Windwos 10 Universal Mail and Calendar app from the windows store.

Reinstall the Windows 10 Universal Mail and Calendar app from the Windows store.

Once this had all been done I loaded the Mail up and it asked me to configure all my mail accounts again (and authorize them with the providers). After this the error message had gone away and all my accounts worked normally. I did also however have to re-enter my credentials for both Google Drive and One Drive.

For more information, suggestions and discussion about this issue, take a look at this discussion on the Microsoft Community boards.

I hope this works for someone else as well.

Windows 10 Console

Best New Feature of Windows 10?

Well for me, it has to be the proper standard support for text selection, copy (CTRL+C), cut (CTRL+X) and paste (CTRL+V) in the Command and PowerShell windows. Finally, Microsoft has gotten rid of the completely unintuitive and non-standard method employed for the last 20 or so years. What took them so long?

Although I still don’t like the fact that copying text in a console window de-selects it. This is not standard behaviour anywhere else. Perhaps they’ll fix this too?