Image too big?

[#1]

Our base (somewhat monolithic) image has gotten too big to put on a 40GB
hard drive. The compressed image file is just over 13GB and is around
25GB once installed. We are imaging with Casper Imaging using both
standard imaging and multicast streams. Both are having this same
problem. Is there any easy fix to this? Obviously the 25GB image will
work on a 40GB drive, but I no longer have an easy way to get the image
onto the drive.

Chad

[jarednichols]

Slim down your image and let people install from Self Service

[ernstcs]

That's what I was wondering...why is it so big? Are you talking just your base OS package or everything that gets installed with Casper Imaging? Are you caching packages locally then I assume?

My OS is around 3.57GB. I've stripped out printer drivers to be packages installed later as needed, as well as the languages.

Are you imaging from a Restore partition or while NetBooted?

Craig E

[stevewood]

You called your image "monolithic" in your email, which leads me to
understand that you have the OS plus all "common" applications installed in
the image and that is what you are laying down on machines. Like Jared
said, pull out all of those apps and install them Self Service.

My OS image is just that, the OS, with nothing else. I use InstaDMG to
build the OS image, then use Casper configurations to push the "common"
applications, with the exception of the Adobe suite. I push the Adobe suite
by a login policy. I put machines I am imaging into a Smart Group by naming
them a certain way so they automatically get added to a "Post Image" policy
that installs Adobe CS3 and all updates.

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

[#5]

I like the idea of layering Apps on top of the image, but for things like
Office 08, iLife and iWork its quicker and easier to just have them in the
image. We have thousands of computers to image over the summer and we use
multicast so we can do a high number of computers at once with limited
server resources.

I do have lots of other packages that we install via policy and casper
remote after the computers are imaged.

We do all of our imaging from netboot using Casper Imaging.

Chad

[ernstcs]

Quicker and easier because of the block copy you mean? I'd still prefer a virgin OS...just my opinion.

Craig E

[tlarkin]

Yes the block copy is faster in my situation. For example, every student machine has iLife suite standard on it, plus MS office, plus several other educational apps which we have district wide licenses for. Once you add that all up, it is like 10 gigs of software that need to go on a student machine standard.

Now when I start mass imaging (which will start tomorrow now that I got server side stuff done) and when I am imaging say, 25 macbooks at the same time AFP gets real flaky switching over to packages and when machines aren't all pulling from the server at the same time. Throughput actually drops.

I don't have a multi cast environment set up yet though. I for one don't have time nor do I have the right equipment all located together to do multicasting. So I am unicasting. That may be a major difference since with multi casting they would all be on the same page?

Anyway, in my experience last year imaging 6,000 Macbooks with a dual boot OS X and Win XP Pro image, it was way faster when we did a straight block copy rather than, the OS, then iLife, then Office, then logger Pro, then whatever edu app they have standard and so forth.

I think that the straight block copy may be faster with multicasting too, but I can't verify that. Don't get me wrong, package based deployment is bad ass, but when doing massive imaging in a short period, at least for me, the block copy of the all inclusive image performs faster as far as imaging times go.

Just my experience. I hope to have multi casting up and running by next year, and I also am hoping to integrate our edirectory with my Open Directory LDAP.....That of course is a whole other can of worms.

-Tom

---

Thomas Larkin
TIS Department
KCKPS USD500
tlarki at kckps.org
blackberry: 913-449-7589
office: 913-627-0351