VMware Horizon Community
pbhite
Enthusiast
Enthusiast
Jump to solution

500 Internal Server Error After 2.12 to 2.13 Upgrade

Just ran the App Volumes Manager installer for 2.13 on our current 2.12.1 server with a local SQL Express DB. After the install finished successfully (which does not have any options to select for the upgrade), our agents can't connect and I can't login - it just returns a 500 internal server error. The login page displays and our domain is listed in the drop-down. The service is starting fine and everything in the logs seems to check out until we go to log in. I tried fiddling with the ODBC connector, changing to a local sa account, made sure there the local computer account was in SQL with dbo permissions on the database, etc. Here's the error in the production######.log file that appears immediately after the login process and just before the 500 error is returned:

ERROR      Manager: Unhandled request exception: nil can't be coerced into Fixnum

In the svmanager_setup.log file, I see all the db tables being created successfully, but there is this error just before the "finished successfully" message

Granting database access to REDACTED\VMW17APPVOL$

console_handle_fault: Exception ActiveRecord::StatementInvalid: ODBC::Error: 42000 (15247) [Microsoft][ODBC SQL Server Driver][SQL Server]User does not have permission to perform this action.: CREATE LOGIN [REDACTED\VMW17APPVOL$] FROM WINDOWS

#<ActiveRecord::StatementInvalid: ODBC::Error: 42000 (15247) [Microsoft][ODBC SQL Server Driver][SQL Server]User does not have permission to perform this action.: CREATE LOGIN [REDACTED\VMW17APPVOL$] FROM WINDOWS>

However, I can confirm that the computer account already exists in SQL and has dbo permissions to the AppVol db (and sysadmin permissions on the SQL instance itself), so this may just be an erroneous error because the account already existed prior to the upgrade.

23 Replies
pstover
Enthusiast
Enthusiast
Jump to solution

Here are my notes.

LDAPS 636 was working with 2.12.  Upgrade to 2.13.1 results in failed logon to the admin console (not the same failed web page blank as with 2.13).  The production log says hostname does not match the server certificate.  I'm assuming that 2.13.x is doing some strict certificate checking not in place with 2.12 since my 2.12 config had an IP address for the domain controller.

As a result I set my 2.12 installation to LDAP 389 and do the upgrade without issue to 2.13.1.

Then I attempt to set LDAP bind to LDAPS 636 in the 2.13.1 console.  This fails with failed to match server certificate.  I change the domain controller field to the FQDN of the domain controller and now the log file says "connection failed, ensure credentials are correct" and the preceding error in the log file.

RADIR: LDAP bind failed: #<OpenStruct code=0, message="Success">. Failed with result code: 49 and error message: 8009030C: LdapErr: DSID-0C0904F8, comment: AcceptSecurityContext error, data 52e, v23f0

sabarishkumarr
VMware Employee
VMware Employee
Jump to solution

Based on VMware App Volumes 2.13.1 Release Notes

  • If the administrator cannot log in to App Volumes Manager console due to incorrectly configured certificates or hostnames, temporarily set the environment variable AVM_DISABLE_LDAP_SSL_VALIDATION = 1 on your current App Volumes Manager service and restart the service.

So you should try setting the env variable if LDAPS is still not working.

Reply
0 Kudos
pstover
Enthusiast
Enthusiast
Jump to solution

FYI setting the AVM_DISABLE_LDAP_SSL_VALIDATION = 1 system variable allows successful LDAPS 636 binding.  I am going to re-verify my adCA.pem setup 100%, although this worked with 2.12.

Reply
0 Kudos
julatoski
VMware Employee
VMware Employee
Jump to solution

FYI setting the AVM_DISABLE_LDAP_SSL_VALIDATION = 1 system variable allows successful LDAPS 636 binding.  I am going to re-verify my adCA.pem setup 100%, although this worked with 2.12.

Please ensure hostnames specified in the domain controller hosts field match exactly to the hostnames listed in the certificates.  Refer to the VMware App Volumes Administration Guide for more information.


Jeff Ulatoski
Product Line Manager, App Volumes
Reply
0 Kudos