@joshua_mchugh George’s mention of using a post install script to do it is more advanced but very worth the effort. Having it domain joined via sysprep specialize simplifies things in the long run.
That being said, you’re probably misunderstooding groups, because they’re a little confusing. Groups in Fog do not dynamically update the OU of the host members, but it can be used to set the OU in bulk on members. There is a plugin to change the behavior of groups if you want, but I’d try it the normal way first.
But if you set the OU on the host, then when it joins the domain via the fog client, it will be in that OU. It will not move a host to a different OU, unless you do something like manually leave the domain and change the computer name and then the fog service will rename the computer back to what it is in fog and then join the domain in the set OU.

I personally use a post install script now that grabs the OU from to host and Injects that into my unattend file. I believe I’ve posted some examples in the past. If I remember tomorrow when I’m at a computer and not a phone, I’ll link them.

@John-L-Clark what version of fog are you running?
I would also suggest enabling the Mac address pass through.
You could also try an older ipxe file

@argylega have you restarted the Mariadb and apache services, or the whole server?
I also assume you mean you can’t login to the website. Is there anything in the apache error log?

@joshua_mchugh I’m not sure if there is a good and proper way to do it but there maybe some way to go about it.

If you use an unattend.xml file that file and windows can place the computer into the proper OU. The idea is to use a post install script programmed in bash to dynamically update the unattend.xml script at deployment time. You can’t use fog group per se to do this since they are really “set groups” where the groupings are only used to bulk update parameters. But if your OU can’t be calculated you can use the user fields in the host record, and or the image name could be determined in the post install script.

I’ve got some examples of how to calculate a host name and OU based on the target IP address of the computer being imaged. This isn’t your solution but shows you what is possible in a post install script in the links below.

https://forums.fogproject.org/post/69726
https://forums.fogproject.org/post/69725

In one section of the links above it shows how to post a question at deploy time that could change how the OU path is calculated before the unattend.xml script is updated. The last tip is to use a post install script to leave bread crumbs behind so that the setupcomplete.cmd or the first run section of the unattend.xml file can find and integrate into an OU path. At one deployment we had to first set the target system’s OU to a clean OU used specifically for imaging because the OU GPOs would break OOBE/WinSetup. Once the system was fully configured we use the unattend.xml auto login and first run section to call a VBS script to read the bread crumb (info saved in a text file) to then finally move the computer to the correct OU.

None of these are proper, but as they say if all you have is a hammer, everything looks like a nail.

@tatanas Let me ask why are you renaming the host in the windows UI? Do you not know the actual name of the system at imaging time?

Second question: are you using the fog client service at all?

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

@Mightmar Just a few points of info to give you.

1. iPXE is managed by a different project than the FOG Project. They have a quicker release cycle than the FOG Project so they will/may support newer hardware quicker.
2. When a specific version of FOG is released it contains the current version of iPXE at the time a specific version of FOG is released.
3. If you manually update iPXE using the following instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe and then reinstall FOG 1.5.10 it will replace the updated version of iPXE created by the previous script with the version shipped with FOG 1.5.10. This is by design in case you make a change that breaks FOG you can always fix it by rerunning the FOG installer putting back the FOG files to a known good state.

So to say it another way, if you find issues with iPXE not supporting certain hardware, I would always upgrade the version of iPXE first and just remember that if you reinstall FOG it will replace the updated versions of iPXE and the FOS Linux kernel with the ones that were shipped with the current release of FOG. While I don’t know what the current release of FOG is I believe there are sub release later that 1.5.10 that fix a few discovered issues.

@alexamore90 Lets try to unpack this.

You have 3 ESXi servers connected to an unmanaged switch.

This part is a bit unclear. After deploying on a few pcs the speed dropps to 900mb/min (watch your unit of measure). Normally its up to 22GB/min (again assuming you are getting this number from partclone).

After deploying to a few PCs the speed drops. Is this simultaneous deployments or consecutive deployments the speed drops?

Unmanaged switch: So this isn’t an enterprise class switch. You may have issues with throughput on the switch itself. The aciscs might not be fast enough for the amount of data your are trying to push through. Look at the throughput listed in the technical documentation for the switch.

You didn’t mention the uplink speed from the ESXi servers to this switch. On a well managed 1GbE network you should get around 6GB/min throughput. On a well managed 10GbE network I’ve seen 13-15GB/min. So your 22GB/min seems a bit higher than expected. I can say with a physical FOG server connected via 1GbE link, I can saturate that 1GbE link with 3 concurrent image deployments. When that happens the error rate increases and the throughput drops off quote a bit.

The other thing if you are trying to do concurrent deployments with these 3 FOG servers, make sure the drives on ESXi are SSD or NVME drives and not spinning disks for performance reasons.

In the end I don’t think this is a FOG server issue specifically, rather something in the environment that is causing the speed issue.

@ALV_SUPECOLES This seems to be similar to this thread: https://forums.fogproject.org/topic/17759/ipxe-initialising-devices

In this case uefi firmware was updated then iPXE stops at initializing devices. If compiling and installing the latest version of iPXE doesn’t solve the problem then we will have to wait for either iPXE developers or Lenovo to fix the problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@nicolas-moraes We have to be careful some Soho routersthe don’t behave well with pxe booting. Some will put its IP address as the boot server even if you have dhcp option 66 configured. I don’t know the edgerouter, but if there is a bootp option make sure that is turned on too.

The edgerouter is based on vyos so it should behave correctly. Make sure when you define dhcp option 66 its the IP address of the fog server and for dhcp option 67 the boot file name needs to be all lower case. Make sure you don’t have a leading or trailing white space in the name.

If you have double checked everything then get a witness computer and load wireshark on it. Make sure you setup a capture filter of port 67 or port 68 start the scanning then pxe boot the computer until you get the error message then stop scanning.

What you are looking for is the DORA sequence
Discover (sent by target computer, akin to hello world, please configure me)
Offer (sent by one or more dhcp server, I would there to be only one of these and from your edgerouter).
Request (sent by the target computer)
Ack/Nack (sent by the dhcp server)

The interesting packet will be the OFFER.

Look at the packet, there should be an ethernet header section with the following fields.
Next-Server: this should be the IP address of your fog server (this is the bootp part)
Boot-FIle: this should be the name of the ipxe file to load.

If either of those are blank some pxe clients will not boot if they look at the bootp fields.

In the dhcp options section you should see option 66 and 67 that should mirror the values in the bootp part.