SOPHOS AND WINDOWS XP SERVICE PACK 2

Sophos has published information for customers using its products who are considering upgrading to Microsoft Windows XP Service Pack 2 (SP2).

http://www.sophos.com/support/knowledgebase/article/1732.html

Also, you may have already automatically received SP2. Please see:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2aumng.mspx

Below are my procedural suggestions on Updates.

August 16, 2004

General Suggestions For PC Updates

I would NOT install ANY update, other than critical security, when it first is released. Microsoft has too much history of having to change and/ or fix bugs. And, you need to have a very clear plan of testing, and implementation, before you go installing updates on all the computers.

1) Wait about 30 days for any serious bugs to become known and fixed by Microsoft.

2) Install on ONE workstation that is typical, but NOT in everyday, normal use. Use that workstation to test all of the applications that are in use by any (every) workstation. This means there has to be a list of (approved) applications that are OK to be installed and used. Testing should verify that every application continues to work in all respects. For example, that Sophos Anti Virus continues to update on its regular schedule over a period of at least a week, and that the anti-virus protection is still functioning (by using the eicar test file).

3) After the documented list of approved applications have been checked off, and a reasonable period of time has passed, and there are no known issues that have come up, and that a newer version of the update being tested has not been released, you can now schedule the deployment of the update. The deployment should NOT be done all at once. No amount of testing can prove that unknown issues do not still exist. (Which is why so many Microsoft updates break things.) I would deploy a major update to not more than half of any department at one time, at least a week apart. That way an entire department is not put out of operation if something unexpected happens.

4) Before deployment, there must be a specific checklist. This will serve as documentation of exactly what has been changed, the date it was changed, and the
specific PC on which the change was made. This information can be of value if an
issue comes up later.

The checklist should include:
Making a full backup of the Registry FIRST
Documenting:
-Application names, versions, patch levels installed on that PC
-Operating System version, build and patch level
-Existing Microsoft O/S patches (Not the same info as above)
-Whether that users data should be backed up before proceeding (Make a
conscious decision)
-The specific steps or sequence that was taken during the update.

There should be a plan of recovery if something goes wrong. The plan must have
been tested first. If you do not know that you can get the users PC back to exactly how it was before you started, do not start. You can not know that you can "recover" a users PC unless you have a written plan of what to do, AND you have practiced that plan and have confidence based on actual experience of doing it.

NEVER use a procedure unless you have practiced it in a test environment first. For example, are you proficient at restoring a registry from backup on a PC that will not boot, or just continuously cycles booting, because you have done it enough times to know that you can do it when under the gun (versus having read about how to do it and think you can). If you don't have known, tested, recovery diskettes, you don't have a chance. If you don't have a plan, good luck.

The above is NOT an exhaustive list. It is a suggestion for a starting point. In
a business environment with real users that have to get work done, making
changes must be taken very seriously and with considerable forethought,
planning, and practice AHEAD OF TIME.

©2004, Nova Business Systems, Inc. Reproduction of this article is forbidden without prior consent from Nova Business Systems, Inc.