Deploy wim images with fog
-
I have 400 machines, half linux, half windows and fog is a nice tool to deploy all types of system.
Wim files are easy to create but not easy to deploy without sccm and I don’t have any AD in my network.
Would it be possible to deploy wim image with fog. -
@lebrun78 You post confuses me a bit, typically FOG is uses to deploy copies of complete systems and not just the install “media” for systems. A wim file on its own is not very useful, you need the installer program to do something with the wim file.
I created two tutorial for doing what I think you want, but I’m not sure.
- PXE booting a MDT ISO file (which MDT uses a WInPE environment to deploy a wim image) https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog
- PXE booting into the Windows setup program https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup
-
@lebrun78
My fog server is used to boot winpe and then launch setup with unnatended xml file to automatically install windows…
i think that you can boot winpe environmnent from your fog and then deploy wim image with dism command automatically too. -
I know this is an old post, but I wanted to clarify one thing. A WIM file is much more powerful than just being an install media. A WIM file basically holds all of the information for the “C” drive. Case in point, the Kace K2000 (an Enterprise deployment appliance) uses WinPE to deploy WIM images to systems. It allows you to inject software and drivers without having to re-capture the entire drive. This allows for a faster deployment and more options.
I would love to see FOG integrate WIM images for Windows deployment. I would even be willing to donate to a fund to make this happen.
-
@eseelke The short answer is, it isn’t going to happen. The WIM files are windows centric. You have to remember that FOG is based on linux, and the engine that writes the image files to disk [i.e. FOS] is linux based. FOG/FOS uses partclone to capture image files, that can be expanded or compress dynamically (to a certain point) based on the size of the target media. I do agree that there would be value in integrating the WIM file format into FOG, but not enough for the developers to spend their time on. FOG has a very fast working solution today.
But, yes, if you want to tweak the golden image you can’t do it from the captured file like you can with a WIM format. The other thing you have to be aware of is that FOG supports more operating systems than just windows. The wim format is (very) windows focused.
[Edit]
Well after the above response I did a little google-fu and found there are linux libraries that support reading and writing wim files. ref: https://wimlib.net/ Briefly looking at the document it appear it is possible. I guess I’ll leave it up to the developers if they are interested, possibly for FOG-too. As for me my initial reaction still stands. -
@eseelke - @george1421 covered many of my initial reactions. With that said, I would be interested in seeing a benchmark of any performance loss (or even gain) of WIM vs FOG’s sector-level clones. As of right now the latest benchmark we’ve seen is that FOG is capable of deploying Windows 10 in about 2 minutes with well configured images, high network bandwidth, and fast hosts/clients.
I believe that we likely wouldn’t integrate WIM into the 1.X series. We are hoping to make some key architectural changes to FOG with the 2.X series, and as @george1421 mentioned, 1.X is “locked into” partclone, as the entire codebase is built around the assumption of its usage. FOG 2.X would have the potential to support non-partclone formats, as we are hoping to make it more agnostic in terms of what it ties into, so it may be worthwhile to investigate.
-
@Joe-Schmitt @george1421
I’d like to mention here, that WIM is something more the just another imaging format.
It could be used to provide something like snapshoting. I remember people were asking on this forum for backup feature. From wimlib site - WIM allows storing multiple “images” in a single archive, automatically deduplicates all file contents.
It means we capture base image, and then after some changes to the system, second capture will store only the Delta to the base image. Images are kept inside single wim file, so we can call a given image through its index.
I can see wimlib project is actively developed(11.2018).
Is there any chance to have WIM supported in ver 1.x? -
@AndrewG78 said in Deploy wim images with fog:
It could be used to provide something like snapshoting. I remember people were asking on this forum for backup feature. From wimlib site - WIM allows storing multiple “images” in a single archive, automatically deduplicates all file contents.
Understand I’m not speaking for the developers these are my own narrow minded opinions.
- First FOG is not a backup tool. There are many other free backup tools that are more robust and have better features than FOG (veeam endpoint backup comes to mind).
- FOG already has a functioning disk imaging tool in partclone. To switch to or add support for another imaging format, it would have to provide something that the FOG Project developers thought was needed or would give fog a technical advantage based on its project mission. Remember the developers work pretty much for free (donations are always appreciated), so implementing a new “anything” would have to motivate the developers to do so.
- WIM format is owned by Microsoft. I searched a bit, but couldn’t find if it was covered by any GPL license or is it encumbered by some patent rights? I see that wimlib supports WIM format, but its still not clear about the legality of using it in a FOSS application. The last thing the fog project wan’t to do is irritate a corporation with deep pockets and teams of lawyers.
- Its not clear from searching if wimcapture/deploy supports operating systems other than MS Windows. If it does then that kind of breaks concept of one appliance for all.
Again these are only my opinions on the matter. I don’t see any value in adding wim capabilities to FOG. The developers have a very limited amount of time these days. Working on a niche functionality for an unsupported use of FOG might not be a good use of their time.
BUT with that said, on the surface it doesn’t look like it would be too painful if someone understood programming to add that capability to FOG, if they were so motivated. If it worked, I’m sure the developers would accept the code addition.
-
@george1421
Thank you for your input.
1.
Format is opened to anyone.
https://www.microsoft.com/en-us/download/details.aspx?id=13096
Microsoft says:
This paper defines the internal format of a Windows Imaging (WIM) file format. This information may be used to build .wim file creation or extraction tools, or other WIM-enabled applications.
2.
Wim is not for backuping only. From wimlib site "
imlib can be used to back up, install, or restore Windows operating systems; to create customized images of Windows PE; or to archive files on either Windows or UNIX/Linux.
"
3.
Although I’m a java guy I could take a look on wimlib integration. Could anyone point me out where to start? -
@AndrewG78 You are right, it definitely sounds interesting.
Although I’m a java guy I could take a look on wimlib integration. Could anyone point me out where to start?
I don’t think integrating wimlib into FOG/FOS is a good way to start this endeavor. Have you done any testing using wimlib yet? For example I would start by preparing some kind of live Linux (guess Debian or Ubuntu should do) USB stick that has wimlib on it. Grab a PC with Windows installed and see if you can capture WIM images from the command line. Best if you have some kind of NAS around that you can mount and store the images on. That’s pretty close to what we do in FOG. Do the same with partclone and compare image size and speed of capturing.
-
@Sebastian-Roth
1.
This is a very new idea. Did not have chance to test wimlib yet. Next week will do so for sure.
I have Samba NAS , will try with centos.
2.
Another interesting wim usage scenario:
WIM keeps in the A-image base Windows + B-snaphot with drivers + C-snaphot with sql server.
And you decide what you want to restore after the Base. So for a host1 u have A+B. For host2 A+B+C.
Instead of 3 images you must keep only one image +2 deltas.
