Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Microsoft IT

Time to End Microsoft's Patch Tuesday? 256

Posted by Zonk from the plenty-of-time-for-trickery dept.
buzzardsbay writes "Techtarget's resident security curmudgeon, Dennis Fisher, is calling for an end to Microsoft's monthly security patching cycle. Fisher points out that 'a hacker only needs one unpatched system, one little crack in the fence in order to launch a major attack on a given network. The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.'"
This discussion has been archived. No new comments can be posted.

Time to End Microsoft's Patch Tuesday? More

Time to End Microsoft's Patch Tuesday?

Comments Filter:

  • I have always wondered... (Score:5, Interesting)

    by AxemRed ( 755470 ) on Thursday May 10, 2007 @12:46PM (#19070863)
    Why don't they just release patches as the make them? Is there a specific reason that they hold them all until "patch Tuesday?"

    • Re: (Score:2, Insightful)

      by Pentavirate ( 867026 )
      So your machine only reboots on you when you're not looking once a month instead of every single day!

      • So your machine only reboots on you when you're not looking once a month instead of every single day!

        That pissed me off a couple days ago. I had stuff downloading overnight and scheduled SageTV recordings that got interrupted. I woke up to my computer at the login screen and thought the power must have gone out. Then the friendly green shield kindly informed me that it rebooted without my permission.

        That's the cue for me to disable the Automatic Updates service. The idea is good but the implementation is aw

        • Re: (Score:2)

          by Feyr ( 449684 )
          at least you were greeted by the login screen. i had one "reboot" for patches, except it didnt reboot, it SHUTDOWN. very nice when you want to use it remotely

    • Re:I have always wondered... (Score:5, Insightful)

      by kcurtis ( 311610 ) on Thursday May 10, 2007 @12:49PM (#19070939)
      It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

      If the updates come out on a random schedule, as done before, you cannot plan ahead for the testing required to ensure the updates don't break functionality.

      • That's the Problem (Score:5, Insightful)

        by bill_mcgonigle ( 4333 ) * on Thursday May 10, 2007 @01:13PM (#19071467) Homepage Journal
        It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

        Your comment is accurate, and gets to the heart of the problem. The current system minimizes cost, at the expense of security.

        The pundit would rather companies get more staff, do rolling testing, etc., whatever it takes - to maximize security.

        Now, as a non-user of Microsoft products and a victim of attacks by unpatched machines, some of them corporate, it's clear that the current strategy just shifts the costs off of the companies and onto me. If it just crashed their networks I couldn't care less. But it's more than that.

        So I need to side with the proposal - the users need to improve their security. They can do this by having rolling patches from Microsoft or picking a more secure product to use. I don't care how they do it, but they need to stop expecting me to pay for their poor performance.

        Unfortunately, liability is poorly defined in this realm, otherwise I could theoretically sue for damages, and their insurance company would make sure they were in good shape or charge them through the roof for being in bad shape.
        • No. They should make patches available as soon as possible. The argument that administrators needs time to test patches only makes sense if patches are available before rolling these out on production systems, whether patches are published a given day of the month or not doesn't change this.

          Making patches available as soon as possible, the administrators can schedule testing and patching as most convenient, maybe weekends are preferred for rolling out patches. And they can decide which patches to fast track
          • Microsoft itself is fairly insulated from liability issues with their licensing agreements.

            A business that knowingly delays deployment of a security-related patch for reasons of convenience, and suffers loss of customer data or other issues that would otherwise have been prevented -- I would not be so certain that the business itself would necessarily be invulnerable to lawsuits from injured third parties.

      • Re:I have always wondered... (Score:5, Insightful)

        by Matt Perry ( 793115 ) <[moc.oohay] [ta] [45ttam.yrrep]> on Thursday May 10, 2007 @01:28PM (#19071747)

        It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.

        If the updates come out on a random schedule, as done before, you cannot plan ahead for the testing required to ensure the updates don't break functionality.
        Nonsense. Companies are free to test and upgrade on a given day no matter when updates come out. I test patches and update my Linux servers once a month even though patches for said machines may come out at any point in time between my patch days. I make exceptions to this only for patches that we deem critical enough to apply outside of our schedule.

        • Re:I have always wondered... (Score:5, Insightful)

          by Kijori ( 897770 ) <ward.jakeNO@SPAMgmail.com> on Thursday May 10, 2007 @02:51PM (#19073313)
          When Microsoft releases a patch for an exploit, it's immediately known that computers are wide open to this attack. Malicious hackers - virus writers and the like included - can reverse engineer the patch to find out what vulnerability is being patched exactly, and know that, since your organization doesn't patch until such-and-such day, you're wide open to attacks. "Exploit Wednesday", the day after patch Tuesday, is a testament to the importance of Microsoft's patches in the development of exploits. Companies can't afford to gear up for patches every day, but can't afford to risk the ramifications of not applying a patch immediately either. Patch Tuesday gets them out of this catch-22.
        • They're actually not free to test and such... time taken out for this testing is time taken out of other projects and slipping deadlines. Sr. Management typically has tight expectations for timelines and budgets.

          With a predictable schedule, you can schedule resources up front to make sure you're actually addressing things without letting the major projects drop.

          Life in a large company is a different world.

          Plus, once you've announced the patches, you've increased the threat exposure by several orders of ma

      • Re: (Score:2)

        by Hatta ( 162192 )
        Obviously you don't have to install the updates as soon as they're posted. Just pick a day a month to do it all. Of course you'll be vulnerable the rest of the month, but that's no worse than it was when microsoft held the patches.

        • Re: (Score:2)

          by LocoMan ( 744414 )
          To be fair, it is worse because before it was a month where (in the best case) only microsoft knew of the patches, while then it would be a month that crackers had to reverse engineer the patches, find out what the vulnerability was, and take advantage of yet unpatched computers.

          Then again, since most home users don't update their computers as it is, that's what's happening already.

      • Re: (Score:2)

        by AxemRed ( 755470 )
        IT departments could still stick to a schedule though... They could apply all available updates once a month just like they do now. If a vulnerability is fixed a week after they usually do the updates, any IT department that wants to stick to a schedule can always ignore the patch until their next scheduled update.

        I have seen one example of how this could work at a university where I used to be employed. They disabled automatic Windows updates by default, and they had some 3rd party software that pushed o

    • Re: (Score:2)

      by OECD ( 639690 )

      Why don't they just release patches as the make them? Is there a specific reason that they hold them all until "patch Tuesday?"

      My guess is precisely to keep it a manageable, once a month job. I don't see how a patch-a-day is going to make IT's life any easier (although it would be a good excuse to hire more staff.)

    • Re: (Score:2)

      by rob1980 ( 941751 )
      If things are going to blow up, you might as well have it all happen on one day of the week/month/whatever - as every time somebody decides to patch something.

    • Re: (Score:2)

      by Rolgar ( 556636 )
      For system administrators, it allows them to only have to address patching Windows machines once a month. If they can do all of the testing, and roll all of the patches out in one go, then it makes using Windows less of a burden by reducing duplicated effort.

      On the other hand, if you're a Microsoft hater, you might think Microsoft is using this to hide how many vulnerabilities Windows has. If users had to reboot 7 times for this week's patches over the course of a month instead of just once a month, they

      • Re: (Score:2, Insightful)

        by Professor_UNIX ( 867045 )

        For system administrators, it allows them to only have to address patching Windows machines once a month.

        This is a stupid idea though. It saves the administrators some hassle, but if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it? Why should I have to wait a month for a patch to a critical vulnerability just because some company's IT department only wants to work one day a mo

        • Every company I've been at over the last decade has been stretched on resources, and my current employer much moreso than any before. While I have some additional control over systems that are my responsibility, and will apply updates as I find them, we have numerous fragile applications that have to be carefully managed in shutdown and restart, and they can take from five to fifteen minutes per system of engineer time in coaxing through a proper patch, shutdown, and restart. Spread this over several hund

        • This is a stupid idea though. It saves the administrators some hassle, but if Microsoft is putting out a patch for a vulnerability then don't you think that maybe, just maybe, the hackers already know about the vulnerability and are actively exploiting it?

          That's a nonsensical argument. You could make the same argument for any piece of software at anytime. So it's a useless factor in your analysis of the criticality of the particular issues addressed by any particular patch.

          Each individual user should be dec

    • Because om black wednesday when your clients start complaining about service failed to start and intermittent memory errors, you know to look for the toxic patch first rather than the more usual virus. Saves a ton of diagnostic time.

    • Re:I have always wondered... (Score:5, Insightful)

      by LurkerXXX ( 667952 ) on Thursday May 10, 2007 @01:39PM (#19071945)
      You always wondered? You must be fairly new to IT. MS switched to that format well within the past 10 years. I think it was around 5 years ago. Before that they released them as each was finished.

      As for why they do them that way now, their large corporate customers asked them to. In large corporate settings there are often lots and lots of in-house-developed applications the company runs. Each time a new patch comes out, the IT dept must go through a lengthy (sometimes several weeks) process of testing the new patch, on test beds of the various models/configurations of computers the company uses, to make sure it doesn't break any of those apps, or any other purchased applications. They often run into many bugs/conflicts that MS doesn't in their testing.

      If MS comes out with a patch, the company starts testing it out, then 3 days later MS comes out with another patch, the big corp now has multiple cycles of testing trying to go on at the same time, using up tons of IT resources, backing things up in the pipeline. If their testing cycle is 2 weeks, and MS releases 6 patches during those two weeks, the pipeline is now filled up with 12 weeks worth of throughput. Not fun.

      If, on the other hand, MS releases on a regularly scheduled day each month, the company can easily run their test suite just a single time, freeing up IT resources, and also letting them plan for the patches/testing, rather than being surprised and having to pull folks off of other projects to work on testing if MS suddenly goes on a streak of releasing several patches in a row.

    • Re: (Score:2)

      by SeaFox ( 739806 )
      It would more obvious to Windows users how insecure the product is if they made patches available as soon as they wrote them. Installing 5 patches at once has less negetive PR-effect that installing a different patch at 5 different times.

      I've heard people who say they don't update because they get sick of downloading patches, don't think they are of that much importance, etc. Maybe its because almost all the patches are for "critical venerabilities". It's like crying wolf after awhile. The term becomes mean
    • You're not in IT, are you?

      Try managing patches for a hundred thousand systems and you'll understand why less frequency is more important.

      So, why not release them as they make them? Two factors

      1) Your average large IT department is going to schedule the deployment,

      2) Once the patch goes out, all you have to do is look at the patch to see what it changed and you know there was an exploit in the previous version. As a result, looking at patches actually make it easier to find exploits.

      So combining the two, i

  • Volume of patches won't get better (Score:3, Interesting)

    by Dynedain ( 141758 ) <slashdot2&anthonymclin,com> on Thursday May 10, 2007 @12:50PM (#19070953) Homepage

    "The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time."
    "

    So the sheer volume of daily patches would make this better?

    Now, MS should take a clue from Apple and have a lot more "rollup" packages than they currently do.

    • Re:Volume of patches won't get better (Score:4, Insightful)

      by gad_zuki! ( 70830 ) on Thursday May 10, 2007 @01:02PM (#19071251)
      Patch day was started because administrators didnt want random patches being pushed out at random times. Its supposed to help the process by giving people a schedule, especially for people who arent using SUS.

      The real question is when are they going to patch the patch system. The 100% CPU svchost bug is killing me and KB916089 (and its predecessor) doesnt do squat.
      • I've had 10% of our company in my office in the last 2 days with that svchost BS. *sigh*
      • We have found the you should not acknowledge any svchost errors, just move the error message aside. Run 927891 again. Shut down. When it comes back up run sfc.exe /scannow. Reboot and then you should be able to run MS update.

    • Re: (Score:3, Funny)

      by Intron ( 870560 )
      To reduce the problems caused by the volume of daily patches, they could save them until a particular time and refer to that as "patch minute". I propose that they make this 5:35 pm in each local timezone to catch the IT staff who are trying to sneak out and have a home life.
    • I agree, on both counts

      The author of the article is an idiot or never andministrated massively patched software if he thinks that more frequent and releases would make things easier.

      If there is any testing, the majority of it would be redundant between patch stuff, to make sure critical things weren't inadvertantly broken. Say that takes 1 day per patch set, now if there are 10 patch sets in a month instead of 1, you just had 10 days spent.

      That being said, while a release-when-done actually make an administ
    • At least with "Windows Update" I can, somewhat, limit the amount of crap going onto my systems.

      But a far FAR better solution is Debian's approach. I get TINY patches and ONLY for what is specifically running on my system.

      It is so much simpler and easier to test with that approach.

      Particularly when compared to things like WinXP's sp2 (with firewall) approach.
      • while ideal MSFT couldn't do that.

        according to MSFT own developers the windows codebase is filled with circular dependancies. Think the backup department of the government department of redundcies.

        Unitl they actually break compatibility, and actually rewrite the codebase instead of just porting windows XP to the Win2k3 kernel, and make the whole system modular, your going to get massive patches.

  • How does the existence (or not) of Patch Tuesday change the number of patches deployed on your network?

    And why are you relying on MS to keep your network secure?

  • SUS (Score:2, Insightful)

    by u-bend ( 1095729 )
    I'm not a fan of MS, nor am I a network administrator, but if you're running a network large enough for patching to be a big problem, shouldn't you have a PDC or BDC or something like that that runs SUS? Then you can choose which patches get installed to clients, and when, right? Probably an oversimplification, but it helped in management of our M$ boxes at a previous job.
    • Umm, those large corporate customers that wanted patch Tuesday, so they can test their huge suite of in-house-developed apps against all the patches at once *DO* have machines running WSUS.

      Testing is a huge issue. Rolling out the patches isn't. If the testing takes 2 weeks, and MS releases a new patch every other day for 10 days, they don't want to suddenly have 10-weeks worth of testing in the pipeline. They want to do it all at once.

      Reality check:

      Often hackers do come out with new novel exploits for un

  • The Real Reason for Patch Day (Score:4, Insightful)

    by Gary W. Longsine ( 124661 ) on Thursday May 10, 2007 @12:52PM (#19071013) Homepage Journal
    Dennis Fisher fails to grok. Patch Day was created because Microsoft was getting hammered by the poor press which resulted from releasing many patches in one month. Patch Day, as much as it sucks, is probably here to stay.

    • Re: (Score:2, Funny)

      by sharkey ( 16670 )

      Dennis Fisher fails to grok.

      True. Patch Tuesday will arrive when waiting is filled.

  • Sounds to me like your IT staff doesn't know how to do their job effectively. Many companies and schools with hundreds or thousands of computers are able to stay patched. It might be more prudent to fire your current IT staff and hire some people that are capable enough to apply patches quickly and remotely without trouble.

    • Re: (Score:2)

      by sqlrob ( 173498 )
      The problem isn't application (or shouldn't be). The problem is testing custom business critical apps, or other third party apps that may break.

    • Re: (Score:2, Insightful)

      by danlor ( 309557 )
      Sounds to me like you are the problem. That's a heinous comment.

      Patching is dangerous. It is not for the foolhardy, or ignorant. Your IT department is there to protect you from the "just do it" mentality. Trust them, and when they wine about problems in the process, take heed.

      Our systems have been taken down twice this year due to bad patches from good old MS. Patches that we in IT were FORCED to deploy before proper testing. Guess who has control of the process in our organization now?

      • Re: (Score:2)

        by l4m3z0r ( 799504 )

        Again I say this is the fault of IT. In your case the managers that "FORCED" you to deploy before testing. The article is mainly concerned with the volume, limit the number of patches. Thats great, just leave vulnerabilities unpatched.

        And what's so heinous about it?

        Where I come from you are held accountable for your performance. And that includes no protection by blaming the consultant, if you hire a consultant and he fails, you AND the consultant are terminated.

  • Patch Tuesday (Score:2, Insightful)

    by Anonymous Coward
    My understanding is that they basically did it to allow IT guys to schedule their downtime and patching, instead of having to scramble every time MS releases a patch in the middle of the week. Which is how it used to work, up until 2003 or so.

    • Re: (Score:2)

      by guruevi ( 827432 )
      From what I remember (it's only been 4 years, don't you remember anything? Or were you too young?) is that Microsoft started to grow a clue about security and had to bring out a patch to their Operating System as good as every single day (for ME, XP, ...). Of course this was to the great amusement of press, Netcraft and *nix sysadmins that boast 100's of years of uptime and Microsoft's marketing machine decided that: if we bring them out only once a month, we can combine them in a roll-up and it won't look
  • It sounds like the problem is not that they only come out once a month, but that so many are released that it takes a long time to apply the patches. If they released one patch every day, it would still take a while to patch every system, especially for large companies or companies with tons of computers.

    It sounds to me like the only real solution is to make better code so that you do not have to release patches as often. It might just be an inevitability that IT must live with.

  • I call Bullshit on the Red Bull (Score:3, Insightful)

    by The Media Mechanic ( 1084283 ) on Thursday May 10, 2007 @12:56PM (#19071139)

    "Known in some circles as Black Tuesday, the second Tuesday of each month in the last few years has become a kind of national day of mourning in the IT industry, as admins call all hands on deck and load up on pizza and Red Bull for the long night ahead."


    I call bullshit on this anecdotal bit of trivia. Is the author of the article actually suggesting that some companies rush to test the new Winblows patches all through the night on Tuesday so that the patches are ready to deploy on Wednesday ? This sounds like a fresh steaming load of bullshit... what places actually force their employees to work ridiculous hours like this just due to an arbitrary vendor schedule! I would not work at such a place, regardless of the amount of free pizza or Redbull available.

    My point is that this bit of exaggeration in the article has no basis in fact and should be supported by quotes from someone who actually enforces this policy at their IT department.

    • Re:I call Bullshit on the Red Bull (Score:4, Informative)

      by Zontar_Thing_From_Ve ( 949321 ) on Thursday May 10, 2007 @01:06PM (#19071331)
      Is the author of the article actually suggesting that some companies rush to test the new Winblows patches all through the night on Tuesday so that the patches are ready to deploy on Wednesday ? This sounds like a fresh steaming load of bullshit...

      You may be right. My previous job was with a company that did a lot of VAR stuff, including various email systems. It didn't matter to us what you wanted - Notes, Exchange, Unix, anti-virus, anti-spam - we could sell you whatever combinations you wanted. I didn't work with Exchange, but the Exchange guys told me that in the past they used to rush out and patch systems with every "critical" Microsoft patch release and then they applied some patch that totally broke Exchange. The patch had nothing to do with Exchange, but it broke it. It took hours to fix the broken servers. After that fiasco, we regarded all Microsoft patches as suspect and we had a group in another state that one of their jobs was to test new patches on Exchange servers and see if Exchange still worked. It didn't matter to us how "critical" Microsoft considered a patch. We didn't patch any of Exchange servers until our test group gave the OK, which was usually a month later.

    • Workstation patches roll in enterprises of any size via WSUS or similar. As far as testing of workstations patches go, that's Microsoft's job. You hold the w/s patches for a few days on your WSUS server, wait to see if there are any issues, and if not, let them roll. If we had to test w/s patches on a per patch basis, we wouldn't be able to run the enterprise. If we were patching w/s's outside of a WSUSish service, w/s's wouldn't get patched.

      So, WSUS manages the roll-out of patches to workstations, and

  • Fix The Real Problem (Score:3, Insightful)

    by EXTomar ( 78739 ) on Thursday May 10, 2007 @01:02PM (#19071257)
    The original reason why "Patch Tuesday" was created was because too many were giving feedback to Microsoft that their patching process was far too disruptive to their enterprise. Before "Patch Tuesday", you could check any particular machine, at any time of day or week, and regardless of its role or usage it may have a patch pestering people that it needs to be applied and the machine rebooted. "Patch Tuesday" essentially is a "work around" to condense all of these patches that could be highly disruptive into a smaller, brief time frame.

    The real problem is the patching system Microsoft chose is highly disruptive. Too many still demand user attention even if applied remotely by an administrator. Although less often, too many still require a reboot which is a larger disruption to the user's work. Should Microsoft consider changing how patching is done so that it isn't so "hands on" and pesters the users and administrators to take action? Improve patching to the point where patches can be applied painless from the IT Center and "Patch Whateverday" goes away.

  • My Thoughts (Score:5, Informative)

    by KenshoDude ( 1001993 ) on Thursday May 10, 2007 @01:03PM (#19071265)

    I am the Sys Admin for ensuring that our roughly 1800 desktops and notebooks get updated with the latest updates. Microsoft's strategy is the very least of my concerns. The patches show up on WSUS the Wednesday morning after they are released. I read up on them, noting any "caveats" in the KB articles and inform our help desk if I find anything signficant. Then, I set my approvals and decline any superseded updates. The clients check in and install the updates over night. I am not sure where all this talk about long nights with Red Bull and whatever come into play. If we have mission critical systems, we withold approval for that group for a week or so until we are confident that there are no undisclosed "caveats." Super simple.

    I like having a regular schedule for updates. But I wouldn't mind a little more frequency. Why not the first and third tuesday of every month? Sounds reasonable to me.

    Now if were only that easy for all the other software vendors out there like Adobe (Acrobat / Flash), Sun (Java), and so on. Where are their enterprise patch management solutions? Why can't I configure my Java clients to check into to one of my servers to automatically apply security updates? Instead I have to spend more money on a 3rd party patch management solution. And I haven't found one yet that is as reliable and simple as WSUS.

  • Comment removed based on user account deletion
  • They should have a patch hour, it would be every day - just like a happy hour, but without the half price drinks. Um, or the happiness.
  • I actually like this monthly Tuesdays schedule (gets me excited ;)). Once in a while for urgent updates.

    I do also notice sometimes the fourth Tuesdays of each month might have other non-critical releases.

  • Billg's Response (Score:2, Funny)

    by Anonymous Coward
    End patch Tuesday? That's the dumbest fucking idea I've heard since I've been at Microsoft.
  • In my experience, the whole reason that you have to "test" patches on corporate machines is that the vast majority of the custom-made and "niche" software that many businesses rely on is HORRIBLE. Bug-ridden, non-standard, breaks every rule. Hell, a lot of it is still 16-bit Windows (and even DOS) software with only minor modifications to keep it working under modern OSs. And so, every update causes problems, because it only barely works anyway.

    If corporations were better at updating their software (and det
    • I imagine thats a part of the problem, I really don't know what percentage of the problem is due to bad cooperate software. I've seen some terrible stuff as well. It sounds strange now, but I'm guessing that may have actually been the fastest( or at least the cheapest) way to do it back when it was done. Microsoft has produced too many ways of doing everything, and doesn't always do a good job maintaining computability for all of those ways.

  • No (Score:3, Insightful)

    by Kjella ( 173770 ) on Thursday May 10, 2007 @02:16PM (#19072569) Homepage
    A bug might have been there for one year, two years, five years. The chance someone will find it by accident in the next two weeks (average delay to release) is rather slim. On the other hand you know the moment the patch is out, hackers will reverse engineer it within a short period of them. That leads to the following conclusions:

    1. You have to patch within a short period of release
    2. One patch may break any functionality, so you must test all of it
    3. If Microsoft releases patches all the time, you must test all the functionality all the time

    In 99% of the companies out there, that's just not going to happen. I love getting daily patches, my desktop or home server isn't a critical business machine. I'm mostly interested in avoiding someone hacking it so I have to set it up again, far more than a broken patch. At the very least that leaves the machine in a "known broken" state that hopefully be fixed by another patch, where as a decent virus infection might end in a reinstall. For many a corporate machine down means you're down. Sales lost, salaries roll and nothing gets done. Sometimes data gets stolen but most of the time the cost is downtime - whether it's broken software or infected software. Quite often the solution is the same - rollback to a known good state (after you've figured out how to not get reinfected). Under those conditions I see why they prefer a mad scramble every patch Tuesaday instead of a mad scramble all the time.

  • It's in my diary.. (Score:3, Informative)

    by Dynamoo ( 527749 ) * on Thursday May 10, 2007 @02:58PM (#19073429) Homepage
    Patch Tuesday is in my diary (well, actually the Wednesday because the patches are announced in the evening UK time). I have a change control provisionally made for EVERY post-patch Tuesday Saturday to cover servers, and I also have an entry for the Friday before patch Tuesday when the advanced notification is made.

    This is the way it goes..
    Friday: Look at the advanced notification to get an idea of the scale of the patches. Once or twice a year there a none.. yippee!
    Wednesday: In the morning we closely analyse the patches to figure out the impact on our organisation. Servers and clients are differently impacted so we look at this to see if we will need to patch servers. Patches are tested on some representative computer systems.
    Thursday: raise the inevitable paperwork for any system changes and monitor for any issues.
    Friday: Check for issues with the patches and then authorise for client distribution via WSUS.
    Saturday: If necessary, patch those servers that are vulnerable. Claim overtime. Yippee.

    We know in advance when this is coming up. We can make plans. We ensure that someone always looks at the patches on Wednesday morning and does the analysis. It's a monthly event that we don't miss. This works pretty well.

    Sure, sometimes you need to apply an out-of-cycle patch.. these are rare but Microsoft seems to understand that they are needed. If we miss it, then we'll alway pick up on it again later.

    Yeah, hardcore sysadmins might like patch and reboot PCs every couple of days or so, but most sysadmins have other things to worry about than constant patching and in my view Microsoft have the balance about right. (One of the few things I like about them!)

  • After repeated experiences of the extremely awful "check for updates" software, which would lock out other apps from starting, including the task manager, I switched it from "notify" to "off". Now I'll do it manually on my own, thanks.

    It still puts a x-shield icon on the bar, and I can live with that, but if it nags me one more time that the automatic update is switched off, it will find that it can't live with that because I will hunt down that clippy-like code and make it non-executable.

Slashdot Top Deals

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Close