FOG 0.33 Requirements
-
a dev will have to chime in for that, but for me its not even an issue. as i always use sysprep
-
We don’t use sysprep :(.
We manage 230 images, and is impossible use sysprep in all images.
And this requirement will be a big problem for us. -
damn that’s a lot of images!! why so many may I ask??
Currently I only manage a few, well only deploy one image really to all our pcs/laptops.
-
Last time I spoke with any of the devs about it we thought it was an issue with the /bin/fog script in the boot image.
Here is the diff between 0.32 and the latest SVN change for that script: [url]http://freeghost.svn.sourceforge.net/viewvc/freeghost/trunk/src/buildroot/package/customize/fog/scripts/bin/fog?view=diff&r1=729&r2=891&diff_format=h[/url]
We’re not 100% sure that it’s a bug in that script, but it seems the most likely.
-
We use FOG to deploy our images in the university. We have more 40 centers (faculties, high schooles, …), 270 IT rooms and 6300 computers and 60 diferents users. Until now we have used REMBO as clone solution, and most of our images are monolitic (one IT room, one hardware, one software => one image). Change the work philosophy is very dificult and slow
-
ah I see, makes sense.
in comparison we are a tiny school lol and have around 500 machines, at least 6 different types of hardware but I still only use one image.
-
I know this isn’t really on topic with the original post, but we currently manage images based on hardware and applications, so even if we deploy the same hardware to users at the high school and junior high, because they have different applications, they have different images. I prefer a as little work as possible after imaging. Right now that involves installing asset recovery software, logging as the targeted end user, initializing a few applications, and freezing the computer with Deep Freeze.
I tried using FOG snap-ins to deploy some of the software after imaging, but I ended up spending more time verifying the installs worked and troubleshooting the failed ones than I saved by having fewer images to maintain. Until I find a robust, EASY and foolproof way to deploy applications and user settings, having mostly complete images for each hardware base and application group wins.
-
Hi,
BryceZ, the problem is only with monopartition resizeble images? -
Correct. Resizable images do not use the cloned systems disk geometry and try to replace the MBR with a standard copy; for some reason this is no longer functional.
-
As monopartition images in W7, we understand a W7 image with: 100 MB W7 special partition + XXX GB W7 system partition, no?
-
As I understand it, 0.32 can handle both scenarios with and without the 100MB partition.
-
[quote=“BryceZ, post: 10239, member: 2”]As I understand it, 0.32 can handle both scenarios with and without the 100MB partition.[/quote]
Yup, I can confirm this. Currently we’re doing W7 with the 100MB partition, but we were doing it without the partition just a couple months ago.
-
And FOG 0.33 beta can resize W7 sysprep monopartition images?
-
Correct. It seems to have no problem with a system that has been sysprepped.
