Vmware Vm Customization Specification Not Working

[Terina]

PowerCLIhas several cmdlets at your disposal for managing OS Customization Specifications. In the previous post we showed you how to create new customization specifications, retrieve and change them, in this post we will cover a common use case, being able to work with network interface card mappings.

To retrieve the NIC mappings of an OSCustomizationSpec you can use the Get-OSCustomizationNicMapping cmdlet. This will give you information about the currently configured NIC mappings of the customization specification.

Dimitar joined VMware and the PowerCLI team in 2007. He is member of the development part of the team and his main responsibilities are the functional design and implementation of features for the vSphere and vCloud PowerCLI components.

PowerCLI has several cmdlets at your disposal for managing OS Customization Specifications. In this post you will learn in more detail how to use them. In future posts we will discuss managing network interface card (NIC) mappings, cloning customization specifications and customizing VMs.

To retrieve the list of existing customization specifications you can use the Get-OSCustomizationSpec cmdlet. It retrieves both persistent and non-persistent specifications. You can additionally filter the specifications by Name and/or Type (e.g. persistent/non-persistent):

You can modify an existing customization specification (whether it is persistent or non-persistent) by using Set-OSCustomizationSpec cmdlet. This allows you to change the parameters of the specification that were configured during its creation:

Failed to create a compute vmware.example.org (VMware) instance stefantest1.example.org: ERF42-5701 [Foreman::Exception]: The user-data template must be a hash in YAML format for VM customization to work.

We have a VMWare environment, I have done the guide on making a Golden image as specified here -us/120560. When I start the new vm it goes through the process of starting the OScustomization change hostname ,SID, etc., then fails with this error Windows could not finish configuring the system. To attempt to resume the configuration, restart the computer. I have done the same customization without sophos installed and it went through. What else do I need to do to get it to work? the OS is server 2016 in vmware 6.5.

Are you running the script with the logging? If yes, the logs will help us to narrow down the issue else I'd request you to request a remote session on the case which you have opened with the Support as it needs detail troubleshooting to get the problematic component.

As per the support case, the VMware customization was failing because of the services which were hampering the customization. The assigned engineer provided that we need to put the batch file, in the end, to set the service to the automatic and then need to make sure that it is currently stopped.

I've been faced with the same problem. The cause is tamper protection.

For the generalization with Sysprep to work, we had to deactivate the tamper protection!

It seems that Tamper Protection blocks access to certain registry keys.

I worked with support and so far when we stop the MCS service it runs fine, now we need to create a startup script that runs once to reenable the MCS service and then deletes itself if the server name is not the same as the golden image.

Hi James, thanks for your update, it helped a lot [:)] We're experiencing the same problem with our Server 2019 Datacentre edition template in vSphere 6.7, running the unmodified gold image prep script (which works fine with VDI clients) we get the "Windows could not finish configuring the system" message and the Shift+F10 method of completing the process fails too. So using your suggestion we've modified the prep script to also re-configure both MCS Agent and Client services as Manual Start and leave Tamper Protection disabled, at which point the process runs fine. It's not a great fix as, like you say, the services then need re-enabling after deployment which is a pain. So see below our script to re-enable them, it's just a quick butchering of the gold image prep script just in reverse, it just needs to be scheduled to run on local administrator login and seems to do the trick. There's no real need to delete it afterwards either as it'll run so infrequently if ever (if you don't regularly login as local admin that is). We'll get a ticket logged with support too to ensure they're aware there's a continuing problem. Cheers, Ken.

If already tried to wait for the completion of the syspep with the power-cli command wait-tools. The problem here is, that the vmware tools are already working before the sysprep is finished and scripts runt into errors because the vm still needs its final reboot after the sysprep

I even tried to work with the recent VI events of the targe machines. Especially reacting on the events "CustomizationStartedEvent", "CustomizationSucceeded" and "CustomizationFailed"Same situaton loke with the wait-tools: the "CustomizationSucceeded" events will be emitted when the sysprep is finished and the vm waits for the final reboot

Maybe the simplest approach would be to use Get-VIEvent to look for the "Customization Succeeded" event. Or if your OS customization process includes a new guest hostname, wait for the $_.Guest.Hostname property from Get-VM to pick up the new name.

In one scenario, I'm handling a similar problem by including a shutdown command as part of the -GuiRunOnce argument to New-OsCustomizationSpec. Then after starting the vm following the clone process, I wait for the vm to finish powering up (Wait-Tools might be just as good here - I honestly don't recall why I'm not using it.)

Then I wait until the -GuiRunOnce shutdown command has completed and the vm is off, at which point it's safe to assume that sysprep and customization are finished (unless the OS has crashed, I suppose).

Of course you'll probably want to re-start the vm afterwards. And this might be a bit Rube Goldberg-ish for your needs; I need the vm off temporarily for other reasons, but the basic suggestion is to use -GuiRunOnce as a way to confirm that the OS is up following sysprep customization. Instead of shutting down, you could write a file somewhere and then check for its presence, or etc. Invoke-VMScript might also be helpful, if for example your clone won't be able to reach your network right away, and the completion of your -GuiRunOnce action would only be verifiable from inside the clone.

You might consider joining the domain within the OS customization process, rather than afterwards. With the AD computer account specifically, I suppose you could check whether or not it exists where you expect before attempting to move it.

So I just spent two hours of my life trying to get my CentOS 7 VM template to deploy correctly with a vSphere customization specification. No matter what I did it would customize the VM, then uncustomize it, essentially leaving me with the template again. I finally asked our oracle and savior, Google, and two amazing things occurred.

Hi Bob, thanks for the post. Do you feel that it is better to use VMware Tools instead of open-vm-tools (as packaged by the Linux distribution)? I only recently discovered open-vm-tools. It looks fine for me. Any views on it?

Using the same answer file I always have and it has always worked. I've seen the KB where username and domain name format need to be changed to user...@domain.xxx and domain.xxx. Does not make a difference. After deploying from template it never joins the domain. However, it does change the name. If I manually join the domain after template deployment it works without issue.

So as a last ditch effort I blew away my templates that have worked forever and rebuilt them from scratch. All that was done on the new w7 and w2k8R2 templates was turn on RDP, installs vmware tools and apply the ton of windoz patches.

Same result. The only way I get a template deployment to join the domain is to specify an IP address in the customization wizard. Straight up DHCP never joins a domain. Again,,as a reminder when doing a DHCP deployment it does NOT join the domain. If I log into the deployed VM I can join the domain with no issues.

The initial build completed without incident, creating a vSphere template. The first deployment failed. Reviewing the var/log/vmware-imc/toolsDeployPkg.log file, the message ERROR: Path to hwclock not found. hwclock was observed. There was a KB article for this ( ) related to Ubuntu 23.10, which mentioned that the util-linux-extra package was needed. I added this to the definition of packages in the user-data file and rebuilt the template using packer build. This resolved the issue and future deployments were successful.

One thing I noticed was that the resulting virtual machine had two CD ROM devices. I looked around and found a PR (link) stating that an option existed to control this behavior as of the vSphere 1.2.4 plugin. I updated the required_plugins mapping in the ubuntu.auto.pkr.hcl file to state this 1.2.4 version is the minimum required. I then added reattach_cdroms = 1 later in the file with the other CD ROM related settings.

One other thing that I noticed in this process was that it would have been helpful to have a date/time stamp either in the VM name or the notes field, just to know when that instance of a template was created. I looked around and found out how to get a timestamp and used that syntax to add a notes = "Template created $formatdate("YYYY-MM-DD", timestamp())" property to my ubuntu.auto.pkr.hcl file.

After making the above fixes, I deployed a VM from the latest template and applied a customization spec which contained a customization script do a few final customization tasks (update /etc/sudoers, generate a new openssh-server key, complete the domain join, make a change to the sssd configuration and finally restart ssd services. This script failed to execute, reviewing the /var/log/vmware-imc/toolsDeployPkg.log I noticed the message user defined scripts execution is not enabled. To enable it, please have vmware tools v10.1.0 or later installed and execute the following cmd with root privilege: 'vmware-toolbox-cmd config set deployPkg enable-custom-scripts true'. Back in my user-data configuration file, in the late-commands section, I added this command to enable custom scripts in the template.

3a8082e126