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!

14 thoughts on “Windows 10 Build 10586 – PowerShell Problems

  1. Hello I am also suffering from all of your bugs listed here in build 10586 and powershell, and I simply don’t have the time to go rooting them all out and fixing them, what a pain in the ass. I even created domain certificates with Document Encryption EKU and still getting same error message after deleting the old certs and only putting the new one in the directory, Every time Windows 10 updates, I notice that many things break in powershell and DSC, I guess the rest of my night will be trying to get dsc working again.

    Liked by 1 person

    • It does look like this release is pretty problematic with regards PowerShell and especially DSC. I’ve logged some of these with PowerShell connect, and hopefully this will get resolved quickly. I have yet to log the one about the PSDesiredStateConfiguartion module version number (although that’s the one that bothers me the most).

      Are you creating self-signed certs for encrypting the DSC credentials or MS DS?

      I use this is the code I use to create self-signed certificates on any DSC nodes:
      New-SelfsignedCertificateEx `
      -Subject ‘’ `
      -EKU ‘Server Authentication’, ‘Client authentication’, ‘Document Encryption’ `
      -KeyUsage ‘KeyEncipherment, DigitalSignature’ `
      -SAN ‘MyServer’ -FriendlyName ‘MyServer Self-Signed Certificate’ `
      -Exportable `
      -StoreLocation ‘LocalMachine’

      It requires the New-SelfSignedCertificateEx.ps1 from

      The cert can then be exported and imported into cert:\LocalMachine\My and used to encrypt the credentials.

      I do hope they release some fixes to these quickly!


  2. No actually I was trying to use my ADCS PKI infrastructure but since it seems like I am unable to create a computer (workstation authentication cert) with the Document Encryption EKU in ADCS, I may have to use a self signed thought to get anything to work. I’m actually quite pissed off that PowerShell is now requiring this new Enhanced Key Usage because I don’t think I can use Active Directory Certificate Services anymore with DSC, (which if true is crazy). Before this restriction ALL adcs CERTS were working fine, and self-signed certificates are just not acceptable outside of a lab environment. I really hope this gets fixed somehow, along with your problem and I’m positive that more bugs will pop up soon. DSC is not really new anymore considering it was introduced in 2013, but it is now impossible to use it in production if self-signed certs are the only way to configure pull servers.


  3. That is a definite problem! And it really annoys me as well that this new requirement for the certificates doesn’t seem to be documented – or at least nowhere that I can find.

    For your ADCS Workstation Authentication template, are you seeing the Document Encryption application policy available? I haven’t tried this specifically, so I can’t confirm for sure (using self-signed certs at the mo), but if you add this to your Workstation Authentication template (or whatever template you’re using to enroll your computer/server certs) does that allow you to use the certs being issued?

    I took a screenshot of what I mean in case I’m using the wrong terminology:

    Hopefully this isn’t too much of a silly question.


  4. You are correct, that would be exactly how I should have added the Extended Key Usage of Document Encryption,I quickly tried to just add the properties to the certificate before issuing it. Also. since I have already issued most of my certificates to work with System Center components ConfigMgr and OpsMgr, (Microsoft’s documentation USED TO INSIST that you had to use Windows Server 2003 compatible certificates to work with ConfigMgr, I am unaware if this has been fixed yet, but it will have to be now I presume It looks like I will now have to reissue my entire PKI now to please PowerShell, Which is great as long as nothing else gets messed up or goes wrong in the process, i am sure there will be some other compatibility bugs found though. I actually did see this issue with the new Powershell certificate requirements documented somewhere on MSDN or Technet, I think it was most likely in the Windows 10 build 10586 changes somewhere. It was only in one place however. Thank you because what I had done was try to issue a cert with my old template and then I tried to change the properties of the cert’s Enhanced Key Usage, but I forgot that I had to change the template. I will try this and let you know what happens. Yes the Sha1 problem is bound to come up now also, I think I might have to rebuild my entire PKI now anyway, which I hate to mess with because there is always one checkbox that I miss that seems to screw everything up. It’s time for Microsoft to come up with some new PKI documentation also, I hate when I have to dig through technet for 2008 certificate services documentation that may be outdated but they don’t tell you if it works in 2012 etc. You have to spend hours going through years of webpages that tell you different things at different times, you know what I mean.
    OK thanks again, I’m also using your NanoServer TP4 script that you fixed right now, for some reason I got Nanoserver running as a generation 2 VM but I got no internet connection and still can’t connect to it at all. It seemed like the image was built fine, but it just stays black and I’m sure I will get it going today. I’m thinking I may have changed some Hyper-V setting when i built it that is screwing it up.

    Liked by 1 person

    • Reissusing all certs because of PS sounds pretty scary to me. I’d hope there was some swtich/reg key that could be set that could revert this behavior as it seems like this is going to be a big issue.

      I think a change log of all the PS changes in 10586 would be so useful right now! I think we’re all kind of flying blind here. I did a quick google search to see if I could find anything that looked like change notes for 10586 relating to certificates but nothing showed up😦

      I’m definitely keen to know if updating your cert template worked – I imagine this is going to be a really common issue/solution. So if it does work would you mind me updating this post with the info as to whether this worked or not?

      As for updating to SHA256 – that looks like a nightmare TBH. I ran into this document which covers the process and it made me feel a little bit sick:

      Awesome you’re using my Nano script – I’ll give you any help with it I can. I wrote it before MS released the official script but in TP3 they didn’t support VHDx/Gen 2 machines (not sure if they added this in TP4 or not) so I kept maintaining mine because I prefer Gen 2/VHDx. Do you get the black screen with a flashing black underscore char?


  5. karl says:

    I’m able to update my template to have the new required pieces and create a new cert.

    However, now when I try to deploy I get “Decryption Error”.

    I think it relates to the password field of a MSFT_Credential object. Using a client with build 10586 you see something like:
    instance of MSFT_Credential as $MSFT_Credential1ref
    Password = “—–BEGIN CMS—–\nSomebase64EncodedContent\n—–END CMS—–“;
    UserName = “SomeUser”;


    Using a client with build 10240, you get something like:
    instance of MSFT_Credential as $MSFT_Credential7ref
    Password = “Somebase64EncodedConent”;
    UserName = “SomeUser”;


    I’m guessing there should have been either a new build for powershell on the server or some other switch ?


    • You’re right – I just took a look at all my MOF files (which automatically update every time I run one of my control scripts) and they’re all using the newer format:
      Password = “—–BEGIN CMS—–\n …\n—–END CMS—–“;

      But I’m not running into any decryption errors though. I’m using Windows Server 2012 R2 with WMF5.0 ( 5.0.10105.0 ) installed. What build are you applying the DSC to? I wonder if this new format for the password is not supported on older WMF builds? I hope this isn’t the case – or there is at least a switch to revert it.


      • Running also on a 2012r2 – with version 5.0.10514.6 which i believe is the production preview, which AFAIK for 2012r2 is the latest available.

        So it works on older…hmmmm. Not sure what that means. I know at somepoint during the betas that encrypted credentials seemed to stop working and then in the production preview started to work again.

        BTW, the I put something up on stackoverflow too at:


      • Ok, I’ve run into the same problem now. This was on a Server running WMF 5.0.10105.0 – so a much earlier version of WMF than you’re trying. I suspect this might actually be a problem with the certificates themselves. I’m going to do some investigation now and see if I can come up with a solution.


  6. That does seem like a possibility. But you’d think that it was the other way round (new format only works with new version of WMF). I’ll install WMF5 production preview on one of my servers this afternoon and see if I run into the same issue and let you know!

    I’m keen to see if anyone has any feed back on Stack Overflow. From what I’m seeing there are some definite issues with this release of WMF 5.0, but there just doesn’t seem to be that much fuss about it. I wonder how many people really are actually using WMF 5.0 DSC out there?


  7. I’ve spent an afternoon trying to solve this (trying different KSP/CSP etc) and so far nothing. All of my config files that contain encrypted credentials have the same issue you’ve reported. This is definitely a big problem! Are you using a PKI or using self-signed certificates?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s