Plan the release of the software updateRelease planning is the process of working out how you will release the software update into the production environment. The following are the major considerations for planning the release of a new software update: - Determining what needs to be patched
- Identifying the key issues and constraints
- Assembling the release plan
Determining what needs to be patchedDeciding what needs to be patched requires accurate and up-to-date knowledge of what is present in the environment. Information retrieved by the Systems Management Server (SMS) 2003 software update scanning tools, together with the information retrieved by the SMS Hardware and Software Inventory Client Agents, can be used to determine the computers on which a particular software update needs to be installed. It is also important to determine the type and role of the computers that are to be updated and their connectivity to the network. Emergency change requestFor critical updates, you need to determine, as accurately as possible, the number and type of systems that are at risk. To obtain inventory data more quickly than the regularly scheduled inventory cycle, the SMS administrator will need to create a mandatory advertisement to run the SMS 2003 software update scanning tools, which forces hardware and software inventory to run on each client computer that is perceived to be exposed to the vulnerability. Identifying the key issues and constraintsThere may be a number of issues and constraints that dictate the steps that are necessary to fully deploy the software update into production. For example, the team tasked with deploying the software update may need to consider the following: - How much time should you give users before the software update is installed automatically? The amount of time permitted will depend on a number of factors, including user roles and responsibilities and the nature of the system instability or security vulnerability that the software update is designed to address.
Figure 2.14 shows an example software update deployment timeline (SLA) that indicates that servers must be patched within seven days of the arrival of a software update that is not deemed business critical. Administrators are granted permission to start patching within the seven-day window, but need to be aware that computers will be force-patched or disconnected from the network after the time period expires. The required response time and actions taken when computers are not updated within the allotted time frame may be different for your organization.
See full-sized image
A similar compliance timeline may be applied to workstations in your environment. - Certain software updates require administrative rights on the computer on which they are being installed. Most end users will not have local administrator rights and the tool used to install the software update will need to be able to acquire elevated rights and privileges to install the software update on client computers.
- If the software update requires a certain amount of disk space to install or the software update is to be cached locally prior to installation, a check needs to be made on the amount of free disk space on each client computer.
- If the software update is large—for example, in the order of several megabytes (MB)—mobile clients may take some time to download it. If the software update is not classified as an emergency, it might be appropriate to postpone installation on those clients until they are physically connected to the network.
- Business-critical computers may have specific times at which changes and computer restarts are permitted (outage windows). The deployment of a software update and any system restarts that are required as a result will need to be scheduled within these outage windows.
- If client computers are locked down through the use of certain Group Policy settings, this may affect the software update’s ability to install correctly.
- If the product to be patched was deployed using Windows Installer, the Windows Installer may require access to original installation files. These files need to be in the same location as they were when the product was originally installed if you are performing an unattended installation of the software update. If the product was installed from physical media such as a CD, for example, Windows Installer will try to find the original files on the currently inserted CD.
- If there are applications that were installed on a per-user basis rather than a per-computer basis for all users, you should reinstall the application on a per-computer basis and then apply the software update to the new installation.
- There can be issues with trying to deploy large software updates to mobile clients that connect to the network through slow and intermittent dial-up links. It can take a long time (up to several hours) to complete an installation across a dial-up link.
Emergency change requestIf the change request indicates that the software update is regarded as an emergency, the following factors need to be considered: - The software update may need to be deployed in a significantly shorter time span than normal. Full deployment, for example, may be expected within 24 hours of the approval of the change request.
Figure 2.15 shows an example deployment timeline (SLA) that indicates that all servers must be patched within eight hours of the organization being made aware of a software update that is considered to be business critical. The time window and speed of response may be different for your organization.
Figure 2.15. Example of an eight-hour emergency deployment SLA See full-sized image
In this example, after the organization has been made aware of the software update, patching of business-critical servers must begin within two hours (12:00 as shown) with 98 percent of all servers brought into compliance by 18:00. The remaining servers need to be brought into compliance by 22:00 or risk being disconnected from the network. A similar compliance timeline may be enforced for workstations in your environment. - SMS intersite senders must be configured to allow high-priority package or advertisement transactions to replicate at all hours of the day. The high-priority setting should be allocated only to packages and advertisements for software update content.
- The outage windows that govern when certain business-critical systems can be patched or restarted will need to be overridden to allow the software update to be deployed within the agreed-upon time frame.
- The software update will need to be applied to all affected systems, regardless of their connection to the network.
Assembling the release planThis is the point at which you will need to plan and determine the order in which the computers within your production environment will deploy the software update. The following are some of the issues you may need to consider when assembling the release plan: - If the software update applies to all servers within the production environment, should those running SMS and monitoring tools be patched first? Patching the management infrastructure first ensures that administrators can use these services to monitor the progress of the deployment.
- Are there any business reasons why one part of the production environment should be patched before another? There may be compelling reasons to apply the software update to computers that are at risk from a security vulnerability or potential system instability and then, after these computers are patched, continue the rollout elsewhere.
- The available network bandwidth between sites will also have an impact on the rollout order. It may be difficult to get the software update out to some sites as quickly as others because of network bandwidth constraints; the software update can be deployed to sites with good network connectivity much more quickly than those where network availability is limited.
- You will need to determine how and when information about the software update, its severity, impact, and the steps that need to be taken to deploy it, will be communicated to users, the business, and the service desk.
- If management architecture components such as Microsoft Operations Manager (MOM) and SMS 2003 site servers also need to be updated, it may be appropriate to plan to have these computers updated manually (by local administrators) to ensure that these servers are not restarted during the rollout of the software update to other computers within the production environment.
- If one site or group of computers has already suffered from a security breach or system instability that the software update addresses, deployment of the software update should be directed to those computers first.
- For sites with poor network connectivity, it may be necessary to plan for the use of the SMS Courier Sender to place the software update files on removable media and for this media to be transported to those sites as quickly as possible.
| |