Chapter 4

Setting Up and Deploying VMM 2012

The previous chapter discussed the new Virtual Machine Manager capabilities, the components of this private cloud–management product, and how the components relate to each other. The focus now shifts to preparing for VMM setup and deployment. This chapter shows you how to do the following:

• Relate VMM requirements to your business needs
• Prepare to install VMM
• Install and configure VMM
• Use clustering to ensure high availability

Discovering VMM 2012 Installation Requirements

Don't just grab the installation media and execute the setup. First take a little time to study the installation requirements. Installing VMM and its components isn't rocket science, but it is important to review requirements that might influence the following choices:

• Should you upgrade your current version or simply reinstall?
• Should all the components be on one server or distributed?
• Should there be one physical location or several?
• Should there be a separate database server or cluster?
• Should there be separate library shares, an existing fileserver, or cluster?
• Should you use Hyper-V only or a mix of hypervisors?
• Should there be highly available VMM?
• Where is the best place for the self-service portal?
• How does VMM update management fit into your current updating strategy?

Studying the VMM 2012 installation requirements can help you answer these questions before you install the software.

The number of servers you'll need for VMM depends on whether you are using a single server or distributed components with high availability for some components.

As recommended in Chapter 3, “Introducing the VMM 2012 Architecture,” one suitable approach is to create a management or infrastructure cluster based on Hyper-V and build your components inside multiple virtual machines. You can start with a two-node cluster of capable physical hosts and build guest clusters for those components that support high availability. This increases cost, but it considerably improves flexibility, scalability, and availability. You will probably add other System Center 2012 modules after VMM, so build a good foundation.

If you are building a private cloud and expect it to grow substantially, you should distribute the VMM components across a number of servers and, ideally, each in its own (virtual) machine. If you base your cluster on Windows Server 2008 R2 Datacenter edition, the number of Windows licenses is not an issue because you are entitled to an unlimited number of licenses.

Many of Microsoft's minimum and recommended requirements are open for debate. Ignore the minimum values and be generous on the recommended ones. If you build your System Center virtual machines on Hyper-V, setting a dynamic maximum memory value, the memory-demand information in Hyper-V Manager will give you good idea about its real-life requirements if you leave it running for a while. Set the minimum memory value to at least 2 GB to avoid a failed memory requirement during setup. It will save you from another reboot.

VMM Management Server

The hardware and software requirements for the VMM management server largely depend on the number of virtualization hosts it manages, the locality of the database, and the location of the VMM library shares. Check the requirements for those as well if you separate these components.

For the best scalable approach, use a dedicated (virtual) machine for the VMM management server and place the VMM library and database in their own (virtual) machine (clusters). Monitor the server's resources with System Center tools such as Operations Manager to determine whether additional resources are required.

The general requirements for the VMM management server include the following:

• The VMM management server must be a member of an Active Directory domain.
• The name of the VMM management server can have a maximum length of 15 characters.
• Startup memory should be 3 GB if the VMM management server runs on a Hyper-V R2 SP1 host with dynamic memory enabled.
• Running the VMM management server on a failover cluster requires Windows Server 2008 R2 Enterprise or Datacenter edition.

Table 4.1 lists recommended hardware requirements for the VMM management server. Table 4.2 lists software requirements.

Table 4.1 Recommended Hardware Requirements for the VMM Management Server

Table 4.2 Software Requirements for the VMM Management Server

VMM Console

Installing a VMM management server automatically includes installing the VMM console. This section describes the requirements for installing the VMM console on a separate computer.

As noted in the previous section, the VMM management server must be a member of an Active Directory domain. Table 4.3 lists recommended hardware requirements for the VMM console. Table 4.4 lists the software requirements.

Table 4.3 Recommended Hardware Requirements for the VMM Console

Table 4.4 Software Requirements for the VMM Console

VMM Self-Service Portal

The general requirements for the VMM self-service portal include the following:

• Installation must be on a separate (virtual) machine.
• The self-service portal cannot be installed on a domain controller.
• Client computers accessing the self-service portal must use Internet Explorer 8 or later.

The requirements for the VMM self-service portal depend on the number of simultaneous connections to the web server. Monitor the server's resources with System Center tools such as Operations Manager to determine whether additional resources are required. Table 4.5 lists recommended hardware requirements for the VMM self-service portal. Table 4.6 lists software requirements.

Table 4.5 Recommended Hardware Requirements for the VMM Self-Service Portal

Table 4.6 Software Requirements for the VMM Self-Service Portal

VMM Database

The general requirements for the VMM database portal include the following:

• The VMM database server must be a member of an Active Directory domain. If that domain differs from the one containing the VMM server, a two-way trust relationship must exist between the two domains.
• The name of the server cannot exceed 15 characters.
• The SQL instance needs to be case-insensitive with collation type SQL_Latin1_General_CP1_CI_AS. Types other than Latin1 are supported as long as the collation type is CP1_CI_AS.
• The required server roles for the VMM admin account on the VMM database are dbcreator, process admin, and security admin.
• Database role membership should be db_owner.

The hardware requirements for the VMM database server depend on the total number of hosts you manage (see Table 4.7). Monitor the server's resources with System Center tools such as Operations Manager to determine whether additional resources are required.

Table 4.7 Recommended Hardware Requirements for the VMM Database Server

Consult Table 4.8 for the software requirements for the VMM database server.

Table 4.8 Software Requirements for the VMM Database Server

VMM Library Server

The VMM library server (Figure 4.1) is essentially a store for the physical files that serve as the building blocks for Hyper-V hosts, virtual machines, and services. The templates and metadata are actually stored in the VMM database. Examples include the following:

• VM and service templates
• Service deployment configurations
• Virtual hard disks
• ISO images
• Scripts
• Several types of profiles
• Stored virtual machines and services
• Update baselines and catalogs

Figure 4.1 Examples of VMM library contents

The general requirements for the VMM library server include the following:

• The VMM library server must be a member of an Active Directory domain. If that domain differs from the one containing the VMM server, a two-way trust relationship must exist between the two domains.
• The name of the server cannot exceed 15 characters.
• VMM includes support for highly available library shares on a failover cluster.
• VMM requires an SMB/CIFS-based file server. It does not support case-sensitive file servers such as Windows Services for UNIX or NFS.

The hardware requirements for the VMM library server largely depend on the size of the files in the library. Table 4.9 lists the recommended hardware requirements. Table 4.10 lists the software requirements.

Table 4.9 Recommended Hardware Requirements for the VMM Library Server

Table 4.10 Software Requirements

Virtual-Machine Hosts

VMM 2012 is the first private cloud–management system that supports the three major hypervisors:

• Microsoft Hyper-V
• VMware ESX
• Citrix XenServer

With this release, Microsoft no longer supports Virtual Server 2005 R2, so you must migrate Virtual Server VMs to Hyper-V before you install VMM.

VMM 2012 supports both individual hosts and clusters on all three hypervisor platforms. Both Hyper-V and XenServer can be managed directly by a VMM agent. Because there is no published API for managing VMware ESX hosts and clusters directly, VMM requires that VMware vCenter Server be added to the VMM fabric as an intermediate management server.

Table 4.11 lists the versions of Microsoft Hyper-V hosts and clusters that VMM supports. Tables 4.12 and 4.13 list the corresponding information for VMware and Citrix hypervisors.

Table 4.11 Supported Microsoft Hyper-V Versions

Table 4.12 Supported VMware ESX Versions

Table 4.13 Citrix XenServer Versions

Hyper-V Host Deployment to a Bare-Metal Computer

A bare-metal computer is a server that has never been used or has to be newly provisioned with an operating system. In VMM you can connect to one or more physical servers via a baseboard management controller (BMC) — which is essentially a computer within a computer — initialize, partition, and format its disks, copy a VHD with a sysprepped installation of Windows Server 2008 R2 Enterprise or Datacenter, and finally add the Hyper-V role. This is a fully automated, standardized procedure. It allows rapid deployment of new Hyper-V hosts. You can also overwrite existing server configurations and bring them under VMM management.

Table 4.14 lists the requirements for bare-metal deployment.

Table 4.14 Hardware and Software Requirements for Bare-Metal Deployment

Update Management

VMM integrates with Windows Server Update Services (WSUS) for managing updates of the servers in the VMM fabric. Servers supported for update management include the following:

• Virtual machine hosts
• Library servers
• VMM management servers
• WDS/PXE servers
• WSUS server

The following tasks are available:

• Configure one or more update baselines
• Scan servers for compliance with attached baselines
• Remediate servers and clusters to make them compliant again with the baselines

The general requirements for update management are as follows:

• In small environments, the WSUS server can be combined with the VMM management server.
• In larger private clouds with higher-volume updates, a dedicated WSUS server is recommended. In this case, the WSUS management console must be installed on the VMM management servers.
• If WSUS is installed on a server other than the VMM server, Microsoft Report Viewer 2010 must be installed on the WSUS server. This report viewer has a dependency on .NET 3.5 SP1 or .NET 4.0.
• VMM is also supported to work with System Center Update Publisher configured for full content updates. Metadata-only updates cannot be added to an update baseline in VMM 2012.

Table 4.15 lists the software requirements for update management.

Table 4.15 Software Requirements for Update Management

VMM Monitoring and Reporting

If you combine VMM 2012 with Operations Manager 2007 R2 or Operations Manager 2012, you get additional information about the health and performance of your private cloud and the virtual machines and hosts that reside there. VMM and SCOM enable this by using performance and resource optimization (PRO).

The integration of VMM 2012 and Operations Manager 2007 R2 or 2012 offers you improved reporting functionality (what-if queries) in SCOM if the SQL Server analysis servers are installed on the Operations Manager reporting server. The minimum version of Analysis Services must be SQL Server 2008 with SP2.

Figure 4.2 shows a diagram view of a VMM 2012 service that is monitored in Operations Manager 2012.

Figure 4.2 SCOM 2012 diagram view of a VMM 2012 service

Setting Up and Discovering VMM

So far this chapter has covered the requirements for VMM and its components. The next part of the chapter focuses on installing and discovering VMM. You are now ready to install VMM based on the topology you have chosen. The following pages deal with standalone and highly available VMM servers, as well as upgrading from VMM 2008 R2 SP1. So get out your VMM 2012 media and start the action!

Preparations for Installing VMM

To make installing VMM a smooth experience, prepare as follows:

• Check your design for networking details, naming standards, network ports, installation locations, required software, and software versions.
• Prepare your physical/virtual machines and clusters before installing VMM.
• Join the machines to your Active Directory domain.
• Create a dedicated domain account for VMM 2012 and add that account to the local Administrators group on the VMM management server.
• Install the Windows Automated Installation Kit (WAIK) for Windows 7.
• Install Microsoft .NET Framework 3.5 SP1 (VMM can autoinstall this feature for you if you skip this step).
• Install a supported version of SQL Server or ensure that you have access to an existing SQL Server installation.
• Prepare file locations and shares for the VMM Libraries.

If you have planned to install a highly available VMM server, you must also do the following:

• Configure an Active Directory domain for distributed key management (DKM).
• Prepare Hyper-V clusters for the VMM management, database, and library servers.

Creating a Domain Account for VMM

Although you may be tempted to use the local system account with VMM, there is a number of reasons why a domain account is the best choice. This account must be a member of the local Administrators group on the VMM management server. A domain account for VMM is required for the following situations:

• If you use a highly available VMM management server.
• If you plan to use shared ISO images with Hyper-V virtual machines you need to perform additional configuration as described on this webpage:

• When your VMM hosts reside in an Active Directory with a disjointed namespace. This is the case when the fully qualified domain name of a Windows server in AD does not equal the FQDN in DNS. You must also add the SPNs of the DNS host FQDN to Active Directory Domain Service if you want to add a Hyper-V host or cluster. For more information, go to the following website:

Configuring Distributed Key Management

The VMM database contains sensitive data about many of your private cloud building blocks. Examples are license keys or admin accounts and their passwords. This is not the kind of information you want unauthorized people to access. For this reason, VMM employs encryption to protect the sensitive data and allow you to store this sensitive information external to the VMM servers.

In fact, VMM uses Active Directory as a redundant and well-protected store for the VMM encryption keys. Of course, you are dependent on your Active Directory admin colleagues, so they must have procedures in place to protect and recover Active Directory in case disaster strikes. Your organization will have a much bigger problem if they don't.

If you install a standalone VMM server, realize that the configuration of distributed key management (DKM) is optional, but nevertheless a recommended practice. However, if you plan a clustered installation of VMM, then you simply have no choice. DKM is a requirement for highly available VMM.

If you are also an Active Directory admin, you can use your credentials to create a container with a descriptive name like VMMDKM somewhere in your AD tree. It doesn't really matter where you place this container as long as you find a logical place for it. If you place the container in the root of your tree, its corresponding LDAP, for example, will be CN=VMMDKM, DN=PRIVATE, DN=CLOUD.

By default the AD groups domain admins, enterprise admins, and AD user SYSTEM have full permissions to this object and its descendant objects. Authenticated users have only read and list permissions. Members of the Administrators group have read, write, and create control, but by default cannot delete child objects.

To create this container, follow these steps:

1. Log into one of your domain controllers with domain admin privileges and start adsiedit.msc from an administrative command prompt.

2. In the ADSI Edit console, right-click ADSI-Edit and connect to your Active Directory domain services.

3. Right-click the desired container or organizational unit and select the object container; select New → Object (Figure 4.3). Type the name of your DKM, such as VMMDKM, and then click Next and Finish.

Figure 4.3 Creating a container for DKM

4. Find the LDAP string. Right-click the new container and select Properties. Then find the attribute distinguishedName under the Attribute Editor tab (Figure 4.4).

Figure 4.4 Using the Attribute Editor

5. From the Security tab, select Domain Admins and click the Advanced button. Choose This Object And All Descendant Objects and set Full Control.

6. Check the Apply These Permissions check box and click OK.

You have now finished preparing to use distributed key management for either a standalone or a highly available VMM installation.

Installing the VMM Server

If high availability is not at the top of your list and you haven't planned to install VMM on a separate management or infrastructure cluster with live migration capabilities, then this installation procedure is meant for you.

On the VMM setup screen, you have access to several tools that might be of interest before you start the actual installation: they include release notes, an installation guide, and a VMM configuration analyzer. From this location, you can also perform a local agent installation, which is discussed later in the book.

6. On the Product Registration page, enter your registration information. You need not immediately provide a product key during setup. You can provide a product key after setup by using the VMM console. If you leave the Product Key field empty, VMM will be installed as an evaluation edition. Click Next.

7. Accept the license agreement and click Next.

8. Choose one of the two options regarding the Microsoft Customer Experience Improvement Program (CEIP). If you think you can benefit from it, answer Yes, I Am Willing To Participate and click Next.

9. Consult your design and enter the correct path for the VMM installation location. You probably don't want to install VMM on the default Windows drive. Click Next to continue.

10. VMM setup will then check to see if you have fulfilled all other prerequisites. Some of them you can simply correct and then click the Check Prerequisites Again button. If you have insufficient memory or if there is a pending restart on your computer, you have to correct this first, restart the computer, and restart the VMM setup. If all is well, click Next.

11. On the Database Configuration screen (Figure 4.5), provide information about the database server. If you already have access to the database with your current credentials, you need only enter the server and instance name. VMM automatically inserts VirtualManagerDB as the new database. If your SQL server listens to a different port or requires alternative credentials, specify them on this page. If the database was created outside VMM or already exists from an earlier attempt, you can decide on an alternative name or first back up and remove that database from the database server. Click Next.

Figure 4.5 Configuring the database

12. At the Configure Service Account And Distributed Key Management page, you can choose between a local system account and a domain account. Provide the domain and the username of an existing domain account. If you are in doubt, reread the paragraph about creating a domain account earlier in this chapter. You get this option only if you are installing the standalone version of VMM. You can change from a local system account to a domain account, but to do so you must uninstall VMM, preserve the database, and then reinstall.

13. On the same page, you can also specify where to store the encryption keys. If in doubt, go back to the paragraph on configuring DKM earlier in this chapter. If you might put VMM on a cluster later, select the Store My Keys In Active Directory radio button, paste the LDAP value, and click Next.

14. On the Port Configuration screen, accept the default TCP ports or choose your own. Be careful when you change these ports. Document the ports you have chosen and also provide the correct ports when connecting to this VMM server from a remote VMM console or when you connect with other servers and components in the VMM fabric.

15. On the Library Configuration screen, create a new library share with a name and location of your choice or use an existing library share. The default location, C:ProgramDataVirtual Machine Manager Library Files, is probably not the best location, because a library can grow quite quickly and the local drive is typically not large. Create a directory on an available drive with plenty of disk space. Note that on a highly available VMM installation you are expected to configure a VMM library location after installing VMM.

16. The Installation Summary screen lets you review all the settings. Go back if you want to correct a setting, and click Install when you are satisfied with all your selections.

17. If all went well, this brings you to the final page, showing that the setup of the selected VMM components is complete. Leave the “Open the VMM console when this wizard closes” check box enabled, and click Close to enjoy the rich new VMM 2012 user interface, which will open the gate to your private cloud.

18. The VMM console offers localhost:8100 as its default connection to the VMM server. You can change this to the name and custom port dependent on your chosen configuration. If you expect to be logging in with different sets of credentials, you can leave the check box Automatically Connect With These Settings set to off and click Connect.

Making the VMM Server Highly Available

With the advent of private clouds as the primary IT landscape for your organization, VMM is likely to become so important that you cannot afford to see it offline for very long — if at all. Unexpected downtime affects not only administrators. The private cloud model extends to many of your delegated admins, the different groups of application owners and self-service users, as well as your customers who might be losing money if they cannot manage their part of the cloud.

Your private cloud design should aim at avoiding downtime for this important component of VMM, but other components should certainly not be neglected and should be made highly available as well. Let's start with a small environment managing only a few virtualization hosts. For this configuration, you might have chosen to install a physical machine with VMM, including all components on a single piece of hardware. This means you have combined the management server with the VMM database, the VMM library, and maybe even the Windows Update server. Of course, server hardware is often very high-quality these days, but if that server's hardware fails and you cannot start the operating system or VMM, how long can you afford to be without VMM's functionality when someone asks you to build a new VM, add some capacity, or deploy a service? Even in small environments, this will not be a professional solution. Even if you can restore a backup in just a few hours, you might still lose important changes.

There are several ways you can build a better foundation for VMM. A safe method is to put the important components in different virtual machines to become not only more scalable, but also much more flexible in transferring those virtual machines between different physical hosts. Even if you don't have any form of clustering yet, the virtual machines are much easier to protect than physical machines. Backing up and restoring a few virtual machines will make your life much easier, as you have probably become accustomed to in recent years.

The second approach is to build separate clusters for SQL Server, the highly available library share servers, and the VMM management service. Keep in mind that you cannot combine the VMM management service and VMM library directly on top of a Windows failover cluster, because you cannot deploy a VMM library agent on the same server as the VMM management server. Combining the VMM library component with the VMM database component is an option. You can place the active database server instance on one node and the highly available file server on another. In case of a hardware failure on one node, both components can live together for a while. The disadvantage is that you have to build at least two clusters of physical Windows 2008 R2 servers just to avoid a hardware failure.

The third option is closer to what you would expect from a private cloud: high availability, scalability, flexibility, and manageability. In this configuration, you take two or more capable physical servers, install Windows Server 2008 R2 (Enterprise or Datacenter) with the latest service pack and important hotfixes, enable the Hyper-V R2 role, enable the failover-cluster feature, add shared storage, and build a multi-node Hyper-V R2 cluster. As in the first approach, all VMM components are either installed in one virtual machine or, preferably, across multiple virtual machines. Apart from tolerance for a physical node failure, you get the additional benefits of live migration, dynamic memory, dynamic storage, and so forth. Of course, if a physical server fails, the guests on that node in the cluster will go down as well but are quickly restarted on one of the other cluster nodes. This Hyper-V cluster is called a management cluster, dedicated to one or more System Center components. Other terms you might come across are infrastructure cluster or private cloud management cluster. The important thing is that you decouple management from the clouds and services you need to manage. Each is fully independent of the other. If your VMM 2012 server is on one of the production clusters, it can suffer if any of the production clusters fail. Of course, there is only a small chance that this will happen, but if it does you are much better off if your VMM 2012 management server, its database, library, and other related management servers are still up and running.

The last and most complete option is to combine the functionality of a Hyper-V host cluster with one or more guest clusters for the most central VMM components, such as the VMM database, the VMM management server, and the VMM library. Web servers hosting the self-service portal can be load-balanced across multiple servers, and any other server that supports some sort of high availability can be added to this concept. This option offers the best of both worlds. It not only protects against hardware failures; it also enables you to patch one virtual cluster node after failing over the virtual SQL server, the virtual VMM service, or the virtual VMM library server and shares.

This does not entail much extra expense. The Hyper-V hosts are already installed with Enterprise or Datacenter editions of Windows. This means you are entitled to four guest OS licenses in the former and an unlimited number of guest OS licenses in the latter. Therefore, building a guest cluster will not add more cost. The Datacenter editions are licensed per processor socket and allow unrestricted virtual-machine migrations between hosts. Using one edition or the other is largely dependent on the number of virtual machines that can live on any of the hosts in the cluster. When you double the number of guests for clustering purposes, the Enterprise edition might quickly prove more expensive than the Datacenter edition.

Now you know why a highly available VMM management server is important. The following instructions show you how to install VMM on a cluster (whether physical or virtual).

Creating a Failover Cluster

If you have never built a cluster, rest assured that the days are long gone when building a cluster involved a touch of magic or a lot of luck. Since Windows 2008, failover clustering has really become a no-brainer because it involves only a few easy steps.

Before you start building guest clusters, you should already have a Hyper-V cluster ready to use. Aidan Finn's Mastering Hyper-V Deployment (Sybex, 2011) is a good source of information about deploying Hyper-V hosts and clusters.

Follow these steps to create a generic, guest failover cluster:

4. Open Disk Manager (diskmgmt.msc), and choose Rescan Disks from the Action menu. Bring the newly presented 1 GB disk online, initialize it, create a partition, and format it. Name the disk Witness and assign it a drive letter (W:, for example).

5. Start Failover Cluster Manager (FailoverClusters.SnapInHelper.msc), right-click it, and select Create A Cluster (Figure 4.6).

Figure 4.6 Creating a cluster

6. Read and accept the Before You Begin screen and click Next.

7. Enter the cluster node names and click Next.

8. Enter the cluster name, check the IP subnet, and complete the IP address. Click Next.

9. Confirm the cluster settings and click Next.

10. Check the cluster report, act on missed requirements, and click Finish.

This generic cluster configuration is now ready for a highly available VMM installation.

Checking the Requirements

As a requirement for installing a highly available VMM, double-check that the following are true:

• A SQL Server installation on a single physical or virtual machine (see the requirements for a VMM database component in this chapter) or a clustered SQL installation is available in the same domain (or in a fully trusted domain) as the VMM management server.
• Microsoft Failover Clustering is installed, configured, and tested.

• Active Directory is configured for distributed key management. (See the section on configuring DKM.)
• Optionally, one or more highly available file shares are available in the same domain (or in a fully trusted domain) as the VMM management server.
• You have already created a domain user for VMM 2012 with appropriate permissions. This account should be a member of the local Administrators group on each cluster node (Figure 4.7).
• All other basic requirements for the VMM management server are complete.

Figure 4.7 VMM 2012 domain user

Setting Up a Highly Available Virtual Machine Manager

On the VMM 2012 setup screen, you have access to several tools that might be of interest before you start the actual install; they include release notes, an installation guide, and a VMM configuration analyzer. From this location, you can also perform a local agent installation, which is discussed later in the book.

Perform the following procedure to install a highly available VMM management server:

Upgrading from VMM 2008 R2 SP1

If you have servers running the previous version of VMM, you can save some of your existing data by doing the extra work of upgrading rather than doing a fresh installation. Most existing data falls into one of the following categories:

• Data about your virtualization hosts that will be rediscovered after they are added to a clean VMM 2012 installation.
• Data that cannot migrate and must be re-created in the new installation

The value of database contents that are not in one of these categories determines whether upgrading is worth the extra work. Although the majority of VMM library files can migrate, objects such as VM templates may need to be re-created based on the VHDs in your current library. The following restrictions apply to upgrading data:

• Back up data before upgrading. A failed upgrade cannot undo the changes it makes.
• System Center Operations Manager 2007 connections as well as performance and resource optimization (PRO) configurations, are lost.
• Job history is lost.
• TCP ports cannot be changed during upgrade.
• Some encrypted data, like passwords stored in templates and profiles, must be reentered manually.

Table 4.16 Preserving Encrypted Data During Upgrades

Upgrade Requirements

On many occasions a clean install is the best approach. Before you decide, consider these upgrade requirements:

• VMM 2008 R2 servers must have SP1 installed.

• VMM 2008 R2 SP1 must be installed on Windows Server 2008 R2.

• A full version of SQL Server 2008 R2 or SQL Server 2008.

• SQL Server 2008 R2 Command Line Utilities installed on your VMM server.

• Old versions of the Windows Automated Installation Kit (WAIK) must be uninstalled before you install WAIK for Windows 7.
• NET 3.5.1.

• Windows Remote Management (WinRM) 2.0 must be enabled.

• Upgrade of Virtual Server 2005 R2 SP1 to Hyper-V.
• Upgrade of older versions of VMware ESX and VMware vCenter Server.
• Upgrade of VMM library servers running on Windows Server 2003.

Moving the VMM Database

If you are running an unsupported version of SQL Server, you must move the database to another server. Another possible reason for moving the database is to upgrade to a highly available VMM server.

These are the steps to move the database:

Preparing the Upgrade

Before you start the upgrade complete the following steps:

Performing the Upgrade

Take these steps to perform the upgrade:

By default the VMM console opens. You can immediately start to discover VMM 2012.

Installing a Management Console

Installing the VMM management server automatically installs the VMM console. By contrast with earlier versions, if you install the VMM management server on a separate computer, you no longer need to install a VMM console on every Operations Manager server. For Operations Manager 2012 to integrate with VMM 2012, you are not required to install a VMM 2012 console, which really simplifies the integration experience.

Use the following steps to install the VMM console:

Installing a Self-Service Portal

Before you install the self-service portal, it is important to check the hardware and software requirements. Verify that the Web Server (IIS) role is enabled with all its required features. You may want to install the self-service portal on its own dedicated server(s).

To install the VMM Self-Service Portal, perform the following steps:

Adding or Removing a PXE Server

A PXE server is used for bare-metal deployment of Hyper-V servers. PXE services can be added by enabling the Windows Deployment Services (WDS) role on a Windows Server 2008 R2 server. The WDS server requires no configuration, but be careful to install WDS with the following information:

• After the WDS role has been added, right-click Windows Deployment Services and choose Configure Server.
• Choose a path different from the OS partition (for example, D:RemoteInstall).
• Select both the deployment server and the transport server options.
• You don't have to add any images to the WDS server because VMM uses a VHD file that you will create later and place in the VMM library.
• You don't have to configure any of the PXE response settings either because VMM uses its own PXE provider.
• Place the PXE server in the same subnet as the physical servers that you want to use for bare-metal deployment of Hyper-V servers.

Take the following steps in the VMM console to add an existing PXE server to VMM:

1. Select the Fabric workspace, expand the Servers folder in the navigation pane, and right-click PXE Servers. Select Add PXE Server (Figure 4.8).

Figure 4.8 Adding a PXE server

2. Enter the name of the PXE server, select a Run As account with proper domain access, and click OK.

To check the progress, click the Jobs workspace and select Set Up A New PXE Server Job in the details pane.

Follow these steps to remove a PXE server:

You can also add or remove a PXE server via PowerShell, which can be accessed either from the ribbon and the PowerShell icon or via Start → Program Files → Microsoft System Center 2012 → Virtual Machine Manager → Command Shell.

If you start PowerShell from the command prompt, you can see if the VMM module is loaded by issuing the following command:

PS C:get-module

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Manifest   BitsTransfer              {Start-BitsTransfer, Remove-BitsTransfer,
                                      Resume-BitsTransfer, Get-BitsT…
Binary     virtualmachinemanager     {Start-SCComplianceScan, Add-SCLibraryShare,
                                      Get-SCLibraryServer, Get-SC…

Add a PXE server with the PowerShell cmdlet in Listing 4.1.

Listing 4.1: Adding a PXE Server

PS C:> $Credential = Get-SCRunAsAccount "Run_As_Domain_Admin"
PS C:> Add-SCPXEServer -Computername "WDS1.private.cloud" -Credential $Credential

Name              : WDS1.private.cloud
ManagedComputer   :
ServerConnection  : Microsoft.SystemCenter.VirtualMachineManager.Remoting
                   .ServerConnection
ID                : dbb330e0-4ea8-476a-988c-27a4cff54877
IsViewOnly        : False
ObjectType        : PxeServer
MarkedForDeletion : False
IsFullyCached     : True

Remove a PXE server with the PowerShell cmdlet in Listing 4.2.

Listing 4.2: Removing a PXE Server

PS C:> $Credential = Get-SCRunAsAccount "Run_As_Domain_Admin"
PS C:> $PXEServer = Get-SCPXEServer -ComputerName "WDS1.private.cloud"
PS C:> Remove-SCPXEServer -PXEServer $PXEServer -Credential $Credential -Confirm

Confirm
Are you sure you want to perform this action?
Performing operation "Remove-SCPXEServer" on Target "WDS1.private.cloud".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend
[?] Help (default is "Y"): y

Name              : WDS1.private.cloud
ManagedComputer   :
ServerConnection  : Microsoft.SystemCenter.VirtualMachineManager.Remoting
                   .ServerConnection
ID                : 24372cbb-b00e-4e12-8c3e-039e836c2335
IsViewOnly        : False
ObjectType        : PxeServer
MarkedForDeletion : True
IsFullyCached     : True

Adding or Removing an Update Server

Take the following steps to add an existing WSUS server to VMM:

1. Select the Fabric workspace, expand the Servers folder in the navigation pane, and right-click Update Server. Select Add Update Server (Figure 4.9).

Figure 4.9 Adding an update server

2. Enter the name of the WSUS server, select TCP/IP port 8530, select a Run As account with proper domain access, and click OK.

Take the following steps to remove a WSUS server from VMM:

You can also add an update server with the PowerShell cmdlet in Listing 4.3.

Listing 4.3: Adding an Update Server

PS C:> $Credential = Get-SCRunAsAccount -Name "Run_As_Domain_Admin"
PS C:> Add-SCUpdateServer -ComputerName "WSUS1" -TCPPort 8530 -Credential 

$Credential

Name                               : WSUS1.private.cloud
Port                               : 8530
IsConnectionSecure                 : False
ServerType                         : RootUpdateServer
Version                            : 3.2.7600.226
UsesProxy                          : False
ProxyServerName                    :
ProxyServerPort                    : 0
ProxyUserName                      :
UpstreamServerName                 : Microsoft Update
UpstreamServerPort                 : 80
SynchronizationType                : Manual
SynchronizationFrequencyPerDay     : 0
SynchronizationTimeOfTheDay        : 1/1/0001 1:00:00 AM
SynchronizationStatus              : Idle
LastSynchronizationDetails         :  Microsoft.SystemCenter.VirtualMachineManager.LastSynchronizationDetails
Languages                          : {Hebrew, Portuguese, Japanese, Greek…}
UpdateCategories                   : {Antigen, Bing, BizTalk Server, Developer Tools, Runtimes, and Redistributables…
                                     }
UpdateClassifications              : {Beveiligingsupdate, Definitie-updates, Essentiële update, Functiepakket…}
DownloadExpressPackages            : False
DownloadUpdateBinariesWhenApproved : True
StoreUpdateFilesLocally            : True
AutoApproveWsusInfraUpdates        : True
AutoApproveNewRevisions            : True
AutoDeclineExpiredRevisions        : True
ManagedComputer                    : WSUS1.private.cloud
CanChangeConfigurationProperties   : True
ServerConnection                   :  Microsoft.SystemCenter.VirtualMachineManager.Remoting.ServerConnection
ID                                 : be9a89a5-fe69-4b7d-9b4f-87f0308ea5a8
IsViewOnly                         : False
ObjectType                         : UpdateServer
MarkedForDeletion                  : False
IsFullyCached                      : True

You can remove an update server with the PowerShell cmdlet in Listing 4.4.

Listing 4.4: Removing an Update Server

PS C:> $Credential = Get-SCRunAsAccount -Name "Run_As_Domain_Admin"
PS C:> $UpdateServer = Get-SCUpdateServer -ComputerName "WSUS1.private.cloud"
PS C:> Remove-SCUpdateServer -UpdateServer $UpdateServer -Credential $Credential

Name                               : WSUS1.private.cloud
Port                               : 8530
IsConnectionSecure                 : False
ServerType                         : RootUpdateServer
Version                            : 3.2.7600.226
UsesProxy                          : False
ProxyServerName                    :
ProxyServerPort                    : 0
ProxyUserName                      :
UpstreamServerName                 : Microsoft Update
UpstreamServerPort                 : 80
SynchronizationType                : Manual
SynchronizationFrequencyPerDay     : 0
SynchronizationTimeOfTheDay        : 1/1/0001 1:00:00 AM
SynchronizationStatus              : Idle
LastSynchronizationDetails         : Microsoft.SystemCenter.VirtualMachineManager.LastSynchronizationDetails
Languages                          : {Hebrew, Portuguese, Japanese, Greek…}
UpdateCategories                   : {Microsoft Research AutoCollage, Microsoft Security Essentials, Virtual Server, Systems Management Server…}
UpdateClassifications              : {English Service Pack, Update, Applications, Definition-updates…}
DownloadExpressPackages            : False
DownloadUpdateBinariesWhenApproved : True
StoreUpdateFilesLocally            : True
AutoApproveWsusInfraUpdates        : True
AutoApproveNewRevisions            : True
AutoDeclineExpiredRevisions        : True
ManagedComputer                    :
CanChangeConfigurationProperties   : True
ServerConnection                   : Microsoft.SystemCenter.VirtualMachineManager.Remoting.ServerConnection
ID                                 : 722008b7-a9cb-42af-b008-0f5c4b789d3e
IsViewOnly                         : False
ObjectType                         : UpdateServer
MarkedForDeletion                  : True
IsFullyCached                      : True

Creating Host Groups

By default, there is one host group called All Hosts. Whenever you add a virtualization host, it will be placed in this folder. If you have many hosts, you can create additional host folders and organize them in a hierarchical way. VMM allows you to create a deep folder structure, but in most cases a simple hierarchy is better.

There is a number of good reasons for placing virtualization hosts in their own separate host group. As you can see by examining the properties of the All Hosts group, you can configure several aspects of host-group properties.

Placement Rules

Placement rules help VMM identify the best virtualization hosts when it deploys a new virtual machine (VM). Such a rule assigns one or more selections that either allow or block placement of a virtual machine on hosts in the host group. You can assign values to up to ten custom properties (see the final item in this section). You specify one of the four choices shown in Figure 4.10 for each of the custom properties. At the time of deployment, VMM compares the VM's values with the rules and allows or blocks deployment of the VM to a host in the group.

Note the difference between “must” and “should.” “Must” is evaluated as binary yes or no, while “should” acts as a more flexible gatekeeper allowing placement of a virtual machine on a host if the conditions conform to the placement rules.

Figure 4.10 Creating a placement rule in a host group

Host Reserves

You can specify that the servers in a host group require certain resources (CPU, memory, disk speed and capacity, network bandwidth) to support the host operating system. Before deploying a VM to a server in the group, VMM ensures that the VM can run without consuming any of the reserved resources. Otherwise, it does not deploy the VM and returns an error.

Dynamic Optimization

If the host group contains clusters, this is the place to configure how aggressively to balance the load among the VMs in the cluster. Chapter 7, “Deploying Hosts and Clusters in VMM 2012,” provides more information about dynamic optimization.

Network

In VMM 2012, it is possible to associate a host group with one or more network resources. The topic of networking can also be found in much greater detail in Chapter 6, “Understanding Network and Storage in VMM 2012.” Just remember that you can specify network resources on a host-group level. Also note that these are not limitations but associations that self-document the network resources that are available to all hosts in this host group.

• Logical networks
• Load balancers
• IP pools
• MAC pools

Storage

If one or more storage arrays are visible to VMM, this screen shows you the storage (both storage groups and logical units) allocated to the host group. Chapter 6 provides more details.

Custom Properties

You can specify a set of custom properties for controlling placement of VMs. Each property is one of the following object types:

• Virtual machine
• Virtual machine template
• Host
• Host cluster
• Host group
• Service template
• Service instance
• Computer tier
• Cloud

You assign each a value to be used in placement rules.

If you have only a few hosts, you might just as well leave them in the All Hosts folder and change the properties in the host group. Be careful not to set the placement rules and host reserves too strictly and make it impossible to place a virtual machine.

When you design your private cloud, also pay proper attention to how to spread your hosts and clusters across the different host groups and specify the placement rules, the host reserves, the network and storage associations, as well as the custom properties that will help you differentiate between the hosts.

There are endless ways of grouping hosts; but by using some of the techniques mentioned in the previous paragraphs, you can probably keep the number of host groups to a minimum. These are a few examples of organizing the host-group hierarchy:

Organize by Location

If you don't have any multisite clusters, this is probably a good approach; but remember that a cluster in VMM is a unit, and the individual nodes cannot be spread across multiple host folders.

Organize by Functionality

If your virtualization hosts are mostly dedicated to a certain type of virtual machines or a particular functionality or department, you can organize the hosts using the name of the functionality or department.

Organize by Hypervisor

If it is relevant to group the hosts by hypervisor, create one host group for each hypervisor in your organization.

Organize by Datacenter

A good way to organize dozens or even hundreds of hosts is to group them by the datacenter in which they reside. Of course, you can make further subgroups per datacenter, but don't overdo it. Limit yourself to two or three levels at most. Remember to keep it simple!

Organize by Development Stage

If your organization uses a Development, Test, Acceptance, Production (DTAP)-type of method, you can create a host group for every step in the development cycle.

Before you reach your final host-group organization, test a few of the previously mentioned types and take a look at the different host-group properties. These are the steps to create a host group:

There are several ways to modify the host group's name or location. By right-clicking the host, you have several options, like Rename, Move, or Delete. You can also find the properties from this context-sensitive menu.

The default host group, All Hosts, cannot be renamed, moved, or deleted. Child host groups can be created under each level. VMM does not stop you from creating a 20-level host-group tree, but this is far from desirable.

If you have added one or more hosts to a child host group, the host groups above that level cannot be removed. First move the virtualization host to another host group and then delete the folder or the entire tree.

Adding a Hyper-V Host to a Host Group

After you set up your host-group structure, you can add new hosts to those groups or move existing hosts from the All Hosts folder to the newly created child host groups.

These are several ways of adding a host to VMM:

Figure 4.11 Checking the job details

If you need to add Hyper-V hosts that are not in the same Active Directory forest, you can find more information in Chapter 7.

An existing virtual machine host can also be placed in a host group from the Fabric workspace under All Hosts and by selecting Fabric Resources from the ribbon (Figure 4.12). Right-click the name of the host, select Move To Host Group, and select the requested host group.

Figure 4.12 Placing a host into a host group

If you would like to see the host-group or host-group path in the Hosts view, right-click the column bar and select Host Group or Host Group Path. This is only one example of adding one of many available columns in the View pane.

Configuring VMM Settings

The Settings workspace is the place to establish a variety of general settings for the product. The following sections describe the available settings.

General

The General section contains the following settings:

Customer Experience Improvement Program Settings

During setup you were asked if you wanted to participate in CEIP. In this section, you can enable or disable your participation.

Database Connection

This provides a read-only view of the database settings: database server name, database instance, and database name.

Library Settings

The refresh interval that VMM uses to index the files on library shares is initially set to one hour. You can either switch indexing off or set a refresh interval (in hours).

Remote Control

The VMConnect port is initially set to 2179. You can change it.

Self-Service Settings

You can specify the email address shown to self-service users in the event of a problem.

Network Settings

This provides access to a number of options for logical and virtual networks, as shown in Figure 4.13. By default, a logical network is created and matched based on its first DNS suffix label. If you change the match setting to Network Connection Name and then add a new Hyper-V host, the Add Host Wizard adds all existing network connections (network adapter names) on the host to VMM. These virtual networks are added to Logical Networks in the Fabric workspace. You can also specify a second matching option to be used if the first fails. In that case, the virtual networks (virtual switches) known to the Hyper-V host are added to Logical Networks.

Figure 4.13 Logical and virtual network options

On this screen, you can also choose whether VMM creates a new logical network if the host network adapter is not associated with a logical network.

Guest Agent Settings

You can configure the way VMM communicates with the VMM guest agent. This can be via either FQDN or IP address.

Network Settings and Guest Agent Settings can also be set via PowerShell. The following command disables auto-creation of logical and virtual networks:

PS C:> $vmmServer = Get-SCVMMServer -ComputerName "havmm1.private.cloud"
PS C:> Set-SCVMMServer -AutomaticLogicalNetworkCreationEnabled $false 
-LogicalNetworkMatch "NetworkConnectionName" 
-AutomaticVirtualNetworkCreationEnabled 

$false -BackupLogicalNetworkMatch "VirtualNetworkSwitchName"

The following command enables communication via IP address between VMM and VMM agent:

PS C:> Set-SCVMMServer -UseIPForVMGuestCommunication $true

Security

Security and delegation in VMM 2012 are controlled by User Roles and Run As accounts. Compared to the previous versions of VMM, this is one area of great improvement.

User Roles

User roles play an important role in delegating access to the different parts of your private cloud and the different workspaces in VMM 2012.

If you open SecurityUser Roles under the Settings workspace, there is initially only one user with the Administrator user role. Except for adding a description, you can only add or remove Active Directory user accounts as members of this role.

Members of the Administrator role can perform all administrative actions on all objects that are governed by VMM. There are a few tasks that can only be performed by the Administrator role:

• Adding Citrix XenServer hosts and clusters (pools) to VMM management
• Adding Windows Server Update Services (WSUS) servers to VMM for update management of the servers in the VMM Fabric

Creating new roles is also a task that can only be done by members of the VMM Administrator role. These user roles can be one of three profile types:

Delegated Administrator

A user with delegated administrator rights can perform all tasks on objects within their assigned scope. They cannot change any VMM settings and cannot add or remove members from the Administrator user role. They cannot add Citrix XenServer servers or WSUS servers.

Read-Only Administrator

Users of this type can view properties, status, and job status of objects within their assigned host groups, clouds, and library servers, but they cannot modify the objects. This user role is suitable for auditors. This role also defines the specific Run As account for the Read-Only administrator to view relevant objects.

Self-Service User

Users with this profile can create, deploy, and manage their own virtual machines and services by using the VMM console or a web portal. A self-service user role specifies which tasks users can perform on their virtual machines and services and can place quotas on computing resources and virtual machines.

Depending on the profile, different options can be set. In the definition of the delegated administrator and read-only administrator, you can not only add Active Directory users as members to the User role, but also select specific library servers and Run As accounts that are authorized for use.

A scope assignment based on the resources in one or more host groups can be defined for all three profiles. The VMM administrator has full access to all resources and cannot be altered under the User Roles section, so there is no Scope section for the Administrator role.

The Self-Service user role can be scoped to one or more specific clouds defined by the VMM administrator. Additionally, specific resources such as VM templates and service templates can be assigned to users of this role. A library path location can be specified for uploading data to be shared with other members of the same role. Unique to this role is a fine-grained list of actions that can be allowed or disallowed, as shown in Figure 4.14.

Figure 4.14 Setting permitted actions for self-service users

The following PowerShell commands set permitted actions for the Self-Service user role:

PS C:> Set-SCUserRole -JobGroup "c7cfbbbd-248b-472f-b991-7a52ec65b756" -Permission 
@("PauseAndResume", "CanReceive", "Save", "CanShare", "Shutdown", "Start", 
"Stop") -ShowPROTips $false -UserRoleDataPath "\vmmlib1.private.cloud
SCVMMLibrary1-Test"
PS C:> $libResource = Get-SCVMTemplate -ID "5c307a0a-5f6f-464a-8e7a- 
78c18077dc2f"
PS C:> Grant-SCResource -Resource $libResource -JobGroup "c7cfbbbd-248b-472f-b991- 

7a52ec65b756"

PS C:> New-SCUserRole -Name "Development Cloud User Role" -UserRoleProfile 
"SelfServiceUser" -Description "" -JobGroup "c7cfbbbd-248b-472f-b991- 
7a52ec65b756"

Run As Accounts

VMM protects Run As account credentials on the operating system level by means of the Windows data protection API (DPAPI). DPAPI uses a Triple-DES algorithm with strong keys. This cryptographic method is safer than password-based data protection.

VMM also uses the distributed key management (DKM) mechanism to store encryption keys in Active Directory, as described in the installation section of this chapter.

Many security-sensitive actions in VMM require credentials. Typing a password for every action in the GUI or in PowerShell is neither secure nor intuitive. As you are probably already accustomed to in System Center Operations Manager, VMM now also allows you to create Run As accounts as safely protected credentials for accessing different types of servers, storage, and network devices.

Run As accounts can be created from the Settings workspace by selecting Run As Account from the Navigation pane. These are the steps for adding a Run As account:

The Access section of the Run As account properties shows who created the account and which user roles and users are related to this account.

For additional security, it is possible to temporarily disable a Run As account if you want to tightly control when such an account is used.

A Run As account can be deleted by right-clicking it and choose Delete.

Servicing Windows

In the Settings workspace under Servicing Windows, a VMM administrator can define one or more scheduled servicing windows. These schedules allow you to reserve time for scheduling services outside of VMM. You can set start time, duration (in minutes or hours), and a recurrence pattern (daily, weekly, monthly).

Servicing windows can be associated with individual hosts, clusters, virtual machines, or services. During the specified times, you can use other applications to perform maintenance on the specific objects.

Use the following steps to subscribe a host to a servicing window.

Backup

You can quickly create a backup of the VMM database. Before you do this, make sure you have prepared a shared directory to which the SQL server has access.

To restore a database, VMM offers a command called SCVMMRecover in the C:Program FilesMicrosoft System Center 2012Virtual Machine Managerin directory.

The syntax of SCVMMRecover is

SCVMMRecover [-Path <location>] [-Confirm]

The command requires the path of the VMM database location and a confirmation. Before you start the database restore, close the VMM console on all computers. A VMM database recovery can be started as follows:

C:Program FilesMicrosoft System Center 2012Virtual Machine Managerin>SCVMMR 
ecover.exe -path \vmmlib1ackupVirtualManagerDB-02122012-191629.bak -confirm
SCVMMRecover 2.0 - Virtual Machine Manager database recovery command-line tool.
Copyright (c) 2008 Microsoft Corporation. All rights reserved.

Virtual Machine Manager database recovery completed.

Summary

This chapter covers all aspects of setting up and configuring VMM as the control center for your private cloud. It details the installation requirements for all VMM components.

You should now understand the design considerations behind the installation choices that VMM provides, and you should have made those choices optimally for your situation. You should be able to determine if a highly available setup of VMM and its important components, such as the database and library, are appropriate for your private cloud setup.

You were given several things to consider when you're deciding whether to migrate from the previous version of VMM or start with a fresh install.

You have seen how different auxiliary components, such as an update server and a WDS/PXE server, can be integrated in VMM. You now also know how to deal with host groups, how to add a domain-integrated Hyper-V host to a host group, and how to configure the items under settings.

You are now ready to learn about another central component of your private cloud, the VMM library.