@Tom-Elliott said in Capture UEFI image on hyper-v VM:

6.1.89

Thanks, this worked for me.

When tasking a host, I’d get the same as @Baessens (Hyper-V).

I went to kernel update and installed 6.1.89 as per Tom’s suggestion and I was able to get past and into image deployment!

I have a setup with Fog w/ PxE booting over UEFI and image deployments + domain joins – all working perfectly.

Our systems are mostly whiteboxes (i.e Gigabyte / Asus motherboards) with i9-14900K and NVMe SSD Boot drives.

Typically, we’d get a system, set its boot order in the BIOS/UEFI config to UEFI: PXE over IPv4 and then leave it. That way, way, the fog agent can reboot the system which in turn causes it to boot over PxE and pull down the latest image which was all working fantastically.

Unfortunately, the latest round of systems we have appear to have an annoying quirk where following image deployment, the first reboot goes via PxE, then windows does its initial boot “OOBE” setup, - and finally, it reboots a second time. After that second reboot, Windows Boot Manager becomes teh #1 boot device (i.e. PXE Boot removed from the primary boot order). Which means I can no longer re-image the system – if I task something via Fog, the system just gets stuck in a reboot loop because it the fog agent reboots it and the system goes straight into windows without PxE booting.

Is there any easy way to resolve this? Can I maybe modify my image to prevent windows from shotgunning the boot order like that? Interestingly, once booted, if I type bcdedit /enum /raw I do not see PXE boot in the order. Just Windows Boot Manager and WindowsBoot Loader

So far, I’ve tried disabling “Fast Boot” which worked for our last round of systems and also password-protecting the BIOS but windows still meddles with it.

Any guidance on how to resolve this would be extremely helpful!

@Gerrit-Anderson Thanks for this – fixed this issue for me! I used to get stuck on Init, but can get further now into the actual boot menu like you. I too have lost my custom background but really that’s a non-issue.

However, when I try to deploy an image, it asks me for a password (which is the FOG webUI username & password of course). I don’t recall this happening with my old TFTP boot files – I guess they must have had the password embedded in there somehow? Anyone know how I can fix this?

Thanks @george1421 , the reason I wasn’t using sysprep oobe generalize was because it was causing my system to lock up at “Please Wait”. I found that un-joining and re-joining it to the domain “generalizes” the system enough so that everything works for us.

Anyway - I re-built the image and integrated the FOG Client (agent) into it. Now it appears the domain joining is working. Bad news is I’ll need to do another round of manual deployment, but that is the last time - after that I will have a full hands off deployment system.

Thanks for your help so far!

As in title.

My machines are on DHCP and receive IP & Hostname from the DHCP server. So far everything is working perfectly, I’ve got my image built and deploying just fine. Now I have just one question. I didn’t sysprep my image (Win 10), I just set it up as a VM, joined it to domain, installed all the software I needed, unjoined from domain and shut down.

So far I’ve deployed 20 images and everything is working great - I just kick it off from the FOG web ui, then reboot the machine in question and boot off LAN and off I go. The image gets deployed, I log in as local administrator, join the machine to domain - from there on out I can access it remotely.

How do I automate this last step? There is a guide on how to do it but it involves installing the fog agent etc - is there a quick nasty way to just throw a powershell in the startup of a local user to join the system to AD? (I am OK with storing passwords in plaintext - machine images only get deployed once every year or so, I can activate the AD account for a day and then disable it later).