I had the same issue, updating the plugin.class.php file did the trick.

Thank you.

@avaryan FWIW, you can start with a online generator to build your basic win10 unattend.xml file: http://windowsafg.no-ip.org/win10x86_x64.html To that we add in the section to load the drivers from a known location. We have to do this because some driver are needed for the OOBE process (we use a single image developed on a vm for all computers in our fleet) to run successfully. Then in the setup complete we use dism to inject any drivers missed during the initial OOBE process (mainly because some hardware is hidden behind other devices that needs it driver loaded first).

In our deployment process we use the unattend.xml file to connect to AD and not the fog client. We calculate the target OU based on several factors that is calculated at deployment time. This dynamic OU selection isn’t possible using the standard FOG environment. So we use a post install script in fog to update the system’s host name, location, timezone, OU location and a few other things that escapes me right now.

Since we use MDT to build our reference image you don’t need to mess with audit mode to default user profiles that is managed by the mdt process.

@noelpd Thanks!!!

@noelpd said in HP 210 Netbook (RealTek NIC) - DHCP Failed on PXE Boot:

So rebuilding a custom bzImage file will not effect it at all

No it won’t

The typical flow is PXE ROM -> tftpserver -> iPXE kernel (what you see in the OP post, and why the iPXE error message) -> FOG httpserver -> bzImage + init.xz (FOS image)

The issue is for some reason iPXE can find the nic (no problem) but it can’t pick up a dhcp address. To me this still screams of being a spanning tree issue, but you have tested otherwise.

Worked with @noelpd via chat.

Apache had an issue with ssl that prevented it from restarting, and git had an issue with ssl preventing it from doing a git pull.

I directed him to use svn instead, and that worked. But there was still the issue with Apache, and @noelpd says that uninstalling and reinstalling apache fixed the issue.

I think there is something else going on related to ssl that caused these two issues to begin with.

@noelpd I concur with Sebastian. You need to try a dumb unmanaged mini-switch between the computer and the building. Most I.T. places have a few laying around. If you don’t have one, they are pretty cheap to get - you should go out and get one.

You should also try brand-new patch cables too.

@noelpd If you are using the FOG Client, please follow documentation in the FOG Wiki:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@Wayne-Workman Thank you!! That modification worked.

Hi noelpd,

I know it’s late and you might have resolved your problem, but I have come up with a cause and solution (at least in my case).
[LIST=1]
[]In order to schedule tasks, whatever it is the task, you must assign an image to the host/group you are trying to send the task.
[]The server from which you are sending the task must be the group’s master node. I realised that, in WebUI > Other Information > Log Viewer > Scheduler, the server wasn’t the group manager and it wasn’t scheduling tasks.
[/LIST]
I hope this helps.

You can register those machines manually, when you know their MACs. So there is no need to switch any kernels. Just put in the MAC, name the host (any name will be fine), and include the path to the working kernel.