This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

King for a Day - What would you change?

For the past few weeks I've had some really good discussions around patch management.  The reasons why some people don't patch, the reasoning behind why people do patch, where it fits into an organization and who's role it typically falls under.  All of the conversations have been great and it is clear to me that patching is not just clicking update and walking away.  Patch management should be part of a robust, important and thought out procedure in almost every organization.  Big and small alike, the processes and challenges are pretty similar for all of us.


As a last brainstorming event on the topic, I thought it would be interesting to play King (or Queen) for a Day.  Looking back at the Patch Management process, if you had supreme powers, what would you change?  How different would/could the processes look?  No need to even ground it in reality if you feel strongly enough about it! emoticons_happy.png

Let's start with reboots becoming a thing of the past.  Patch an application or OS and NOT have to restart or incur downtime penalties?!?  Revolutionary!

Expulsion from my computerized Kingdom for any vendor requiring manual patching.  If you've packaged it up in a way that requires me to manually copy files or change registry entries, you haven't put enough time into your patch.  This would be considered a capital offense in my fiefdom.

What would you do if you could just summon your subjects, wave your hand and make it so?

*Reply to this post to earn 50 points and 1 entry to win an iPod Nano

  • Obviously the hardest thing to deal with is downtime for the business.  The more applications that can run like Exchange with DAG's and SQL 2012 with AOAG, the easier it is to patch nodes invisibly to the user community.  So I guess my super power would be to load balance it all and make them all run like vmware with snapshots pre patch that are automanaged.

  • Doesn't have to be grounded in reality?  Alright!!


    No reboots, easy rollback (without reboot), method for testing the update ON THE SERVER THAT WILL BE PATCHED prior to actually installing it. Some sort of guarantee by the vendor that releases the patch that it will not break the server or the app that runs on the server being patched (perhaps dollars for downtime?)

  • Yeah that was much more creative and better than my answer lolol!

  • I would like it to be standard for patching solutions to manage VM Snapshots both the creation of and scheduled deletion a week later.  This would provide an easy fallback point for when patches cause problems.

  • I would like it to be standard for patching solutions to manage VM Snapshots both the creation of and scheduled deletion a week later. 

    Scheduled deletion is high on my list as well.  It still surprises me that VMware themselves haven't implemented that yet.  seems like something just about EVERYONE wants.

  • Doesn't have to be grounded in reality?  Alright!!

    No reboots, easy rollback (without reboot), ...

    What fun would King for the day be if it had to be grounded in reality?!  You have to break out of the box for Big Ideas to come out. emoticons_happy.png   I know for sure that reboots are going to be high on everyone's pet peeve list.  Heck - one of the biggest perks of a recent VMware upgrade was the NEW ability to upgrade the tools without a reboot.  It was practically a top reason to upgrade!

  • First, I would declare that Microsoft must put in the update window what the update/patch does for each patch.  Not just some of them (although sometimes I think they are trying to do this more often). 

    My next decree is that no vendor should issue a patch that re-installs the entire program!  Fix only what's broken.

    I know you said it, but it's worth repeating.  No reboots!

    During the patching process, it would be required to preserve a copy of all old files and all old registry entries.  It's been said, but here it becomes law...easy painless rollback!

  • My next decree is that no vendor should issue a patch that re-installs the entire program!  Fix only what's broken.

    That's an excellent one!  I completely forgot about that.  It drives me CRAZY to download a 300MB Patch!  At that point, just call it a Release and toss some new features in it!

  • For sure no restarts, and compatibility screening so it never broke application.  Version checking to ensure you have all the prerequisite items covered.  I would have it update all software and BIOS, and Hardware firmware.   I would have something that can handle devices like WAP, and Printer boards.  one tool that could effectively Update anything with a PC chip and attached to the network, and have it work.  yep i said it work, not be a crippled piece of plastic, copper and silicone, no work, as in be faster, better and not use a ton of HDD space, maybe a archival process to remove out old components that obviously wont ever be needed again.

  • My King for a Day change would be to have every server load balanced and clustered as well as have them all HA with DRS and vMotion capabilities so that there would be no such thing as down time!!!  All devices have redundant hardware so there are no "single points of failure" throughout the Network.  I'd also have a patch management solution that would handle all updates for all software packages.... Oh yeah, and have users fix all of their problems without ever calling for assistance!

    Well you asked!