Is FOG right for me?
-
Hello,
I was wondering if Fog is the right tool for me. I have a Windows 2012 server with tools and apps that I want to clone and push to 10 other servers via PXE. Would fog work for me in this scenario?
-
You really didn’t provide much detail to give you anything more than an educated guess.
With that said, I would have to ask a question back to you: Do you know linux (even a little?)
For 10 devices I might not go with FOG (if I did not already have the infrastructure setup).
Assuming that you don’t know anything about linux (only need to know for installation) and you are only installing 10 systems, I might just go the MDT route. (Now you didn’t mention if the 10 other servers were the same hardware or located in the same site/subnet). But again assuming they are running on the same hardware, I would just create a reference image using MDT and the driver pack for the hardware. Once you have the reference image built then you have to decide to capture the image with MDT, Clonezilla, FOG, or ghost. Servers are typically only built once per the life of the hardware, where workstations are typically setup between 2 and 3 times in its life cycle. If your only goal with setting up FOG is these 10 systems, you will spend less project time by just capturing the image with clonezilla or ghost.
Understand my goal is to not turn you away from FOG, but its to get you to the finish line faster. If you were going to deploy to 30 or 100 nodes my suggestion would be a bit different.
-
Hello,
I appreciate you taking the time and providing a well rounded response.
Just to clarify, I usually deploy Linux operating systems using our own custom pxe system however it lacks support for Windows server operating systems. I’m actually very comfortable with Linux. For first time in years we had a project come in requiring Windows server deployments.
Our initial deployment will about 10 but this will eventually be scaled to 100-300 nodes in our infrastructure. The hardware run on the same site & hardware (supermicro E3 Xeon servers) however the nodes run on different subnets, each isolated to its own vlan, and some even isolated to different switches all connected to our core routers. Each server is assigned a public /29 IPv4 address by default in its own vlan.
Would you suggest fog in this scenario?
-
OK with the linux comfort level much higher than the typical FOG admin has and your (eventual) intended scope I would say that FOG would work well for you (lin and win). The only concern I have right now is" Does the FOG OS (FOS) kernel support your server hardware. This support is required for imaging only. The issues I can see is support for the NIC(s) and any raid controllers used during the imaging process. The FOS image has support for the majority of the desktop hardware, servers tend to have specialized NIC and disk configurations. Once the OS is loaded then the client OS is your issue.
If you have locations/servers behind slow links (such as a site to site mpls/vpn) you may want to deploy storage nodes at those locations. Those storage nodes will contain the deployment image and the ipxe boot files for that location. The deployment is still managed from your master FOG server, but the deployment happens remotely. If you use the location plugin for FOG you can set up locations for each remote site, then assign storage nodes and client systems to those locations. This ensures a client will not try to image across your site to site vpn link.
So what to do next? I would spin up a test fog master server. The stable FOG release is about 2 years old. Newer hardware may not be supported with the stock kernels. I would update the kernels to the latest that are supported under 1.2.0 stable (I think they are 3.19.3) to ensure your hardware is supported. Ensure your proposed target hardware can pxe boot into the fog ipxe menu. Then run the compatibility test. This will tell you right away if FOG is a viable option.
If your target computers don’t boot well, I would then recommend you upgrade to the trunk release ( 1.3.0 beta). This image is still in beta state, and is a bit more like a 2.0 release than a minor upgrade. This environment has many more options than the 1.2.0 stable release. The developers are working hard to get the 1.3.0 solid. Right now they are working hard on EFI support which has delayed the stable release a bit.
