The introductory article on patch management can be found here.
Around the beginning of August 2014, all college-owned computers will be migrated from the old K1000 5.4 to the new K1000 version 5.5, possibly receiving a newer version of the Dell KACE Agent. For a few months, Windows computers on a KBOX patch schedule will receive application patches from a different, temporary, K1000 process, one based on K1000 scripts, not on KBOX patching. This does not affect computers running Mac OS X, only Windows. What you see during patching will look different, and may work a bit differently than before, but it will run at exactly the same time as the patch schedule you subscribed to (the deploy step). The applications that will be included in this process are marked with § in the list below. It is very likely that any Web browsers running at that time will be terminated without warning. ITS plans to have a better, permanent, solution in place by the end of the calendar year, if Dell KACE fixes some bugs. Here is a restricted, more technical, explanation of the temporary patching process, meant for ITS staff and student workers. |
The KBOX is only for Carleton-owned computers. |
The KBOX 1000 (K1000) receives patches from Lumension , a security company. These patches are then delivered to campus computers. Patches in the K1000 are security related patches only. Feature related patches and upgrades are not available from KBOX patch management.
The K1000 delivers security-based patches for the following applications:
When software vendors release patches, Lumension and KACE test them before making them available to the K1000. This provides more levels of review to catch any potential problems. The K1000 downloads new patch signatures and patch package files for selected operating systems nightly. Then, Carleton computers use the available patches based on the patch schedule to which each computer is assigned. Some patch schedules check for ("detect") patches at one time, and then apply ("deploy") the detected patches at a different later time. Other patch schedules check for ("detect") patches and then apply them ("deploy") immediately thereafter.
There are 10 different patch schedules to which a computer can be assigned. Each computer, virtual machine (VM), and booting operating system (e.g., dual boot), should be assigned to one and only one patch schedule. Any VM or booting operating system on a computer should be assigned to a different schedule than the computer itself, so you can make sure the correct environment is running at the time of each schedule.
| Note: We have found it is very difficult to explain these different patch schedules in writing, so please be patient in reviewing this section, and contact the ITS HelpDesk (x5999) when you have questions. |
Here is a list of the different patch schedules each with a different color, and next to that is a picture of when the different steps (detect or deploy) of each patch schedule runs:
|
When a patch schedule Detect only step runs, nothing is displayed. The computer may seem a bit sluggish, but you can keep working.
Every patch schedule Deploy step has these characteristics:
This table lists the different patch schedules again with more detailed information:
Again, we know this information is hard to interpret. Please contact the ITS HelpDesk (x5999) for help.
It depends on when the computer (or VM or booting operating system) is active and on the campus network, and whether you want patching to compete with your trying to get other work done. In general, if you don't want to be interrupted, choose an EndOfDay or Overnight schedule, and leave your computer powered on, not in sleep mode, and connected to the campus network.
If you take your laptop computer home most nights, choose instead a schedule that runs during the day at a time when you may be away from your desk (e.g., Convo, CommonTime).
If your laptop computer is seldom on campus at all, choose the NextCheckIn schedule which will try to run every time you are back on the campus network if you miss the scheduled times. But NextCheckIn can be very annoying, so choose it only if none of the other schedules works for you.
A note about the NOJava schedules: The patch schedules whose names contain the phrase NOJava exclude any Java Runtime Engine (JRE) updates, because a few third-party applications run correctly only when their preferred version of Java is not changed. Only if you have such an application should you choose a NOJava schedule, and in those cases, you can enhance your computer security by disabling Java in Web browsers: Look for a Java Control Panel with a Security tab and a setting titled "Enabled Java content in the browser" that you can uncheck. If doing this causes the application Web site to fail, just reverse your actions.
KBOX patch management should not reinstall patches that are already applied, nor should it downgrade your applications. With regard to Mozilla Firefox, note that version 31.1esr was released at the same time as consumer version 32 (31+1=32), so ESR version numbers may appear old when they are actually up to date.
KBOX patching cannot run if a computer is in sleep mode at the scheduled time. Most campus computers are configured to go into sleep mode after a period of inactivity, usually 4 hours. But if a patch schedule step runs at 6am, and you left your computer on at work at 6pm, the computer will be sleeping by 6am when patching is supposed to start.
There are 4 solutions to this problem:
The introductory article on patch management can be found here.
