Native 802.1x Support for Enterprise Operating System Deployments
Provide Support 802.1x Natively w/o the use of prestart up scripts in WinPE. Many large organizations have protected network infrastructure for their environments that want to be able to easily utilizes the Deployment feature on these protected networks.
Dave Wall commented
Yes please! This is incredibly difficult in its current state. We are even having problems with Windows 10 in-place upgrade giving inconsistent results. We have implemented the recommendations from the excellent Adam Gross (SquareDozen). This isn't even supposed to be an issue: "According to the Windows 10 Product Group (via Microsoft Premier Support), an In-Place upgrade should migrate 802.1x settings." Adam Gross, https://www.asquaredozen.com/2018/07/29/configuring-802-1x-authentication-for-windows-deployment-part-4-integrating-802-1x-authentication-into-an-in-place-upgrade-task-sequence/
We are not allowed to MAC exceptions here, so for us there are many moving parts which make this very difficult to manage. We managed to get our Wipe and load OSD working, but it isn't pretty...
So anything that makes this process more friendly and less arcane would be welcomed!
Espen Molund commented
Зеленов Владимир commented
For those of you following this, here's a great blog series to assist with 802.1x deployments covering various scenarios.
Herman van Drie commented
I would rather see that WiFi support (Wlan AutoConfig service) introduced into WinPE, which is already present in WinRE for Windows 10.
Also, I would love to see that OSD status messages are able to be delayed when connectivity is not present (yet) using a TS variable.
I was able to utilize WinRE with some coding of my own to allow OSD to fully run over wireless with deployment set to "Access content directly from a distribution point when needed by the running task sequence" so it would not require pre-caching.
See my tweet here: https://twitter.com/hvandrie/status/875303380977164288
In the corporate environment I work for this resulted in bare-metal installations using USB media as start up to boot WinPE media to initiate the deployment in less than 70-80 minutes using a 802.11ac network. Which was faster than fast ethernet!
Travis Vieson commented
I agree. ADK 1607 and 1703 both need KB4025632 to work. What would be nice is an option when creating the boot image/media SCCM to use the PFX specified for 802.1x authentication. In a native environment I already need a certificate to communicate to SCCM, why not have an option to use the same certificate throughout the TS. At least then I only need to worry about cleaning up certificates at the end versus getting the system to build.
Raphael Jülich commented
We just rolled out 802.1x and we are heading for a Solution where we use Orchestrator to create the SCCM Object and also create a MAC Exception on the Radius Server. After the TaskSequence has finished, the Orchestrator removes the MAC Exception again and everyone is happy!
Fingers crossed that 2017 will bring some support to WinPE and SCCM task sequences so that we can do some OSD on a network that uses 802.1x security.
We have the benefit of being able to use Mac authentication bypass for the OSD phase and we do switch to native 802.1X late in the OSD TS.
Would I like to see a better way? Yes - Also stop blocking GPO:s during OSD or make it selectable. The claim that GPO:s has to be blocked for OSD to work is a piece of BS. MDT do work with GPO:s
We're headed backwards here. The latest WinPE 10 (version 1607) broke the dot3svc service. https://social.technet.microsoft.com/Forums/en-US/win10itprosetup/thread/93f32a23-7558-4742-91ab-ba0e7801ed0e/#3853df61-8dcf-4560-8b01-27da4fcca235 Those of you who are in an 802.1x environment, help me make some noise on this please.
Dustin Hedges commented
Each 802.1x implementation is different. We essentially "hack" ours together in both WinPE and FullOS to get things to work. We leverage a combination of User Account Auth and Certificate Auth (where appropriate) and that's ONLY because we are essentially forcing our Information Security department to allow it.
Not every implementation is the same. And not every site, at every company, has the luxury of a dedicated "Imaging Lab" that can be exempt from 802.1x policies.
Gerhard Eriksson commented
We are looking into if we can utilize Intel AMT so that authenticate the PC on our network because of lacking support for 802.1x. For the time being We use same method as Cristopher.
We have 802.1x on our network and in order to achieve a successful operating system deployment we have had to implement hacks upon hacks into our process. I've gone through 2 dozen iterations of our boot image trying to get the script "just right" and it is still not 100% functional. Because of this, most of our deployments are still done on an isolated network segment where 802.1x is disabled.