Support for virtual machines in a safe and up-to-date state using the Microsoft Offline Virtual Machine Servicing Tool, WSUS and NAP

Virtualization is becoming an increasingly common server park consolidation technology. Many organizations pushed the crisis to its widespread use. According to IDC, in the last quarter of 2009, 350000 servers were released, of which 18.2% were virtualized.

At first glance, virtualization is wonderful from all sides. optimizes equipment utilization and increases infrastructure flexibility. But if you look closely, it turns out that she also has unobvious negative effects. Let's look at one of them.

As soon as virtualization technologies become available to a sufficiently large number of people in an organization, euphoria occurs. Now, deploying a set of virtual machines with the necessary services is an order of magnitude easier than a physical server. Resources seem almost unlimited, so each department begins to deploy its virtual machines. At this point, the uncontrolled reproduction of virtual machines begins. After a while, everyone gets confused about who now belongs, who is responsible for the particular virtual machine and where it is located. As a result, over time, many unattended virtual machines appear inside your infrastructure. Some of them continue to work uncontrollably, some of which are turned off, and some months are in a sleeping state. Due to the fact that the update of these test virtual machines is not configured, it turns out that inside the infrastructure there are points not affected by the corporate security policy. If the organization does not have a streamlined configuration and change management process, it will soon begin security incidents.
')
All the methods that I will write about below mainly apply to Windows virtual machines, but are partially applicable to Linux / Unix.

The problem of the lack of updates within virtual machines can be tackled by a combination of several methods. Implementing a unified storage system for deployment images of virtual machines, such as the SCVMM library. In the virtual machine templates, the ways of automatic updating should already be prescribed in advance. To prevent the owner of the virtual machine from disabling the update agent in it, you can apply Network Access Protection technology which allows you to quarantine physical and virtual machines if they do not comply with our network policies. One of the policies can be the work in the agent update system and the last update time is no more than X days or hours. In the same way, you can control the availability of antivirus in the system, its updates and status, and other system processes we need.

These measures solve the problem of keeping the included virtual machines up to date. Unfortunately, at the moment neither WSUS nor SCCM can update only systems that are in the enabled state. And what about reference virtual machines stored in the SCVMM library or machines that are on Hyper-V hosts in pause state? Usually in slang such machines are called “sleeping”. They can stay in this state for months. All this time, updates are not installed on them. At the moment of switching on such machines can potentially serve as a springboard for an attack or spreading an epidemic.

To keep these systems up to date, we just need the Microsoft Offline Virtual Machine Servicing Tool aka OVMST. This tool allows you to perform the following tasks:

• Update disabled virtual machines in the SCVMM library.
• Search for and update stopped and sleeping virtual machines on Hyper-V hosts.
• Update virtual machine templates.
• Starting with version 3.0, the Offline Virtual Machine Servicing Tool utility allows you to add update files to VHD files of virtual hard disks stored in the SCVMM library

To understand how OVSMT works, let's take a look at the typical infrastructure of the infrastructure necessary for servicing sleeping virtual machines.



As you can see in our infrastructure there are a library and a SCVMM server, a server for servicing virtual machines, a WSUS or SCCM update server. It is worth noting that all these hosts are usually isolated from the main network using VLAN. Only the host with SCVMM has access to the main network. In this case, it is a gateway between VLANs. This is done so that the virtual machines that we will be updating could not put at risk the main network by exchanging data in it during the installation of updates.



Let's take a look at how virtual machines are updated?

1. Reading data from the SCVMM library and selecting virtual machines, templates, disks.
2. Search for “sleeping” virtual machines on Hyper-V hosts connected to SCVMM.
3. Creation of service groups and placement of virtual machines in them, templates of disks assembled in the first and second steps.
4. Migrate “sleeping” virtual machines from Hyper-V hosts or deploy them from templates stored in the SCVMM library on Hyper-V hosts for updating the guest OS.
5. Waking up or turning on updatable machines on a Hyper-V serving host.
6. Forced check for updates required by the virtual machine.
7. Apply updates to the virtual machine.
8. Check the status of updates.
9. Turning off the virtual machine, if necessary, preparing to put it back into the SCVMM library using sysprep.
10. Return Wirth. machines to the host where it was originally located or placing it in the library from where we got it

So, we’ve covered the OVMST mechanisms of operation. I’ll describe the step-by-step algorithm for configuring this complex in the next part of the article, but for now you can read the OVMST webcast .