Systems Deployment

INCLUDE
I include all basic standards that I consider should be part of a deployment. AV, Spyware, Office should be part of it and let altiris do the rest..Also, I take into account to remove any specific client guids from the sysprepped image that accompany any software client. I then update the image quarterly basis and track the updates through the life of the image once tested properly. I find it is the best procedure and fastest to keep abreast of imaging deployment.

Sure the script is pretty simple and is ran using group policy and leaves a tag on the workstation so when the same user logs in again the script checks for the tag and if user identifier is located in the tag it will not run. I will not get into much details about but basically the script will force an update from a wsus server and depending on which group the user is in will install a custom set of apps just for that user. If another user logs on that is in a different group the script will install different set of custom apps just for that user. But neither user can use other user's set of apps. There is no need for the users to have local admin rights to the box. Everything is taken care of by the combination of the script, group policy and the wsus server. Anything that would need admin rights is already taken care of within the image itself.

keep in mind the software set are internally developed so there is no licensing issues and if any updates that are needed are done upon launching the app.

Sorry for all the edits

A balance of both techniques is usually the most efficient solution. For ease of maintenance, the operating system and the applications should be kept separate, and building individual machines in this way really does not take that much more time. However, if deploying an operating system update, it makes sense to build a tactical image with all the standard apps included (at the latest revision levels) and deploy that image to gain the benefits of a speedier build.  Subsequently, additional or replacement machines can then be staged individually using the base image and the latest revisions of all required app packages.

I work on the principle if it goes to everyone it goes into K2000, in saying that the baked in WIM image is Windows with all its patches and Office with the same. Every else is a post install or deployed via K1000. Image patching Office with all its security updates 12 months down the track if you installed it like to do VLC or 7-Zip.

I think this is a judgment call and a balancing act really-- an automated installation of Office is not quick and needs to go on every computer so it seems obvious to me. However, I've heard others insist that simplifying image management is more important to them. If you automate the generation of your image (as I hope everyone does) then updating an image is not a very painful task. I say if everyone gets it, put it in the image.

I agree with bkelly. It really is a judgment call. I include the basic drivers and plugins on my base image. If we didn't have Altiris, I'd include a whole lot more on the base image but with Altiris I let the applications install separately after laying down the basic image.

I say if everyone gets it, put it in the image.

Wow, I find that answer quite surprising. I thought the whole concept of application packaging was to install and update application independently of the OS.

I exclude software packages religiously.
Even if everyone and their brother gets it today, what 'cha gona do if:
- software configuration requires change (e.g. point it to a different server, or change a setting)
- software needs an update
- software no longer needed
???

You end up doing the same work twice. Doing the same work twice only pays off if you're hourly [:D]


BTW, rather than have poll options as "Yes/No", can we have them as "Include/Exclude"?

RE: >> I exclude software packages religiously.

Amen to that.

RE: >> BTW, rather than have poll options as "Yes/No", can we have them as "Include/Exclude"?

Yes, ageed!

I did not answer the poll question. I would assume Yes=Include and No=Exclude
But you know what they say about assumptions! [;)]

I agree with jsantiago. If you know what you are doing you can work around any install sources having moved, if config changes need to be pushed, etc. and if you work in a large environment it makes the imaging process a little quicker for the techs doing the daily work.

I agree with Jsantiago as well. I have tried both ways and found that having base packages installed already was faster than doing the OS image deployment only then installs. The way I set my images up I don't really need to touch the image at all. If things change I have a one time logon script that runs that corrects any config issues.

...[font="courier new"]one time logon script? Would you mind expanding on this?
And, I assume, your every user has admin rights to make system-wide changes, too?

Yes, I do the same as InternalPower. Often will not even use the log in script though, but will link a batch file to the GPO which uses the IF EXIST filename command syntax (IF EXIST can also be negated by NOT before condition or filename). You can use a tag file like InternalPower does, that is one common method. The one I prefer is to have the IF NOT EXIST check for a file that you know will exist only if the app is already installed. If the file is not there, the command will run. If the condition is not met it will go to the next command in the batch file, etc.

Here's and example of a member learnig to do just what I mentioned :)

http://itninja.com/question/need-to-uninstall-jre-1.5.0_14-from-domain

I guess it all depends upon the technology used to create images. We use a product that is based upon Microsoft's BDD 2007 framework, so of course an image is just the core OS compiled into a image file (.wim). Then we've created application roles that allow us to determine what machines get certain applications after the core OS has been applied to the system. I guess if Ghost (or a similar technology) is being used then a thick image capture of the OS with all the appropriate software would have to be done. Also numerous images need to be maintained for different hardware platforms if Ghost is used; with BDD/OSD (and I'm sure with many other imaging technologies from the last few years) one master image is created for all hardware platforms.

While there is no MS supported method to make multi-HAL compatible images with 2k or XP, it is quite easy to do. I've built one single image for both of the last two enterprises that I work for.
The BDD method of installing apps after the OS is nothing new, it uses a mini-SMS client and works pretty much the same as RIS combined with SMS always has. .wim images can also contain preinstalled applications. You are just using a different tool (ImageX) to capture the image, and the image is not sector based but rather in the .wim format. You can still customize a default user profile, install applications, and sysprep the image just as you always have.

To add to what angryasianantelope stated, and to respond to danr29, sometimes a "thick" image is needed, and a multi-HAL capable image is possible (we use XP Pro 32-bit here). Our image works on every D-series Lattitude and every Optiplex we have (Lattitude D410, D520, D600, D610, D620, D630, D800, D810, D820 -- Optiplex 240, 260, 270, 280, 620, 745, 755).

We have two images. One for faculty/staff (has Office, Firefox, flash/shockwave/quicktime, and Adobe Reader), and one for students (has nearly 70 pieces of software installed, with TONS of customization).

We use this method because the machines are imaged, at most (and barring HDD failure) once a year. The students have a mandatory profile that is downloaded from one of our domain controllers at each login (about 16mb of data). I use SMS to send out certain software like PowerDVD (since each model of dell, and even machines within each model, came with a different version), Flash/Shockwave, Quicktime, etc. Any "errors" that didn't get caught during image testing (hey, no one is perfect) are corrected via SMS also.

We have somewhere in the neighborhood of 890 student machines that get imaged each summer. We can't have so many computers flooding our poor SMS server (which also serves as a database server for some of our applications) each time the machines are imaged.

Right this moment we are using Symantec ImageCenter with a DOS boot floppy (loaded from a recent UBCD build I've created) to automate everything (it allows the student workers or other technicians to select which server they image from (currently there are two), which image to drop, to back up a machine before it is replaced, etc).

Included but still add software where it is needed. We build a number of different images as virtual and can just update them as needed, then resend them to k2000 after they are sypreped.