For the reference image build out, I have our setup configured to build the reference image completely using a single set of task sequences. That task sequence lays down the image (on the reference image) runs the windows udpates, installs office, vc runtime libs, and all of the other applications then runs a final windows update. Without the windows updates I can build the reference image in about 20 minutes. With the windows updates it takes about 14 hours (no problem I just start before I go home). Then once that is done I sysprep the image and capture with FOG.
Now I didn’t mention the drivers. In our case when we setup the reference image, we tell windows to look in the c:\drivers folder for any drivers. Then during OSD (OS Deployment) after FOG lays the image down on the target machine we run a fog postinstall script that picks up the model of computer and then copies the right drivers onto the target computer (c:\drivers). That saves us from having 15GB of drivers (12 Dell models worth) inside our captured image. Our golden image is about 15GB in size using this process. Also we can add new models without having to recapture the reference image. We do rebuild the reference image once a quarter to pick up the latest windows updates and to include updated add on applications (i.e. flashplayer, java, etc.) when required. But with a fully automated reference image build there is no heavy lifting to rebuild the reference image.
@cml didn’t know that. Thank you but it didn’t work. When I update the group of all it doesn’t “encode” the password. Going into any of the hosts and clicking the “eye” shows the password in clear. If this is saved on the host then it correctly gets encoded (after clicking the eye).
@Wayne-Workman Good catch! I had exactly this in mind when I said that we had issues with empty disks with fogpartinfo. The new method (using lsblk) should work on empty disks. Would be interesting if someone could test this as well. Easiest would be to boot an unused client into debug mode. Then use the dd command from KKTwenty101’s posting to “murder the partition table”. After that try deploying (using the init files I posted) to that client.
seems to make no difference, PIGZ 0 actually slowed down to 300. so ive bumped it to 6 with 4 cores and 4gb ram and will simply live with a 40 min upload. Imaging was quicker though, imaged at about 3gb/min, old partimage was about 2gb/min
as for the server, htop is telling me that neither of the 2 cores are being taxed at all so the server probably could live with 1 core (im not starved of cores so not an issue for me).