Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Server Configuration Management at Microsoft

Using System Center Configuration Manager to Deploy Critical Security and Non-Security Updates in the Enterprise

Technical White Paper

Published: April 2012

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.


Download Technical White Paper, 616 KB, Microsoft Word file




Products & Technologies

Microsoft IT is continuously striving to reduce risk to business assets and intellectual property created by unpatched servers. MSIT also needs to have a configuration management program that provides asset intelligence, desired configuration management, and the ability to deploy both security and non-security updates during the same maintenance window.

Microsoft IT was able to improve performance and server availability and reduce risks by shortening the cycle time to deliver security and non-security updates. Desired configuration management has enabled IT administrators to identify configuration drift across platforms services and Line of Business applications.

  • Reduces risks by shortening the cycle time for security and non-security updates
  • Improves server stability and performance
  • Asset inventory information enables MSIT to understand and manage the server environment
  • Improves application stability and availability by monitoring and maintaining desired state configurations
  • System Center 2012 Configuration Manager
  • Desired Configuration Management
  • Security patch management

Hh996745.arrow_px_down(en-us,TechNet.10).gif Executive Summary

Hh996745.arrow_px_down(en-us,TechNet.10).gif Introduction

Hh996745.arrow_px_down(en-us,TechNet.10).gif Solution

Hh996745.arrow_px_down(en-us,TechNet.10).gif Best Practices

Hh996745.arrow_px_down(en-us,TechNet.10).gif Conclusion

Hh996745.arrow_px_down(en-us,TechNet.10).gif For More Information

Executive Summary

MSIT uses Microsoft® System Center Configuration Manager to comprehensively assess and update servers, both physical and virtual, in the enterprise. Assessing and maintaining the integrity of software in a networked environment through a well-defined configuration management program is a key first step toward successful information security. It is also the foundation for server and application stability and performance. The configuration management program at Microsoft includes the following services:

  • Asset inventory

  • Deployment of security updates

  • Deployment of software or non-security updates

  • Desired configuration management

The purpose of this paper is to share information about processes and technology that Microsoft IT uses to support their ongoing server configuration management program. This document is written for business decision makers and IT professionals who are interested in learning how MSIT uses System Center Configuration Manager 2012 for configuration management; it is not intended to serve as a prescriptive guide, since each enterprise environment is unique. Organizations can adapt the plans and lessons learned from this paper to meet their own specific needs.

This paper briefly looks at the history of patch and configuration management at Microsoft and describes how, by using System Center 2012 Configuration Manager and well-defined processes, Microsoft IT was able to reduce risk, and improve performance and availability.

Note: For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security files in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.


Microsoft IT understands the risk to business assets and intellectual property created by unpatched servers and applications. They also understand the benefits of having a configuration management program that includes asset intelligence, a robust security patch management (SPM) service, and the ability to distribute patches and software updates at a predictable cadence through scheduled maintenance windows. MSIT deploys security patches and software updates on a routine basis. Servers in the environment are less subject to various known issues or security threats that could cause them to be unavailable or at risk. MSIT also regularly deploys non-security updates that improve availability, deploying them consistently across all servers in the production environment.

MSIT relies on configuration management to help avoid incidents that could result in unexpected outages or loss of assets. To avoid those kinds of incidents, MSIT keeps applications available, secure, and up to date. Maintaining an environment that is performing optimally ensures that MSIT gets the most out of their infrastructure investment.


Configuration management and security patch management are not new concepts at Microsoft. Processes and technologies that help provide a level of predictability and consistency toward ensuring servers at Microsoft remain updated and compliant have been in existence for more than a decade.

The configuration management program of today evolved from a program that initially used Microsoft Systems Management Server (SMS) to address only security patch management. When System Center Configuration Manager released, MSIT began to use the product as a discovery mechanism for asset inventory information as well as security patch management.

Asset inventory has become a data source that server and application administrators use as a rapid auditing tool. Now internal customers can come to MSIT with specific inventory information requests about servers in the data center. The centralized data, stored in a Configuration Management Database (CMDB), is available to business groups so that they can build business logic behind it.

MSIT has also added software distribution alongside security patching. MSIT operations use the processes and resources of the security-patching infrastructure to install updates alongside security patches within the framework of scheduled maintenance windows. As software distribution grows, further automation is being driven into the existing asset inventory, and MSIT is building up the newly available Desired Configuration Management program, which provides desired configuration management services to service and application owners in the organization.

From the perspective of managing security patches, not much has changed from the core activities of earlier efforts. The number of servers for which MSIT manages the configuration continually grows—up 5,000 in the last year alone. The integration and enhancement of the features available in Configuration Manager has helped MSIT keep up with the ever-increasing number of threats and the volume of security patches now regularly released.

Maturing the Service

Rapid service growth required some maturation of process for MSIT to be able to improve the configuration management services that they provide. To identify areas of improvement for the service, MSIT reached out directly to their customer base to find out what was working for them and what they would like to see changed or improved.

MSIT compiled "voice of the customer" feedback and then spent the last year building on its existing services to meet the requirements of the customer. MSIT then hosted sessions for internal customers who use the patching service, and invited other candidates who were likely to benefit from the patching service.

After collecting information about what could be done better and what would drive adoption of the service, MSIT focused on technical issues such as improving agent health and reach, improving the reliability of update package delivery, and adding environment order so non- production servers have the option of being patched first.

Cross-Team Roles

Configuration management is a cross-team cooperative effort that involves the following specialized teams and roles:

  • Microsoft Response Center (MSRC). The Microsoft Security Response Center (MSRC) identifies, monitors, resolves, and responds to security incidents and Microsoft software security vulnerabilities. Customers can contact the MSRC by going to: http://www.microsoft.com/security/msrc/report.aspx

  • Information Security. The Information Security team reviews the vulnerabilities posted by the MSRC and assigns them a deployment priority according to internal security needs. For example, the threat may not be as imminent to Microsoft because of Microsoft's implementation of previous updates or protective firewalls. The Information Security team sets the enforcement dates for updates and sends the information the Operations team.

  • Service Desk. The service desk responds to and resolves incidents that occur across data center servers.

  • Problem Management. The Problem Management team investigates trends or incidents that resulted in a large influx of help tickets. Once a solution or update is determined, the Problem Management team engages with the Operations team to deploy the update.

  • Operations. The Operations team manages the Configuration Manager infrastructure. The Operations team provides the following services:

    • Works with the owners of the CMDB to ensure necessary server configuration data is collected.

    • Builds the update deployment package that includes security patches and software updates, and distributes the package to targeted servers according to scheduled maintenance windows.

    • Works with application owners to identify what their desired configurations are and implements those in Configuration Manager.

    • Works with the security updates that are released and with Problem Management to identify what needs to be distributed.

    • Work with application owners and Problem Management to implement desired configuration checks that need to run against servers.


Microsoft IT uses System Center Configuration Manager for the configuration management of approximately 31,000 physical and virtual servers. These include domain controllers and servers running Microsoft Exchange Server, Microsoft SQL Server, and Web servers. Built on Microsoft technologies such as Microsoft Windows Server® Update Services (WSUS), and the Windows® architecture, Configuration Manager provides MSIT with the ability to comprehensively inventory, assess, and update servers.

One of the benefits of server configuration management using Configuration Manager is the centralization of data and administration. MSIT manages servers in data centers that span the globe. When using Configuration Manager, information from each server in the environment flows to a centralized location allowing MSIT to look at data from either one sub-set of servers or across the entire enterprise.

From an administrative standpoint, security updates are easy to deploy as much of the Configuration Manager functionality is automated. Using a public catalog from Microsoft Update, MSIT needs only to select the updates to be deployed and set the deployment schedule. Configuration Manager integrates with Windows Server Update Services (WSUS). Configuration Manager automatically uses WSUS in the background on the server side for scanning and installation. The Configuration Manager agent engages the Windows Update agent to directly scan, install and report the compliance of software updates.

Non-security updates, including hotfixes, require more effort to deploy because they need additional packaging and deployment configuration. Using Configuration Manager's software distribution feature, non-security updates are bundled and deployed alongside security updates during the same maintenance window.


Figure 1. MSIT data center System Center Configuration Manager logical architecture

Figure 1. MSIT data center System Center Configuration Manager logical architecture

The Configuration Manager architecture at Microsoft does not make use of secondary sites, and is designed to scale from 10,000 to 100,000 servers. Organizations may choose to break up their Configuration Manager architecture, and use secondary sites to accommodate a number of scenarios including limited bandwidth between primary and regional data centers, the inclusion of desktop management, or operating system deployments.

Centralized administration of Configuration Manager is one reason the operations team remains small. The team consists of one service manager, three service engineers, and a small supporting operations staff.

Asset Inventory

In order to manage the tens of thousands of servers at Microsoft, MSIT collects large amounts of asset inventory information, enabling the business to:

  • Forecast hosting costs for datacenters and lock down budgets.

  • Identify the number of systems that are running software to be updated.

  • Identify systems or clusters whose configurations could lead to outages or poor performance.

It is important to have configuration standards defined, it is also important to determine how many servers meet the defined standards. Changes in the environment happen quickly�servers are re-imaged, configurations are changed, software is installed or uninstalled; MSIT uses Configuration Manager to poll the environment for asset inventory information, and keep it up to date in the CMDB.

Configuration Management Database

Configuration Manager asset inventory data is the source for server configuration information and provides the data for the configuration management database (CMDB). The CMDB serves as a centralized location to retrieve data about all of the assets owned by Microsoft IT, including server, networks and applications. The CMDB provides customers throughout the organization with the data they require to develop their custom business intelligence solutions.

Configuration Manager asset inventory collects hardware information and basic operating system configurations—for example, what operating system or service packs are installed, what roles and features are enabled, and what software has been installed. It can collect any item exposed to Windows Management Instrumentation (WMI), the registry, or that is in the local file system.

Using the CMDB to Schedule Maintenance Windows

For convenience, server owners are able to enter their preferred two-hour maintenance window to patch their servers in the CMDB. Many server owners do not designate a maintenance window in the CMDB, so MSIT established a default maintenance windows used to patch and deploy software updates to servers that are not otherwise scheduled.

Security Patch Management

Security patches are released the second Tuesday of every month. MSIT has adopted a 19-day cycle to complete patch and software updates. The 19-day cycle, developed in cooperation with executive leadership, operations, server and application owners, and Information Security, balances the desire to reduce risk and provide the business the time to prepare and orchestrate updates across test and production servers. The process drives the activities of the teams that are accountable for security patching.

Standard Patch Cycle Overview

The 19-day cycle starts on the second Tuesday, known as Patch Tuesday of every month as shown in Figure 2. "Patch Tuesday" marks the start of the 19-day cycle.

Figure 2. Patch cycle

Figure 2. Patch cycle

  • Smoke Test: The cycle begins with the release of security patches on the second Tuesday of each month. The Operations team receives the list of security and non-security updates and creates the update installer package. The Operations team installs the updated packages to their Configuration Manager infrastructure first. That helps validate the update package and ensure that the servers are ready to deploy the patch to smoke test and production servers The smoke test cycle is a deployment targeted to development and test servers that are representative of the configurations found in production.

  • Production: Production servers are updated in the maintenance window set by the customer.

  • Force patch. Any server that remains noncompliant after Production patching cycle will be updated in accordance with the customer selected maintenance window during Forced Patch week. This is the final opportunity to install updates in the patch cycle

Pre-Patch Deployment Activities

Risk Assessment and Scheduling

The MSIT Information Security team uses a standardized risk methodology to determine the risk of applying or not applying patches to vulnerable servers. Once the nature of each patch is established, a rating is assigned as defined in Table 1.

Table 1. Patch Ratings and Definitions




A vulnerability whose exploitation could allow the propagation of an Internet worm without user action.


A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of users' data, or of the integrity or availability of processing resources.


Exploitability can be mitigated to a significant degree by factors such as default configuration, auditing, or difficulty of exploitation.


A vulnerability whose exploitation is extremely difficult or whose impact is minimal.

Microsoft IT follows two schedules for deploying updates to servers:

  • Updates of all ratings from low to critical deploy within the regular 19-day cycle.

  • Less often, active exploits or out-of-band updates must deploy rapidly and therefore follow an immediate deployment timeframe (IDT) cycle. Typically, IDT patches deploy within 24 hours of release.

Creating and Deploying Security Patch Deployment Packages

To create a security update deployment package, the Operations team first receives the list of updates that have been released, ranked for criticality, and approved for deployment into the Microsoft environment by the Information Security team. The detection of a new bulletin triggers a patch approval PowerShell script that provides automation responsible for looking up the bulletin IDs in WSUS and approving the updates for deployment in Configuration Manager. Prior to wrapping automation around this process, the Operations team used the Configuration Manager console to manually approve updates.

MSIT tailored automation logic to approve only the updates required by Information Security for the Microsoft environment. While it is possible to simply approve all updates, selectively choosing only the packages suitable for the environment greatly reduces the amount of storage required on the Distribution Points, limits the associated replication and client processing time, and reduces demands on the network.

Automation for Creating Collections, Advertisements, and the Task Sequence

Using PowerShell MSIT automated the creation of individual Configuration Manager collections. Each collection corresponds to a distinct maintenance window and includes all of the servers scheduled for updates during that time. The automation runs continually before, during, and after patch cycles. Collections are kept up to date, and the system scans daily for bulletin re-releases and out-of-cycle bulletin updates.

Advertisements make the connection between what to run (such as software distribution packages and task sequences), which collections to target, and when to run them. A distinct advertisement is created per collection, but all of the advertisements run the same task sequence.

The task sequence defines each step required to take place and provides a logical structure around those steps.

As a best practice, MSIT uses Configuration Manager Task Sequence engine, which enables the deployment software updates at the same times as security patches. The task sequence engine orchestrates the order of actions performed and provides customers the ability to add pre- or post-actions to the deployment package. The custom-built base package has a placeholder to accommodate software update requests from Problem Management and handles the various reboots that might be required during the update deployment.


To avoid negative impacts to a large number of servers, MSIT first performs a smoke test of security patch and software updates on development and test servers that are representative of the configurations found on production servers. This best practice provides the operations team the opportunity to ensure a deployment is configured correctly and the Configuration Manager infrastructure is functioning as expected, and provides application owner the opportunity to test line of business (LOB) applications with the updates early in the cycle so they can fix issues before broader deployment.


As part of the patch cycle, communication is key in setting expectations. As another best practice, a weekly communication rhythm was adopted to inform stakeholders what is being patched, when it is being patched, how the efforts are going, whether there are patch deployment or installation issues, and finally whether the compliance goals were met.

Ongoing Patch Deployment Review

Even though scripts have automated many of the actions that the Operations team used to perform manually, the team cannot let the cycle run completely unattended. Errors in automation can block updates from being approved or deployed and affect compliance results. The Operations team monitors automation functions, to ensure each is operating properly.

Data from each patch cycle including Meta data, such as quantity and type of patches deployed is persisted in a SQL database. The Operations team analyzes this data each week of the 19-day cycle to assess if the organization is on schedule to meet the security-patch compliance target. Reports comparing previous cycles with similar characteristics to the current cycle are used to asses if deployments are on target or identify challenges, which require further investigation. The historical data provides an understanding of trends, based on the comparison of experience with similar cycles that allows for a proactive patch cycle analysis. The team checks the data on a weekly basis to determine whether they are on trend. When a cycle is not on trend, indicators from the report as well as input from the community help MSIT determine whether there is an infrastructure problem, or a problem with the list of approved updates, or whether there an issue with the actual patch.

Post-Patch Deployment Activities

After a patch cycle has completed, MSIT uses Configuration Manager and/or other vulnerability assessment tools to scan assets and verify if patches were properly deployed. MSIT maintains a service level agreement (SLA) with the Information Security team of 95 percent compliance for security patches.

Report on Security Patch Compliance

In this final step, the Information Security team performs a scan of the environment to measure compliance, and provides platform compliance state reporting to executive leadership, MSIT operations, and server owners.

Software Distribution

As a best practice, MSIT uses Task Sequence technology, a feature of System Center Configuration Manager, to install non-security software updates on servers during the standard 19-day patch cycle. The table below displays the process workflow for each team and the tasks to be completed:

Software Distribution Intake Process:





Problem Management

The problem Management team reviews the root cause, and remediation for high priority incidents across MSIT.


Problem Management

The remediation is bundled into a software package, or .MSI file that can be easily deployed

Stakeholder Signoff

Release Management

A ticket is then created with Release Management, who priorities the release, reviews with the Change Advisory Board (CAB), and schedules for implementation.


Release Management

Release Management sends communications to the relevant server owners, and hands off to the Operations team.



The Operations team builds the advertisement for the targeted servers, and deploys the software distribution package.


In order to communicate the additional software distributions deployed during maintenance windows, MSIT develop a "pre-deployment" report. Users can access the report to view software distributions targeted for their servers along with the updates targeted for the next cycle. A "post-deployment" report for customers and the Operations team is available to view deployment results for a given cycle.

Desired Configuration Management

The Desired Configuration Management (DCM) feature of System Center Configuration Manager allows you to assess the compliance of servers with regard to a number of configuration items. Because configuration drift, often a result of change, can be a significant driver of incidents in any environment, a desired configuration service was developed. The centralized desired configuration management service enables configuration maturity at the Enterprise, Infrastructure, and Application levels.

The service compliments another MSIT strategy titled "stay current". This strategy measures and reports on the compliance of servers to hardware and software standards. Server owners are able to use "stay current" reports to determine how their servers measure against data center compliance standards. They can also request their own custom configuration monitoring for DCM to monitor.

For more information about the "Get Current" strategy, visit http://technet.microsoft.com/en-us/library/hh475857.aspx.

Service owners can define configuration templates to use as a baseline or can ask the Operations team to look at specific values in asset inventory. The Operations team uses the baseline template or the configuration values that the service owner deems as being optimal in the CMDB to audit the server owner's environment. The Operations team provides comprehensive reporting to help the server owners understand how compliant they are against their baseline. MSIT separates the DCM service out into two areas:

  • Global desired configurations are baseline configurations that apply to all servers, and are derived from MSIT server standards. Results from this category are used by server owners to correct configuration drift as well as problem managers to identify negative trends

  • Application specific designed configurations are configurations defined by application owners and only apply to the servers running their applications.

Microsoft IT evaluates compliance on a daily frequency and therefore an errant change made by a support personnel will be reflected in the report the server owners receives within 24 hours.

Three concepts are key to understanding what is required to configure DCM to detect configuration drift:

  • Rules (configuration items). Rules are the actual formulas used to validate target configurations.

  • Technology role (baseline). A role is a logical collection of rules targeted to a specific configuration type. For example, a role might contain rules that target a particular group of application servers, or a particular technology like SQL Server® using installed configuration data.

  • Server collection. A collection is a target group of servers and is constructed dynamically. A server is included in the collection if it meets the conditions established when the server collection was created. The server collection may be based on a naming convention, a registry entry, or existence of a particular file. A server collection will map one to one to a technology role.

The configuration management service has a single initial onboarding process and a single sustain process. Onboarding requests are bundled into releases and completed twice monthly. Sustain processes are completed upon request, based on queue state and workloads. As illustrated in Figure 4, the initial onboarding process consists of three sequential sub processes.

Figure 4. The primary onboarding process

Figure 4. The primary onboarding process

These three sub-processes are:

  • Intake process. The intake process is the starting point for requests to initiate a new template or modify an existing one.

  • Triage process. During the triage process requests are reviewed for accuracy and completeness, then prioritized and scheduled for engagement based on criticality, resources, and release cycles.

  • Onboarding (release cycle). The onboarding process involves the actual development and implementation tasks needed to instantiate a configuration collection package in production.

Best Practices

Imposing Compliance Deadlines

Deadlines are important for security patch compliance. Many external organizations have communicated to MSIT that they struggle with this. If the organization is serious about limiting and meeting their risk obligation, senior leadership will need to be uphold compliance deadlines. MSIT recommends and uses the approach that a patch not installed by a server owner prior to a compliance deadline, will be installed for them. Executive sponsorship is key to getting server owners to participate or adhere to deadline.

Standardization and Desired Configuration Management

It is much easier and less costly to implement a patch and vulnerability management program when standard configurations are used. In an extreme example, patch management tools may be ineffective if deployed within an environment where every IT device is configured uniquely, as side effects of the various patches on the different configurations will be unknown and untested. Organizations should focus their standardization efforts on the systems that make up a significant portion of the IT resources.

One example of best practices within standardization is to establish a baseline. A baseline is a set of documented standard configurations of a product or system at a specific point in time. Baselines establish a standard that systems of the same class and category are required to match. Effective IT operations use baselines as a trusted point from which systems are built and deployed. Asset inventory provides accurate information for the servers, including all software that is required by different types of systems or server roles. MSIT uses the CMDB to store baselines. The baselines include operating system version and application versions plus all required software updates.

Using Problem Management

Service desks are an excellent source for identifying non-security software update trends. A best practice is to analyze ticket volumes to identify trending issues and deploy fixes early on that can prevent problems before they happen at scale. This is another way MSIT uses Configuration Manager to support their configuration management efforts, by proactively rolling out fixes to the entire environment rather than just addressing issues as they break.. Performing enterprise-wide comparisons, MSIT are able to target any server, or any group of servers, that needs the non-security software update.

Monitoring is another best practice within problem management. System Center Configuration Manager infrastructure servers are monitored using System Center Operation Manager to ensure they are online and available during maintenance windows. Monitoring is suppressed on the data center servers while they are being patched.

Default Maintenance Windows

Providing a default maintenance window accommodates the majority of server owners. Performing patching updates that often require reboots on weekends or during their local off-peak business hours results in few significant impacts to the applications during key business hours.

Gathering Performance Metrics

Microsoft IT operates on the principle that "you cannot improve what you do not measure." To improve services, performance statistics are gathered and analyzed. Some suggested metrics to collect are shown in Table 2.

Table 2. Sample Patch Management Metrics

Sample Metrics


Number of patches released

Number of released patched per month, provides a baseline for month-over-month comparison.

Overall compliance per patch cycle

Overall compliance metric for all patched servers in the environment against the successful deployment of all updates during a patch cycle.

Patch success ratio (per patch)

This metric can be used to determine whether a single patch failure negatively impacted overall compliance metrics.

Patch success ratio (per server)

Can be used to determine whether a specific type of server or configuration is the common factor in patch success or failure

Number of support incidents (per patch)

Number of support engagements that are initiated during a patch deployment per patch.

Agent health – 95% healthy

(daily measurement)

Number of systems with a CM agent installed which have successfully returned inventory data and patch results within configured refresh schedule

Time from smoke test success to 60% saturation deployment

This measurement establishes an ongoing baseline comparison that helps validate each milestone success of the patch process in meeting overall compliance goals for each patch cycle.

Identify time from 60% to 80% saturation deployment

Identify time from 80% to 95% saturation deployment


The biggest change that has occurred since Microsoft first employed a patch management process has been the cadence and consistency in which patches are applied. The established process of patch management allows predictability for a server or application owner, hence the ability to meet compliance expectations increase.

Improved processes and the use of System Center Configuration Manager 2012 have reduced the patch cycle from 30 to 19 days, despite a steady increase in the number of released patches, the inclusion of non-security software updates, software distributions, and growth in the number of servers in the environment.

The security patch management service was designed to proactively narrow risk by shortening the amount of time that a security or configuration vulnerability can affect servers on the network. This has been achieved through the creation of a predictable global process and project cycle for applying security patches.

The introduction of DCM as part of the configuration management program has given MSIT the ability to look at baselines and help server owners ensure that their servers and IT systems comply with desired configuration states. The desired configuration service takes some of the custom business logic that other teams were building on top of asset inventory to assess the servers in their environments, and made it part of the overall configuration management service offering. The resulting platform consistency has helped improve availability, security, and performance network-wide.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:



The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.


Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2012 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Excel, Hyper-V, SQL Server, Windows, Windows PowerShell, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.