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.

View VMs not able to connect to the domain

Here is a peculiar issue that I ran into.
Randomly users would not be able to log on to their View virtual machines, with the machines throwing the below error.

"Windows cannot connect to the domain, either because the domain controller is down or otherwise unavailable, or because your computer account was not found.  Please try again later. If this message continues to appear, contact your system administrator for assistance."

This issue was seen on a non-persistent pool on a View 4.0 pool and Windows XP machines.

To resolve this issue, I had to do two things.

1. The original parent VM was not joined to the domain and only the linked clone VMs were joined to the domain. According to the View Administrator Guide it is a requirement for the parent VM to be part of a domain before pools are deployed from it.

2. I referred the below KB - http://kb.vmware.com/kb/1006341

 - Start Registry Editor. To do so, click Start, click Run, type regedit in the Open box, and then click OK.
 - Locate and then click the following registry subkey:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
 - In the right pane, click the DisablePasswordChange entry.
 - On the Edit menu, click Modify.
 - In the Value data box, type a value of 1, and then click OK.
 - Quit Registry Editor.

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

VMware tools and View agent installation order

According to the VMware documentation, the View agent has to be installed after VMware tools. If you were to do a VMware tools upgrade on the base VM or the View VM as part of maintenance, it might lead to undesirable results especially with View 4.0 version. The View VMs might start responding very slow or sometimes would not be available.

Uninstalling the tools and agent and reinstalling them in the correct order appears to resolve the issue. So if you run into any issues with the View VMs, especially after VMware tools upgrade, try this step to try resolving the issue.

Also make sure you are running the latest version of the View agent.


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

Upgrade to VMware View Manager 4.5 - a use case scenario

Upgrading your existing version of View (4.0) to the newer version 4.5 could be a little tricky, if certain steps are not performed in the correct order. The documentation provided by VMware is very exhaustive but not that user friendly.
I have penciled out a procedure that might be helpful in determining the upgrade plan specific to your environment.

It is IMPORTANT that you go through the upgrade guide and the installation guide in addition to the below procedure. This is a specific use case scenario applicable for the setup mentioned below.
1. vCenter is 4.0 and running on 32 bit machine. Also installed on same machine is View Composer 2.0. View Connection Server is also running on a 32 bit machine.
2. vCenter has to be migrated to a 64 bit machine and upgraded to 4.1.
3. View Composer has to be upgraded to 2.5.
4. View Connection Server also has to be migrated to a different 64 bit VM.
5. Standalone SQL 2005 is used as a database for both vCenter and View Composer.

Recommended:
- Preferably, perform all the below steps with a domain administrator account, that is also part of the local administrators group.
- Also when running any program during the installation, always select the "Run as Administrator" option.

To do before the upgrade:
1. Check the compatibility of all involved products.
2. Take a backup of your Virtual Center Database and View Composer Database.
3. Note down the computer name and the ip address of the existing 4.0 Virtual Center Server.
4. Make a copy of the folder that contains SSL certificates (on the existing 4.0 Virtual Center Server).
This folder is located at %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter.
5. Schedule downtime for your View infrastructure, disable all provisioning.


Upgrade Virtual Center to 4.1 and View Composer to 2.5
[The below steps can also be leveraged to migrate your VMware update manger and orchestrator also.]

On the existing vCenter Server machine:
- Run the View Composer 2.5 installation on this machine and upgrade the View Composer to 2.5 on this machine. Perform steps given in Pg. 31 of the View 4.5 upgrade guide.
- Stop the Virtual Center Server and View composer service.
- Take a backup of the Virtual Center database and View Composer database. These would be bak files. These files would be used to restore the database on the new Virtual Center machine. (Instead of backup you can also use the Detach/Attach option to move the database.)
- Migrate the RSA key container used by View Composer. Refer pg. 31 of the View 4.5 upgrade guide.
- Mount the vCenter 4.1 installation to this VM. Navigate the contents and you should find a Datamigration folder containing a datamigration.zip file.
- Extract this file on to the local system.
- Open command prompt (run as administrator) and navigate to the folder where you extracted the contents of the datamigration.zip file and execute the "backup.bat" script.
- Once the script completes, copy the datamigration folder completely to the network location which is accessible from the newly created VM.
- Remove this machine from the domain.
- Shut down the existing virtual center.

On the new 64 bit machine created to host vCenter 4.1 and Composer 2.5:
- Change the name of this VM to be the same as the original Virtual center machine and add to domain.
- Assign the same IP address as the original Virtual center machine.
- Migrate the RSA key container as per steps given in pg. 32 of the View 4.5 upgrade guide.
- Install the database application and restore the Virtual Center database and View Composer database.
- Create a 64-bit DSN for the Virtual Center database and the View Composer database.
- Copy the datamigration folder from the network location to this machine.
- Open command prompt and navigate to this folder and execute the "install.bat" script.
- You will have to have the vCenter 4.1 installation files on this machine (mount the vCenter 4.1 iso on this VM).
- The "install.bat" script will start the installation of the Virtual Center 4.1. Point to the 64-bit DSN when prompted and complete the installation.

- Start the installation of View Composer 2.5
- When prompted for the DSN, manually enter the name of the 64 bit DSN that you created pointing to the restored View Composer database.


Upgrade View Connection Server to 4.5

On the existing View Connection Server:
- Run the installation for View Connection Server 4.5 and upgrade the existing installation.

On the new View Connection Server:
- Start the installation for View Connection Server 4.5 and select the option "Replica Server" and point to the existing View Connection Server.
- Finish the installation.
You can then uninstall the Connection Server from the old machine.
If you still find the old connection server listed under Connection Server in the admin portal, you need to run the vdmadmin command to remove it. (Pg. 24 of View 4.5 upgrade guide.)

Note: The name of the Connection Server has to be updated.

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

Short Intro.

Well, here goes.
I have been working with VMware products for more than a year now. As part of my work I handle issues related to configuring and maintaining the View Manager product. I thought of this blog to share some best practices, simplified procedures and titbits that could come in handy when working on View. Hence the name "ViewTrivia".

Disclaimer:
The views expressed here and information provided are entirely my own and the contents are not read or approved by any company (including VMware).