After asking, if IT departments were too slow to patch Windows, we asked our readers to participate in a survey about Windows patching and the results are in! Despite efforts to automate patches, patching Windows computers, both servers and clients, are still an incredible time sink for IT departments.
Best Microsoft MCTS Training – Microsoft MCITP Training at Certkingdom.com
There were several IT people who pointed out a major problem in patching Windows is that the server then needs rebooted and often cannot be done during the day. Of the 171 responders, more IT departments test patches before rolling Windows updates out than don’t, but the average amount of time that it takes to roll patches out after Microsoft’s Patch Tuesday seemed to vary quite a bit.
Question 5 was, What are the main reasons that would cause you to delay rolling out a patch longer than 24 hours after Microsoft releases it?
Custom software came in as the main reason it would take more than 24 hours to test and deploy patches. Yet not far behind was the lack of manpower to roll out critical patches; testing less-imortant patches ranked lower in priorities. And very close behind was the fact that people frequently find that Microsoft’s patches cause issues with software and resolving those issues often took more than 24 hours. “Other” ranked as the next reason, followed by IT departments which have regulatory requirements that require time-consuming tests of each patch.
This is where the comments came in and an overwhelming clarity of how much patching stretches manpower. There seems to be a great unhappiness that patching requires rebooting the server which usually means it must be done after normal working hours. Here are some of my favorite comments you submitted along with this survey.
*PLEEEEASE find a way to apply a patch without rebooting the whole server? C’mon, it cannot be that difficult.
Microsoft+Adobe+Java+AntiVirus+Mozilla (Firefox+Thunderbird)+OpenOffice … it just takes too damned long!
Patching is hard but necessary. I wish companies like Microsoft and Apple were legally liable for buggy and insecure software.
The biggest hurdle is getting an outage time from the business to reboot the servers. By the time you’ve patched the servers (500+) I find we then have a week before the next lot of patches come out!
I find that an increasing number of patches don’t work immediately. On the other hand, MS gives support for that…, but it’s 2 hours gone in smoke.
Soon after I took over we went from requiring 12 people to each spend 12- 20 hours to patch servers, we went to needing 2 people to work about 6 hours each using scripts. After I was moved to other tasks, they resumed the previous manual process. Production PC’s are patched a month after they’re released, and production servers are patched twice a year.
My company relies on our supplier to patch machines. The last update blocked me from TRUSTED spreadsheets on our internal network. It took our company no time to shut the real value of our workdown.
Way to long [expensive] and fraught with danger of hosing a server.
It’s not just about Microsoft anymore. The real time wasters are the other patches (Adobe, Firefox, Quicktime etc.)
Patching windows machines is more involved than simply Microsoft patches, unless you don’t run other software.
Another big issue is patching critical machines after hours. Some things cannot be rebooted during the day so I am required to reboot at night.
It is core to our operational success – but it is a major labor hit for our patch team which also is responsible for numerous other duties as well.
Let’s face it. Microsoft’s insecure systems cost us untold billions of dollars each year not to mention the overload that they place on the internet infrastructure of the world.
THIS IS WHY WE ARE CONVERTING TO LINUX ACROSS ALL SERVERS AND CLIENTS THAT JUST NEED BASIC OPERATIONS.