Enable Task Sequences to automate an existing OEM/Reset image (from OOBE)
Part of the big push for modern management, and solutions such as AutoPilot, is so that you "don't need to spend time replacing a perfectly good OS that is already on the device". Especially when dealing with clean devices such as Surface, this makes complete sense... except in cases where AutoPilot and Intune aren't used or cannot be used.
My suggestion is: Let's create an option for a PXE-enabled Task Sequence to run, and essentially perform the automation of the existing OOBE, by essentially bypassing the partitioning and WIM application steps. That way, much like the selling points for modern deployment solutions, there is no gathering of drivers, collection of customisations and power management configurations (i.e. Connected Standby), or other time-wasters required to replace the existing image "that has been carefully configured and tested by the OEM". This way, you get all the benefits of Autopilot, but you get to do it on-premises with Configmgr.
Murray Webber commented
Okay, I make this sound easy, and I know it's not... because I've tried to automate this myself with zero luck. But here's what I've found while trying (including suggestions):
a) It's easy to disable the default "Partitioning" steps to retain the existing disk contents.
b) We then need a template unattended answer file to continue allowing customisations. The best option here, is to have an option within the "Apply Operating System" step that disables the current two "Apply" steps for the WIMs, but otherwise retains the use of a package for the unattended answer file.
c) If the above step can be solved, we should still be able to use the "Apply Windows Settings" (osdwinsettings.exe /config), "Apply Network Settings" (osdnetsettings.exe configure), and "Apply Device Drivers" (osddriverclient.exe /auto /bestmatch:%OSDAutoApplyDriverBestMatch% /unsigned:%OSDAllowUnsignedDriver%) steps to customise the unattended XML that now resides in the "_SMSTaskSequence" folder.
d) Next, we can still mostly run the "Setup Windows and Configuration Manager" step, as we will still need to download andprepare th ConfigMgr Client instalaltion package, will still need to generate the "SetupComplete.cmd" to reinitialise the TS after reboot, and will still need to ensure that we inject the required binaries from within WinPE (i.e. OSDSetupHook.exe, TSProgressUI.exe, tres.dll), and then perform the OSD Hook setup, etc. Without the source folder for the OS "Setup.exe", some magic may need to be done, but I suspect an action that will copy the customised XML to the Panther folder should suffice.
e) Do whatever it is I'm missing from above (because I can't get this working myself), and automate the existing OOBE, then continue with the Task Sequence as normal.
This could save a lot of time for some admins, and would also be perfect for those one-off devices that we suddenly have to support. Obviously, the first step could be handled by a Provisioning Package (PPKG) instead, but those have their own limitations and issues that take time to deal with. I honestly believe the above suggestion would be a great addition to ConfigMgr's capabilities.