Don’t Get Fancy with VMware’s Customization Wizard…or Else!

VMware Versions in production at the time of this writing:
View 5.3 with Workspace 1.8
ESXi 5.5
vCenter 5.5 U1


The following applies to anyone running a VDI environment with full Windows 7 clones. If that doesn’t apply to you, you’re free to go. Although if you do, you’ll miss out on more incredible authoring by yours truly.

In this post, I explained a problem we were having in which random machines in a full clone VDI pool were mysteriously going offline with an ‘Agent Unreachable’ message in View Administrator. There was more to it, but I didn’t think it was necessary to give the history, until now.

When the clones were built, an existing customized Sysprep (unattend.txt) file was used. This is the same file that is used to Sysprep hardware laptops, prior to sending them to users. VMware’s documentation mentions that this is a supported option when building clones. However, if something goes wrong, VMware will draw the line on what they will support. The content of the Sysprep file is out of VMware’s control, and therefore will inevitably push troubleshooting within the VMware bubble.

If using an existing specification, you're on your own.

If using an existing specification, you’re on your own.

The main problem with the clones, built with a customized specification, was they never progressed beyond the ‘Customizing’ state in View Administrator. At that point, the support case was opened with VMware. During the troubleshooting, we noticed one of the keys in the GuestCustomization folder (CustomizationInProgress) was set to 1. When it was manually changed to zero, the desktops became available and functioned properly. The desktops would not function in View when the registry key was deleted.

There was no real explanation for why the Guest Customization registry sub-key was getting deleted, although we know the only VMware product on the desktop that has permissions to do that is VMware Tools. We also didn’t know why the key was getting stuck in the ‘1’ state during pool creation. This case with VMware Support ended after we successfully built a couple of pools using the ‘Customize using the Customization Wizard’ option. The VMware-built file was imported into View and chosen during the creation of the pools.

We never got a definitive explanation on what was causing the stale state and deletion of the Guest Customization registry sub-folder and its keys. The working theory is to always use the VMware Guest Customization Wizard, even if you have a verified, error-free sysprep file available.





Categories: VMware

Tags: , , ,

1 reply


  1. ‘Agent Unreachable’ in VMware View 5.3 and the Missing Registry Key «

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Brad Hedlund

stuff and nonsense


Every cloud has a silver lining.

Live Virtually

A Storage and Virtualization Blog

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video

Just another site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments


Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

%d bloggers like this: