HTTP 500 Internal Server Error is thrown when accessing the App Volumes Manager webpage after upgrading VMware App Volumes Manager from 2.6.0.1226 to 2.12.0.70

Problem

You’ve completed an upgrade of VMware App Volumes Manager from 2.6.0.1226 to 2.12.0.70:

… by uninstalling the old version then reinstalling the new version using the same database but notice that launching the Apps Volume Manager now display the following HTTP 500 Internal Server Error:

Reviewing the logs on the App Volumes Manager server in the folder:

C:Program Files (x86)CloudVolumesManagerlog

Reveals quite a few large 200MB+ logs:

Opening these logs file in Notepad++ shows the following error repeatedly logged:

[2017-01-17 00:25:04 UTC] P2236R698508  INFO Started GET “/cv_api/version” for 127.0.0.1 at 2017-01-16 20:25:04 -0400

[2017-01-17 00:25:04 UTC] P2236R698508  INFO Processing by CvApi::VersionsController#show as */*

[2017-01-17 00:25:04 UTC] P2236R698508 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-01-17 00:25:04 UTC] P2236R698508 ERROR    Manager: Inspecting Array (21028620) (from log block)

Solution

I’m not much of an expert with App Volumes so I called support to have an engineer review the logs and was told that the line:

[2017-01-17 00:25:04 UTC] P2236R698508 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]’

… indicates that a table in the SQL database named ldap_domains was missing.  Reviewing the database via Microsoft SQL Server Management Studio confirms the missing table:

The engineer classified this as a catastrophic error during the upgrade and said that it looks like many of the other tables were not created during the upgrade.  He wasn’t completely sure but the issue may have been due to the major jump in version and the schema changes between the versions.  At this point, the suggestion was to restore a database backup and attempt to reinstall or reinstall with a new database and reconfigure the configuration with the existing AppStacks.  This environment was only used by 20 users so I decided to perform a reinstall and reconfigure.

To ensure that the previous created AppStacks are imported, ensure that you select the same datastore containing all the AppStacks during the initial configuration after the new install:

Not exactly the best solution but since I’ve configured Active Directory groups to grant access to the applications, it was easier for me to go this route than try to perform a restore and then upgrade again: