So I was bringing my systems up-to-date and applied SRP1 to my W2K SP2
Active Directory Controller/Exchange Server/DNS box. Merrily installs,
prompts for a reboot, I say "Yes"...boom!

Machine is an IBM and it reports a POST error 176, "The system has been
tampered with!", and locks itself up tighter than a drum (and no, I
didn't have any of that wonderful BIOS security stuff enabled on the
box, but it said it anyway).

SRP1 kills IBM NetFinity's I could easily decry.

...except for the fact that it just happened that the internal cover
switch failed, pooched the motherboard, and had nothing to do with SRP1.

Its highly likely that the readers of NTBugtraq have more than 100,000
NT/W2K machines under their control (or within their purview) and so its
also likely that some of them aren't being perfectly taken care of, or
are dying as we speak due to myriad reasons. No doubt they sometimes die
after a reboot after applying a patch, let's face it, you reboot for
that reason more often than any other on a server.

My point is this. Microsoft have said to me in the past, and I concur,
when a patch appears to cause a problem with your server its more likely
that it wasn't the patch that caused a problem, it was something else
prior to the patch that caused the problem.

Now I'm not saying this to discourage reports of problems with patches,
on the contrary, I hope I get them always from all of you.

I would, however, suggest that if you are going to apply a patch that
requires a reboot, you may wish to consider rebooting the system prior
to applying the patch. I know, "that's an extra reboot, and I can't even
afford one!"...but even if you could only do this on one of your systems
you may find a pattern emerging. The pattern may be that one particular
server, or set of servers, has problems sometimes with patches while
others don't. That might point to one particular admin who just can't
afford a reboot after a change, installation, or patch application and
so always uses the -z switch or says "No" to the reboots. It might show
that particular brands of servers need patches prior to some MS patches
(like Compaq's with RAID controllers, say). It might show that a
server's drive was full prior to the patch installation, and it didn't
survive the reboot.

Finally, there's PSS, Product Support Services. If you encounter a
problem applying a patch, you call PSS ASAP! They're the ones who are
able to diagnose the problem and identify the solution. If there is a
problem with a patch, they *have* to get involved. Yes, it costs money
to call PSS unless you already have a support contract, but problems
related to security bulletin patches are reimbursable. So, you whip out
your credit card, shell out to get to an engineer, and when they
identify the problem as being the fault of the patch, they credit you
back the money (usually in the same day if its easy to identify the
source of the problem). Of course, if it turns out that the problem
wasn't related to the patch (as in one of those things I mentioned
above), you're stuck for the fee.

If you do contact PSS, send me a note with your SRX number. I can then
get that to the right people in MS so they can track your support call
and, if it's a problem with the patch, get the bulletin pulled ASAP (or
revised).

Hope this helps some of you.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]