Configuring 802.1x Authentication for Windows Deployment – Part 3 – Integrating 802.1x Authentication into a Bare Metal Task Sequence

This is Part 3 in my Configuring 802.1x Authentication for Windows Deployment series. Be sure to check out all of the other parts here.

You will need all of the files you created in Part 1 for this part.

During a Bare Metal/Wipe & Load OSD Task Sequence, the Task Sequence will start in WinPE and copy down the OS installation files. Once Windows as been installed, the Task Sequence will boot out of WinPE and into the new OS. WinPE doesn’t pass any of the authentication information to the new OS, so you will need to re-authenticate with 802.1x. To accomplish this, you need to copy your 802.1x authentication script down locally and add an entry to your Unattend.XML to launch the script at during the correct pass in Windows setup.


You can edit your Unattend.XML using the Windows System Image Manager that’s part of Windows ADK or you can manually edit it. The script needs to run during specialize pass.

After loading your OS media into WSIM, follow the steps below to add the commandline for your 802.1x authentication script.

Add the following as the Path. It should point to the location where you will copy your auth package to in the next step.

This is what the resulting XML should look like.


h1>Adding everything to your Bare Metal Task Sequence


Create a new Package in ConfgMgr and include all of your script files in the package. Then add a new Run Command Line Task Sequence step before Install Operating System step. Set the Package source to the new package your created.

The path in this command line needs to match the path in the Unattend.XML file.

That’s it for your Bare Metal Task Sequence. If you’ve been following the steps and testing, you should be able to build a Bare Metal build using Computer Authentication on an 802.1x protected network.

Part 4 Covers In-Place Upgrades


  • Reply
    June 11, 2019 at 7:19 am

    Hi, thanks for this guide. It’s really helpful.
    I’m stuck at the change between WinPE and Windows 10.

    Everything works as you described it. But at the first restart, the script from the unattend.xml (ImportComputerAuthProfile.bat) starts (CMD Window appears). At the same moment. Windows restart the machine. But I don’t know why. Windows don’t wait until the script runs to end. After this restart, the TS Stuck for ever in “Please wait” screen.
    Why the System don’t wait until the Script is run complete.
    I’ve tried it with another script, which timeouts for 2 Minutes. Here the system doesn’t wait too and restarts the machine after 1-3 Seconds.

    I’ve made everything like you described it. Have you an idea what I made wrong? Sorry for bad English… :/

  • Reply
    August 31, 2019 at 8:49 pm

    Thanks for the guide!

    I too am also stuck with the batch script running during OOBE but closing after importing the certificates. I have added echo logging steps so I am pretty sure that the script is being forced closed before all the steps have executed. I am attempting to integrate this solution in a Windows x64 1809 Enterprise build if that makes any difference.

    Any advice or suggestions would be greatly appreciated as I have been at this for a couple of days now without any progress.



  • Reply
    September 1, 2019 at 3:49 am

    I think I answered my own question…

    The command line defined in the unattend.xml has be run synchronously, not async.

  • Reply
    Thomas Ehler
    June 30, 2020 at 7:38 am

    If I run the ImportComputerAuthProfile file set package before the “Apply Operating System Image” step, the tempfolder isn’t there after reboot.

    • Reply
      October 19, 2020 at 2:02 pm

      The same thing happened to me. I just changed the location in my unattend.xml to point directly to the package that gets downloaded to the _SMSTaskSequence folder:

      cmd /c C:_SMSTaskSequence\Packages\PACKAGEID\ImportComputerAuthProfile.bat


    This site uses Akismet to reduce spam. Learn how your comment data is processed.


    Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `POST` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): Guzzle in /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113