Desktop & Servers

Desktop, Device and Server Management

Desktop, Device and Server Management is the second Core Infrastructure Optimization capability. The following table describes the high-level challenges, applicable solutions, and benefits of moving to the Standardized level in Desktop, Device and Server Management.

Phase 1: Assess

The Assess phase is the first major step in the patch management process. The process starts with assessment, because you will need to determine what you have in your production environment, the security threats and vulnerabilities you might face, and whether your organization is prepared to respond to a new operating system or application software update.

Ideally, assessment is an ongoing process that you should follow to ensure that you always know what computing assets you have, how you can protect them, and how you can ensure that your software distribution architecture is able to support patch management.

The key areas for ongoing assessment are:

• Inventory/discover existing computing assets.

• Assess security threats and vulnerabilities.

• Determine the best source for information about software updates.

• Software version control to maintain standard application versions.

• Assess the existing software distribution infrastructure.

• Assess operational effectiveness.

A comparison of these tools is located at the end of this section. Microsoft partners and other third parties offer additional products and tools that can be used in the Assess phase.

Phase 2: Identify

The goals for the Identify phase are to:

• Discover new software updates in a reliable way.

• Determine whether software updates are relevant to your production environment.

• Obtain software update source files and confirm that they are safe and will install successfully.

• Determine whether the software update should be considered an emergency.

Discovering a new software update starts with notification, which should be supplied either through a subscription to a reliable source that provides scanning and reporting activities, or by some other reliable notification mechanism. The following are the most commonly used notification mechanisms:

• E-mail notifications:

• Viewing updates in the Windows Server Update Service (WSUS) console toolbar.

• SMS 2003 Inventory Tool for Microsoft Updates (ITMU): 

• Vulnerability scanning tools, such as MBSA, to scan for missing updates.

You can determine the applicability of a software update to your IT infrastructure using the following screening methods:

• Reading security bulletins and Knowledge Base articles.

• Reviewing individual software updates.

After you have obtained the update, it should be verified through the following activities:

• Identifying and verifying the software update owner.

• Reviewing all accompanying documentation.

• Ensuring that the software update is free from viruses.

Phase 3: Evaluate and Plan

Your goal during the Evaluate and Plan phase is to make a go/no-go decision to deploy the software update, determine what resources it will take to deploy it, and test the software update in a production-like environment to confirm that it does not compromise business-critical systems and applications.

The key requirements for evaluation and planning are:

• Determine the appropriate response.

• Plan the release of the software update.

• Build the release.

• Conduct acceptance testing of the release.

To determine the appropriate response to an available update you should:

• Prioritize and categorize the request.

• Obtain authorization to deploy the software update.

Release planning is the process of working out how you will release the software update into the production environment. Following are the major considerations for planning the release of a new software update:

• Determine what needs to be patched.

• Identify the key issues and constraints.

• Build the release plan.

To build the release, you must develop the scripts, tools, and procedures that administrators will use to deploy the software update into the production environment.

Testing should be carried out, regardless of whether the software update is regarded as normal or business-critical, with the following results:

• After the software update installation is complete, the computer should restart and operate without incident.

• The software update, if it is targeted at computers connected across slow or unreliable network connections, can be downloaded across these links, and, after this completes, the software update successfully installs.

• The software update is supplied with an uninstall routine, and this can be used to successfully remove the software update.

• Business-critical systems and services continue to run after the software update has been installed, and the machine has restarted, if that is a necessary step.

Phase 4: Deploy

Your goal during the Deploy phase is to successfully roll out the approved software update into your production environment so that you meet all of the requirements of any deployment service level agreements (SLAs) you have in place.

The deployment of a software update should consist of the following activities:

• Deployment preparation.

• Deployment of the software update to client computers.

• Post-deployment review.

The production environment needs to be prepared for each new release. The steps required for preparing the software update for deployment should include the following:

• Communicating the rollout schedule to the organization.

• Staging updates on distribution points.

The steps required to deploy a software update in production should include the following:

• Advertising the software update to client computers.

• Monitoring and reporting on the progress of deployment.

• Handling failed deployments.

The post-implementation review should typically be conducted within one to four weeks of a release deployment to identify improvements that should be made to the patch management process. A typical agenda for a review includes:

• Ensure that the vulnerabilities are added to your vulnerability-scanning reports and security policy standards so the attack does not have an opportunity to recur.

• Ensure that your build images have been updated to include the latest software updates following the deployment.

• Discuss expected results compared to actual results.

• Discuss the risks associated with the release.

• Review your organization’s performance throughout the incident. Take this opportunity to improve your response plan and include lessons learned.

• Discuss changes to your service windows.

Operations

The patch management process is an ongoing and iterative cycle. While Operations is not a patch management phase in the Infrastructure Optimization Model, it is necessary that IT operations define the frequency of patching that best suits your organization’s needs and security goals. Your organization should define a system for determining the critical nature of released patches and have a service level defined for each patch release level.

Available Tools

A number of tools and products can automate the delivery and installation of software updates. As defined in best practice patching, exercising manual control over which patches are installed to managed computers is a requirement. Allowing Automatic Updates or Microsoft Update to run unchecked does not comply with best practice patch management for organizations; however, in some cases, when dedicated IT staff is limited or users are remote and unmanaged, these technologies can be used.

The recommended options for managing software updates are Systems Management Server 2003 (SMS 2003) and Windows Server Update Services (WSUS). In addition to these options, numerous Microsoft partners and other third parties offer options to assist with patch management.

The following table lists software tools available from Microsoft to perform installation of software updates.

Feature	Microsoft Update (MU)	Windows Server Update Services (WSUS)	Systems Management Server 2003 (SMS 2003)
Content Types Supported	All software updates, driver updates, service packs (SPs), and feature packs (FPs)	Same as MU, with only critical driver updates	All updates, SPs, & FPs, supports update & app installs for any Windows-based software
Applicability	Individual users	Small- to mid-size businesses

 

Standard Images for Desktops and Laptops

To succeed in deploying an operating system, organizations must use the best technology and business processes available, in addition to best practices for optimizing those technologies. By developing baselines for the computing environment, organizations have a known and fixed configuration for deployment, which lowers the cost of support, troubleshooting, and other operations. Through imaging, a standard build that includes core applications, the operating system, and any additional organization requirements can be used for workstation deployment. This document lists tools that are available and the steps you should take to automate and establish standard desktop images. Deployment of standard images will be covered in future documents.

Phase 1: Assess

Most IT implementers share a common goal: to create a corporate-standard desktop configuration that is based on a common image for each operating system version in the organization. IT implementers want to apply a common image to any computer in any region at any time, and then customize that image quickly to provide services to users.

In reality, most organizations build and maintain many images—sometimes up to 100 different images. By making technical and support compromises, making disciplined hardware purchases, and using advanced scripting techniques, some organizations have reduced the number of images they maintain to a just few. These organizations tend to have the sophisticated software-distribution infrastructures necessary to deploy applications—often before first use—and keep them updated.

In the Assess Phase it is important to inventory your workstations and determine the number of active operating systems and applications in your environment. We recommend that you use a tool to automate the inventory process, such as Systems Management Server (SMS) 2003, the Application Compatibility Toolkit, or the Windows Vista Hardware Assessment.

Phase 2: Identify

During this phase you should list any current disk-imaging technologies and standard images used by your organization and identify the imaging direction, tools, and techniques you would like to implement. Advances in desktop imaging technology should prompt consideration for updating legacy imaging tools and practices.

A number of tools are available to capture a desktop image. Imaging technology can be sector-based and usually is destructive when applied to the targeted computer, or it can be file-based and nondestructive. Using file-based image technology, you can install new images in a separate partition of deployment-targeted PCs, which allows advanced in-place migration scenarios.

Microsoft offers a free command-line tool to enable disk imaging. The imaging utility, called ImageX, uses the Microsoft Windows Imaging Format (WIM) image format. Instead of a sector-based image format, the WIM image format is file-based and nondestructive. The SMS 2003 Operating System Deployment Feature Pack also leverages ImageX technology and the WIM file format to create and deploy desktop images.

Phase 3: Evaluate and Plan

During the Evaluate and Plan Phase you discuss possible approaches your organization can use to implement a standardized desktop imaging strategy. You should weigh the costs and benefits of each imaging technology and image type to develop a strategy that best suits your organization’s needs. Factors that affect the costs associated with building, maintaining, and deploying disk images are development costs, test costs, storage costs, and network costs.

As the size of image files increases, costs increase. Large images have more updating, testing, distribution, network, and storage costs associated with them. When you update even a small portion of the image, image administrators must distribute the entire file to client computers.

The three primary strategies for standard images are:

• Thick images

• Thin images

• Hybrid images

Thick Images

Thick images contain the operating system, applications, and other corporate-standard files. The advantage of thick images is simplicity; deployment is a single step because all files are deployed at once. Also, applications are available on first run. The disadvantages are maintenance, storage, and network costs. Thick images also limit flexibility. Either all computers receive all applications whether needed or not, or many different thick images must be developed and maintained. Using thick images is a common legacy approach.

Thin Images

Thin images contain few if any applications. The advantages of thin images are many. They cost less to build, maintain, and test. Network and storage costs are lower. There is far greater flexibility. However, flexibility increases deployment and networking costs.

Hybrid Images

Hybrid images are a combination of thick and thin images. In a hybrid image, the disk image is configured to install applications on first run, giving the illusion of a thick image but installing the applications from a network source. Hybrid images have most of the advantages of thin images, yet are not as complex to develop and do not require a software distribution infrastructure. Installation times are longer, which can increase initial deployment costs.

An alternative is to start with a tested thin image and build a thick image on top of it. Testing the thick image is minimized, because the imaging process is essentially the same as a regular deployment.

Another alternative is to add a minimum number of core applications to a thin image. These applications could include antivirus software and line-of-business (LOB) applications required on all computers in the company.

Test Plan

Another important part of the development stage is the creation of a test plan. You need to determine all configuration scenarios in which the disk image must work. These configurations include both hardware and business processes that client machines support. A bug reporting and tracking mechanism is important to ensure that all problems that arise in testing are addressed.

Stabilization

The image and deployment process created in the Development stage must be fully tested and stabilized before deployment to the enterprise. You must diligently follow the test plan created in the Planning stage. All problems encountered should be logged and tracked with a bug reporting system. When all bugs are resolved, the final image or images can be deployed to client computers.

Phase 4: Deploy

BDD 2007 Lite Touch Installation requires minimal infrastructure. You can deploy target operating systems over the network by using a shared folder or locally by using removable storage, such as a CD, DVD, USB hard drive, or other device. The configuration settings for each individual computer are usually provided manually during the deployment process.

Operations

Maintenance of the final image or images is an ongoing process. Updates to the operating system, device drivers, and applications must be analyzed for their applicability to your enterprise. Either they must be integrated into the existing image, or completely new images must be built. Then you must test and validate the final images before they can be deployed to client computers.

 

• < Prev
• Next >