>At this time and even in the "critical days"
you'd better think twice
>before installing any new patches.
Thank you for your feedback. Unfortunately, I could not
disagree with you
more strongly. One of the big fallacies of holding patches trying to
achieve a consistent environment is if there is actually a bug in one or
more of those patches (as you seem to suppose). If you get to the century
change over and there is a problem with a COTS product, you may be forced to install the
patch that has that bug in it in order to fix a Y2K problem.
That is a position of much higher risk than if you had installed it earlier,
experienced the bug and worked through a fix (when you had more time and
resources to handle the problem).
When you experience a Y2K COTS problem and you call the manufacturer on January 1, here is
how your conversation will go: VENDOR: "Did you install the patches we instructed you
to install?" CLIENT: "No. I applied a
software freeze." VENDOR: "That is the end of our liability and ability to
help you, we can't support you until you install all the patches we told you
I have extensively looked at this issue (of whether or not to apply patches)
for my client. I don't have a copy of the paper I wrote for them (it
belongs to them), but I think I could summarize the results of the study
from memory. (Four days per week, I work for a consulting firm of about
What you have done with this blanket statement of freezing all software
patches is that you have said that maintaining a stable baseline is more
important than achieving Y2K compliance. IMHO, you need to achieve a
delicate balance between these two opposing forces.
There are basically two or three time periods that you need to consider
separately. On a separate dimension, there are also two or three categories
of software in each of those time periods.
The first time period are those patches that are released "long" before Y2K.
[You need to define the term "long" that is appropriate for your clients.]
Those you have time to test and verify proper operation. In general, I
recommended installing any patches labeled Y2K (or any patches that are
pre-requisites of any patch) after testing and approval by a CCB
(configuration control board) and holding patches that are not related to
The second time period are those patches that are released "shortly" before
Y2K. Those, there may not be time to test as thoroughly, but some minimal
testing and scanning for viruses should be able to be done. Again, hold
non-Y2K patches. Install Y2K patches and pre-requisites to Y2K patches (but not
pre-requisites to non-Y2K patches).
The third time period are those released shortly after Y2K has begun
(basically December 31 - January 3 or so). These patches are critical Y2K
problems - someone was working over a holiday weekend to get these out.
Don't take them lightly. IMHO, you need to install all of these after doing
a virus scan on the patch. If there is any basic functionally test that
can quickly be done on the patch, do it, but it is more important to get it
installed before further production processing than performing on-site
On the second dimension of the answer, there are patches for products that
do not interact with the custom developed applications [my client is a
development shop; for normal businesses, probably the equivalent would be
products for standalone systems]. These have a much easier threshold for
installing patches. In my recommendations above, you would probably install
either Y2K patches or non-Y2K patches about as easily. A typical example in this
category would be a domain name server or a backup utility - they
typically do not directly interact with anything else.
The second category of products are those which interact with in-house
developed applications by their nature. The most common example is the
operating system. Here is where you draw a strong distinction between Y2K
related patches and non-Y2K related patches.
If the users are responsible for the compliance of their own desktop, that
may be a third category that just applies to them.
Combining all these separate cases and eliminating duplicates resulted in
about five basic categories of whether or not to install a patches. I do
not believe you can make a blanket statement saying freeze everything
without putting your clients in extreme risk. Consider not having a
complete software freeze to be a risk mitigation method.
>I propose that very soon stop downloading and installing new
>service packs, unless you absolutely need those corrections
>that are offered by the vendor.
You need to make a decision now on how you will make that decision
after the turn of the century. The purpose of my original posting was to
make this issue well understood. If you don't have any method of finding
out (in a timely manner) that manufacturers have issued a last minute patch,
you have made that decision by default. You don't have a choice. I am
trying to give you the option of making a knowledgable choice to install
something that is absolutely needed.