Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Installing Windows updates

Status
Not open for further replies.

JeeatTT

IS-IT--Management
Sep 28, 2008
23
GB
Hi,

I look after the day to day running of a Windows 2003 SBS Server.

I need to know what is "best practice" when it comes to downloading and installing Windows updates (the ones that come up with a yellow shield in the system tray).

The reason I ask is because of what happened yesterday.

My server is set to notify me of Windows updates I need - towards the end of the day I download and install them and once everyone's logged off I reboot the server.

I do this only because I didn't want that irritating nag screen coming up every few minutes (it seems) and I feared that I may accidentally click on "Restart Now" instead of "Restart Later" (especially as the buttons are identical !).

Yesterday, however, my IT Support company - during their weekly dial-in "housekeeping" - went ahead to download AND install the waiting updates. This has happened before, but thankfully the only problem it caused me was the irritating nag screen.

However, on this occasion one of the updates was a Security Update for Exchange SP2 and immediately all my users were disconnected from the Exchange server in the middle of their work - most were reconnected about 5 minutes later when the update was finished, one had to be manually "reconnected" for some reason.

I don't know if it's connected (though it'd be an incredible coincidence if not), but about 20 minutes later I started getting complaints from 2 departments that their jobs hadn't come out of their network printers (1 each dept). I looked on the server and there were no jobs in the queue, neither would my test page come out from the server. I knew it wasn't an IP issue as I could use the web browser to view the status of each printer. All the other network printers continued working fine.

A few hours later, the problem was cured by an engineer opening up the Services and re-starting the Print Spooler service (even though - as far as I can see - it hadn't stopped).

Could one of the other Windows updates (there were 3 but I don't know the names of the others) have caused this printing problem or is it un-connected ?

I'd really appreciate any feedback.

Regards,
Julia
 
There are two camps (at least) on this issue.

1. The "if it ain't broke don't fix it" group that has auto-updates turned OFF and analyzes each update for its value and potential to do harm. Many wait until the SBS community has has deemed them safe, or chooses to implement updates one at a time to evaluate their benefit.

I am of this school. I did not install SP2 until I put it on CD because, when doing a recovery using SBS backup, you need to return the install to the server's former Service Pack Level, and I wanted to be sure it was on a tested CD and backed up before I installed it. I usually install the "critical updates" one at a time on my SBS box, but all the clients are set to download and install critical updates automatically.

2. The "download all critical updates as they become available" which is the school of thought that your tech subscribes to. This is the "recommended" method by MS but you get a slew of updates installed at once, and troubleshooting a problem update could take a while. As a rule, most of these updates are heavily tested and very safe, but there might be some unique conflict between your server's apps and an update. As a compromise you could always choose "Custom" install and install the updates one at a time rather than as a group to see if there will be any issues.

Please note that I am not a schooled MS admin, just a SMB part-time sysadmin...take my advice accordingly [smile]

Tony

Users helping Users...
 
"Could one of the other Windows updates...have caused this printing problem or is it un-connected ?"
Yes... this weekend the latest patch release caused a Terminal Server Gateway RDP issue at a client.

Most of my clients have WSUS for Windows updates. At my largest clients, I manually select the updates to install after a week or two of the patches release, this gives me time to obtain feedback on forums relating to patch problems. Generally releasing the patches to the workstations first, then a few days later to the servers

Like you I have issues with servers after patching, roughly every 2nd or 3rd round of MS releases causes small headaches, even with feed back from forums.
If there are issue with a patch round, I generally uninstall all the new patches and re-install the patches individually, this usually corrects the issue. If not I repeat the uninstall, install the individual patches, testing between each patch until the culprit is found.


........................................
Chernobyl disaster..a must see pictorial
 
Hi,

Thanks for all your replies.

Can I just clarify - is it ever *safe* to install the Windows updates on a server during the working day ?

I've always felt it was a bit risky, especially with 20 or more staff logged on.

But the IT support company I use at present clearly see downloading and installing updates as a routine task they do for lots of companies each Friday (they offer a weekly housekeeping service).

I'd appreciate a second opinion on this because I cannot afford to have Exchange "go down" on me again in the future or to lose some of my network printing capability (after the reboot the updates required I also had a problem with Routing and Remote Access service - it stalled and I had to reboot the server once more. This was very maddening as I had to come into the office since I couldn't log on from home!


Regards,
Julia
 
Patching is never safe, it just follows the rule of life, nothing is guaranteed.
Just from experience, I have not had an issue during the installs, just after the reboot. Actually I prefer installing during the day if it possible, after the normal work day( does not happen much). At least I can remedy the issue instead of a 40 mile round trip, as I had to do this last MS round due to one of the patches corrupting a few of the Terminal server's firewall configurations, locking me out(two trips).
At the moment the "if it ain't broke, don't fix it" philosophy is sounding pretty good. With off hours patching, half the time a patch round goes south, it's effects are not immediately apparent.


........................................
Chernobyl disaster..a must see pictorial
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top