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.
@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
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.
I wouldn’t see it as something to go in the next release, as you say it will complicate things.
It would help in cases were the imaging process fails, and then the host auto reboots and loses the log. A debug will allow you to see the error if it happens again, but uploading it to the server would make it available via the fog console without the need to deploy again.
My first thought was to do it via http, which would give the server the option of ignoring it if space was an issue, or it could be made a configurable item.
@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.
Just a thought reading the following post.
https://forums.fogproject.org/topic/8239/windows-10-image-won-t-deploy/32
If partclone terminates unsuccessfully, assuming it gives a relevant exit code, would it be worth uploading the partclone log, /var/log/partclone.log to the fog server.
It could even be uploaded for every deploy, just keeping the latest.
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.
I used round robin, it gave both speed and resilience, however that was on an unmanaged switch.
@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%
There are a couple of thing to understand about mapped drives and processes running as the system account.
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