Deploying Vista SP1 or Not. That is the Question!

Deploying Vista SP1 yes or no? That is the question. And it is a hard question.

You can download the service pack, and install it on your test machine. Does it run great? But do all your applications run on it? It is very hard to test all of it. And if you test all of it, did you really test ALL of it?

If you are sure you tested, you roll out a couple of key users, and then? Yes probably a couple of applications fall down. They are not Vista service pack 1 compatible. The users can go home for a couple of days because you have to rollout the computers again. And that is something you do not want. It takes time, costs money, and it is a boring job.

So, I have a solution that can help you much further. Altiris is not supporting this, and I also do not support it, but it is a great way to rollout service packs and patches without the risk of going down. You can get the service pack in real live on real machines, with real users without the risk breaking their machines down.

How to do this?

First of all, download the servicepack from Microsoft. Do this on a Vista machine, because on XP or Windows 2003 Microsoft won't let you download it.

Place the download on a packaging machine were SVS is installed. Start SVS, and create a new package. Give the package the name you like, and then do a global capture. The Vista service pack 1 creates multiple PID's during install, so in a single program capture you miss a lot of the service pack.

After building the package, you can export the package. Now you have a package of a service pack. You can now import it on the machines you like to test it. Be sure the hardware of the packaging machine is the same as the hardware you deploy it on. Vista Servicepack 1 contains hardware components, and deploying the package to other machines will stop.

The package you have now imported emulates a Vista SP1 machine, and you can let some of the keyusers use it in real. But remember!!!! The machine is not actually updated. It only thinks it is. All the older DLL's that are potentially insecure are still on the machine. But your software and the OS will think it is updated and will actually use the newer redirected DLL's.

After you are convinced that all software runs on the machine, you can delete the package and do a real update. Now your machines are updated, and you do not have the risk that machines or software will stop working because of the service pack.

I use this method for servicepacks and for updates from Microsoft. In previous times I often encountered bad updates. Now I can test them in a live environment without having the risk that machines will stop working.

Again remember that it is not smart to update all machines with virtualised software. Updates, servicepacks and Virusscanners are not recommended to virtualise.

If you wish to do this also for updates, then take on machine out of production. Every week on Wednesday, Microsoft always brings updates on Tuesday, I start Windows update on this machine. I do not install the updates, but first do a global capture for the machine. Then I click update the machine. All patches and updates are now automatically captured. The package will not be very clean, but because it is only for evaluation or testing, I do not care.

The package can then be deployed to the key users, and you have a very good reference before pushing the updates to the entire corporation.

Regards
Erik Westhovens
www.dvs4sbc.com