MCTS Self-Paced Training Kit (Exam 70-652): Securing Hosts and Virtual Machines
- 6/17/2009
- Before You Begin
- Lesson 1: Securing the Resource Pool
- Lesson 2: Securing the Virtual Environment
- Case Scenario: Planning a Resource Pool Security Strategy
- Suggested Practices
- Chapter Summary
Lesson 2: Securing the Virtual Environment
In addition to the security settings you assign to host servers and resource pool components, you should also look to the security of your production virtual machines. Another element that is essential in any virtual infrastructure security policy is the assignment of appropriate roles to administrators and technicians. Both help complete your virtual infrastructure security strategy.
Preparing Hyper-V Management Roles
You can prepare management and administration roles with Hyper-V in two ways. The first is designed for smaller resource pools and the second is designed for resource pools that rely on a central host server management tool.
Distributed Management Resource Pools In small resource pools, you must rely on the Authorization Manager to assign least-privilege access to administrators and technicians with various roles. These are called distributed management resource pools because they do not contain a central management tool and all Hyper-V hosts are managed individually. Only organizations running very small resource pools would use this approach.
Centrally Managed Resource Pools Resource pools that rely on a host server and virtual machine management tool will also rely on this tool’s delegation capabilities to assign least-privilege access rights to administrators and technicians. For example, organizations that rely on SCVMM would use SCVMM’s internal controls to assign delegation rights.
The method you will rely on is determined by the type of environment you work in, the trust you have in your fellow administrators, and the number of host servers and virtual machines you have to manage.
Introducing Authorization Manager
Authorization Manager (AzMan) is a tool that allows you to manipulate special, application-specific credential stores in Windows servers called authorization stores. Note that Authorization Manager is only available on full installations of Windows Server 2008. Server Core has no equivalent tool. The benefit of these stores is that they can be tied to specific applications and they can be used to assign role-based access controls to either users or groups. As always, groups are preferred because they guarantee that each user is given a specific set of access rights.
Authorization stores can be stored in a variety of locations (see Figure 8-16). Each has its own characteristics, which are outlined in Table 8-4.
Figure 8-16 Choosing the store type during the creation of a new store
Table 8-4 Secure Virtual Service Offerings
Location |
Description |
Locally in an XML file |
For Hyper-V host servers, the XML store is located in %ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.XML. This file must be secured and guarded carefully if you choose to work with local stores. Note that this file is located on both full and Server Core installations. |
However, because it is only an XML text file, it can easily be replicated to any number of independent Hyper-V servers and then reloaded locally to ensure that all hosts run the same access rights configuration. |
|
This store can only be protected through NTFS access rights or through Full Drive Encryption with BitLocker. |
|
Active Directory Lightweight Directory Services |
The authorization store can also be located within an AD LDS directory store. AD LDS does not offer the network operating system capabilities of AD DS, but it does support the ability to create a replication scope for its application-specific directory stores. Therefore, you could use it to ensure that multiple Hyper-V host servers rely on the same authorization settings. |
This store is slightly more secure than the XML store because it is also located within a file on the local file system. However, you need to use directory interfaces to manipulate it. |
|
SQL Server |
The authorization store can also be stored within a SQL Server database. Because many Hyper-V resource pools include a database server to support management tools and utilities, this is unlikely to be a viable option for Hyper-V. Remember that if you use a management tool, you should not rely on Authorization Manager stores. |
However, this option would be more secure than the first two because it is centralized and is contained within a database. |
|
Active Directory Domain Services |
Configuring the authorization store to be saved within the directory service automatically makes it available to any number of domain-joined Hyper-V member servers. Authorization stores are not only used with Hyper-V, but because they are application-specific, you can also save several of them in the directory without impacting the others. |
This option is the most secure and should be the default in any environment where authorization stores for Hyper-V are required, there is no other management tool, and the host servers are joined to a domain. |
Authorization stores provide a simplified data structure for the integration of groups and business rules as well as authorization policies. They can be manipulated through the Authorization Manager Snap-in or its application programming interface (API). In Windows Server 2008, this snap-in is already included in a console that can be called by typing AzMan.msc at the prompt in the Start menu. By default, no store is opened when you first launch Authorization Manager. To open the Hyper-V initial store, right-click Authorization Manager in the Tree pane, choose Open Authorization Store, and then navigate to %ProgramData%\Microsoft\Windows\Hyper-V to open InitialStore.xml. This will populate AzMan with the default Hyper-V store (see Figure 8-17).
Figure 8-17 The structure of the Hyper-V initial store
Authorization Manager was first introduced in Windows Server 2003. Stores that use the AzMan Schema version 1.0 are compatible with Windows Server 2003. Stores that use Schema version 2.0 are only compatible with Windows Server 2008. Version 1.0 stores can be upgraded to version 2.0, but the upgrade process is one-way and irreversible. Because all servers running Hyper-V are also running Windows Server 2008, you can create version 2.0 stores to manage RBAC in Hyper-V. Remember, however, that your domain controllers will also need to be running Windows Server 2008 and be running the Windows Server 2008 directory functional level.
XML stores provide limited role-based access control functionality because they do not support delegation of applications, stores, or scopes. This is because its sole protection is the NTFS access control entries (ACEs) and this level of protection can only control access to the entire contents of the store within the file. In addition, NTFS cannot support sequential writes to a file as a single operation. Therefore, the XML file could become corrupted if two administrators modified it at the same time from two different interfaces. This does not happen with the other locations for authorization stores.
Hyper-V authorization stores are made up of four different components:
Store scope The scope of a store determines its breadth in your organization. Scopes can span geographical locations; organizational structures; operational functions such as development, staging, testing, training, or production; or can simply be assigned to a directory in AD DS. When assigned to AD DS directories, the scope will span the entire directory it is stored in. This is because AD DS authorization stores use Lightweight Directory Application Protocol (LDAP) naming structures and these naming structures provide a directory-level scope.
Store tasks Tasks are based on operations. Even though you cannot create any new Hyper-V operations in AzMan, you can regroup any number of tasks to create specific roles within your organization. Table 8-5 outlines examples of the various tasks you can assign in AzMan with regard to Hyper-V as well as the operations they allow access to. These tasks are not predefined in AzMan and must be defined interactively before you can assign them.
Store roles Roles regroup different tasks to support specific operational functions within your resource pool. Roles can include administrators who have access to everything; Host Monitors; VM Monitors, who monitor either the hosts or the VMs they run; VM Creators, who manage the state of VMs; Host Administrators, who control host-only operations; or any other required role according to your organizational standards.
Assigned users or groups Users or groups—preferably groups—are assigned to the various roles you generate in the authorization store.
Similarly, the process of creating or modifying a store follows a four-step procedure that focuses on each one of the four aspects of a store.
Table 8-5 Tasks and Operations
Tasks |
Operations |
Add external network to server |
|
Add internal network to server |
|
Add private network |
|
Apply a snapshot |
|
Attach internal network adapter to virtual machine |
|
Connect to a virtual machine |
|
Create a virtual floppy disk or virtual hard disk |
|
Create a virtual machine |
|
Delete a private network |
|
Delete a snapshot |
|
Delete a virtual machine |
|
Export virtual machine |
|
Import virtual machine |
|
Modify virtual machine settings (reconfigure a virtual machine) |
|
Pass Ctrl+Alt+Delete (send control signals to a VM) |
|
Pause a virtual machine |
|
Remove external network adapter from a virtual machine |
|
Remove external network adapter from server |
|
Remove internal network adapter from a virtual machine |
|
Remove internal network adapter from server |
|
Remove private network adapter from a virtual machine |
|
Remove private network adapter from server |
|
Rename snapshot |
|
Rename a virtual machine |
|
Resume a virtual machine |
|
Save a virtual machine and stop a virtual machine |
|
Start a virtual machine |
|
Turn off a virtual machine |
|
View Hyper-V Server settings |
|
View network adapter management |
|
View virtual machine |
|
Using the Authorization Manager to Assign Management Roles
By default, only the local administrator of a host system has any role within the default InitialStore.xml policy. Also, the policy is an XML policy by default and is individual to each host server.
AzMan operates in two different modes. Administrator mode lets you modify an existing policy. Developer mode lets you create new policies and modify the structure of an existing policy. AzMan launches in Administrator mode by default.
Ideally, your policies will be stored within the utility directory you use to centralize host server access. This means that you need to create a new policy. When you do so, you’ll need to perform several activities:
Change to developer mode.
Create the store and place it in AD DS. This also defines the scope of the policy.
Identify the application for which you want to create a store.
Define the roles you want to assign.
Identify the groups to which you want to assign the roles.
Ideally, you will begin with the last task because these groups will be required to assign roles to them. Proceed as follows:
Log on with domain administrator credentials on a computer that includes the Active Directory Users And Computers (ADUC) console. Launch the console through the Start menu and Administrative Tools. Alternatively, you can use the ADUC portion of the Server Manager console if you are logged on to a server or are using the console remotely through Terminal Services RemoteApps.
Create the required security groups. These groups should be placed within their own OU if possible. If you have an existing OU structure, identify an appropriate location for the OU in your hierarchy. If you don’t have an existing structure, you can create a new top-level OU called RBAC Assignments. Right-click the domain name, select New, select Organizational Unit, type RBAC Assignments, and click OK. This creates the OU and moves you into it.
Right-click the OU, select New, and then select Group. Name the group, make sure it is a Global Security group, and click OK. You should create as many groups as you intend to have roles. Keep the structure as simple as your organizational policies allow. For example:
Resource Pool Administrators Includes the domain administrators for the utility forest. You should limit the number of users in this role.
VM Users Includes anyone who can use a VM but can only use VMs.
VM Administrators Includes anyone who can modify VM settings.
Add the appropriate accounts to each group. Right-click the group, select Properties, move to the Members tab, and then click Add to locate the accounts to add. Click OK twice when done and repeat for each group. Remember the group names you used and close ADUC.
You can now move to AzMan. Use a computer that has AzMan installed. A full installation of a computer running Hyper-V will work. Log on with domain administrator credentials and launch AzMan by typing AzMan.msc in the Search box in the Start menu. Press Enter to launch the tool.
Note that the existing policy is not displayed. Remember that it is stored within the ProgramData folder, which is a hidden folder by default. You can either type the path to InitialStore.xml or change your settings to view hidden files and folders and simply navigate to locate the file through the Browse button. Open the XML store to view its contents. The path to the store is c:\ProgramData\Microsoft\Windows\Hyper-V. If you are performing this operation remotely, the path is \\servername\C$\ProgramData\Microsoft\Windows\Hyper-V, where servername is the name of the Hyper-V host server whose store you want to modify. Right-click Authorization Manager in the Tree pane and choose Open Authorization Store. Note the structure of this store. Expand each section of the store.
Create new tasks. Rely on the information in Table 8-5 listed earlier. Create each of the tasks in this table. Proceed as follows.
Right-click Task Definitions under Definitions in the Tree pane and choose New Task Definition. Name the task as displayed in Table 8-5. You do not need to add a description because the task name is already descriptive.
Click Add to add operations to this task. You will receive a warning that there are no tasks defined (see Figure 8-18); this message appears only the first time you create a task. Click OK. This opens the Add Definition dialog box.
Figure 8-18 The No Tasks Defined warning
Move to the Operations tab and select each of the operations listed in Table 8-5 for this task (see Figure 8-19).
Figure 8-19 Assigning operations to tasks
Click OK twice when done and repeat for each of the task definitions in the table.
When you have defined the tasks, you can move on to create new roles. Right-click Role Definitions under Definitions in the Tree pane and choose New Role Definition. Type VM Users, add a short description such as Members can work with virtual machines, and click Add to assign tasks to this role. Click the Tasks tab, select the appropriate tasks (see Figure 8-20), and click OK twice to complete the role definition process. Repeat for the VM Administrators role with a description of Members can create and manage virtual machines. Use the values in Table 8-6 to assign tasks to each role.
Figure 8-20 Assigning tasks to role definitions
Table 8-6 Assigning Tasks to Roles
Role
Tasks
VM User
Apply A Snapshot
Connect To A Virtual Machine
Pass Ctrl+Alt+Delete (Send control signals to a VM)
Pause A Virtual Machine
Rename Snapshot
Resume A Virtual Machine
Save A Virtual Machine And Stop A Virtual Machine
Start A Virtual Machine
Turn Off A Virtual Machine
View Virtual Machine
VM Administrator
Apply A Snapshot
Attach Internal Network Adapter To Virtual Machine
Connect To A Virtual Machine
Create A Virtual Floppy Disk Or Virtual Hard Disk
Create A Virtual Machine
Delete A Snapshot
Delete A Virtual Machine
Export Virtual Machine
Import Virtual Machine
Modify Virtual Machine Settings (reconfigure a virtual machine)
Pass CTRL+ALT+DELETE (send control signals to a VM)
Pause A Virtual Machine
Remove External Network Adapter From A Virtual Machine
Remove Internal Network Adapter From A Virtual Machine
Remove Private Network Adapter From A Virtual Machine
Rename Snapshot
Rename A Virtual Machine
Resume A Virtual Machine
Save A Virtual Machine And Start A Virtual Machine
Start A Virtual Machine
Turn Off A Virtual Machine
View Virtual Machine
Now assign the role definitions to role assignments. Right-click Role Assignments and choose New Role Assignment. Select the VM Users role (see Figure 8-21) and click OK. Repeat for the VM Administrators role. This adds the two role definitions to your authentication store.
Figure 8-21 Assigning role definitions to role assignments
You can now assign users to the two new roles. Right-click VM Users under Role Assignments in the Tree pane, click Assign Users And Groups, then choose from Windows and Active Directory, type VM Users and click Check Names, then click OK. Repeat for the VM Administrators role.
Your role assignments are complete for the first server you were working with. Now copy this updated XML file to each of your host servers:
Use Windows Explorer to copy the file to each of the hosts on your network. Make sure you copy the InitialStore.xml to the %ProgramData%\Microsoft\Windows\Hyper-V folder and replace the existing file.
Return to Authorization Manager, right-click Authorization Manager in the Tree pane, and choose Open Authorization Store. Open the remote store on the other host servers. Use \\servername\c$\ProgramData\Microsoft\Windows\Hyper-V to open a remote store. Click OK.
Right-click the new store and choose Reload. This reloads the information in the store. Note that it is identical to the one you just created.
Repeat steps 1 through 3 on each host server to ensure that they all use the same authorization store.
Make sure you repeat this copy and reload process each time you modify the store. This is one more reason why you should use AD DS groups to assign roles: If you need to add or remove a user, you only have to do it in a single location—Active Directory Domain Services—and it will be modified on each of your host servers.
Using SCVMM to Assign Management Roles
As you learned in Chapter 3, SCVMM relies on a SQL Server database to store configuration information about the environment it controls. In addition, it is a sophisticated virtualization management tool that can support homogeneous or heterogeneous resource pools. Because of this, it already includes defined roles, tasks, and operations for the delegation of administrative tasks in resource pools. For example, you have already seen and used the Self-Service Portal, which relies on role delegation to allow users to work with their own VMs. This portal defines roles for users. The Delegated Administrator section of SCVMM defines roles for administrative delegation. Three main roles can be defined with SCVMM:
Full Resource Pool Administrator This is the default administrator role in SCVMM. This role grants access to every SCVMM feature on every host server.
Delegated Administrator This role supports the delegation of administration to portions of SCVMM. These portions include:
Host Groups Delegated administrators can access host server properties and the VMs they run through the host groups you assign them.
Libraries Delegated administrators can access VMs, templates, guest operating system and hardware profiles, ISOs, and more through the libraries you assign them.
Virtual Machine User This role is defined by the Self-Service Portal. Any user that has access to this portal can work with the VMs you assign and the VM rights you grant to the role (see Figure 8-22).
Figure 8-22 Controlling self-service user rights in SCVMM
Working with a variety of the various assignments you create in SCVMM allows you to control exactly which access rights users will be granted.
Delegation in SCVMM is performed through the Administrators view under User Roles. To create a new user role, click New User Role in the Actions pane and then follow the steps in the wizard. The New User Role Wizard in SCVMM lets you assign two different types of delegations: for delegated administrators or for self-service users (see Figure 8-23). By default, the wizard starts in Self-Service User mode.
Figure 8-23 Delegating administrative tasks in SCVMM
Securing Hyper-V VMs
When it comes to protecting virtual machines, you should already be in familiar territory because the VMs you run are mostly production machines and as such should benefit from the standard security features you assign to production systems.
You should still be aware of a few caveats with regard to the VMs you run and who has access to the files that make them up:
Consider how you will structure your storage system for VMs. You should keep all of the files that make up a VM in the same folder for ease of use. However, keep in mind that doing this also makes it easy to steal a VM. Make sure you set tight access control lists on the storage folders you use for VMs and their components.
Parked VMs might be more at risk. Resource pool administrators often have a number of different virtual machines that are not necessarily in a running state. In addition, resource pool administrators often have a tendency to place these resting VMs in a saved state. This generates a file with the memory contents of the VM. In certain situations, this file can be a risk because it can contain in-memory passwords. Malicious users who gain access to this file could use it to discover these passwords and gain access to information they should not have. Keep this in mind each time you save the state of a sensitive VM.
Audit all VM access, as mentioned in Lesson 1. This ensures that you know who has and who wants access to the files that make up your VMs.
Verify that all virtual machines are up to date before you deploy them in a production environment. This process was discussed in Chapter 4.
Keep all VMs—parked or running—up to date in terms of updates and hotfix packages. It is very easy to fall into the “update trap” with VMs and forget to update VMs that have been parked for long periods of time. Then, when the VM is finally restarted, it is at risk and could cause a serious security breach in your network.
Keep the number of resource pool administrators to a minimum while still being able to maintain and operate the environment properly. Resource pool administrators are highly trusted individuals. Screen these individuals thoroughly before giving them this level of authority in your network. If more administrators are required, use the delegation practices mentioned at the beginning of this lesson to assign appropriate rights.
As a rule, you should consider running Windows Server 2008 on your virtual machine servers because this is the most secure version of Windows Server and you should update it whenever new versions come out. In addition, you should be relying on the security technologies outlined in Table 8-7 within your production virtual workloads.
Table 8-7 Secure Virtual Service Offerings
Contents |
Comments |
Communications |
Make sure all users, including administrators, understand their responsibilities in terms of security practices. |
Security configuration |
Pay special attention to the following:
|
Anti-malware |
Implement Windows Defender along with proper antivirus technologies. |
General AD DS security |
Implement very tight permissions management. Implement multiple password policies to require highly complex passwords for administrators. Tighten delegation-of-authority settings on your servers. Implement read-only domain controllers in remote offices. Implement software restriction policies to ensure that no malicious code is allowed to run in the production domain. |
File system |
Secure the file system to protect VSOs. Implement access-based enumeration to further protect information. Rely on digitally signed Windows Installer packages for all third-party or custom product installations. |
Print system |
Implement a full security strategy for all printers. |
.NET Framework security |
Applicable to any machine that has an application role or any machine that includes Windows PowerShell. (In many cases, this will be every server in the VSO network.) |
Internet Information Services (IIS) |
Implement tight Web server security on all Web servers. |
User identification |
Rely on smart card or two-factor authentication for administrators in very secure environments. Highly secure environments will use two-factor authentication for all users. |
Security policies |
Assign proper policies for the VSO network. |
Resource access |
Tightly control all resource access. Implement EFS for mobile users. Rely on AD LDS for custom application resource access. |
Role-based access control |
Implement in every application as much as possible. |
Access auditing/monitoring |
Turn on auditing, as well as AD DS auditing, to track all changes. |
Digital Rights Management (DRM) |
Rely on Active Directory Rights Management Services to apply DRM to all documentation that is copyrighted or sensitive in any way. |
Perimeter networks |
Configure the Windows Server Firewall with Advanced Security to control access to all servers, especially those in the perimeter network. |
Apply the same tool to Windows Vista PCs and mobile workstations. |
|
Virtual private networks (VPNs) |
Rely on VPN connections for all remote access. |
Routing and Remote Access (RRAS) |
Implement a remote access authentication service for users working remotely. |
Secure Sockets Tunneling Protocol (SSTP) |
Ensure that all remote communications, as well as internal intra-server communications, are encrypted. |
Public key infrastructures (PKIs) |
Implement Active Directory Certificate Services (AD CS) in support of smart card deployment and software restrictions. |
Identity federation |
Rely on Active Directory Federation Services for extranet access, if it is required. |
Security Configuration Wizard |
Ideally, create base servers for each role you intend to deploy, create a baseline policy from each of these servers, and apply the policy each time you work with a new server for any given role. |
Virtual service offerings require more in terms of security settings because they are designed to interact with end users and therefore have more services built into the infrastructure. The scope of protection for VSOs depends on the size of the organization. Certain security technologies are reserved for resource pools, just the way that some are reserved for virtual service offerings. For example, you should not need to run Server Core in your VSOs because they are virtual machines. It is more important to make sure that you apply the appropriate level of security on a full installation of Windows Server 2008 than to deploy Server Core on virtual machines. In the long run, you will appreciate the access to the graphical interface when it comes to long-term management practices of your VSOs.
Populating Virtual Machines on Host Servers
You should consider relying on the various virtual networks supported by Hyper-V to segregate traffic between machines. Remember that Hyper-V supports four different virtual network types: public, internal, dedicated, and private. By linking your virtual machines to each different network type, you can further protect them from attack (see Figure 8-24).
Figure 8-24 Controlling VM connectivity through Hyper-V virtual networks
You can also use multi-homing—the inclusion of multiple virtual adapters in a VM, with each adapter linked to a separate network—to further reduce VM access to public networks (see Figure 8-25). For example, you might prepare a perimeter network and link each machine—authentication server, Web Server, management systems, and so on—to a private network. Then you multi-home the Web server or any server that needs to interact directly with the public to a public, external network. This lets Internet users access the Web server, but all other perimeter communications are handled over the private network and are more secure because they are not exposed to other networks.
Figure 8-25 Creating a perimeter network in a virtual environment
Be creative when you position virtual machines on your servers. After all, you want to maximize virtual machine density on your host servers to minimize the number of hosts you require. However, always make sure that VMs that are of a different level of sensitivity are isolated from each other. This can only be done by managing and assigning Hyper-V’s virtual networks.
Managing Time Synchronization in VMs
When you run enlightened guest operating systems in your virtual machines, you run virtual machines that can take full advantage of Hyper-V’s Integration Services. One of these services is time synchronization. As you know, time synchronization is an essential part of any modern network and is crucial when working with Active Directory forests and domains. By default, machines that are members of Active Directory domains will connect to the PDC Emulator master of operations—a special domain controller role designed to manage time in AD DS networks—to synchronize their clocks. This ensures that all machines in the domain use the same time source. Proper time synchronization is essential if you want Kerberos authentication to work properly. Any machine that is out of time synch with a domain controller cannot log on, nor can users on that machine log on.
However, when you work with directories in a virtualized environment, your machines can obtain time synchronization from two sources: the host server in Hyper-V and the PDC Emulator in the network. If someone compromises the time on a host server, all of the VMs on the server will be unable to log on. Therefore, you should carefully consider where you want your VMs to obtain their time. The best policy is as follows:
Turn off host time synchronization on each virtual machine in a production domain. This is done in the VM’s settings under Integration Services. Simply clear the Time Synchronization check box (see Figure 8-26).
Figure 8-26 Setting time synchronization settings for a VM
Use appropriate policies to have all member machines synchronize with the PDC Emulator for the domain. This is automatic when a machine joins a domain. If the domain is at the bottom of a forest hierarchy, its PDC Emulator will automatically connect with the PDC Emulator of its parent domain, the PDC Emulator for the parent domain will connect to its parent domain, and so on until you get to the root domain.
Root domain PDC Emulators should use the network time protocol to connect to a proper external time source. If you prefer to avoid this, change the properties for the VM that runs the PDC Emulator role in the root domain and have it synchronize time with its host server.
Now you will have a single VM that synchronizes with the host server and all VMs will synchronize with this VM. Make sure you protect the host server that runs this very important virtual machine.
Note that time synchronization is less important on other virtual machine networks such as training, testing, and development environments. Use your discretion to configure it for these networks.
Updating Offline VMs
As mentioned earlier, it is very easy for administrators of hundreds of virtual machines—especially virtual machines that are at rest—to let them fall out of synch with software updates. Few organizations take the time to manually start each VM once a month, update it, reboot it as required, and then store it again. This is why Microsoft has developed the Offline Virtual Machine Servicing Tool (OVMST). This tool is designed to automatically update all VMs whether they are on or off. The OVMST is a solution accelerator and, like all solution accelerators, it includes both guidance and some utilities. To be able to use this tool, you must have the proper infrastructure in place:
The downloaded OVMST, which can be found at http://technet.microsoft.com/en-us/library/cc501231.aspx.
System Center Virtual Machine Manager. Either version 2007 or 2008 will work.
Windows Server Update Services version 3.0 or 3.0 SP1 or System Center Configuration Manager 2007 SP1 or 2007 R2.
The last requirement is for an internal update delivery mechanism, which can either be WSUS or SCCM. At least one of the two is required. The process for applying updates is relatively straightforward. All operations are based on resources being stored within SCVMM Libraries.
Because the update process can require extensive resources, you should use a maintenance host dedicated to the OVMST updating process for stored resources and for staging VMs before you deploy them in the production environment. Note that this host—or at least the machine running the OVMST—must use a full installation of Windows Server 2008 because the OVMST relies on the .NET Framework and Windows PowerShell to operate.
Basically, the OVMST performs the following operations (see Figure 8-27):
A servicing job is created within the Windows Task Scheduler. This job can be set to start once per month—for example, after the second Tuesday of each month.
The servicing job relies on logic from the Windows Workflow Foundation—part of the .NET Framework—to launch Windows PowerShell operations on each stored virtual machine.
For each machine, the servicing job performs the following tasks:
Deploys the “at rest” VM from the SCVMM Library to a servicing host.
Wakes the virtual machine by turning it on or restoring it from a saved state. This VM is woken on an isolated network to ensure that it does not conflict with existing VMs that have the same name. Note that the isolated network must be prepared beforehand on your servicing host.
Launches the update cycle using the technology you have in place (either WSUS or SCCM).
Reboots the VM as required to complete the update process.
Returns the VM to its original state—off or saved.
Returns the VM to the Library.
Proceeds to the next at -rest VM.
Figure 8-27 The OVMST update process
If you have a large VM environment and have several VMs that are continuously at rest, you should look into the OVMST and deploy it in your network. Organizations with such a need should find it relatively easy to have one or more hosts dedicated to the servicing role because updating VMs is such an important task.
Practice: Delegating Administrative Roles in SCVMM
In this practice, you will work with SCVMM to create delegated administration roles and then view the results. This practice consists of three exercises. In the first exercise, you will create a new account that will be a delegated administrator. This is performed in Active Directory Users And Computers. In the second exercise, you will create the delegation role. In the third exercise, you will log on as the delegated user to view the results of a role delegation in SCVMM. Perform these exercises first on Server01 and then in SCVMM01. Log on with domain administrator credentials to begin the exercise.
Exercise 1 Create a Delegated User
In this exercise you will use Server01 to create a new user in the Contoso directory. Perform this exercise with domain administrator credentials.
Log on to Server01 with domain administrator credentials. Launch the Active Directory Users And Computers (ADUC) console through the Start menu and Administrative Tools. Alternatively, you can use the ADUC portion of the Server Manager console.
Create the new user account. You should normally place the user in a proper OU, but for the purpose of this exercise, you will place it in the Users container. Right-click Users, select New, and then select User. Name the user Terry Adams with a logon name of Terry.Adams and click Next. Assign a complex password to the account, clear the User Must Change Password At Next Logon check box, and select Password Never Expires. The last selection ensures that you do not need to worry about password changes while studying for the exam. Click Next and then click Finish. The account is created.
Create a new top-level OU called RBAC Assignments. Right-click the Contoso.com domain name, select New, select Organizational Unit, type RBAC Assignments, and click OK. This creates the OU and moves you into it.
Create the required security group. You create a group to simplify long-term delegation management. If you ever need to assign these rights to another user, all you need to do is add them to the group. Right-click the RBAC Assignments OU to select New, and then Group. Name the group Library Administrators, make sure it is a Global Security group, and click OK. You would normally create as many groups as you intend to have roles. Remember, however, to keep the structure as simple as your organizational policies allow.
Add the Terry Adams account to the Library Administrators group. Right-click the new group, select Properties, click the Members tab, click Add, type Terry Adams, and click Check Names. Click OK twice when done. Close ADUC.
Your directory is ready to support role delegation in SCVMM.
Exercise 2 Create a Role Delegation in SCVMM
In this exercise you will create a role delegation in SCVMM. Perform this exercise on SCVMM01 and log on with domain administrator credentials.
Log on to SCVMM. Launch the SCVMM Administrator Console. You can double-click the shortcut on the desktop or use Start, then All Programs, then Microsoft System Center, and then Virtual Machine Manager 2008 to click the Virtual Machine Manager Administrator Console shortcut.
Move to the Administration View and click User Roles. Two roles should appear: Administrator under the Administrator profile type and Testers under the Self-Service User profile type.
Click New User Role in the Actions pane. This launches the Create User Role Wizard. Type Library Administrators, type a short description, and select Delegated Administrator from the drop-down list under User Role Profile. Click Next.
Click Add, type Library, and click Check Names and then OK. Click Next.
On the Select Scope page, select All Libraries and click Next (see Figure 8-28). As you can see, this page lets you determine the scope of delegation. By selecting All Libraries, you grant access to Library Stores only. Click Create to generate the new role.
Figure 8-28 Selecting the scope of delegation
Your new role has been created and is now available in SCVMM. Now make sure the Library Administrators can log on to the remote server.
Return to Server Manager, which should be open in the Task Bar.
Click Server Manager (SCVMM01) to view the Server Manager Home Page.
Click Configure Remote Desktop and then click Select Users.
Click Add, type Library, click Check Names, and then click OK three times.
Your computer is ready for delegation.
Exercise 3 View the Results of a Role Delegation
In this exercise you will log on as a delegated administrator and view the access this grants you. Perform this exercise on SCVMM01 and log on with the Terry Adams account.
Log on to SCVMM01 with the Terry Adams account. Launch the SCVMM Administrator Console. You can double-click the shortcut on the desktop or click Start, click All Programs, click Microsoft System Center, click Virtual Machine Manager 2008, and then click the Virtual Machine Manager Administrator Console shortcut. This opens the Connect To Server window.
Localhost:8100 is already listed and Make This Server My Default is selected. Click Connect.
The console opens in the Overview and is focused on the Hosts view. Note that you do not see any hosts, but you have full access to the Libraries (see Figure 8-29).
Figure 8-29 Viewing a delegated console
Change to Virtual Machines view. Notice that you do not have access to this view, either. However, when you change to Library View, you’ll notice that you have full access to all Library resources. You can manage resources, deploy VMs, and perform any task that is tied to an SCVMM Library.
Change to Administration view. Notice that you have access to some items in Administration view—even the ability to create new user roles. However, if you create a new delegated administration user role, you will find that the only thing you can delegate is Libraries (see Figure 8-30). Explore the console thoroughly to view what can be done as a Library—only administrator.
Figure 8-30 Delegated administrators only have control over their own delegation scope.
Log off when your tour is complete.