VMware Horizon Community
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Trying to install additional Manager - "Unable to start App Volumes Manager"

I'm trying to install a 2nd Manager, the installation goes well, and the service starts, but the landing page displays "Startup Failure":

ODBC::Error: S0002 (208) [Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid object name 'svconfigurations'.: EXEC sp_executesql N'SELECT TOP (1) [svconfigurations].* FROM [svconfigurations] ORDER BY created_at DESC'

I installed the SQL 2012 native client and updated the DSNs (both x86 and x64) to use that driver instead as a test, but it made no difference.  I did follow documentation and unchecked the overwrite box, so my primary Manager is still fully operational.

Any ideas?

0 Kudos
1 Solution

Accepted Solutions
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

It was permissions, but not to the msdb database.  I had set default schema for the user to [dbo], but what worked was [db_owner] (it always had the db_owner role, btw).  Small change, started services, all systems go.

View solution in original post

0 Kudos
5 Replies
jahos_
Enthusiast
Enthusiast
Jump to solution

It seems that there is something wrong with your odbc connection. Appvolumes is using the 32bit odbc connection.

Apparently there is a 32bit and 64bit system dsn listed in both 32bit and 64bit odbc managers. You should check the 32bit "svmanager" system dsn in the 32bit odbc manager (c:\windows\syswow64\odbcad32.exe) and verify if you can connect succesfully to the database.

Also there is a database.yml file in the appvolumes installation directory which contains the db connection settings.

What I noticed also when installing a second manager, is that although I unchecked "overwrite database", it did overwrite it and I lost my complete config.

0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

We also had this problem the first time we installed the manager.

It could be that permissions on the database aren;t correct. If you installed it with the local system account then you should have an account in the SQL server that connects to this machine.

0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

The ODBC settings are correct, and do connect when I test them (I did this before posting, as well as changing from the default SQL driver to the native driver for SQL 2012 R2 SP2).

There's nothing in the database.yml file other than what DSN to use and the username.  I don't think changing anything in that file is the way to go.

0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

It does feel like a SQL permissions issue from the message received, but the local SQL account I created for the AppVolumes db is set to DB_Owner.  You know what, as I type this I realize what it probably is.  The user does not have permissions to the msdb database as well.  Let me try that and post back...

0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

It was permissions, but not to the msdb database.  I had set default schema for the user to [dbo], but what worked was [db_owner] (it always had the db_owner role, btw).  Small change, started services, all systems go.

0 Kudos