In a recent article, I discussed the advantages of and some techniques for minimizing the number of desktop images that an organization uses. Regardless of how well the image management process is streamlined, the images will eventually become obsolete. It's important to have an image lifecycle management plan in place before that time comes. In other words, you should have clear policies that dictate how and when images are replaced.
Reasons for updating images
Under what circumstances should an existing deployment image be replaced with a new one? In some cases, this is an easy question to answer. For example, if your company is planning to deploy Windows 7, then you would probably create a new set of desktop deployment images once Windows 7 is released.
The same might also be said for new applications. For example, if an enterprise plans to upgrade to Microsoft Office 2010 when it is released, or if its employees started using a new accounting application, then it should update desktop deployment images to include those applications. Of course the release of a new operating system or new applications isn't the only reason for updating desktop deployment images, nor is a new application (or application version) always justification for an image update.
One of the main reasons for using images is to minimize the amount of work involved in setting up new PCs. Remember that images become outdated very quickly as new patches are released. It doesn't usually make sense to create a new deployment image every time that a new patch is released, but it may make sense to update deployment images after a major hardware purchase.
Using a 6-month-old deployment image to set up a few new computers probably isn't going to be a big deal most of the time because a patch management system can quickly bring those systems up to date. Imagine ...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
what would happen, however, if you used that 6-month-old image to set up a thousand new PCs. You would probably overwhelm your patch management system, and you may have a support nightmare on your hands until the patch management system can catch up because all of the new computers would be in different, partially patched states.
Update considerations
When you are deciding whether to create a new deployment image, consider the amount of administrative effort involved. You must also take into account how long your patch management system would take to bring new computers based on that image to a current state.
These considerations bring up an important question: Should you create a new image every time you adopt a service pack?
The answer depends on a couple of factors. For starters, you need to consider how many images you have and how much work it is going to take to rebuild all those images. If you only use two or three images, then rebuilding an image each time you adopt a new service pack might not be such a bad idea. If you maintain a large number of images, then you're going to want to give rebuilding the images a bit more thought.
I recommend you always rebuild the images when adopting a new operating system service pack. At the same time, though, Microsoft releases service packs for all sorts of things, and some of them are going to be more important than others. For example, I probably wouldn't create a new set of images just because Microsoft released a service pack for the .NET Framework. I would probably just let my patch management system take care of applying the service pack. Of course, the next time there is justification for creating a new image, I would include the service pack (and any other patches) in it.
This brings up another point. Depending on how much work is involved, you may want to build a new set of images every few months to include recent patches in your images. There is nothing wrong with deploying an image and letting your patch management system bring the recently deployed desktop up to date. If the image is too outdated, however, the new PC may be left in a vulnerable state until the update process completes.
Furthermore, the update process may take a long time if excessive number of patches is missing. Since we can count on Microsoft to deliver a steady stream of new patches, consider creating a new set of images every three to six months.
Overall, image lifecycle management isn't an exact science and each organization is going to have its own unique image management needs. Even so, the best practices discussed in this article should help you achieve a balance between keeping images current and keeping the task of creating images manageable.
ABOUT THE AUTHOR:
[IMAGE]Brien M. Posey, MCSE
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). He has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Posey has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal website at www.brienposey.com.
