I recently upgraded a View 4.6 installation to 5.0. The update went pretty well until I went to update the View agent inside the desktop sources. The install kept failing with the following error message:
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action VM_RegisterPcoipPerf32, location: ...\pcoip_perf_pr...
After a bunch of searching/testing, I finally realized that McAfee On Access Protection was blocking the ability for the composer agent to register as a service. McAfee exclusion in place, I continued to have issues with the installer, so I removed VMware Tools and cleaned up all of the VMware installer bits using the tool in this KB:
Cleaning up after an incomplete uninstallation on a Windows host (http://kb.vmware.com/kb/1308)
After a reboot I was able to install the View 5.0 Agent and then I finally re-installed VMware Tools and recomposed my desktops. Now for the next error, which showed up in the View Connection Server/Admin console after attempting to deploy these new linked clones:
View Composer agent initialization state error (-1): Illegal state (waited 0 seconds)
I couldn’t find much documentation on this error…but after searching through some of the agent logs, I realized that the “VMware View Composer Guest Agent Server” service wasn’t installed in my guest VM. It appears this option only exits in the View Agent installer if VMware Tools is already installed in the VM. Re-running the View 5.0 Agent installer gave me the option to install the composer agent and thin print support.
I just performed an upgrade from VSphere 4.1 to 5.0 and View 4.5 to 5.0. Migrated from Win2k3 View server to Win2008 R2 64 server, migrated DB from SQLExpress to SQL 2005 Server. After the VSphere upgrade the View Admin website worked, although we received an error message when selecting the check box for Enable View Composer. We check, re-checked everything. Many errors were similar to what were noted on this site as well as others.
The issue and correction to the problem: SQL 2005 No Count Setting. Un-check this box and it works Details below:
I’ve come across an interesting situation while migrating the View Composer database from a MSSQL 2005 EXP to a MSSQL 2005 STD.
After we migrated the Composer database to MSSQL 2005 STD, I was able to connect to it using my original ODBC and start the View Composer Service.
But after the service is started, I could not connect to it from the View Connection Manager. It keeps prompting me a connection error.
Then I went into the Composer log and observed this:
2011-01-17 15:28:00,107 | 3 | INFO | SimAuditLogger.WebService – Operation AddAdConfig.
Caller user name: MYDOMAIN\vSphereUser
adConfigEntry.Fqdn : mydomain.local
adConfigEntry.LogonUser : mydomain.local\ComposerUser
In vmware-viewcomposer.log on VSphere server i have:
2011-01-17 15:28:00,115 | 3 | INFO | Persistence.Database.SimDbTransaction – An active transaction is about to be rolled back during VMware.Sim.ServiceCore.Persistence.Database.SimDbTransaction Dispose.
2011-01-17 15:28:00,116 | 3 | INFO | Persistence.Database.SimDbTransaction – Implicit rollback performed.
2011-01-17 15:28:00,116 | 3 | FATAL | Sim.ServiceCore.SimServiceApiImpl – Error: fail to execute web service call: AddAdConfig
VMware.Sim.ServiceCore.Exception.SimDaoException: Hibernate threw exception during Commit. —> NHibernate.StaleStateException: Unexpected row count: -1; expected: 1
at NHibernate.AdoNet.Expectations.BasicExpectation.VerifyOutcomeNonBatched(Int32 rowCount, IDbCommand statement)
at NHibernate.AdoNet.NonBatchingBatcher.AddToBatch(IExpectation expectation)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object fields, Boolean notNull, Int32 j, SqlCommandInfo sql, Object obj, ISessionImplementor session)
at NHibernate.Persister.Entity.AbstractEntityPersister.Insert(Object id, Object fields, Object obj, ISessionImplementor session)
at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
— End of inner exception stack trace —
at VMware.Sim.ServiceCore.Persistence.SimDaoHelper.LogAndThrow(Reason reason, String message, Exception inner)
at VMware.Sim.ServiceCore.SimServiceApiImpl.AddAdConfig(AdConfigEntry adConfigEntry), Machine Name: VC-server, Timestamp: 17.01.2011 12:28:00, App Domain Name: SviWebService.exe, Thread Identity: , Windows Identity: NT AUTHORITY\SYSTEM, OS Version: Microsoft Windows NT 6.0.6002 Service Pack 2, reason: Hibernate
I searched through the vmware knowledge base, and could not find a resolution for it.
Then I got around to checking the configuration of the DB instance running on SQL 2005 STD that was having this problem, and I noticed that someone had turned on “no count” as a default connection option.
Setting “no count” basically tells SQL server not to report back how many rows were affected by the last operation executed. Of course, this is a big problem for Hibernate which uses those row counts to determine if an update was unsuccessful.
After I uncheck that no count option, I can connect to composer from the connection manager.
You can find this “no count” setting by going to SQL Server Manager, right clicking on the DB Server instance you have registered in the Object Explorer, and selecting “Properties”. Next, select the Connections page, and look in the “Default connection options” list for the “no count” setting. It must be unchecked for Hibernate to function properly.