Deploying provisioning package to windows 10 using PXE :: Is this possible?

bareimage

Hello:

I am trying to figure out if it possible to use Fog to provision windows 10 machines instead of imaging. The idea is as follows. There is a folder on Windows 10 that host provisioning packages that will run upon boot and install Airwatch agent, and then station gets provisionioned with all software that is needed.

I can use USB stick with provisioning package that will surpress all of the dialogs upon boot. What I am trying to find out if I can do the same with PXE

So goal is like this
Brand machine out of the box

Boot PXE
Select one of the booting workflows
Workflow will copy correct provisioning package to the local folder of the machine that is booting
System is restarting and the provisioning package is getting deployed.

george1421

@bareimage You have to excuse my ignorance of provisioning packages, but what value is pxe booting here?

Why not copy the provisioning package to the target computer and install it from inside windows? One might think you could do that with PDQ Deploy or some other application deployment software. Heck, even psexec and a script could do that.

So a little background here. FOG imaging using a customized linux OS called FOS (Fog Operating System). FOS is linux so it can’t do anything (really) in regards to windows or running windows executables, like Windows PE can. You can, copy files to the windows drives and do basic registry changes. If all you want to do with FOG is just drop a file in a specific location FOG can do that.

Please provide a bit more feedback on how you apply a provisioning package to Windows 10.

bareimage

This post is deleted!

bareimage

So lets start with OS X

In OSX environments we use the following workflow

Prior to IMAC Pro

Create basic image with MDM client baked in (Jamf for example)
Load the package into Deploy Studio, Imagr or Casper Imaging or Fog Project
Netbook the station, deploy the OS package without any software
Let MDM do the rest, create user, make configuration profiles

Post Imac Pro

Setup DEP with MDM link and erase the station.
Let MDM do the rest, create user, make configuration profiles

Windows

On windows the same thing is harder to accomplish
Provisioning profile is not zero touch, it has to be loaded on USB, or station needs to be started and then you can run provision profile. For 200 stations is ok, but when you deal with MASIVE 10K deployments this is not feasible.

There are couple of things that can happen.

Enrollment into Autopilot, but you need to use AzureAD + MDM (costs skyrocket)
Airwatch MDM can handle Dell provisioning, HP is coming soon (but you are locked)
USB or manual enrollment (but will take more user interaction)
SCCM+Intune (costs are high)
Fog Project + Image per each configuration (high costs at image creation, you will need to create different sets of drivers and etc)

There is a folder in Windows 10, that is scanned during startup for provisioning profiles. So here is my idea… If it is possible

USE PXE Boot Sequence

Copy provisioning profile to the folder on C drive where the provisioning profiles need to be placed so they are ran on the next boot. The Provisioning Profile would kick on the next boot sequence, and install MDM Agent (Airwatch, Hexnode etc). The MDM would push software to the client station. This would create much lenient system for deploying, removing need for imaging one of the large costs in IT infrastructure…

george1421

@bareimage Thank you for the detailed explanation. I do see a path forward with FOG.

I have this question for you: Windows scans a specific directory upon startup for a provisioning package. Does this happen upon each reboot or does this scan and load happen only during OOBE?

Next question: Do you currently use FOG for imaging?

bareimage

@george1421 According to the documentation, it happens at startup. So the pass would be, as follows.

During the initial boot deploy the profile, and run it or restart. Upon successful deploy and join to MDM (Airwatch, or Hexnode) delete the provisioning profile

I am not currently running Fog. Our current computers are Macs with dual boot, so I deploy Naked Windows with provisioning profile set to execute and enroll into MDM. Then MDM deploys all of the software and compliance policies.

It was decided that OS X is not cost effective in the situations where students are not likely to run OS X. My goal moving forward is to avoid building thick images, for entire fleet, and do provisioning instead. I am very surprised that Provisioning is not as widespread as it should be.

I am all ears regarding possible Fog scenario

george1421

@bareimage Well I’m still not 100% clear on the provisioning process, TBH that is something new with windows 10 and many people are still stuck in the methods for deploy operating systems from the past. So they try to force windows 10 into something they know. We all will need to understand provisioning packages because that is the direction microsoft will go with all future operating systems.

As I see it you could go about this in 2 ways.

(non-fog) Use an application deployment tool like PDQ Deploy to drop the provisioning package in the proper location on the target computer and then force a reboot. This can be done remotely and all hands off. You are just placing the file in the right location and then letting windows find it on startup. What ever magic happens inside the provisioning package is done there. There is no need to pxe boot or even need fog in this situation.
Use FOG to deploy (push) the (thick or thing) image to the target computer. Once the image is pushed to the computer, then FOG can drop the provisioning package in the proper location then reboot the computer. The target computer would then run through OOBE as it normally would. At the end of OOBE it assume it would see the provisioning package and then it would do its magic. FOG can load a 15GB thick image to a bare metal computer in about 4 minutes for a typical install. In my work infrastructure I can push that same 15GB image in just over one minute.

Option 1 would take less internal resources since you are only dropping the provisioning package onto the target hardware. The issue you have is how will you get windows onto the bare metal to begin with? If you are using OEM versions of windows, then the target system should be loaded from the manufacturer. The risks are if the system hard drive fails you will have to manually reload widows from OEM media.

Option 2 take more internal resources to setup, but you can then have a system to go from bare metal to fully provisioning system using the lite touch process of imaging.

Patrick231