Sysprep fails with error "Windows could not finish configuring the system. To attempt to resume configuration, restart the computer."

This other day, I was working with a customer who was trying to deploy a full-VM pool, using Sysprep. The guest OS was Windows 7.
The VMs were provisioned fine, but the sysprep itself was not proceeding. Checking the console of the VM, we saw the below error.


Restarting the computer led to the same error and it was stuck in a loop.

VMware has this KB 1034618, but it recommends an hotfix which was already included in Windows SP1.
I then discovered that the user had installed Kaspersky AntiVirus software. This was the culprit. Apparently there is a setting in Kaspersky that causes the Sysprep to fail.
If a Kaspersky Lab 2012/2010/2011 product is installed on your computer, then in some cases after launching System Preparation Tool (Sysprep), with the values sysprep /oobe /generalise /reboot, and your computer reboots, the above error may appear on the screen.

In order to eliminate the problem, disable your Kaspersky Lab 2012/2010/2011 product's Self-Defence before launching System Preparation Tool (Sysprep).

More information available in the below Kaspersky document.
How to eliminate Sysprep launch error on a computer with a Kaspersky Lab 2010/2011/2012 product installed?

If this article is of some help, please leave a comment.

Removing the list of Connection Servers from the View Client drop down list.

If anyone has been wondering as to how to remove the list of connection servers from the drop down list of the View Client, given below is the registry key which holds this value.

On the machine running the View Client, navigate to the below registry key. This key holds the list of Connection Servers that were connected to from the View Client. You can delete the values for this key if you want to empty the drop down list.

HKEY_CURRENT_USER\Software\VMware, Inc.\VMware VDM\Client\BrokerHistory

If this article is of some help, please leave a comment.

Users have to login multiple times to get a View Session and muliple "Pending Session Expired....." events logged in the VIEW ADMINISTRATOR

You might notice an issue where end users would be required to login multiple times on the View Client before they get to a desktop.
As a View administrator, you would notice multiple events in the EVENTS of the VIEW ADMINISTRATOR.

"The pending session for user <domain/user> on VM <vm name> has expired".

If you are seeing this issue on a floating pool where the VMs are set to refresh or delete on logoff, this issue can be caused if your DNS server is not getting updated with the new IP address of the newly created/refreshed VMs.

When a View VM is deleted or refreshed, it gets a new MAC address and thereby a new IP address. Now ideally the DHCP server should update the DNS server. But in some environments, this does not appear to be the case. You can verify this by checking the IP on the VM itself and in the DNS server.

If you are experiencing this issue, you need to make a change on your DHCP server. For the scope under which the VMs fall, make sure the below option is enabled.

"Always dynamically update DNS A and PTR records"

If this helps in fixing your issue, please do leave a comment.

And yes, also make sure that the userinit key on the View VM has got the correct value. You can refer to VMware KB article or communities for this detail.

If this article is of some help, please leave a comment.

Error during provisioning - VMware.Sim.Fault.InvalidParentVmFault, InvalidSnapshotDiskConfiguration

I worked on this peculiar issue the other day. I was trying to provision additional VMs on a linked clone pool and the provisioning was failing with the below error.

Error during provisioning - VMware.Sim.Fault.InvalidParentVmFault, InvalidSnapshotDiskConfiguration

I went into the pool settings and made sure that it was pointing to the correct parent virtual machine and snapshot.
I then got to know that this parent VM was originally residing on a different host on this cluster. And when I moved the parent VM back to the original host, the issue was fixed.
I came across this user on VMware communities who had this same issue.

My understanding is that one can move the parent VM between hosts as long as it is within the same cluster. But maybe I am wrong. I was not able to find anything on this though.

If this article is of some help, please leave a comment.

Recompose of View VMs fail with error "NonCompatibleDeploymentGroup"

I worked on this issue where the user was unable to perform a recompose task on a linked clone pool, that was part of the older version of View Manager. The View Manager had been recently upgraded to version 4.5

The error message included the following -
"VMware.Sim.Fault.InvalidOperationFault, NonCompatibleDeploymentGroup "

After some investigation, I found out that this issue was caused because the linked clone pool was still associated with the old VC_CONFIG_ID in the Composer database. The VC_CONFIG_ID is changed during the upgrade process.

Running the below command on the Composer database resolved the issue.
UPDATE dbo.SVI_DEPLOYMENT_GROUP
SET VC_CONFIG_ID = 'right_id'
WHERE VC_CONFIG_ID = 'wrong_id'

The right VC_CONFIG_ID can be identified from the table  dbo.SVI_VC_CONFIG_ENTRY in the View Composer database. It would be the ID associated with any new pool created after the upgrade.
Another way would be to find the VC_CONFIG_ID from the ADAM database of the View Connection Server.

If this article is of some help, please leave a comment.

Removing Stale/Orphaned VMs from View Manager

This other day, I got to work on a simple but interesting issue. This user had a power outage in his datacenter and all his servers went down. This caused various tasks initiated by the View Connection Server to fail which in turn led to orphaned VMs.
We tried removing the stale entries as per the below KB article, but we were still not able to create new VMs with the same name.
Manually deleting linked clones or stale virtual desktop entries from VMware View Manager

I was finally able to fix it, after I cleared the stale/orphaned VM entry from all the below locations.

1. View Connection Server Adam database - Refer above VMware kb
2. View Composer database - Refer above VMware kb
3. Virtual Center inventory - Manually delete the VM
4. Virtual Center Datastore - delete the VM folder
5. Active Directory

If this article is of some help, please leave a comment.

Active Sessions data not updated in the View Admin UI

I worked on this issue on a View 4.0 setup, where the Admin UI was not correctly showing the number of Active Sessions. There were multiple users who were logged in to the VMs on this pool, but the number of Active Sessions were shown as zero and all the VMs were in Ready Status in the View Admin UI, which was incorrect.

The session status of the VM is communicated by the process WSSM.EXE that is running on each of the individual VMs. You can check if this process is running by checking the Task Manager. Ideally, this process would be started on a user logon and is controlled by the below registry key.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

The value of this key would be something like this.
"C:\WINDOWS\system32\userinit.exe","C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe"

On this computer, the value for this key was pointing to a third party program and there was another key created with the name "UserinitReplaced" and the path for the WSSM.EXE was also missing.
Apparently this third party application had been installed after the View agent was installed. Uninstalling the View agent and reinstalling it, put the missing path under the key "UserinitReplaced" and this resolved the issue.
If doing a recompose after updating the parent VM is not an option, you can push a group policy to update the appropriate registry key ("Userinit" or "UserinitReplaced" ) to include the path for the WSSM.EXE process.

Note: Making any mistakes here might lead to issues like MyDocuments window opening continuously.
http://www.kace.com/support/kb/index.php?action=artikel&cat=2&id=662&artlang=en

If this article is of some help, please leave a comment.