Best posts made by jbsclm

I did one a couple of years ago, you could give it a try to see if it still works.

The zip contains an iso which you can burn to usb, and also instructions on how to build it.

https://forums.fogproject.org/topic/4253/physical-boot-disk-for-imaging
0_1448223513202_ipxe_ask33.zip

@Tom-Elliott Hi Tom. since we use the mac address as the unique id for the hosts, then the file could be named mac-partclone.log.
If it overwrites any previous file for that host then there would only ever be one file per host, I don’t know how big the file is, but given that images are gigabytes, then it shouldn’t be that much data (relatively) even with many hosts.
Even better if it could be restricted to when partclone fails.

Regarding the error at line 10, perhaps the reg key was already removed by the avg uninstall command at line 4, but I can’t see why it would be different in a window.
Also for line 25 to work, the “domain name\domain computers” group will need read and execute access to “\naswin\deploiement$”
From experience, calling msiexec under the system account can sometimes fail if you don’t have "ALLUSERS = 2 " in the arguments, it depends on the msi.

There are a couple of thing to understand about mapped drives and processes running as the system account.

1. A mapped drive only exists in the process which maps it, so mapping it a startup script will not make it available to later processes. You need to always refer to the share by its UNC path.
2. You will need to ensure that the share you are trying to access has read and execute permission set for “domain computers” , the client system account belongs to this group.

@Wayne-Workman another thing to be aware of is that when you run as the system account, you won’t get the full environment that a normal process would get. It would be better to state a local path in full, rather than rely on environment variables, particularly in the case of %temp%

@x9rok
It is some while since I last used it, but from what I remember, if there was no task for the PC you should get the FOG menu, which would then time out after the period set in the FOG GUI, if you didn’t select an option.
If you don’t get the FOG menu then it may be that the ipxe script needs changing to pass extra parameters to boot.php.
If the reboot is caused by the timeout expiring, then it could be that the network card is left in a funny state by the previous boot attempt.

As per the comment from george1421, you don’t need to change the boot order, F10 or F12 should get you a boot menu, depending on the BIOS. We used Dell PCs, and it was F12 for them.
You really don’t want usb at the top of the boot order, as if you forget to change it back, it is security hole.
It is worth making your BIOS password protected and only having Hard Disk on the boot device list, that way only authorised people can boot from anything other than the Hard Disk.

Don’t forget that the machine account in AD has a password, this gets changed on a regular basis, this happens invisibly, it is a function of the way AD words.
From memory it gets changed every 30 days, and as I say is completely invisible to users and admins, the last changed date can be read from AD via LDAP, although it needs a bit of work to translate it into human readable format.
If you image a PC without sysprep, when you deploy that image it will not join the domain if the machine account password has changed.
This will need the PC to be deleted and re-added to AD to resolve.

Another thing to test would be the memory on the FOG server.
From experience, undetected memory errors can lead to the symptoms you describe, i.e.random fails of CPU/memory intensive operations.
If this were the case I would also not be surprised if you were getting strange errors reported by the OS, e.g. sigsegv