Keep windows updated, automatically

[Guus]

This seems like kicking in an open door, but how many computers running Windows do you know which aren't updated properly?

Windows Update itself has been updated, for the better, imho. One of the better new features (apart from the layout change) is the new Windows Automatic Updating, a feature that replaces the older Critical Update Notification. The name change reflects the new features: instead of just getting a message whenever a new update is available, you can install the update immediately! A small set of options is available, giving you control over when or if you will be notified, and when downloading starts.

As far as I've checked, these new updates are applicable for Windows 2000. If I'm correct, new XP machines already had these features available to them. I'm not sure what happens when you try to update any older version of windows (NT, ME, 9x). I don't have any computers available here that run those OS's. Could anyone give those a try, and report back what happened?

Update your system now. Visit http://windowsupdate.com.

[Leviatan]

Windows XP boxes can be setup to auto update themselves, as far as I know, a NT 4.0 domain controller I have at work whas not able to auto update itself, but then again NT 4.0 won't be supported anymore in a few months.

[VanEck]

yes but you must take into consideration that these patches can seriously harm your system and make it unstable. microsoft will release many hotfixes and patches that have not been properly tested, but are meant to just show an effort on their part. only major service pack releases have gone through microsoft's "rigorous testing" and are thought to be safe. but again, these service packs can seriously harm your system as well. they have not been tested with everything that a user can have on their machine. service packs are better to install with a fresh load of windows, as the first thing installed. when installing on a system that has been in use for some time, it is wise to backup all important data!

[Guus]

Then again, if i have to choose between a buggy bugfix or no bugfix at all, I'm choosing the bugfix.

[Leviatan]

Yes but some bugfixes can seriously screw up a system, I once went through hell just after installing a fix that Microsoft had pulled off the net later on after finding out that it made systems unstable.

[gold eagle]

Guus - you may want to keep an online system configured the same as your production units.
then regardless of os, when fixes, patches etc come up load it onto that unit first. This has worked for me for years without nasty surprises, and yes, on occasion, a vendor supplied patch has destroyed it.

[Guus]

The tricky part there is, that most of our computers here are online systems. Since we connect to a highspeed network, we're a populair target for most warez-sharing scriptkiddies. So, still, to fix most exploited bugs, we run every microsoft patch, buggy or not. It's better to have a new, unexplored security hole than an old one, which is exploited by every rootkit there is.

Apart from this, could someone point me to buggy Microsoft (w2k) patches? Which ones exactly are those, and what is the bug in the patch itself? This is not a challange, this is just an ordinary request for information.

[mohaughn]

That I'm aware of right now there are no security related hotfixes out from MS that have any adverse "bugs." However, the latest IE security hotfix does not actually fix all of the bugs that it claims to fix.

The last hotfix that contained an error was I believe the first IIS rollup hotfix.

If anyone is curious as to how MS tests hotfixes, this is the development cycle of a fix. I work for a large company, and we pay a lot for the support we have(dedicated engineers), so my experience with MS is a little different than those of people who call in to the regular 800 number for support.

1) Problem reported to MS. They will usually gather all data from the person reporting the problem and then rebuild the environment in which the problem occured and try to reproduce the issue. Once the issue is reproduced they will expand their testing to find out if the bug affects any other aspects of the software. This is usually done by PSS support engineers, or Alliance(dedicated) engineers.
2) The problem is then handed off to the next tier of support, called CPR(critical problem resolution). The CPR engineers are the ones that actually go through the code and write up the bug report. The bug report usually contains a detailed description of how the software should act, how it acts because of the bug, and what code needs to be changed to get the desired functionality. The bug report is then given to the development guys.
3) Dev writes a "buddy-fix." CPR and PSS/Alliance test the buddy fix in their lab to make sure that it fixes the problem in a lab environment. If it passes this step, some minimal testing is done to look for issues and then it is given to the customer reporting the problem. Sometimes MS will not be able to properly reproduce an issue, in these cases MS will ask the customer to actually install the "buddy-fix" themselves. If the buddy-fix resolves the issue, it is turned into a hotfix, and then bundled with the GFE installer.

As someone stated earlier, very little compatibility testing is done with hotfixes. I would venture to guess that security hotfixes, as they go out to a larger population, receive better testing then non security related fixes.

Here are some handy guidelines that I think anyone using MS hotfixes should follow:

1) Never install a hotfix the day it comes out. Give it a couple of days for the testers at places like bugtraq, etc... to check it out. Chances are that at the time of the patches release very few people will know how to exploit the problem. Definitely there will not be any script kiddies tools or auto exploits available at the moment of release. If, on the odd chance the risk of being exploited is really high, you might want to consider a quicker install, but only when testing has been done.

2) Test everything in a non production environment. If you install a hotfix on a production webserver and end up crashing the server, you are the one to blaim. Not testing things is just as bad as not being worried about security threats in the first place.

3)Realize that hotfixes are order dependent. What this means is that if you are building a new system make sure you know what order you should install the hotfixes in. This is very easy to determine. Basically you just look at the file versions. If two hotfixes contain updates to the same file, make sure you install the one with the higher file version last. If you are only installing security hotfixes, the date of release is a good order to follow. Again, this plays into the testing part. If you do install hotfixes out of order, it is probable that your system could still be exploited.

4) Perform full backups before and after(different tape) installing the hotfix. If the machine is of a highly critical nature I would suggest verifying the backup prior to installing the hotfix. Verifying a backup consists of taking a test machine and restoring the tape there. This requires an identical(or very very similar) hardware platform.

5) If you are doing this for a company, make sure you communicate the need for the fix, and possible problems to your management. If the fix is buggy and the above steps do not catch it for you, you do not want to have your management suprised that the server was even being upgraded at all.

6) Keep track of all changes. It is possible that a fix may break something small, having a detailed account of all changes to a system can aid in troubleshooting problems later on.

[Guus]

Ah, now I see why VanEck got so exited. He was talking updates on servers, I was talking updates on desktops. Yes, I fully agree, blindly applying all patches on critical systems or servers is a bad idea. Thanks for the construtive post Mohaughn, it's a good read.