Had some fun with upgrading App Volumes from 2.11 to 2.12.
Normally this is a no brainer upgrade. Just by following the manual.
But… This is why i crap on SQL accounts based on domain users used for windows integrated authentication instead of a generic SQL account. Yes both have their pro’s and con’s but still..
First of all, installing App Volumes under this context requires for initial install and upgrades that the computer account has rights on the database. Running the installer under that user is not enough.
Most DBA will puke on the request to add computer accounts to databases.
The software upgrade of App Volumes will be successful but the database will be missing tables and App Volumes will greet you with an error 500 in your browser.
error 500
In the logs:
(x86)/CloudVolumes/Manager/vendor/bundle/ruby/2.2.0/gems/activerecord-sqlserver-adapter-3.2.13/lib/active_record/connection_adapters/sqlserver_adapter.rb:455:in `initialize’: 28000 (18456) [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ‘vDrone\vDrone-AV01$‘. (ODBC::Error)
console_handle_fault: Exception ODBC::Error: 28000 (18456) [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ‘vDrone\vDrone-AV01$’.
*** script/grant_sqlserver_access: start 2017-04-11 12:31:50 UTC
#<ODBC::Error: 28000 (18456) [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ‘vDrone\vDrone-AV01$’.>
[2017-04-11 12:36:28 UTC] P2368R49 INFO Started GET “/cv_api/version” for 127.0.0.1 at 2017-04-11 14:36:28 +0200
[2017-04-11 12:36:28 UTC] P2368R49 INFO Processing by CvApi::VersionsController#show as */*
[2017-04-11 12:36:28 UTC] P2368R49 ERROR Manager: Unhandled request exception: ODBC::Error: 42S02 (208) [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name ‘ldap_domains’.: EXEC sp_executesql N’SELECT TOP (1) 1 AS one FROM [ldap_domains]’
[2017-04-11 12:36:29 UTC] P2368R49 ERROR Manager: Inspecting Array (20941260) (from log block)
See that the logs cry about the computer account unable to access the database although the ODBC connections made during setup work just fine. Setting the App Volumes Services to run under that domain user does solve that first part but your database is still missing tables due to the upgrade failure.
How to solve this now?
In the directory of the App Volumes Manager there is a batch file called svmanager_setup.bat.
Run this under that SQL domain user context. It will take a few minutes and shows a few errors but on the end it repaired the database and filled it with the missing tables. It will also correct the App Volumes config files on how to connect to the database.
Lessons to be learned?
Use SQL accounts where possible, saves headaches and upgrade failures.
If that’s not possible then be sure to add the computer accounts of your App Volumes manager to a security group and grant those access to the database.
If that’s not an option, well, you just had to read this to fix your issue and think.. damn.. 🙂
VMware just released App Volumes 2.12.1 which now has support for in place upgrades!
The latest release of App Volumes includes an improved upgrade process, Writable Volumes exclusions, and important security fixes.
- Improved Upgrade Process
You can now upgrade from App Volumes 2.12 to App Volumes 2.12.1 without uninstalling your existing 2.12 installation. Upgrading from versions earlier than 2.12 still requires App Volumes Manager and agent binaries to be uninstalled before proceeding with 2.12.1 installation.
Note – As a best practice with any system change, ensure that you have a backup of your systems including security cerificates and configuration files before performing an upgrade. Customizations to App Volumes outside the normal configuration interface may not be retained.