WinPE 10 1703 and 802.1x - problem with netsh RRS feed


All replies

  • We are currently facing the same issue, we tried the hack on the 1607 boot image to no avail, basically the same result as now with the new 1703 boot images.

    Service starts, but can't find any interfaces or profiles or whatever, so not able to apply the 802.1x configs to the interface. 

    Was also hoping that it would be fixed in this release and am hoping for a hot fix of some kind, since it's hurting our migration plan going from W7 to W10 for about 1500 clients. We have a workaround solution, but it's not a long term sustainable one.

    Tuesday, April 11, 2017 10:38 AM
  • Hi, 

    I have tested this issue in WinPE for 1703, and same issue. 

    I will feedback this issue in our platform. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, April 11, 2017 11:16 AM
  • I worked on fixing problems with netsh in order to get WiFi support working in 1607 and 1703. It worked for me. See the additions I made to WinPE FixNetSh . This may also fix the wan issues.
    • Edited by plarini Sunday, April 16, 2017 5:58 PM
    Sunday, April 16, 2017 4:16 PM
  • Thanks, I hope to be able to test this out next week sometime.

    (For some reason the site threw a 404 the first time I clicked the link, but then it worked a few minutes later when I tried again...)

    Monday, April 17, 2017 1:52 AM
  • The link was wrong at first. You must have tried just before and then just after I fixed it.
    Monday, April 17, 2017 10:52 AM
  • FYI, the FixNetsh bit doesn't help the 802.1x stack in any way.
    Monday, April 17, 2017 6:12 PM
  • I was able to get 802.1x/NetSH working with limited success.  I did a file comparison of the System32 directory of a working 1511 boot WIM and the broken 1703 boot WIM, and copied over the missing files.  Then I added in the files specified by plarini with his FixNetSH, as well as the related .dll.mui files.  Then I added the registry entries specified by plarini.  Saved the boot WIM, put it on boot media, and booted with it.  

    At that point, the service was able to start, netsh shows interfaces, and the profile imports.  Unfortunately, I can't get a certificate to import with certutil.exe, so I get an "authentication failed" message.  With 1511, certutil was not included on the boot WIM, and had to be manually copied over from a full OS.  With 1703, the boot WIM contains certutil.exe already, but it isn't working.  There are no error messages, but when executing it, the system always just goes to the next line.  I tried copying certutil.exe from the full OS, but it didn't make a difference.

    Here are the files I copied over to the boot WIM.  I'm certain there are more than are needed, but the total size is ~7MB, and I'm more interested in it working than trimming down the size.


    Here is the .reg file I imported, having loaded the SOFTWARE hive from the boot WIM to HKLM:\Mount


    Edit: I tried replacing certutil.exe and certutil.exe.mui from Windows 10 1511, and it actually works on the ADK 1703 boot WIM.  I'm now able to successfully authenticate using certificates with 802.1x when using the ADK 1703 boot WIM.  I'm going to classify this fix as "janky, but good enough."

    • Proposed as answer by Atamidos Thursday, April 20, 2017 12:37 PM
    • Edited by Atamidos Thursday, April 20, 2017 12:39 PM
    • Unproposed as answer by Cristopher_WPU Thursday, April 20, 2017 4:57 PM
    Wednesday, April 19, 2017 6:58 PM
  • Very nice.

    I was using WinRE instead of WinPE to get the WiFi package. I knew about 4 of the dll's you added to my list. They were already included in WinRE:





    Of the other 5 you added, I found only one was needed:


    You should be able to eliminate:





    Thursday, April 20, 2017 2:35 PM
  • Thanks for the work you've put in already and sharing your progress. I'm really annoyed by the way MS handles enterprise-critical features like 802.1x since ADK 1607.

    Is there any chance you have tried your workaround for 802.1x with MSCHAPv2 authentication as well?

    • Proposed as answer by Ovidiu Popeti Thursday, November 16, 2017 6:53 PM
    • Unproposed as answer by Cristopher_WPU Friday, November 17, 2017 12:35 AM
    Monday, April 24, 2017 10:48 AM
  • OK, using the info posted by Atamidos above I have successfully connected to our 802.1x secured network in WinPE 10 1703.  Here is how I did it:

    Download and install Windows 10 1703 Enterprise 90-day evaluation.  (I used this because as a volume license customer I can't get it until May 1.)
    Install the ADK version 1703.
    Use documentation here to create and customize a 64-bit Windows PE environment. 
    Be sure to add the dot3svc optional component using instructions in this link.
    Add any network or storage drivers using the instructions in this link.
    Copy the missing DLL files required by running these commands.

    copy /Y C:\Windows\System32\authfwcfg.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\clbcatq.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\dmcmnutils.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\eapprovp.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\fwcfg.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\hnetmon.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\mdmregistration.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\nshhttp.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\nshipsec.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\onexui.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\p2p.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\p2pnetsh.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\peerdistsh.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\raschap.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\rastls.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\rmclient.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\rnr20.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\rpcnsh.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\TtlsExt.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wcmapi.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wcnnetsh.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\whhelper.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wifidisplay.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wininetlui.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wlanapi.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wlancfg.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wwancfg.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\wwapi.dll C:\WinPE_amd64\mount\Windows\System32
    copy /Y C:\Windows\System32\en-US\authfwcfg.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\fwcfg.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\hnetmon.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\nshhttp.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\nshipsec.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\onexui.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\p2p.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\p2pnetsh.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\PeerDistSh.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\raschap.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\rastls.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\rpcnsh.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\TtlsExt.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    rem UIAutomationCore.dll.mui gives access denied, might have to copy it offline - it worked without it
    copy /Y C:\Windows\System32\en-US\UIAutomationCore.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\WcnNetsh.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\whhelper.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\WiFiDisplay.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\wininetlui.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\wlanapi.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\wlancfg.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US
    copy /Y C:\Windows\System32\en-US\wwancfg.dll.mui C:\WinPE_amd64\mount\Windows\System32\en-US

    Add registry entries by running the these commands.

    reg load HKLM\Mount "C:\WinPE_amd64\mount\Windows\System32\config\SOFTWARE"
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "authfwcfg" /t REG_SZ /d "authfwcfg.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "fwcfg" /t REG_SZ /d "fwcfg.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "hnetmon" /t REG_SZ /d "hnetmon.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "nshhttp" /t REG_SZ /d "nshhttp.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "nshipsec" /t REG_SZ /d "nshipsec.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "p2pnetsh" /t REG_SZ /d "p2pnetsh.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "peerdistsh" /t REG_SZ /d "peerdistsh.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "rpc" /t REG_SZ /d "rpcnsh.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "whhelper" /t REG_SZ /d "whhelper.dll" /f
    REG ADD "HKLM\Mount\Microsoft\Microsoft\NetSh" /v "wwancfg" /t REG_SZ /d "wwancfg.dll" /f
    reg unload HKLM\Mount

    Copy certutil.exe and certutil.exe.mui to a folder in your mount.  I used version 6.1.7601.18151 but apparently the one from Windows 10 1511 also works.

    Copy your XML and CER files required to connect to 802.1x.

    Unmount the image and create an ISO and/or bootable USB device.

    Boot into WinPE. 

    Run the following:

    net start dot3svc
    X:\<path to>\certutil.exe -addstore root X:\<path to>\<filename>.cer
    Netsh lan add profile filename="X:\<path to>\<filename>.xml"
    Netsh lan set eapuserdata filename=X:\<path to>\<filename>.xml allusers=yes interface="Ethernet"

    Wait approx. 60 seconds.

    Congratulations - you are now connected to an 802.1x secured network in WinPE 1703.
    If you don't know where to get the XML and CER files, search the web for WinPE 802.1x and you'll find a lot of stuff.
    I'm sure a lot of this can be trimmed down but I'll let the experts at Microsoft handle it from here on out.

    Monday, April 24, 2017 12:46 PM
  • Unmount the image and create an ISO and/or bootable USB device.

    It's worth noting that these changes don't have to be made directly to the boot WIM if you're using SCCM.  I have all of these files added to the image via the customization tab in the WIM's properties, and specify a script to launch at boot time that copies the files/keys to the appropriate locations before starting the 802.1x authentication.
    Monday, April 24, 2017 11:59 PM
  • Be sure to add 'rastls.dll' too, else you might be able to connect to WPA-Personal mode WiFi but you won't be able to connect in WPA-Enterprise mode, or with 802.1x on LAN.

    As we're in need of WiFi in OS Deployment, I've managed to create a C# tool with some help of ManagedWiFi to import certificates/wifi profiles and connect to wireless network. The routine to import certificates is using unmanaged code due to need to import into Enterprise NTAuth store, which in DotNET native code seems impossible. I think you guys here might find the same issue that connections might not establish due to 'wrong' store being utilized: KB814394.

    Only now I find that the WinRE is too big (> 500 MB), due to DotNET requirements, and I would like to trim it down. As soon as I remove the ReJuv package it breaks the WinPE partly: wpeinit.exe is crashing due to kernelbase.dll exception code c06d007e. Trying to figure out the issue, it looks maybe like a user profile issue. But am not sure. I don't see any changed files in the systemprofile dir when comparing original WinRE vs new (without ReJuv). Any help would certainly be welcome.

    What is commonly referred to as a coincidence still happend for a reason!

    • Proposed as answer by MikhailCompo Monday, May 22, 2017 1:07 PM
    • Unproposed as answer by Cristopher_WPU Monday, May 22, 2017 10:45 PM
    Wednesday, May 3, 2017 9:19 PM
  • I can confirm that on WiFi in WinPE 10.0.14393 (1607) and 10.0.15063 (1703) that 802.1x works with MSCHAPv2 to connect to WPA-Enterprise mode wireless networks.

    What worked on my XML connection profile:

    <OneX xmlns="">
    					<EapHostConfig xmlns="">
    							<Type xmlns="">25</Type>
    							<VendorId xmlns="">0</VendorId>
    							<VendorType xmlns="">0</VendorType>
    							<AuthorId xmlns="">0</AuthorId>
    						<Config xmlns="">
    							<Eap xmlns="">
    								<EapType xmlns="">
    										<TrustedRootCA> *** YOUR TRUSTED ROOT Certificate Thumbprint ***</TrustedRootCA>
    									<Eap xmlns="">
    										<EapType xmlns="">
    										<PerformServerValidation xmlns="">false</PerformServerValidation>
    										<AcceptServerName xmlns="">true</AcceptServerName>

    And than you'll have to inject your credentials using:

    <?xml version="1.0" encoding="utf-8" ?>
      <Credentials xmlns:eapUser="" 
              <MsChapV2:Username>*** UserName ***</MsChapV2:Username>
              <MsChapV2:Password> *** Password ***</MsChapV2:Password>
              <MsChapV2:LogonDomain> *** LogonDomain ***</MsChapV2:LogonDomain>
    Note: Username may be in different styles, like prefixed with domain and then leave LogonDomain empty.

    What is commonly referred to as a coincidence still happend for a reason!

    Wednesday, May 3, 2017 9:29 PM
  • Already found the answer/reason myself...

    When removing ReJuv, as I noticed it - or maybe it was another (dependent) package -, from WinRE it removed the wpeinit.exe critical dependent file: X:\Windows\System32\unattend.dll .

    Upon copying the file, restart wpeinit.exe it successfully initializes again.

    What is commonly referred to as a coincidence still happend for a reason!

    Wednesday, May 3, 2017 10:09 PM
  • Hi Atamidos,

    Could You please clarify, have You added the script to copy files/keys in Boot Images "Customization" -tabs prestart command? Then added script to start 802.1x when creating Boot -media? Or whuch method You're using? I'm using SCCM 1702 & MDT 8443 & ADK 1703 and yes, facing the same issue.

    Best Regards,


    Tuesday, June 13, 2017 5:48 AM
  • Wednesday, July 5, 2017 8:24 PM
  • Many thanks for the information :) Will finally be able to switch from our 1511 WinPE images now.

    Let's spread the word!

    Wednesday, July 5, 2017 8:55 PM
  • Has anyone seen this link on reddit? It's blowing up on Twitter right now.

    I'm on the east coast and done for the day. Any brave people want to give it a try?

    Edit:  Looks like a few others beat me to the punch.  I can't wait to try this!

    • Edited by Cristopher_WPU Wednesday, July 5, 2017 9:24 PM because I'm not quick enough
    Wednesday, July 5, 2017 9:14 PM
  • Did it work for you?  For me, the service starts, but 802.1x fails to authenticate.  I don't see any obvious source of issues.
    Friday, July 28, 2017 9:04 PM
  • Yes, the hotfix works with WinPE 1703 and MS-CHAPv2 in our environment.
    Friday, July 28, 2017 11:38 PM
  • We are using certificate based authentication.  I wonder if that piece is still broken.
    Monday, July 31, 2017 2:11 PM
  • We import a certificate using certutil.exe as a part of our authentication and it works fine now that KB4025632 has been applied to our WIMs.  If there are any further problems, a separate thread should be started.  The original problem this thread is about has been resolved. 
    Tuesday, August 1, 2017 11:11 AM
  • I'm still getting an error.

    My authentication script attempts to import our root certificate so that it can authenticate the ISE server.  When the certutil.exe command runs, I get at error "The code execution cannot proceed because RstrtMgr.dll was not found. Reinstalling the program may fix this problem."

    I have performed a DISM /get-packages to ensure both the dot3svc package and KB4025632 are included in the WinPE.wim file.

    Tuesday, September 12, 2017 3:47 PM
  • Yeah, certutil is still broken, the hot fix does not address this issue.

    Copy RstrtMgr.dll from a clean 1703 install to your winpe as part of your bootimage creation process and it should work just fine. Had the same issue...

    Tuesday, September 12, 2017 3:55 PM
  • I haven't had any issues since the KB came out. I'd suggest you open a new thread to address the problems you're having with certutil.exe.

    Tuesday, September 12, 2017 4:52 PM