@c70m83 Just to try and see why exactly those three (PC24, PC08 and PC12) seem problematic you might try to connect those to other ports on the switch where you know that other PCs work.
As George said, PXE boot does not depend on Windows or any operating system. No matter what you have installed on disk PXE does work!! So if it used to work then something within your network / DHCP setup changed!
@lebrun78 I just had an idea. Maybe this is caused by a problematic entry in the DHCP leases cache file?? Take a look at /var/lib/dhcpd/dhcpd.leases. Not really sure what we are looking for but you might search that file for pattern 148.60.10. to see what leases are in the store. If you find something concerning than I would stop dhcp service for a second, make a backup copy of that file, edit and remove the problematic entry and start dhcp service up again.
As you seem to have a lot if fixed addresses defined you might not even care much about the leases. In that case you could even clear the whole leases file (stop dhcp before) and see if it makes a difference.
@jc35 So shutdown is not hanging anymore and fog-client functions as expected? Did you also test scheduling a power task to shutdown or reboot the machines?
The short answer is no FOG can not decrypt or encrypt any form of hard disk protection. FOG can clone encrypted hard drives in RAW (read slow) mode. FOG will not be able to resize images created in RAW mode. So RAW mode is a sector by sector copy so your target drive needs to be exactly the same size as the source or larger than the source. You do have to be careful of encryption that use the TPM chip. These types of disks created with these encryption tools can’t be moved between computers with the drives encrypted. The FOG server can surely clone them, but the target system won’t boot if the TPM chips don’t match.
Typically you wouldn’t encrypt the source disk, and then launch the drive encryption on the deployed image via a GPO policy. At least that is how we did it using Symantec HDE.
