Issues upgrading Horizon 6 View Composer – Possible Bug

The last couple of Horizon upgrades I have done have gone smooth for the most part.  One little thing I have come across is an issue when upgrading the View Composer component.  I was aware of the challenge and had come up with a workaround, but I wanted to look a bit closer when I was upgrading my home lab from Horizon 6.2 to 6.2.1.

My home lab Horizon 6.2 environment includes a Windows vCenter 6 VM that is co-installed with MS SQL Server 2012 Standard.  The OS is Windows Server 2012 R2.  I have the choice of either installing the View Composer component on a standalone server (and use SQL Authentication for the View Composer Database), or installing View Composer on the same server as my SQL Server, and use either Windows Authentication or SQL Authentication in my ODBC Data Source Name.  To save a bit of RAM (aren’t most of us memory bound in our labs?), I decided to co-install View Composer with SQL Server.  This is similar to two other Horizon environments I have installed, that also had a similar issue to the one I will outline below.

Once I have moved forward through the Horizon 6 Composer installation, you get to the spot where the services are starting up.


This remains until I get the troublesome error below:


Well, the last installation I did required me to modify the service account for the svid (VMware Horizon 6 Composer) service.  Surely those credentials should be there?  Well, when I opened up my services console, I see that not only is the installer correct that the service is not started, but it is attempting to start the service as the LOCAL SYSTEM.



Further probing shows an event log error below.


Another odd part is by canceling the installer, it indicates that the installation will be rolled back to it’s original state.  When I do that, and look to see if my Composer Service is still there, I see it is not.


There are many blogs out there that indicate the fix is to simply (during the install), go into your service login page and enter your credentials for your service account that has permissions to your SQL database. — From 2012

That is something that does work, but here is another idea.  What if I simply created a new account on our SQL Server with the proper database permissions, but uses SQL Authentication?  I went ahead and did that, and created a new ODBC Data Source Name that was named slightly different.


Inside the configuration, I specified the SQL Authentication-based account I just created.


I re-ran the installation referencing the new ODBC DSN, and voila, the installation succeeded.

This very well might be a bug with the installer, as we should be given an opportunity to either enter a service account username/password, or the installer should simply carry over the old credentials.


Leave a Comment

Your email address will not be published. Required fields are marked *