In case anyone else has this question, the Reports tab serves this purpose. Once an AD user logs into FOG and starts doing things, the history report will log it.

Got it working! This worked for me after making sure the drive was changed to GPT and I also labeled the efi parition as “EFI”:
menuentry “Windows” {
insmod chain
insmod ntfs
insmod part_gpt
set root=(hd1,gpt2)
chainloader (hd1,gpt2)/efi/microsoft/boot/bootmgfw.efi
}

Just realized that the set root part is redundant. I am partitoning the drive now to copy the files from the FOG USB key then tell the UEFI on the PC to boot from this new GRUB partition first. Looking good!

@londonfog as long as you don’t put any custom files in /var/www/fog you should be good. I have pmagic on my fog ipxe menu and put the files in /var/www/pm11_winpe and the permissions for the files are correct.

This is what my ipxe menu item parameters look like:
set tftp-path tftp://${fog-ip}
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU

Try updating the Kernel drivers? I’ve seen varying ipxe performance from different hardware. For example, I’ve seen ipxe boot faster on an Optiplex 7020 vs 3020 which is a newer model.

Success! Dropped the files into /var/www and used set web-path to ${fog-ip}. In case anyone else has this issue this is my iPXE menu item parameters:
set tftp-path tftp://${fog-ip}/os
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU

@george1421 There wasn’t any doubt on my end…but I can imagine you read that and said to yourself “of course it did…”.

@sebastian-roth Sounds good. My NEW secondary FOG server is up and running on 20.04.

@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.

@mcana66 What I did was create a file in /tftproot called autoexec.ipxe and put this in:

#!ipxe
ifopen net0
dhcp net0

chain ${boot-url}/scripts/menu_EFI.ipxe

This is for my FreeNAS box that I use for other projects and testing. You can chain any ipxe script (or any boot script like boot.php on the fog server) you want from there. The ${boot-url} variable is set in the default.ipxe file also located in /tftproot.

@rogerbrowntdl dnsmasq runs on the FOG server to detect architecture and boot type then serve the boot files over tftp. This is my understanding of how it all works:
PC sends DHCP server a request for an IP address with a pxe packet.
DHCP assigns an IP address then directs (relays) the PC to the FOG server.
FOG Server handles this request by sending either undionly.kpxe or ipxe.efi depending on the architecture of the PC (dnsmasq tftp service).
PC downloads and executes the correct file.
After that FOG loads the boot menus.

@george1421 Thanks! I wonder if a chat bot could help with reading through what worked and make a tutorial.

@george1421 I’ve been reading through it but it all looks like a conversation/experimentation/testing more than a tutorial on how to get it working in FOG. I saw a link from that thread to getting NFSv4 set up on Linux but to get it to work in FOG is the key I need. Was there a specific post or posts that show how exactly you got it working?

I didn’t want to necro the “Feature Request NFSv4…” post. Has anyone successfully got NFSv4 to work properly with capturing and deployment?

@Tom-Elliott said in Hide/Secure FOG Client download page:

Private key is built to the client at install time. The Public server ca cert is pulled at install time

This is what I was unclear about. I thought the installer already had FOG’s private key. So each client gets its own private key?

I noticed the page/url where you can download the FOG client isn’t locked behind a login/auth so in case anyone is looking to lock it you can add these lines to /etc/apache2/apache2.conf:

# Restrict access to FOG Client
<Location "/fog/client/download.php">
    Require ip <*ip or subnet/mask*>
    Require all denied
</Location>

# Hide Server info
ServerTokens Prod
ServerSignature Off

Restart apache2 service after making changes to apache2.conf

What this will do is restrict access to the FOG Client downloads to specific IP or subnet. I have mine restricted to my lab/imaging network. I don’t think it is a good idea to have this download available to all production network users. I’m not 100% sure (devs please correct me) but I believe the FOG Client has the private key embedded in order to connect to the FOG server via HTTPS. I wouldn’t want that private key extracted from the client installer.

Using Access Controls I use the Technician group to restrict the FOG Web UI down to bare essentials for field techs to deploy and capture images. How can I hide a Host group from the Technician user group?

@george1421 I see. So a basic script like (I’m paraphrasing the commands here) “get mac get userID get IP > log.txt” but from there it would have to write to the FOG’s reporting system right?

Currently we can see which user deploys an image to registered hosts but not to unregistered hosts. Why is that? Shouldn’t there be a way to record that an image gets deployed to an unreg’d host? At the very least a MAC address would be helpful. I use LDAP in my environment for FOG auth so theoretically I would be able to see which user deployed an image to this MAC. If an IP address can be reported that would be even better.

Bumping this topic. I too see the issue. I only see imaging events for registered hosts. I have a lot of field techs imaging unregistered hosts and need to have these events logged.

I had to make a correction. I meant to say pre-1Gbit internet not 10Gbit internet. We have 10G backbones (intranet) but not to the internet.