Category Archives: VMware View

Manually Add Desktop to Automated Pool

Situations may arise that require an administrator to add existing desktops to an existing View desktop pool. For example, two environments merge and a group of persistent desktops need to be combined into a new environment. This would also be useful if a desktop gets inadvertently removed from View.

Backup ADAM Database using

  • Launch Command Prompt with elevated credentials
  • Navigate to: C:\Program Files\VMware\VMware View\Server\Tools\bin

Figure 1 – Backup of ADAM Database

If the desktop is already a member of a desktop pool, remove the desktop from View Administrator (Optional)

Figure 2 – Remote Desktop from Pool

From a connection server, launch ADSI Edit and connect to the View ADAM instance. The connection settings are listed below.

Figure 3 – Connect to ADAM Database

Navigate to Server Groups, and select the pool to be modified.

Figure 4 – Modify Desktop Pool

Convert the pool from Automated to Manual by modifying the pae-ServerPoolType attribute in the ADAM database.

Automated Pool with naming pattern – Attribute Value = 1

Manual Pool – Attribute Value = 5

Automated Pool with manual naming– Attribute Value = 12

Note: There are other possible attributes that the desktop pool may be. Be sure to note the original pool type, so it can be changed back in step 8.

In View Administrator, the pool will be listed as manual pool.

Add the desktop to the pool as shown below, and refresh the status.

Figure 5 – Add Desktop to Pool

Return the pool back to the previous type by modifying the pae-ServerPoolType

Reassign user to View desktop (if applicable)

Figure 6 – Assign User to Desktop

Once the desktop is added back to the pool, and the pool is back to an automated pool, the desktop virtual machine should be available. In some cases, the desktop may go into a customizing state, and eventually change to Agent Unavailable.


Troubleshooting Tip – The resource ‘104’ is in use

View Administrator experienced a strange issue not long before a scheduled upgrade to Horizon 6. Each time Composer attempted to spin up a new desktop, the task would error out in vCenter with the error The resource ‘104’ is in use. One would think that this issue would not have much impact. Unfortunately, this issue wreaked havoc on a linked clone pool. Over a thousand errors were reported in View Administrator overnight when this issue arose, as the desktop pool was not set to Stop provisioning on error. Upon refreshing the ports on the vSwitch, the error went away.

A quick search turned up a VMware KB article discussing that the number 104 refers to a specific port on the virtual distributed switch. Looking at the ports on the virtual distributed switch, it was observed that an older version of a template that was once servicing a full clone pool was occupying the port in question. There seemed to be some sort of confusion on the side of vCenter. Errors like this had been solved in the past by rebooting vCenter. The next outage window available for a vCenter reboot was allocated for the upgrade window. Since the first step in the upgrade was to reboot vCenter, this seemed like a good time. After the reboot of vCenter, and a successful upgrade the issue persisted.

It was time to look at the template. Since the template was an older version of the standard desktop that was kept around for fallback purposes, it was determined that a good first step was to convert the template to a virtual machine, and disconnect it from the vDS. Upon right-clicking on the template, it was discovered that the option to Convert to Virtual Machine was grayed out. A quick search returned the VMware KB article discussing possible permissions issues. Since permissions were not the case, the article recommended removing the VM from inventory. Removing the template from inventory fixed the problem, and it has yet to return. Rather than re-add the VM to inventory, the VM was deleted, as it was no longer in use.  

Horizon 6.0 Upgrade Notes – Composer Error 1920

Lesson: Backup machine certificates before upgrading View Composer

When upgrading a View environment, the first place to start is View Composer. In a recent upgrade to Horizon 6 the upgrade of Composer failed with Error 1920, shown below:

It did not take long to find this VMware KB article which then pointed to his Microsoft KB article. The error occurs in environments that do not have Internet connectivity and cannot connect to the appropriate URLs for checking certificate trust lists. Microsoft provides a patch and a policy setting to resolve the issue. The fix was simple enough. Upon implementing the fixes provided by Microsoft the installation was restarted. When reaching the step in the installation where the certificate is to be selected, it was found that the machine certificate for this system was removed. There is no explanation for this certificate removal. The two places this was seen was in a lab environment, where certificates were easy to redeploy, and an environment that was using self-signed certificates. This is why it is always a good idea to backup certificates before upgrading View Composer, or any operation for that matter.

Horizon 6.0 Upgrade Notes – View Events Database Unresponsive

Upon upgrading a View 5.2 environment to Horizon 6.0, the previously functional events database in View Administrator became unusable after the upgrade. The first place that was examined was the SQL database server where the View Events database resides. Upon logging into the server, it was quickly observed that the CPU of the SQL server was pegged at 100%. After some time the CPU of the SQL server returned to normal. To confirm the suspicion that the events database issues was related to the pegged SQL CPU some testing was performed. While watching task manager on the SQL server, View Administrator was launched and navigated to Monitoring\Events. Upon attempting to view the Events, the CPU on the SQL server spiked dramatically. It was time to find out why.

A little digging into the background of the View Events Database in VMware View explains the table layout. There are a couple of notable tables:

  • Event – Contains metadata and search optimization data for recent events
  • Event_data – Contains data for recent events
  • Event_historical – Contains data for older events
  • Event_data_historic – Contains metadata and search optimization data for older events.

In the Events view with a functioning events database the text below is shown:

This article from the VMware KB formally explains that the UI in View Administrator defaults to a maximum of 2000 events to be viewed. It also includes the settings to change to increase this value. It notes that this maximum number of events is in place to ensure performance. The higher the number of events in the event and event_data tables, the more time and system resources required to fetch and display the records.

There is also a setting in View Administrator that allows us to configure how long to Show events in View Administrator. When Show events in View Administrator is set for 2 months, as shown below, events older than 2 months are moved to the historical tables in the database. The Classify events as new for option specifies how long view considers these events “new.” Environments that have a lot of events should keep these values low, to ensure View Administrator can pull back the events quickly.

Now, getting back to the original problem that this article was written to discuss. Looking at the Events Database under system health showed the following:

The following items were gleaned from this view 1) View Administrator can only see 2000 events for performance reasons 2) there were 89964 events in the recent tables and 3) there were over 2 million events that have been recorded since the initial deployment of the environment. It seemed time to create a new database. After reconfiguring View Administrator to point to the new database, the Events view started working again.

In retrospect, it may have made more sense to modify the Show events in View Administrator time down to a week, hopefully pushing many of those events into the historical tables. Either way, the problem was resolved. After a few days, the number of events recorded in the events database was a much more reasonable.

One thing to keep in mind during the upgrade is that each desktop disconnect from the connection server and reconnect to the connection server when the connection server is rebooted registers an event in the events database.  Multiply that by however many hundreds of desktops are on that connection server, and by how many times each connection servers was rebooted – likely more than once.  This generated a lot of events. Also, some composer issues that occurred not long before the upgrade registered quite a few events. The issue there was that the linked clone pools were not configured with Stop provisioning on error and continued to fail over and over again. The error, caused by the “The resource ‘182’ is in use” (covered in another article) generated thousands of events in the events database.

By creating this new DB, there was a dramatic reduction in the amount of events that View Administrator was trying to access.  The problem View was having was that the tables storing current events was too large.



Horizon 6.0 Upgrade Notes – Sessions Disconnecting after 20 hours

After upgrading the environment from View 5.2 to Horizon View 6.0 a few users started to notice that their View desktop would log off overnight. This was new to them, as prior to the upgrade their PCoIP connection to their desktop would remain active throughout the night. These users were running the View 5.1 Client on Windows 7 desktops. The first step to understand the change in behavior was to review logs. First, was to review the logs from the View Client installed on their desktop, located here: C:\Users\%username%\AppData\Local\VMware\VDM\logs. The logs reported the following message at around 4am:

<DesktopWindow> [wswc_pcoip] The connection to the remote computer timed out and was disconnected.

Doing the math, it was determined that the View Desktop disconnection occurred exactly twenty hours after the user had logged in the prior morning. This seemed suspiciously precise. Next, it was time to look at View Administrator, as some new options are available in Global Settings. The Forcibly disconnect users setting was set to 30 days, so that was not the culprit.

It was time to turn to for a bit of searching on the Forcibly disconnect users setting.  This turned up information on the Forcibly disconnect users setting in the View Administration guide for Horizon 6.0 located here. The information in the Administration Guide states that “For clients that do not support application remoting, a maximum timeout value of 1200 minutes applies if the value of this setting is Never or greater than 1200 minutes.” This was the 20 hour number that was seen in the logs, but did not help address the immediate problem.

Further research turned up an interesting VMware KB article 2091458, which helped shed light on the way the various versions of software work together, resulting in the change in behavior. The article starts by discussing new capabilities in Horizon 6.0 where Horizon clients can inform the View Connection Server that a user is still interacting with the client by detecting mouse and keyboard actions. This setting is controlled by the Forcibly disconnect users setting mentioned earlier. The article then went on to explain that the 20 hour limit will be imposed upon client versions prior to 3.0 and Horizon Clients for Windows Store. This article provided a little more clarity surrounding specific versions, which was helpful. Finally, the article explained how to configure the View LDAP so that these legacy clients are not disconnected after the 20 hour period. This is done by adding the cs-disconnecte legacyclientsessionsontimeout=0 attirbute to pae-NameValuePair on the object CN=Common, OU=Global, OU=Properties which is shown in the picture below.

This seemed to be a good stop-gap measure until all of the View clients were upgraded, ensuring sessions from older clients are not disconnected after 20 hours.