AND WINDOWS XP SERVICE PACK 2
has published information for customers using its products
who are considering upgrading to Microsoft Windows XP Service
Pack 2 (SP2).
you may have already automatically received SP2. Please see:
are my procedural suggestions on Updates.
Suggestions For PC Updates
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.
Wait about 30 days for any serious bugs to become known and
fixed by Microsoft.
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).
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.
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.
checklist should include:
Making a full backup of the Registry FIRST
-Application names, versions, patch levels installed on that
-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
-The specific steps or sequence that was taken during the
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.
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.
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
changes must be taken very seriously and with considerable
planning, and practice AHEAD OF TIME.
Nova Business Systems, Inc. Reproduction of this article is
forbidden without prior consent from Nova Business Systems,