To build your scripts, you would work in debug mode and get them pieced together in there, then save them to the server from there. While in debug mode, you can get a listing of all variables with printenv and also George worked hard to get some more data exposed to the FOS engine.

Even though fog.postdownload runs for every deploy, you can within your script create conditionals for only this computer or that model and so on.

A popular use is to place driver files in the needed spot.

Other uses might include - putting specific installers onto the c: volume, placing configuration files for software, or as George does, modifying existing files on the disk like the unattend.xml file to set within it the proper computer name among other things.

The fog.postdownload script gets called on each deployment. This is the master script where the deployment admin can choose what happens, its a bit of an external hook into the deployment process. The important thing to remember here is the fog.postdownload script runs from the FOS engine (from the perspective of the target computer). If you need access to resources you need to mount them in your fog post install script. Be it local disk or nfs mounts back to the fog server. The post download scripts must be programmed in bash to execute on the target computer. This is linux so you may not run any windows commands in the post install scripts like DISM.exe.