Posts made by utopia

I agree with @george1421 about using Clonezilla for this. However, if you have a competent technician on-site at the remote location to perform the imaging tasks, then there is no scripting necessary. This is a good thing because the documentation related to scripting Clonezilla is a bit thin in places. So there can be some trial-and-error guesswork before you get it working the way you want.
To summarize the overall process without scripting:
Use Clonezilla to capture the image to be deployed. Depending on your requirements (for example sysprep if it is a Windows image) you may or may not need to deploy the image to a host from FOG first in order to capture the image from that host using Clonezilla. The reason for this (at least the last time I checked - which has been a while) is that while both FOG and Clonezilla use PartClone to capture/deploy images. The requirements for the files within an image are different between the two methods and so the images are not directly inter-operable. If anyone knows whether this has changed and can verify that they are now directly inter-operable, please correct me.
Also, you can capture a Clonezilla image directly to a USB flash drive. But I almost always use a local hard drive or network file share / NAS instead due to the relatively slow write speed when capturing to a USB flash drive. Once captured, then copy the Clonezilla image folder to flash drive(s). Also, I like to keep the images on a separate flash drive than the one used to boot Clonezilla. But that’s just my preference. Doing so will allow you to remove the boot media before the imaging job completes so you don’t have to wait to get started on another host. You will still need multiple flash drives containing the image, and you will need to use Clonezilla’s “to RAM” option in order to do it that way.
Lastly, of course, you will need Clonezilla boot media. The Clonezilla web site has various versions available along with recommendations on making the bootable media. Some of the tools I have used are: UNetbootin (to make single boot media), YUMI (to make multi-boot media), or if you have the time to dig in and do it manually go to the Syslinux project site to learn how it actually works.
So yes, while it is possible to script Clonezilla for automation, depending on your skills and intuition it may be simpler to train someone at the remote site to do it manually. For example, provide step-by-step instructions with screen shots of the various Clonezilla deployment steps.
I hope this helps.

@Tom-Elliott Thank you for the info. I apologize if “new feature” was the wrong term to use. I will take a look at the FOG Project Documentation as you suggest to see if I think it may be something that I can pursue myself.
Thanks again for all your fantastic work!

Getting a “Host Name” column in the Snapin Log report has been near the top of my wish list for quite a while as well. I have held back in giving my plus-one to this request since I didn’t wish to slow down the overall progress toward a final release of 1.3.0. Now that we have been in the RC stage of 1.3.0 for the past few months, I am even more reluctant to put forth such a request. But I have seen that new features continue to be added. And it remains quite cumbersome to have to check each host individually for state/return code when pushing out snapin tasks, particularly for larger groups. So at this point, I will ask “Would adding columns to the Snapin Log report primarily for Host Name, and possibly also Checkin Date/Time be overly burdensome or out-of-line at this late RC stage of 1.3.0?” Or even better, as @tian suggested, a pull-down column selection list for the web page and PDF export would be ideal. Some way to identify the Host Name in the Snapin Log is the primary goal. I thank you for your consideration of this. And I understand if it is not a high priority to the developers at this time.

@Wayne-Workman said:

DHCP responds with lease which includes next-server and boot file

I would suggest that you consider pointing out that this stage will include the response from the normal DHCP server and may possibly also include a response from a separate proxy DHCP server (if one is in use).