[unisog] Server Update Policy, Procedures and Maintenance Schedules:

gentuxx gentuxx at gmail.com
Sun Sep 3 06:16:59 GMT 2006

Hash: SHA1

Eric Wohlford wrote:

[ ... snip ... ]

> We are in the process of setting up a Maintenance Schedule.  This would
> be were we would run updates, defrag drives, make sure files are cleaned
> up (temp directory?s), check hardware, if need be cleaning dust out of
> the cases, and other similar tasks as they come up.

IMHO, this should occur.

> As it is now there are two camps of thought on this on our campus:
>    1. Keep it similar to how it is now but make it official that one day
>       a month we will be stopping all services including our ERP, Email,
>       and LMS, in order to perform Maintenance on our Servers.

Depending on the diversity of your systems, one day a month may be a
luxury.  A more "regular" routine might be a better idea.

>    2. Start a Schedule that would have us do it ?after hours,? this
>       would have us do it either in the late evening or early morning
>       hours.  99.9% of our client base is in the same time zone.

This is preferable, however, especially in a University/College
environment, the term(s) "after hours" is /completely/ subjective.  The
staff/faculty may go home at 5, or 6, or 7 (depending on their class
schedule of course), but students will be up all hour of the night doing
various things.  So, an identification of "critical" and "high-use"
systems is very important.  For example, departmental servers might
suffer some impact (performance, reboot, etc.) without much consequence
at 02:00 local time, but taking down a general proxy server for
"routine" patching (maintenance) may be a significant issue.
> Some concerns have come up that our IST Dept. may be ?too small? (4
> staff members) to support an ?after hours? schedule, and even one
> thought that Educational Institutions do not work this way at all.  I
> personally am a member of the second group of having an ?after hours?
> schedule.  I am asking a few questions as a poll to see what the
> Procedures are that others are using when performing this type of task. 
> If you wish you may email me directly and I can compose a summary of
> responses to post back to the list.  As a side note all servers are
> under the control of a central IST Department.
> Questions:
>    1. Do you have a policy on updating Servers you would be willing to
>       share, such as how long you test a patch before applying, or which
>       types of servers are updated first?

	Yes, but caveat that with, I'm not part of a Univ. org.  Duration of
testing depends on the severity of the vulnerability being patched (we
have our own standard, which may not be applicable for your
environment).  Externally accessible systems are always updated first,
and even on an accelerated schedule.

>    2. When do you run these types of Maintenance Schedules on your
>       servers, during normal business hours or after hours?

After hours.  Most updates occur after 17:00 local time.  User impacting
changes go through a change management approval process and are usually
scheduled for a weekend.  You may have less flexibility depending on the
systems you're updating.

>    3. How many IST Staff members do you have to support your schedule?

Depends on the change.  Anywhere from 1 to 30.

>    4. How large of an institution do you consider your self to be?  And
>       are you public or private?

Very large.  Public.

>    5. Does your staff manually update the servers or are they on a
>       Managed system such as ?Patchlink,? or ?Microsoft SUS or MOM?? 
>       And if they are on a Managed system which one?

Both.  "Managed" systems in use, WSUS/SUS, LanDesk, Radia, etc.

>    6. Any other suggestions you have would be greatly appreciated!

Um....I respond better to specific items.  Not being in a Univ/College
org, I can only offer "general" advice, and can only expect it to be
taken with a grain of salt (or two).  ;-)

- --
echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239  D840 4CF0 39E2
18D3 4A9E
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the unisog mailing list