NewDocsIntoHeadHi everyone, Alaks Sevugan here, and today I’m going to talk about updating your Services.  We have already seen how image based composition makes deployment a breeze, however most of you probably deploy an application once - so the real power in composition is derived from how services are maintained and updated.

Update Process

Let’s walk through how updating a service works. Once the application has been deployed, either the application has to be updated or the OS has to be updated or the machine characteristics have to be updated. Remember, a deployed service is always linked to the service template it was created from. Service templates contain all the VM template definitions.

Here is a typical workflow for updating a Service:

image

  1. Updated app or the OS image has been updated outside of VMM, is added to the library
  2. You need to make a clone of the service template and the VM template to point to the new application or VHD
  3. Then you associate this new template with the deployed service that you want to update
  4. Test this configuration in the a test environment
  5. During the service (or maintenance) window you can update the service to match the new version of the template.

Update Types

VMM will support two types for updating a service – regular updates and image based updates.

In regular updates, changes in the service template are applied to the service instance without replacing the OS image e.g. if you update memory of the VM there is no need to change the OS. Similarly if the new version of the template contains next version of an app, we can go ahead and replace the existing version of the app without losing the app state and this can be done without replacing the OS image.

In image based updates, we will go ahead and replace the old OS image with new image composed of OS and app – again without losing app state. A typical example of this can be moving from existing OS image to an OS image with new patches.

Regular Update

Let’s walk through how Regular updating works. Here is the typical workflow:

image

  1. Begin the update on tier by tier basis based on the servicing order of the tier.
  2. Within each tier groups of machines are updated in parallel
  3. VMs are removed from Load Balancer
  4. Application level changes are applied
  5. VMs are added to the Load Balancer
  6. This process is repeated for each of the tiers.

Imaged Based Update

Let’s walk through how Image based updating works. Here is the typical workflow:

image

  1. Begin the update on tier by tier basis based on the servicing order of the tier.
  2. Within each tier groups of machines are updated in parallel
  3. VMs are removed from Load Balancer
  4. Application state is saved to a data disk
  5. Slide in the new patched OS image
  6. Recustomize the OS
  7. Install the application(s) and put their state back
  8. Add the machine back to the Load balancer
  9. This process is repeated for each of the tiers.

This shows you how we are able to compose OS, roles/features, applications and the state and manage the lifetime of a service.

So in summary, by making the deployment and updating of a service this easy, you spend less time worrying about root cause analysis and investigation, since you can simply re-deploy from a updated known good configuration and keep service up and running. It also significantly reduces configuration drift, since hundreds or even thousands of services and virtual machines can be composed from only a handful of identical operating system images.

Alaks Sevugan | Senior Program Manager

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv

clip_image001 clip_image002