@fogcloud Pxe boot has to get to the boot.php file. It does this over port 80 or 443 if you have https enforced. When you enforce https ipxe is compiled with the fog ca and the certificate generated by said ca as trusted certs within your local version of ipxe.
I’m not quite sure what you mean by restricting access only to the web UI. Do you mean close all other ports? Because that will likely break tftp and nfs as they use other ports and imaging and pxe boot will be broken. ipxe itself will be fine if you’ve booted to it outside of native pxe boot where the ipxe boot file (i.e. ipxe.efi or snponly.efi) is downloaded via tftp. ipxe then downloads the boot.php file from the fog web server and boots to it to get to the fog pxe menu.

@Tom-Elliott Was going to try, but discovered that after the last CHKDSK, the FOG Client wasn’t running correctly. Now I can’t uninstall or reinstall it correctly. I think for now I am going to re-create this image from scratch. I am speculating that since this was an older image that we had added onto several times, that a Windows update of some kind caused partition issues of some sort. I plan to format and install Windows from Scratch, and then build the image and pull it tomorrow. If this works I will report back with my findings.

In the meantime, are there any logs that I could send that would help you or anyone else who also finds themselves having this issue? Happy to assist in any way I can. I sincerely appreciate all the support and assistance on this.

@Tom-Elliott I believe you are correct. I ran a CHKDSK /F and it repaired the disk, but now I am faced with a new error. It claims “could not allocate new MFT record: No space left on device” and several other issues. Not sure where to go from here other than perhaps start a new Fresh Windows image?

@Tom-Elliott

Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!

@Tom-Elliott So, does that mean I need to add port 80 and 443 to an inbound TCP rule on the machine I am trying to capture from? The client seems to not pick up the task no matter how long I wait. I assume it shouldn’t take more than 60 seconds or so.

Thank you for helping with this.

@Tom-Elliott said in Cannot capture image: run lists overlap:

nfs-kernel-server

I am getting this error in 1.5.10.41 after updating. I am running on CentOS 8. I restarted my NFS Server, but that didn’t seem to do anything. I noticed that the NFS “interfaces” were pointing to something other than my servers interfaces so i changed those to match what the server says is the network interface. Not sure if NFS interfaces are something different or they should match as well? Any assistance on how to troubleshoot this would be great as I have an image to capture and at this time can’t accomplish that.

We are a FOG Server school, and we utilize the .13 client. We are on version 1.5.10.41 which we recently updated to. When we attempt to start tasks, the client on the machines don’t seem to execute the tasks regularly. I am thinking it is because we are missing firewall rules on the machine we pull the image from, but am unsure. Are there specific ports we should be adding on the client itself in Windows Firewall? If so, what are they, and are they inbound, outbound, TCP or UDP?

Any assistance would be appreciated. We have the FOG client itself in the Windows Firewall inbound list, but doesn’t seem to have changed anything.

@MatMurdock You can also do a full host registration and that allows you to set the group and the snapin associations at registration and kick off the image from there.

I use the API powershell module (see my signature) and have created custom functions and powershell tools to manage most my assignments. That takes a bit more work to get setup at scale but gives you more customization options.

Starting fresh, well depends on how fresh, the best answer depends on how you’re going to use Fog. Like if these are all brand new computers that aren’t in any other system yet, then doing quick reg on them all might be best.
I myself do full registration and inventory for new hosts. If all your computers already exist on the network or in Active Directory you could get the host information and import. Many moons ago I made this host scanner example https://forums.fogproject.org/topic/9560/creating-a-csv-host-import-from-a-network-scan?_=1721413305258 that will create a csv of all hosts and their macs on your network in the provided subnets.
If you can get them all in before hand, then mass-setting the snapins would be much easier.

@MatMurdock A newly imaged machine will automatically deploy any assigned snapins.

The design is flexible and you can do it in many different ways but here’s a general example that would utilize a group.

• You have a group named ‘Group A’ with computers you want to image with the same image and join the domain in the same ou and have them use the same bunch of snapins
• You assign the image via group management, they all now have the same image
• You assign the AD information, they all now have the same AD info
• You assign some snapins, they all now have those snapins assigned (in addition to anything else those hosts already have assigned, you could also do a group remove of all snapins first if desired)
• You push the task to deploy or multicast deploy on the group
• All the machines in that group now have a deploy task for the image and a deploy task for the snapins associated

@MatMurdock That is correct.
If git pull gives you trouble (sometimes happens on upgrades) then do this within your git folder (i.e. /root/fogproject)

git fetch --all
git checkout working-1.6
git reset --hard origin/working-1.6
git pull

Then the cd bin and installfog.sh are good.

Also lols to CrowdStrike