We are working towards a most stable release of the 1.5.x line of FOG and will publish release candidates of FOG 1.5.9 for this over the next weeks. We ask people to participate and help test to get the final release as good as we can.
Well first let me say there is no definitive guide on this. To put it in the simplest terms, FOG doesn’t care about the target OS. FOG only copies disk blocks from here to there and back. Now if you bring the FOG Client into scope the FOG server can reach into the target OS to do things post deployment.
With that said, if you want to get to a single click deployment with FOG (regardless of the tareget OS at the moment) you can get pretty close.
There is a process I call “Load and Go” that allows system manufacturers load a target OS on a system with just a few menu selections. System rebuilders can use this process because once the target computer is imaged the FOG server will never see (typically) this system again. In this “Load and Go” work flow the system rebuilder pxe boots into the fog ipxe menu one time by using the F10/F12 boot menu and selecting pxe boot. That target computer will then pxe boot into the FOG iPXE Menu. From there the system rebuilder will pick “Deploy Image” and then selects the image name from the list of images loaded on the FOG server. From there the process is automated by a FOG Post install scripts that prepare the target system before the first boot of the OS. These post install scripts connect to the target computer’s disk and make any adjustments to the ini or cfg files needed to prep the system for the target OS’s self installers. In this Load and Go case you don’t register the target computer with the FOG server, because the fog server will never see or need to manage the target computer after imaging. The FOG client is not installed on the target system either since there is no need to manage the computer with FOG post deployment.
As I said the FOG Client isn’t installed on the target image nor is the target computer registered in FOG. This load and go process saves on these steps and time. Because the FOG client is not installed on the target computer (it technically could be) but not registered with the FOG server, the target OS will need to have all of its configurations set before the first boot of the target OS.
So lets say in the case of MS Windows, to use this process you will need to use an unattend.xml file. That file will contain everything needed to configure the system post OOBE/WinSetup. So your fog postinstall script will need to update the unattend.xml script to properly name the computer as well as connect the computer to AD. This is one way we deploy on my campus. I can use either the “Load and Go” method or the traditional register, image, deploy, manage route. It depends on the use of the target system on how we deploy the system.
I have some tutorial on post install scripts that go over the basics and the second link is a bit more step by step to set it up.
@OkeriKai said in "Language french" invalid stockage group:
Un dernière question, quand est-ce que la version 1.5.9RC2 sera t-elle stable ?
I don’t have an answer for that. The more people that test 1.5.9RC2 the more happy the developers are to move it to stable. Just don’t forget to go NOW and change the branch back to master so you don’t forget later and wonder why things are not working good.