Microsoft

Microsoft Endpoint Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

← Ideas

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.

908 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Steven shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
Noted  · 

16 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Anonymous commented  ·   ·  Flag as inappropriate

    I don't know if this is something that would be possible. You are asking for SCCM to provide a client at PXE boot with no OS with a certificate. Unless you can install the cert into the motherboard, I'm not sure how that would happen. If you are talking about during re-image, this would be an ADK change that's needed as you are wanting certificates to be added to the WinPE image.

  • Cristopher commented  ·   ·  Flag as inappropriate

    After many years, I'm seriously considering taking my 3 votes off this item as it's clearly never going to happen. I'd rather contribute my votes to something that has a chance of seeing the light of day.

    OSD is more and more becoming of a legacy provisioning tool while Autopilot is being pushed harder and harder by MS.

    In spite of great contributions from the community, we never got OSD to work in our 802.1x environment and even made some backwards progress when trying to work more closely with our network security team.

    About a year ago we threw in the towel and stripped all 802.1x customizations from our OSD scenario. In spite of the incredible inconvenience it causes, all of our PCs get imaged or re-imaged on a dedicated network segment with no 802.1x.

  • Dave Wall commented  ·   ·  Flag as inappropriate

    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!
    Thanks.

  • Herman van Drie commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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!

  • Cristopher commented  ·   ·  Flag as inappropriate

    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.

  • Mats commented  ·   ·  Flag as inappropriate

    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

  • Dustin Hedges commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Cristopher commented  ·   ·  Flag as inappropriate

    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.

Ideas: Operating System Deployment

Categories

Feedback and Knowledge Base

(thinking…)