How do fog images work and can it do this?
-
Does fog work like SCCM where I can build 1 generic image and use it for multiple flavors of hardware? How will it know what drivers need to be added to the system if so? I’m looking for a solution for building systems on our MSP side of the business and can’t use SCCM because of licensing and frankly SCCM is slow and clunky as it is. The big thing i’d probably miss with fog is the ability to pick and choose what software is added to the system. Is fog able to join systems to a domain? What about patching after deployment? I’m guessing no so how do people handle this? Thanks!
-
@C-M said in How do fog images work and can it do this?:
Does fog work like SCCM where I can build 1 generic image and use it for multiple flavors of hardware?
Yes, but you would prepare your image before hand to do this with the right drivers and generally sysprep is in the mix, but some have done this without sysprep.
The big thing i’d probably miss with fog is the ability to pick and choose what software is added to the system.
FOG has a feature called snapins, that you may deploy to computers via the fog client. Snapins can be something as simple as an MSI, an EXE, a batch script, anything that can run silently can be made into a snapin. FOG can also manage printers.
Is fog able to join systems to a domain?
Yes, via the FOG Client. It also can name computers for you during the imaging process and post-imaging for computer renaming later - joined to the domain and not.
What about patching after deployment?
There are snapins, which can run scripts and MSIs and EXEs. Other than that, you can setup a WSUS server which comes standard with Windows Server 2012 and up, and if you are joining to a domain, you may have this already. Not sure if Server 2008 has it.
-
Great thanks for the info. I’m used to sysprep and ghost from long ago but using SCCM is a bit different since you just give it a windows cd image and it basically does an install for you then installs software or any other things you want. In this regard it sounds like fog works more like ghost. The good thing is the newer versions so windows seem to contain most of the drivers you might need for newer systems so there won’t be as much fiddling with drivers probably. I did look at the snapin stuff but didn’t see a way to deploy additional software. I need to look more into the client I guess but I was hoping for a system that did not require anything installed on the systems to be imaged. Most will leave our premises and possibly never return.
-
@C-M said in How do fog images work and can it do this?:
Most will leave our premises and possibly never return.
If you will not be in charge of managing computers after they are imaged, you probably shouldn’t be using the fog client. And without registering computers, you can quick-image.
There are similar outfits to what you’re doing that use fog to get the job done, people who salvage and resell computers use fog. Generally they buy/get old computers by the pallet and quickly build an image for the models and then image them all quickly.
We’re here to help you along and answer questions if you want to give fog a shot!
-
@Wayne-Workman Sounds great thanks again for your quick replies!
-
@C-M Lets see where to start. (I did quickly read through Wayne’s most excellent posts).
For your setup I would go about it this way.
First setup MDT to create your reference image in a VM. ESXi is the best choice, but you can use vm player (watch your licensing), or hyper-v. This is only to create your reference image. If you use the light touch method, once you start the image creation process the next time you touch the reference image is when you sysprep it. You can have MDT install the OS, run windows updates to download and install all current updates and then layer on any applications and then finally run one last windows update. We use this method to create one thin image (OS and updates only) and a fat image (OS, updates, and all applications) using the light touch method. Understand it take time to setup this environment but once it’s done we can build a new reference image each quarter without any pain.
Drivers: One comment you can either let MDT add the drivers to your reference image or do the hackish way to load your drivers. If you let MDT do it you will have to add every driver for every combination of hardware you will deploy your image to. In my case that’s 15 model of dell computers. The hackish way to do it is via a post install script where you will copy the correct drivers to a certain location on the target computer based on the model of that computer. Then on first boot of the target computer it will detect and load the drivers as needed. If you are working as a MSP I would go with the thin image (and then have your custom apps layered on after) or one fat image per client, but that is up to you.
Once you have the reference image build and sysprepp’d then pxe boot the vm into the FOG menu and capture the image. From there you just deploy as normal.
In regards to connect to the domain, if you don’t use the fog client then just use the unattend.xml file to connect the client to the domain. That is how I do it for one environment here. I can’t have any non-MS software on the target computer, so I just let the unattend file connect the computer to the domain and the right OU.
-
@george1421 Oh so MDT will work in conjunction with Fog? I’ve never tried to run it outside of SCCM but its currently what i’m using to load drivers and apps into our builds with SCCM after the initial deployment. I’d prefer the thin method as it seems easier to keep up to date and add and remove apps at will.
-
@C-M Yes use a standalone MDT server to build your reference image in a VM and then sysprep. Then capture the vm by pxe booting into FOG. Works very smooth.
-
Also, this might still be a thing
https://wiki.fogproject.org/wiki/index.php/Auto_driver_InstallHave you tried the FogApi powershell module? It's pretty cool IMHO
https://github.com/darksidemilk/FogApi
https://fogapi.readthedocs.io/en/latest/
https://www.powershellgallery.com/packages/FogApi
https://forums.fogproject.org/topic/12026/powershell-api-module -
@Arrowhead-IT I can say that is what I started with for my postinstall scripts. I can say if you use dell drivers, then the model cab files will take you a long way to a dynamic image deployment. All you need is a dmi query to identify the target computer you are deploying to, to copy the right drivers to the target computer post imaging.
-
@george1421 said in How do fog images work and can it do this?:
@Arrowhead-IT I can say that is what I started with for my postinstall scripts. I can say if you use dell drivers, then the model cab files will take you a long way to a dynamic image deployment. All you need is a dmi query to identify the target computer you are deploying to, to copy the right drivers to the target computer post imaging.
We really need to dig into that deeper…
-
@C-M said in How do fog images work and can it do this?:
I’d prefer the thin method as it seems easier to keep up to date and add and remove apps at will.
Both thin and fat images have their place. If you update your images every quarter (to have the latest windows updates) then adding in your software is not a big deal (as long as MDT does it). There isn’t any more work involved than having a thin image and layering on the applications post deployment. Plus with a fat image I can go from bare metal to fully deploy and ready to move to the work site in about 13 minutes. That is with MS Office, SAP GUI, AutoCAD, and a few other PIG applications.
Using a fat image (and a multicast deployment) I can redeploy to a whole lab (50 workstations) in about 20 minutes. With that said there is also uses for thin images where you might have a dynamic application load. In that case we push the image out with FOG and then use PDQ Deploy to deploy the application set to the workstation. (I could use FOG Snapins for this too, we just had PDQ Deploy setup first).
