System Center overview

Microsoft System Center 2012 is a comprehensive management platform, and unified management toolset. It enables server-side tools and applications for cloud and datacenter management, and client-side tools (Configuration Manager and Endpoint Protection) to manage and protect physical, virtual, and mobile client environments. This document provides information about planning capacity and performance for System Center 2012 server-side applications.

System Center server-side applications provide capabilities for application management, service delivery and automation, and infrastructure management, as summarized in the following diagrams.

Deployment and capacity planning

Deploying System Center 2012 server applications requires you to determine the applications you need to deploy, and then carry out capacity planning for each server-side application.  A full installation of the System Center suite takes at least nine separate servers or virtual machines, and a minimum of a 32GB of RAM (cumulative).

There are a number of best practice steps that we recommend you use when planning your System Center 2012 deployment.

Step 1: Identify the System Center applications you need to deploy

• App Controller — Provides common application management that enables self-service management of applications that are on-premise, in a private cloud, or in Windows Azure public clouds using the same tool.  Using App Controller you can manage and deploy services to a private cloud (using VMM) and to a public Windows Azure cloud, in a consistent template driven manner.
• Data Protection Manager (DPM) — Provides enterprise backup capabilities that enable disk-based and tap-based data protection and recovery for computers in an across Active Directory domains. It performs replication, synchronization, and recovery point creation to provide reliable protection and rapid recovery of data both by system administrators and by end-users.
• Operations Manager — Provides system and software monitoring with a single console to monitor and manage physical, virtual, networking, application, and cloud resources.
• Orchestrator — A workflow management solution that enables you to automate the creation, monitor and deployment of computer, cloud, and datacenter resources in your environment.
• Service Manager — Automates the delivery process for changes and incidents to simplify and enable support processes. It provides end-users with a support submission tool and self-service tools, and provides a centralized repository of information across multiple Microsoft products.
• Virtual Machine Manager (VMM) — Deploys and configures virtualization hosts, networking, and storage resources, to create and deploy virtual machines and services.

Step 2: Identify key deployment scenarios

Identify the scenarios in which performance is important and the scenarios most likely to challenge sizing and performance objectives.  For example

Step 3: Identify workloads

Identify the workload that applies to each scenario. For example, the number of virtual machines you need to deploy, or the number of users your self-service solution must support.

Step 4: Identify performance objectives

Define and enter performance objectives for each of your key scenarios in Capacity Planner. Performance objectives reflect business requirements, such as meeting workload requirements and SLAs, and they usually include the following:

• Response time—For example, Microsoft Outlook Web Access transactions should not take longer than 2 seconds to complete.
• Throughput—For example, the system should support 100 transactions per second.
• Resource utilization—For example, a server should not use more than 50 percent of its available processor power.

Step 5: Identify budget and hardware resources

 Identify your budget, which establishes resource constraints. For example, how many servers can your organization afford? Common resources to consider include the following:

• CPU
• Memory
• Disk usage
• Network usage
• Hardware price

Step 6: Allocate budget

You can use exported Microsoft Excel workbooks from Capacity Planner to add details about the cost of hardware to help you calculate the budget for the deployment. 
In terms of budgeting time and device utilization, latency of transactions and percentage of device utilization is calculated by Capacity Planner. This is done by simulating the server application, hardware devices, and projected user load.

Step 7: Evaluate

Evaluate your design against objectives and budget. Repeat this step as often as necessary. You might have to modify your design or allocate your resource budget differently to meet performance objectives. 
Capacity Planner can help you accomplish the following tasks: 

• Modify your design. 
• Reevaluate requirements. 

Step 8: Validate

Validate your model and estimates. Repeat this step as often as necessary. This is an ongoing activity and includes prototyping, assessing, and measuring.
The further along you are in your project's life cycle, the greater the accuracy of the validation. Validation is based on available benchmarks or on a proof of concept in a lab environment. 

Capacity Planning for App Controller

An App Controller installation consists of the following servers and databases:

• One or more App Controller servers each hosting a website console for access using a supported browser.
• A SQL Server database

System requirements and supported configurations

Use the following resources when planning hardware, software, and capacity requirements for deployment of App Controller servers and SQL Server for App Controller scenarios.

Resource	Details
System requirements (System Center 2012) System Requirements (System Center 2012 SP1)	Summarizes hardware and software requirements, supported operating systems, and SQL Server database requirements.
Scaling limits (System Center 2012) Scaling limits (System Center 2012 SP1)	The section “Performance and scale” in the System Requirements topics summarizes the supported scale limits for App Controller.

Capacity Planning for DPM

A DPM installation consists of the following:

• One or more DPM servers
• An instance of SQL Server running on the DPM server, or alternatively on a remote server located in the DPM server domain.
• The storage pool on which the DPM server stores replicates and recovery points for protected data.

Capacity planning tools

DPM provides storage calculators for sizing DPM storage pools for applications that can be protected by DPM, including Hyper-V, Exchange, and SharePoint. Note that this tool is designed for DPM 2010. Obtain the Storage Calculators for System Center Data Protection Manager 2010 from the Microsoft Download Center.

System requirements and supported configurations

Use the following resources for DPM capacity and deployment planning:

Resource	Details
Planning the DPM server configurations	Use the information in this location to do the following: Estimate the number of DPM servers required in your deployment Decide where to locate the DPM servers. Get best practices if you want to use a remote SQL Server
Planning the storage pool	Use the information in this section to: Identify the type of storage you want to use for DPM Calculate the capacity requirements for the DPM storage pool Plan the disk configuration and capacity
Planning tape libraries configuration	If you are using DPM with tape libraries or tape drives attached to the DPM server with SAN or SCSCI, using the information in this section to plan the number of tapes you need, and get information about compatible tape libraries.
Planning Operations Manager Server configuration	DPM provides administration using the Operations Manager console. Use the information in this section to estimate the number of servers running Operations Manager that are required for your DPM deployment.
Planning protection groups Planning protection configurations	Use this section to identify the types of data you want to protect using DPM, and recovery goals for that data. Identifying this information will help you figure out how many DPM servers you need, where they will be located, and the amount of space you need to allocate in the DPM storage pool.
System requirements	This topic summarizes the following: Hardware and software requirements for DPM servers Storage pool requirements DPM data protection limits SQL Server requirements Software requirements for computers protected by DPM Domain and forest requirements

Capacity Planning for Operations Manager

An Operations Manager deployment consists of the following:

• Management group elements that can be installed on a single server, or distributed across different servers:
  • The management server used to administer the management group and communicate with the database.
  • A SQL Server operational database that contains configuration information for the management group and stores monitoring data collected and processed for the management group.
  • A SQL Server data warehouse database that stores long-term monitoring and alerting data for historical purposes.
  • The Operations Manager agent that is a service installed on a monitored computer. This computer uses the agent to report to a management server in the management group.
  • Management packs that define the information that is collected by the agent on a monitored computer, and returned to a management server.

Capacity planning tools

Operations Manager Sizing Helper tool aids capacity and deployment planning. It helps you to identify hardware and requirements for Operations Manager deployment scenarios, including Windows Monitoring, Network Monitoring, and Application Performance Monitoring. Using the sizing tool, you input the number of Windows computers, the number of network devices, and whether Application Performance Monitoring (APM) will be enabled or disabled in the deployment environment. Based on the figures you specify, the tool estimates the following hardware requirements

• The number of Operations Manager management servers required in the deployment, and the required hardware configuration for the servers.
• The number of servers required to run associated roles, including Operations Database Server, Operation Data Warehouse Server, Web Console Server, and SQL Server Reporting Services Servers, and the required hardware for the servers.
• Resource pool requirements for monitoring network devices.
• Database and data warehouse sizing and requirements.

Obtain the sizing tool Excel spreadsheet from the list of System Center 2012 – Operations Manager tools available on the Microsoft Download Center.  The tools also includes a number of best practices for capacity planning.

System requirements and supported configurations

Use the following resources for Operations Manager capacity and deployment planning.

Resource	Details
System requirements (System Center 2012) System Requirements (System Center 2012 SP1)	Use this topic to identify the following: Software requirements Operational database requirements Data warehouse database requirements Requirements for computers running the Operations Manager agent Port requirements to allow Operations Manager traffic to traverse a firewall, and firewall port exceptions Minimum required connectivity speeds Clustering requirements Scaling limits for numbers of monitored items`
Considerations when Upgrading to System Center 2012 - Operations Manager	Performance and scale considerations when performing an upgrade.
Considerations for a Clean Installation of System Center 2012  - Operations Manager	Performance and scale considerations when performing a clean installation.
Considerations when Designing a Management Group	Performance and scale considerations for servers and resource pools when  designing a management group.
Considerations for Application Performance Monitoring	Performance and scale considerations for agents and the operations database when monitoring application performance for .NET applications.
Considerations for High Availability and Disaster Recovery	Performance and scale considerations for high availability of management servers.
Environmental Prerequisites for Operations Manager	This section summarizes Active Directory, authentication, and certificate requirements, and requirements for agent administration.
Single-Server Deployment of Operations Manager	This topic provides scenario overview planning information for a single server deployment.
Distributed Deployment of Operations Manager	This topic provides scenario overview planning information for distributed deployment.

Capacity Planning for Orchestrator

Orchestrator consists of the following components:

• Runbook designer—The tool used to build, edit, and manage Orchestrator runbooks.
• Orchestration database—Microsoft SQL Server database that contains all of the deployed runbooks, the status of running runbooks, log files, and configuration data for Orchestrator.
• Management server—The communication layer between the Runbook Designer and the orchestration database.
• Runbook server— Where an instance of a runbook runs. Runbook servers communicate directly with the orchestration database. You can deploy multiple runbook servers per Orchestrator installation to increase capacity and redundancy.
• Runbook tester—A runtime tool used to test runbooks developed in the Runbook Designer.
• Orchestration console—Used to start or stop runbooks and view real-time status on a web browser.
• Orchestrator web service—A Representational State Transfer (REST)-based service that enables custom applications to connect to Orchestrator to start and stop runbooks, and retrieve information about operations by using custom applications or scripts. The Orchestration console uses this web service to interact with Orchestrator.
• Deployment manager— A tool used to deploy integration packs (IPs), runbook servers, and Runbook Designers.

For more information and an architectural diagram summarizing Orchestrator components, see Orchestrator Architecture.

System requirements and supported configurations

Use the following resources for Orchestrator capacity and deployment planning.

System requirement/Supported configuration	Information
System requirements for installation on a single computer (System Center 2012) System requirements for installation on a single computer (System Center 2012 SP1)	Summarizes hardware and operating system requirements.
Feature requirements	Summarizes feature requirements for specific Orchestrator features, including the Management Server, Runbook Server, and Orchestrator Web Service.
TCP port requirements (System Center 2012 and System Center 2012 SP1)	Summarizes the ports required to let Orchestrator traffic through corporate firewalls.
Orchestrator Security Planning	Use this section to help with security planning for Orchestrator service accounts, users groups, database security, runbook security, Orchestrator web service security, Orchestrator console security, Orchestrator firewall requirements, Orchestrator security scenarios, and data encryption.
Feature Performance Considerations	This topic includes information about Orchestrator processes that influence performance in a production environment.
Evaluate System Requirements	Use this topic to determine how to plan your Orchestra deployment. It includes information about determining your project scope, identifying tasks you want to automate, identifying system workflows and running jobs, determining the number and placement of runbook servers, fault tolerance requirements, network traffic requirements and potential bottlenecks, and service and operations requirements.
Deployment Recommendations	This topic summarizes server recommendations for your Orchestrator deployment.

Capacity Planning for Service Manager

A Service Manager deployment consists of the following:

• Service Manager management server—The server used to manage incidents, changes, users, and tasks
• Service Manager database—The database that contains the Service Manager configuration items (CI) from the enterprise, including incidents, change requests, and the product configuration.
• Data Warehouse management server—The computer that hosts the server piece of the data warehouse
• Data warehouse databases—Database that provide long-term storage for business data generated by Service Manager, and is used for reporting.
• Service Manager console—The interface used by the help desk staff to perform Service Manager functions. It is installed automatically when the management server is deployed, or can be installed in a standalone manner.
• Self-Service portal—Web-based interface used to interact with Service Manager

Capacity planning tools

The Service Manager Job Aids tool helps you to plan hardware requirements for a number of different Service Manager deployments, including a test and small deployment (100-2000 computers), a medium deployment (2001-5000), a large deployment (5001-20000) and an enterprise deployment (0+). Based on the scenario you select, the tool provides estimations for:

• Minimum hardware recommendations for each required Service Manager role, including CPU, hard drive space, and RAID levels. Usage is indicated by the number of configuration items in the Service Manager database, work items per month, and days of data in the data warehouse.
• Topology diagrams for each scenarios
• Calculator for the free and used hard drive space required for a specific scenario.

Obtain the.zip file containing the job aids from the list of System Center 2012 – Service Manager documents available on the Microsoft Download Center. 

System requirements and supported configurations

Use the following resources for Service Manager capacity and deployment planning.

Resource	Details
Hardware requirements (System Center 2012 and System Center 2012 SP1)	Summarizes hardware requirements for all Service Manager components.
Software requirements (System Center 2012 and System Center 2012 SP1)	Summarizes software requirements for all Service Manager components, and SQL Server requirements.
SQL Server requirements (System Center 2012 and System Center 2012 SP1)	Summarizes required SQL Server features and best practices.
Operations Manager considerations (System Center 2012 and System Center 2012 SP1)	Summarizes considerations for combining Operations Manager and Service Manager.
Language support (System Center 2012 and System Center 2012 SP1)	Summarizes language support for Service Manager.
Databases created (System Center 2012 and System Center 2012 SP1)	Summarizes the SQL Server databases required by Service Manager.
Port assignments (System Center 2012 and System Center 2012 SP1)	Summarizes ports used in a Service Manager deployment.
Installing Service Manager on a Single Computer (System Center 2012 and System Center 2012 SP1)	Describes the topology requirements for deploying all Service Manager components on a single computer for test purposes.
Installing Service Manager on Two Computers (System Center 2012 and System Center 2012 SP1)	Describes the topology requirements for deploying Service Manager on two computers. The first computer hosts the Service Manager management server and the Service Manager database. The second computer hosts the data warehouse management server and the data warehouse databases.
Installing Service Manager on Four Computers (System Center 2012 and System Center 2012 SP1)	Describes the topology requirements for deploying Service Manager on four computers.
Configurations for Deployment Scenarios (System Center 2012 and System Center 2012 SP1)	Summarizes recommendations and test details for each of the deployment scenarios (single computer, two computers, four computers)

Capacity Planning for VMM

A VMM deployment consists of the following elements:

• VMM management server—The server on which the Virtual Machine Manager service runs and which controls communications with the VMM database, the library server, and virtual machine hosts. Management server tasks include:
  • Implementing a VMM role-based permissions models for administrators interacting with VMM using the VMM console or VMM Windows PowerShell cmdlets.
  • Allowing administrators to interact with VMM objects, including hosts, virtual machines, and templates. The VMM management server creates, deploys, migrates, shares, and delete these objects for supported hypervisors, including Hyper-V, VMware ESX, and Citrix XenServer.
  • Processing commands and controlling communications with the VMM database, the library server, and virtual machine hosts.
  • Auditing VMM changes initiated by the system or by VMM administrators.
  • Optionally integrating with Operations Manager.
  • VMM database—The SQL Server database that stores the VMM configuration.
  • VMM console—The user interface that runs on, or connects to, a VMM management server. It is used to centrally view, configure, and manage physical and virtual resources controlled by the VMM server, including virtual machine hosts, virtual machines, services, and library resources.
  • VMM library server—The VMM library server hosts shared folders that are used to store file-based resources in the VMM library. VMM library resources are used to deploy virtual machines and services, and include virtual hard disks, templates, and profiles.
  • VMM self-service portal—An optional website used by self-service users to deploy and manage their own virtual machines. The self-service portal was deprecated with VMM in System Center 2012 SP1.

Capacity Planning Steps

Deployment and capacity planning for VMM can be broken down into three stages:

• Stage 1: Planning VMM server deployment—Plan the number of servers and server topology required in your deployment, and determine hardware, software, and performance requirements.
• Stage 2: Planning the VMM infrastructure deployment—This including planning for the SQL Server database, the library server, and optionally the Operations Manager SDK connector (for Operations Manager connectivity).
• Stage 3: Planning client deployment – Plan for user permissions, and user interactions via the VMM console and Windows PowerShell.

Stage 1: Planning VMM server deployment

Planning for a VMM server consists of the following steps:

• Step 1: Determine the number of VMM servers you need
• Step 2: Determine hardware requirements
• Step 3: Determine high availability requirements
• Step 4: Determine virtualization software requirements
• Step 5: Tweak other performance settings

Step 1: Determine the number of VMM servers you need

To determine the number of VMM servers required in your deployment consider the following:

• What VMM topology do you need? Does your business environment include multiple locations, and branch or remote offices?
• How many hosts and virtual machines do you need to support?
• What are your self-service requirements?

Selecting a VMM topology

The VMM server can be deployed in a number of scenarios. The table below captures details and limits for each type of topology.

Number of hosts	Topology	Topology description	Useful links
Up to 20	Single server	All VMM components installed on single server	SCVMM 2012 SP1: Quickstart deployment guide
21-150	Colocated	VMM server + Library server installed on single computer. All other VMM components installed on second computer
		VMM + Database installed on single computer. All other VMM components on second computer
151-1000	Distributed	All VMM components installed on separate computers. One or more remote computers should be used as library servers and the default library share on the VMM server should not be used. The database server should be located with high-speed connectivity to management servers.

Branch office deployment

For branch office deployments note the following:

• In a branch office deployment, the recommended topology is to place the VMM server in the datacenter, and then place library servers and shares, and hosts, in each branch office. This avoids heavy traffic loads between the library and hosts when transferring files. Note that the VMM server coordinates these transfers but is not directly involved. For scalability, you can use clustering introduced in VMM in System Center 2012 SP1 to add more VMM management servers in an active/passive cluster configuration. Along with a clustered SQL Server database and file server clusters for the VMM library, this provides increased resilience for your VMM topology.  
• For a branch office scenario you can consider installation of a host and a library server on the same computer. The topology works well if you have 150 or less images (templates, ISOs, vhds). The advantage of this configuration is rapid deployment, because the files for building virtual machines do not need to be transferred across a network. The disadvantages are that this configuration requires more overall hard disk space, since it requires maintaining multiple copies of the same files, rather tha using a single, central library server. In addition you do not get all the advantages of intelligent placement with this configuration, since you usually want to use the local host since it is closer to the library server.
• Each VMM server must be installed on a separate computer, and have a separate VMM database. Multiple VMM servers can use the same database server, but not the same database.
• Each host or library server can only be managed by one VMM server.

Support limits

The following table summarizes the support limits for a single management server. Support limits indicate the maximum numbers tested with and supported by a single VMM server (physical or virtual) running with the recommended hardware.

Limit	VMM in System Center 2012 RTM	VMM in System Center 2012 SP1
Virtual machines	8000	25000
Hosts	400	1000
Concurrent jobs	250	250
Concurrent clients	50	100

Step 2: Determine hardware requirements

The hardware on which you deploy VMM is an important factor in capacity planning, performance, and scalability. The largest load contributors in VMM include:

•  Enabling PRO functions using Operations Manager SDK connector
• Calculating effective permissions
• Tracking job status

Hardware requirements recommendations for servers running VMM components are based on the number of managed hosts the VMM server must support, as summarized in the following table.

VMM component	Details	Processor		RAM		Hard disk space
		Minimum	Recommended	Minimum	Recommended	Minimum	Recommended
Management server	Up to 150 hosts	Pentium 4, 2.8 GHz	Dual-Core 64-bit, 2 GHz	2 GB	4 GB	80 GB	150 GB
	More than 150 hosts	Dual-Core 64-bit, 2 GHz	Dual-Core 64-bit, 2.8 GHz	4 GB	8 GB	150 GB	200 GB
Library server	-	Pentium 4, 2.8 GHz	Dual-Core 64-bit, 3.2 GHz or greater	2 GB	2 GB	Varies based on the number and size of the stored files.	Varies based on the number and size of the stored files.
Computer running VMM console	Up to 150 hosts	Pentium 4, 1 GHz or greater	-	2 GB	-	2 GB	-
	More than 150 hosts	Pentium 4, dual processor, 2 GHz or greater	-	4 GB	-	4GB	-
VMM Self-Service Portal (not supported in SP1)	Up to 10 concurrent connections	Pentium 4, 2.8 GHz	Pentium 4, 2.8 GHz	2 GB	2 GB	512 MB	20 GB
	More than 10 concurrent connections	Pentium 4, 2.8 GHz	Dual-Core 64-bit, 3.2 GHz or greater	2 GB	8 GB	10 GB	40 GB

For additional details and software requirements see System Requirements for System Center 2012.

Step 3: Determine high availability requirements

The VMM management server is cluster-aware and if a management server in a cluster fails, automatic failover to an alternative management server in the cluster occurs. If your VMM performance requirements include high availability and failover, consider deploying VMM in a clustered topology. Note the following:

• VMM clustering is only supported in active/passive mode. You can install the VMM management server on up to 16 nodes in the Windows failover cluster, but only one node is active at any time. This means that clustering does not scale capacity, or increase performance times.
• For best performance we recommend that the server running the SQL Server database is installed on a separate failover cluster from the cluster running the VMM management servers.
• In addition we recommend that you running the Windows File Server used for the library server in a failover cluster.

For information about cluster deployment see Installing a Highly Available VMM Management Server.

Step 4: Determine virtualization software requirements

VMM in System Center 2012 SP1 supports the following software as virtual machine hosts:

• Microsoft Hyper-V
• VMware ESX/ESXi 3.5 and 4.1
• Citrix vCenter Server 4.1 and Citrix XenServer 6.0

It’s important to note that the maximum numbers of hosts and virtual machines supported for a single management server are aggregated across all supported hypervisors. For example, each host managed by a VMware vCenter server counts as a host managed by VMM. Therefore if a vCenter server supports 200 hosts and 2000 virtual machines, managing this environment using VMM will reduce overall VMM limits by that amount of hosts and virtual machines.

Step 5: Tweak other performance settings

There are a number of VMM settings that can be tweaked to ensure best use of system resources. These include system refreshers, database job retention settings, WCF timeout, and VHD mount timeouts.

System Refreshers

VMM uses system refreshers to perform periodic polling to detect configuration changes of VMM resources such as hosts and virtual machines, and performance updates. Refreshers run on virtual machine hosts and the library server, and remotely against vCenter server. Polling ensures that the VMM database contains accurate data. Refreshers that run locally on hosts send data back to the VMM management server for processing. Refreshers consume network bandwidth and system resources. If you have hundreds of hosts and thousands of virtual machines, additional network bandwidth will be required to handle refresher traffic. In addition, in some cases you might want to change default polling values to reduce the polling frequency. Refresher settings and their recommended values are summarized in the following table.

Refresher	Details	Default Setting System Center 2012 RTM	Default Setting System Center 2012 SP1
Host (HostUpdateInterval)	Runs on every host and updates host properties. It also updates disk/SAN and host network (NIC / virtual switch) information. It does not check any virtual machine related properties or host performance counters. It can be triggered in the console or with a cmdlet.	30 minutes	30 minutes
VM refresher: light (VMPropertiesUpdateInterval)	Runs at set value on every host currently in the VMM database. It checks the host state and virtualization software status, syncs the virtual machine state, marks virtual machines as missing, and imports new virtual machines created outside VMM.	2 minutes	Never This refresher is turned off for Hyper-V hosts that are capable of supporting WMI eventing. If eventing is not supported the 2 minute refresher is used.
VM refresher: full	Runs at set interval on every host, and when you click on a virtual machine or run the Refresh-VM cmdlet. It updates all virtual machine properties, resource polls, and clustering information. It does not update performance counter information.	30 minutes	24 hours If you need to see property changes made outside the VMM console within 24 hours, trigger the refresher manually.
Cluste refresher	Runs at set interval and refreshes all cluster properties. Can be manually triggered in console or with cmdlet.	30 mins	30 mins
Library refresher	Runs on schedule configured by user and updates the library share information and library objects. Can be manually trigged in console or with cmdlet.	User configurable. Can be disabled, or incremented at hour intervals	User configurable. Can be disabled, or incremented at hour intervals
Perf refresher	Runs at set interview or whenever a state change occurs on the virtual machine. It collects performance counter information of the host and VMs on the host.	9 minutes	9 minutes
VirtualCenter refresher	Runs at set interval and refreshes virtual center properties, ESX hosts and resource pools managed by this virtual center. Can be manually triggered in console or with cmdlet.	30 minutes	30 minutes
PRO Tip refresher	Runs at set interval. Looks for PRO specific alerts in OpsMgr and reconcoiles PRO tips in VMM database with those returned from Ops Mgr. Cannot be triggered manually	30 seconds	30 seconds
Storage light refresher		Na	2 hours. The refresher reads information in cache nstead of performing deep discovery of storage devices.

Note the following:

• Refresher values are created in the registry under the key HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings. All values are of type REG_DWORD and need to be specified in seconds. The VMM service must be restarted to apply new registry values.
• SP1 introduces an eventing channel for business critical events, including virtual machine state changes (start, stop, move etc); cluster node state changes (add, remove, pause), and Hyper-V service state changes. This eventing channel allows critical changes to be propagated in a much faster manually. To use this feature, a host requires either Windows Server 2012, or Windows Server 2008 R2 SP1 with this WMF 3.0 update. For systems that do not support WMF 3.0, SP1 will use the same refresher model as System Center 2012 RTM.
• We recommend that most virtual machine and host operations should be performed using the VMM console or PowerShell cmdlets. If you do make changes, changes that are event-monitored will be updated in VMM almost instantly. Other changes will be reflected within 24 hours, or can be updated manually by triggering a refresh in the VMM console or using the Read-SCVM or Read-SCVM host cmdlets.

Garbage Collect Older Jobs

VMM retains jobs in the database for a period of time for auditing purposes. If the job count in the database exceeds the recommended upper limit (around 10000) VMM might consume large amounts of memory or use high CPU resources, especially when applications try to retrieve job objects when querying for job completion status. To avoid this issue you can tweak the amount of time that jobs are retained in the database.

Registry key	Registry location	Default value	Recommended value
TaskGC	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\Sql\TaskGC	90 days	7 days

For more information see Microsoft support article 2009348: The SCVMM Virtual Machine Manager service may consume high memory or CPU utilization.

WCF Timeout

VMM uses WCF for communication between PowerShell and the management server. It delivers requests from clients, and sends events from the server to the client. If there are a large number of parallel requests, the channel can become overloaded, causing delays which can result in timeouts. If you expect high traffic loads for PowerShell to server communication, increase the timeout value.

Registry Key	Registry Location	Default	Recommended value
IndigoSendTimeout	HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\IndigoSendTimeout	120 seconds	300 seconds

VHD Mount Timeout

If multiple virtual machines are created in parallel from the same base disk VMM needs to mount the same base disk for making checks. This results in a small window where failures can occur due to disk conflicts which might cause VMM to retry the operations. If you are creating a large number of virtual machines in parallel, for example in VDI scenarios, you might want to increase the timeout interval to reduce the chance of failure.

Registry key	Registry location	Default	Minimum	Maximum	Recommended value
VHDMountTimeoutSeconds	HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settingst	10 minutes	10 minutes	1 hour	30 minutes

Planning the VMM infrastructure deployment

The VMM server orchestrates and tracks tasks. The infrastructure components that the VMM server relies on to perform these tasks include the database server, library server, and Operations Manager SDK connector. The SQL Server database serves as a local location for retrieving and storing data. It handles both read and write requests, and must be designed to allow scaling.  The library servers act as a repository for files not stored in the database. As a virtualized environment grows, there is additional pressure on the library server to keep up with the I/O demand. The SDK connector is required to enable PRO-based monitoring and alerting. In an enterprise environment, PRO will impact the performance of the server and database.

Planning for the VMM infrastructure consists of the following steps:

• Step 1: Plan for the library
• Step 2: Plan for the SQL Server database
• Step 3: Plan for networking and storage
• Step 4: Plan for Operations Manager integration

Step 1: Plan for the library

The VMM library server is a file server with one or more shares. A VMM agent runs on the file server, and communicates with the VMM management server. The VMM library contains the following:

• File-based resource storage— The VMM library is a catalog of file-based resources such as virtual hard disks, virtual floppy disks,  ISO files, answer files (UNF, XML) PowerShell scripts, driver files (used during the deployment of an operating system when you use VMM to convert a bare-metal computer to a Hyper-V host), and application packages (including SQL Server data-tier applications, Web Deploy packages, and Server App-V packages). To use a file in VMM it must be added to the library.
• Deployment point—In addition to using the library as a file catalog, the library server is also used as a deployment point for creating and storing virtual machines and templates. The library includes template and profiles to standardize the creation of virtual machines and services, equivalent objects (users-defined groupings of library resources considered equivalent), cloud libraries (read-only shares assigned to a private cloud), self-service user content such as authored templates, and stored virtual machines and services). Hardware and Operating System profiles also appear in the library server, but actually have no on-disk representation because they are stored in the database.
• For more details about library server content, see Configuring the VMM Library Overview.

During a default installation of VMM the library server is installed on the same computer as the VMM management server, with a default share path of c:\Program Files\Microsoft System Center Virtual Machine Manager\VMMLibrary. Alternatively the library server can be installed on a separate computer in the same datacenter as the VMM management server, or in a separate location.

The following sections outline best practices for capacity planning for the VMM library. You can add to these best practices in VMM: Library Server Best Practices, in the TechNet Wiki.

Installation and deployment best practices

• The number of library servers required is function of the quantity and size of the files that will be stored in the library. Review the complete list of hardware and software requirements and guidelines for library server deployment at System Requirements: VMM Library Server.
• If you select not to use the default library share installed on the VMM server, and instead use an alternative share on the server, create the share on a volume that is separate from where you install the VMM server installation files. This helps with both performance and storage capacity.
• If you are deploying more than 150 hosts, we recommended that you do not use the default library installed on the VMM management server. For better performance, install the library server on a dedicated file server or virtual machine host. Installing on a virtual machine host is generally recommended only for a branch office deployment where bandwidth might be limited.
• For redundancy, store the virtual disk and ISO files on a volume using RAID-5 or RAID-1+0. The more spindles that are used the better the performance.
• For performance, assign as many physical disks to the RAID group as possible, to avoid potential I/O bottlenecks when deploying or storing virtual machines.
• If you connect to a library server from hosts across a LAN, the library server should be as close to the hosts as possible on the network. It is a best practice to connect all computers in a VMM configuration with at least a 100-Mb Ethernet connection. Using a gigabit Ethernet connection will improve performance especially when combined with a more powerful processor than the recommended processor on the VMM server. 
• For high availability and failover, make the library servers and shares highly available. To make the library server highly available, you can create highly available file shares on a clustered file server that meets the operating system requirements for the VMM library server. For more information, see Checklist: Setting Up a Clustered File or Print Server (Failover Cluster) and Create a Shared Folder in a Clustered File Server.
• Do not create clustered file shares for the VMM library on the same cluster as a clustered VMM management server installation. VMM does not support this configuration.
• Another way to provide functionality similar to fault tolerance without clustering is through the use of equivalent objects. Equivalent objects allow the use of any instance of certain file-based resources (specifically .vhd files, .iso images, and custom resources) instead of the site-specific one. This allows VMM to perform virtual machine and service deployment in the event of a VMM library server failure. For example, a VHD file that is located on a library share in Seattle and a VHD file that is located on a library share in New York may be marked as equivalent. For more information, see How to Create or Modify Equivalent Objects in the VMM Library.
• VMM does not provide native replication capabilities to replicate physical files files from one library server to another. To replicate library files manually outside VMM, you can use DFS Replication (DFSR) and DFS Namespaces (DFSN), but note the following:
  • If you use DFSR actions that require browsing are not supported because VMM is not DFS-aware
  • VMM views every share it manages as a separate location. So that even if a file appearing in multiple shares is the same across all of them, VMM will view each as a unique file, and assign it a unique GUID.
  • When using DFSR you need to create and manage a virtual machine template n each library share when you want to deploy new virtual machines. The template must reference a VHD file on the local library share as well.
  • If files or folder within a DFSR share change, the file paths on that share are updated in VMM. However, the library shares where the files get replicated to show up as new files in VMM. All the original objects are marked as missing by the Library Refresher. You must manually remove the missing objects from the VMM library shares.
  • The library service must be in the same domain as the VMM management server, or in a domain that has a two-way trust with the management server domain (including domains with disjointed namespaces).
  • Place the library server and shares in the same physical location as the virtual machine hosts they service. To reduce network traffic, plan for use of minimum network bandwidth between the hosts and the library servers. This ensures that the traffic load required when transferring library files to hosts is kept to a minimum. Note that that files are transferred directly from the library to hosts. The VMM server coordinates the job but it not directly involved in the file transfer.
  • To scale out the library environment, add more library servers and shares as requirements grow. Each library server can have multiple library shares. Note that only one VMM agent can run on each library server, and so the library server can only connect to one VMM management server. However, a VMM management server can connect to more than one library server.
  • If you use a SAN, have a library server on the same SAN as the virtual machine hosts that use the library. This ensures that the library server and the hosts can all access the same logical unit numbers (LUNs) on the SAN, which allows for faster file transfers.
  • Deploy hosts and library servers at each branch office managed by a central datacenter. This allows users in branch offices to build virtual machine using resources from a local library server. This ensures productivity during network outages, and saves bandwidth, because copying VMM resources over the network to and from library servers is network intensive.
  • In branch offices you can locate the library server on the local virtual machine host. This avoids network traffic involved in file transfers. For increased I/O performance, locate the library server on a separate volume (and spindles) than the virtual machine host.
  • For easy management of library resources, and to help prevent large file copy operations across WAN links, you can organize your library servers into custom library groups. For example, you can use library groups to associate library servers with a nearby host group. (The library group property can only be set after a library server is added by using the library group property of library servers.) When you create a new virtual machine and you choose a base .vhd from the library, you can scope your choices to library servers associated with the host group where you want to place the virtual machine.
  • Aligning library servers with library groups and host groups is beneficial when your library server is connected to the same SAN as the hosts in a host group. By using descriptive library group and host group names (such as, SAN_A), you can then readily identify which library servers and hosts are connected to the same SAN and therefore can take advantage of faster file transfers on the SAN. When you are selecting an object (template, virtual hard disk, or virtual machine) to create a new virtual machine, you can filter the objects by a specific library group name. When you are selecting a host on which to place the virtual machine, you can filter the available hosts by the aligned host group name.

Step 2: Plan for the SQL Server database

VMM uses a SQL Server database to store the VMM configuration. The VMM database does the following:

• Stores the configuration of the VMM instance.
• Receives performance data from the VMM management server for each of the virtual machine hosts. This data is recorded as a set of rolling averages; each average is updated every 9 minutes. So after the first record has been written it is only updated; it does not grow any larger.
• Delivers virtual machine host performance data to the VMM management server so that it can perform intelligent placement calculations, on user demand, to recommend on which host a virtual machine should run.

The VMM management server interacts with the database as follows:

• Reads the configuration from the VMM database at startup and writes configuration changes to that database.
• Communicates with VMM agents running on the VMM database server, and the servers hosting the private cloud fabric resources (for example the VMM library servers and virtual machine hosts).
• Manages physical-to-virtual (P2V) conversions running on connected servers.
• Manages provisioning of services and virtual machines on to connected virtual machine hosts within the private cloud. Virtual machine images do not pass through the VMM management server, but rather are transferred directly from the VMM library servers to the virtual machine hosts.
• Receives performance data from each of the virtual machines and virtual machine hosts in the private clouds and writes that data to the VMM database. This data is transferred once every 9 minutes.
• Performs intelligent virtual machine performance optimization calculations upon demand to move virtual machines to the virtual machine host within the same private cloud that has lower utilization than the original virtual machine host.
• Performs intelligent power optimization by automatically turning off virtual machine hosts not currently in use. These computers can be automatically turned on if user demand increases.
• Sends configuration and performance data to the VMM console for display.
• Optionally requests and receives performance data from Operations Manager, which it then sends to the VMM console for display. Operations Manager data is not written to the VMM database

Best practices for capacity planning for the VMM database are as follows:

• There are some differences between versions of SQL Server supported for the VMM database in Systems Center 2012 RTM and System Center 2012 SP1. For more information, see System Requirements: VMM Database.
• Hardware requirements and recommendations for the VMM database server are based on the number of hosts in the VMM deployment. For details, see System Requirements: VMM Database.
• The VMM database server must be in a same domain as the VMM management server, or in a domain that has a two-way trust with the management server domain.
• Each VMM server requires a dedicated SQL Server database, and only one VMM management server can connect to a VMM database.
• For high availability and failover, make the database server highly available. To do this, cluster the SQL Server.  SQL Server 2012 provides AlwaysOn support for VMM. For information about AlwaysOn functionality, see SQL Server 2012 AlwaysOn: Multisite Failover Cluster Instance. For information about configure AlwaysOn for VMM in System Center 2012 SP1, see How to configure SQL 2012 AlwaysOn Availability Groups in System Center 2012 Virtual Machine Manager Service Pack 1, on the System Center engineering blog.
• If you configure high availability in your VMM deploy, install SQL Server on a separate failover cluster from the failover cluster used for the VMM management server.
  

Step 3: Plan for the networking and storage

Designing the infrastructure fabric requires consideration of the LAN and WAN network infrastructure, and the storage subsystem. It includes identifying the bandwidth requirements and the bandwidth capacity of the virtualized environment. VMM 2012 supports storage management for SMI-S storage subsystems, and thus provisioning management capacity planning and storage extension needs to be planned and prepared.

Network planning

When preparing the network infrastructure there are three key considerations:

• Connectivity
• Bandwidth
• Network traffic

Connectivity

Ensure that network channels between VMM components are configured correctly. Ensure that firewalls in your environment do not block the necessary communication between VMM components, by ensuring that the correct ports are open. For information about the ports and protocols used in VMM, see About Assigning Ports in VMM.

Bandwidth

Creating and manage virtual machines with VMM can involve moving multi-gigabit files across the network. For example, when you store a virtual machine from a host in the VMM library, or migrate a virtual machine from one host to another.

As a best practice connect all computers in a VMM configuration with at least a 100-MB Ethernet connection. Using a gigabit Ethernet connection will improve performance. If you use a gigabit connection, combined with a more powerful processor on the VMM server than the recommended processor, it will further improve performance.

If your environment extends beyond a central data center to include branch offices or other remote sites where you want to create, run, and manage virtual machines, there are additional topology considerations. For more information, see Supported Configurations.

Network Traffic

VMM performs and number of periodic refreshes of the library, hosts, and virtual machines. These refreshes add to your network traffic. For very large virtual environments, this traffic can become significant.

• By using a Fibre Channel or iSCSI SAN, you can reduce network impact by doing SAN transfers, instead of transfers over the network. When you make a SAN transfer, the logical unit number (LUN) containing the virtual machine is remapped from the source computer to the destination computer instead of transferring the files over the network. SAN transfers are much faster than standard network transfers, and are independent of the size of the files being transferred. For more information about using VMM in a SAN environment, see the "Configuring a SAN Environment for VMM" topic in Deploying VMM (http://go.microsoft.com/fwlink/?LinkId=102058).
• If you use an iSCSI SAN, you also need to consider the network traffic created by using your iSCSI connections with VMM.
• Determine whether any networks in your deployment are isolated, and require a separate VMM instance. For example, organizations often isolate lab networks from production networks and require a separate instance of VMM for each.
• Virtual desktop infrastructures (VDIs) can be co-located in the same instance as server loads. However, if the organization is deploying a non-trivial VDI, we recommend that you dedicate a VMM instance for VDI management. 

Storage planning

When preparing the storage infrastructure, you need to account for storage space requirements for the operating system and VMM server software, and storage for the database:

• To achieve maximum storage performance, you should install the operating system on a separate disk from the VMM server software.
• The database should reside on its own set of disks.
• Follow Microsoft SQL Server best practice guidelines with regard of data and log volume requirements.
• Use RAID-I for your OS and software volume, and RAID-5 or RAID-I+0 for the database volumes.
• Using a SAN will help you achieve the highest performance and availability for your database.
• Protection against network failures can be achieved using NIC teaming on a VMM servers, to group multiple network adapter ports for a connection to a single physical segment. NIC teaming should be supported by the manufacturer of the network adapters in the machine.

Step 4: Plan for Operations Manager integration

You can optionally integrate Operations Manager with VMM to monitor the health and availability of virtual machines and virtual machine hosts managed by VMM. Operations Manager can also monitor VMM components, including the VMM server, the database server, and library servers. Note that Operations Manager is required to use the following features:

• Performance and Resource Optimization (PRO)—The PRO feature leverages the Operation Manager SDK framework to process requires for data and access specific features in Operations Manager that are relevant to VMM. It uses the VMM Management Pack to understand hosts, virtual machines, and host groups. Using extended management packs (PRO packs) monitors are set up to look for specific conditions in a virtual machine or host, and alerts are triggered. PRO places an additional resource load on the VMM server and database, and on the Operations Manager environment. The load increases as the environment and generated data grows.
• Maintenance mode integration
• Creating and viewing VMM reports for VMM component monitoring.
• Support for SQL Server Analysis Services (SSAS) to provide forecasting reports.

To deliver integrated reporting, VMM uses the Operations Manager Connector Framework to connect to a management group. The scope of reporting data available from a connect is limited to virtual machine hosts within that management group. If more than one management groups contains a virtual machine host, two options to deliver integrated reporting are available:

1. Multiple Operations Manager management groups—Use one VMM instance for each Operations Management management group that contains virtual machine hosts.
2. Dedicated Operations Manager management groups—Dedicate an Operations Manager management group to VMM, and multihome the Operations Manager agent on virtual machine hosts.

Note that a VMM instance must be monitored by a single management group, but a management group can monitor multiple VMM instances. 

Option 1: Multiple management groups

This option uses separate VMM instance for each Operations Manager management group that contains virtual machine hosts. The VMM management server in each VMM instance will be connected to an Operations Manager management server. To plan this design, determine the number of VMM instances required, and which management groups will contain virtual machine hosts. This option requires the deployment of additional VMM instances, each with a VMM server and components. It makes placing and sizing VMM management servers more complex, and does not allow consolidation of virtual machine management.

Option 2: Dedicated Management Group for VMM

In this scenario the Operations Manager agent is configured to multihome, so that it simultaneously sends event, alert, and performance data to more than one management group. This will require collaboration with the Operations Manager administrator to define a new management group, dedicated to VMM integration. Operations Manager agents running on virtual machine hosts are configured to multihome, providing pformance data to both their regular management group, and to the VMM-specific management group. This option offers simplified and streamlined deployment, and allows consolidation of virtual machine management.

For detailed information about deploying VMM and Operations Manager, see:

• Configuring Operations Manager Integration with VMM (Note that this article was written for System Center 2008)
• Integrating VMM 2012 and OpsMgr 2012 (Kevin Holman)
• OpsMgr 2012: a quickstart deployment guide (Kevin Holman)
• How-To: Integrate SCOM with SCVMM 2012 and enable ProTips (Andrea Pichler)