VMware Labmanager Support Extended

I love Lab manager, ever since I first gave the self-service portal to my training department I have been a huge fan.

It answered my use case for me and it has been a firm favourite in the team for a number of projects. Now I must admit that I had planned a “bye bye LM” post for last month as it went end of life but I have been rather busy at work and totally missed it.

However I saw the other day a rather nice mail from VMware saying that support has been extended for another year. Great news as we were gearing up to our work loads to a mixture of View and vCloud.

View was a simple one as we were using LM to host some business process desktops, which is all honesty would be far better in View. However moving our self-service users to vCloud just felt like we were moving to a product that is more than we need.

Perhaps that is why VMware have extended support as other people feel as I do and have not just taken the jump to vCD as they would have expected.

I do wonder if this extra year will see more people migrate from LM, I am dubious as to if we will or not. Since I have been looking at it I can see a number of other use cases in our Internet data centre, such as segregating our prod and staging environments as well as allowing us to orchestrate more of our deployments and test platforms, but they would be sizable projects that when presented to the business they have not jumped up and down to get them started.

I do have some notes that I started to jot down on the migration from LM to vCD,  seeing as I didn’t find a great deal out on the web I will type them up as they may help someone else who is not so fussed on seeing out another year in lab managers warm embrace!!


Lab Manager 4 Guest Customisation

I think I lost count of the hours I spent trying to understand how LM 4 handled customising a guest O/S. In my case I wanted to deploy Windows XP and Windows 7 systems.

For those of you that have never done an large scale office deployment let me just just say that Windows 7 and dare I say Vista brought about some big changes in the way deployments went down. All for the better. In fact I really should get some posts up around the Vista and Windows 7 deployments that I have done over the last few years.

For lab manager that also meant that the customisation of each OS was totally different. I am hoping that with my scripts and notes below I may save someone else some pain.

Pre Requisites

  • Sysprep must be enabled in LM and have a Sysprep package built (only required if using Sysprep and a supported OS, XP, 2003 etc)
  • Template must have LM version of VM tools installed into it using the LM console
  • Template must have required customisation script created on the template

Building a Sysprep package

This is documented in the LM user guide but it wont detail some extra steps that were taken here at Thomson. In order to get Netdom and any other files required I placed them in the $oem$ and the root of the Sysprep folder on SVLAB01. I doubt it needs to be in both places but this seemed to work.

The folders are located here

c:\Program Files\VMware\VMware vCenter LabManager\Tools\CustomizeGuest\Windows\Sysprep\WinXProgram files\vmware\labmanager\tools\guestcustomization\windows\sysprep\winxp\i386\$OEM$

C:\Program Files\VMware\VMware vCenter Lab Manager\Tools\CustomizeGuest\Windows\Sysprep\WinXP

The reason for copying the files here are that they are copied over by the guest customization process by default and meant an easier time writing the script as files existed.

Creating the template

This can be created manually or using an SCCM deploy for example. The only pre-reqs for this customisation to work is that the template cannot be joined to the domain and must have the LM version of VM tools installed.

To ensure you have the LM version of tool deploy the template and then open it in LM. Viewing the console in LM you will see an install VM tools button above it. This is detailed in the LM user guide.

Guest Customisation Adding the Template Settings

Windows 7

Windows 7 already has Sysprep available in the System32 folder. So we don’t have to worry about having a Sysprep package built.

Unless you go to the trouble of installing the RSAT tools you won’t have NETDOM available to do something similar to XP. So we will have to use Powershell and the add-computer cmd-let.

Here is how it’s pieced together…

A share on the lab manager server has been created called LM$ which located on the root of the C drive C:\labmanager customisation scripts

On the windows 7 template the following has been added to the guest customisation

The windows temp folder has been used as a location to copy to. When the machine is deployed for the first time the following will happen


  1. Windows 7 will boot and get to the logon screen. At this point Sysprep is called and takes a few minutes to run, the machine will reboot
  2. VMware tools will call guest customisation whilst Windows is configuring itself
  3. Guest customisation will just show as a DOS box with little info (not helpful!) but it’s running what you tell it to in the picture above. It will never fail on an error and stop the process.
  4. Once its finished and windows has finished the net result should be a machine sitting on the CTRL ALT DEL screen and not a local user prompt.


Powershell Script


The powershell script is using the add-computer cmd-let. However in order to get this to work with out being prompted for a password you are required to do some more leg work. By default the command will prompt for a password. Below is an annotated version of the scripts contents.


$credential = New-Object System.Management.Automation.PsCredential(“tdl\ztit”, (ConvertTo-SecureString “thomson” -AsPlainText -Force))


This first line create the magic that does not require you to enter a password. It creates the $credential variable and uses a new object to store the password in.


Add-Computer -DomainName “tdl.net” -Credential $credential


The final line calls the cmd-let and the $variable that we have used.  We can also specify an OU for the machine to be added to by using this command instead


Add-Computer -DomainName “tdl.net” -Credential $credential -OUPath (“OU=Windows7,DC=tdl,DC=net”)


For more info check this page out http://iboyd.net/index.php/2009/10/23/windows-7-is-missing-netdom-exe/



As I mentioned earlier the customization stage will never fail or give you any output. However there is once saving grace in the Guest-Customization log that is stored on the machine you are trying to deploy in the %temp% (Windows\temp) In Win 7 you will have to take ownership when prompted to view the contents. This log file also exists in XP as well.


Windows XP


As stated earlier the NETDOM files are already copied for us by the guest customization process so we can just call it from the templates settings directly as shown below.

Working with labmanger configurations

I have been working with Lab manager for quite a few years now and I have to admit that I found the documentation a little light in some places. Over the years I have been making notes on some of the tasks that I have seen other get wrong or keep asking me how to do. So I thought why not compile all of these thoughts into one giant LM post.

Working with configurations and Libray’s

To create a new configuration you are required to do the following (these are high level steps)

  1. Create a new template or use an existing one
  2. Create a new configuration in your workspace
  3. Add machines to your configuration and select the template that the machine should be built from. This stage is also where you select the network and name the system
  4. Once you have your configuration you have two choices, if it will only be temporary then you can just deploy it. If you plan to re-use it then go to step 5
  5. At this stage to we need to re-use the template so we should capture it to a library
  6. Once captured you should go and delete the configuration that you created. This saves on disk space and ensures that our linked clone chain remains low and manageable for a given template.

At this point it’s worth discussing how Lab Manager uses Linked Clones. A linked clone is a rather neat way of saving disk space. However major draw back is that they can also become very complex and converse to saving disk space they can also eat it up silently in the background.

Let’s try and expand on this. Let’s say that you have a template and that template spawns a configuration made up of three machines. You would have something that looks like this;

Each new VM would be a linked clone, as you can see this is a 10th of the disk space that the template was. In this example each linked clone is currently 1GB. Disk space is used by the clones Copy On Write disk (COW) The COW captures the writes that are specific to that instance it also reads from the parent disk as well. So at the moment we have saved a lot of disk space, instead of having 40GB of disk space used we have only used 13GB. Seems pretty simple.

BUT… This is where it gets interesting as our configuration can be cloned, lets just say because someone else wants and exact copy of what we have in their work space or someone wants to create a clone to backup a current state of a configuration. This is where our chain becomes slightly more interesting.

We have now ended up with a new configuration which in Lab manger looks to be standalone but the underlying effect is that we now have another level in our chain. So VM 6 now has a COW of 1GB (it could be more of less depending on its use. I am just using simple numbers for illustration) this COW relies on the COW of VM3 and the Template. This also means that even if the configuration that contains VM3 and co is deleted it will still remain as it’s required as part of the chain. It won’t be until the configuration that VM6 is deleted that the chain would go.

Lab manager leases and clean up

So it’s at this point where another twist should be introduced, lease maximums. A lease protects the storage from situations that arise where an expired VM is deleted if it has not been used with in the period defined for a lease. We currently have a lease set globally to 30 days for workspace configurations only. A template or a library should be a confirmed point in the chain that is not removed.

In our case an expired VM is one that has not been used in 30 days. If on day 28 it gets deployed the timer is restarted. Expired VMs are managed by the resource clean up in Lab Manager, also known as “Garbage Removal”.

24 hours before garbage collection occurs a notification is sent out to the owner to warn of the deletion. Our settings are pictured below.  Flagged removes the configuration but leaves it on the data store. This is not what we wanted. So we delete automatically.

Let’s just look at one more example of how the chain can become even more complex.

As you can see this time not only have configurations been cloned but templates have been cloned as well. Without expired VMs being deleted we have ended up with a long chain taking up a lot of space. Ideally in this situation you would only want to be one or two levels in the chain to achieve the same result.

Each group of VMs is a configuration that is either running or just there to provide a link in the chain. To undo all of these chains you have to consolidate the templates and remove inactive configurations. The quickest method of doing that is this

  1. Clone the VM template (must be full clone) to a new data store. This will consolidate all of the chain back to one file. This may increase the size of the template.
  2. Un-deploy all machines
  3. Turn off host spanning in LM to remove the service VM from the data store.
  4. Delete the data store from VC. This will delete all files and folders
  5. Delete the data store from LM
  6. Add the data store back into the VC
  7. Add the data store back into LM
  8. Turn host spanning back on

So how can we manage this situation? The first step is to ensure that workspace leases are enforced globally. The next piece of the puzzle is to utilise libraries.

A library can contain a large number of different configurations. These can be selected by individuals and cloned to their work space. Each clone is then subject to the lease set.

Some good guidelines to get you started

To fill a library with configurations you first have to create your configuration.  To ensure that disk space used is minimal don’t deploy your configuration. Instead you should capture it to a library. Below are some screen shots of the context view

This is our lone template. As you can see it has no clones.

Now you can see that we have created a configuration for training that contains 30 virtual machines.

Let’s see what happens when we capture that configuration to a library. You will also note that this configuration has not been deployed at this stage.

The context view above is actually of a VM that is now in the library. What has happened is that the capture has made the library copy the first link in the chain and not the last. This is the key reason why a library is important as now any clones from library will expire and can be deleted. The library will never expire and will always be the safe point that can be deleted back to in the chain.

When the configuration is deleted we will just end up with the guys on the furthest right disappearing. After the library capture has occurred the first configuration should be deleted just to keep things nice and tidy.

So now we have a library how should we now create configurations and manage them.

The first step is to go to the library and clone it to a work space.

The on going management at this point should be pretty straight forward, as if the configuration is idle for 30 days the garbage clean up will remove it from the data store and the owner can just deploy a new one from the library.

Adding and deleting machines when using a library.

When you just work with configurations this is actually quite straight forward. A library changes this.

Deleting a machine from a configuration

Let’s assume that one VM has an issue and the owner decides its quicker to just delete it and re-deploy a new one. Here is how we do it.

  1. Power off the VM
  2. Select to un-deploy
  3. Delete the machine
  4. Go to the Library and select to clone to work space
  5. Select and existing work space
  6. Select the individual machine
  7. That’s it!

Below is a screen shot of the options to select. Also shown are how the contexts of the chain change.

As you can see when the machine is deleted is becomes a different icon and will be deleted automatically after 30 days or it can be manually deleted. For the sake of this document the machine was manually deleted using “Delete Expired VMs” option.  The context view would just show no icon after the top VM in the library.

Once its added it just shows as another link from that top VM again.

Adding a new VM to a library

Lets assume that you now need 35 machines in your configuration and you only have 30. There is no way of doing this without deleting the library and making a new configuration with the correct number.

Although it would not be the best way going forward you can go and add a machine to the configuration that has been cloned to the work space. This has been done and as you would expect the newly added VM appears at the same level as the library but is now separate to the library. Its our standard procedure to delete these after use and then create a new configuration and capture that to the library.


Lab manager can very quickly run away with out its administrators if it’s not managed. Linked clones provide substantial disk space savings and should be used wisely with library configurations. Training will be shown how to work with a library moving forward, as well as how configurations can expire.

MIS will remain the gate keepers managing the templates and libraries. This will ensure a stable point in the chain that can be safely reached in the future without fear of deleting a part of the chain that is critical.