Category Archives: Horizon 6 Upgrade

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.

Advertisements

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 Google.com 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.