When upgrading did you select "overwrite the database"?
It seems as if your configuration DB has been overwritten but why it can't find the object Domain_controller no idea.
I guess that somehow you manager lost it's connection with the database. Do you have a centralized DB on SQL? What can you see on the DB? Are all tables there? and is the info there?
No, the option "Overwrite the database" was not selected. The SQL database is on a dedicated server. The tables are updated only partially. I can see a new table "dbo.ldap_domains". The new tables "dbo.fileshares", "dbo.domain_controllers" and "dbo.ssl_certificates" are missing...
I tried it three times with the same result. I think, I will do a clean install of the environment.
1 person found this helpful
Are you sure that the account you are starting the Appvolumes service with in DBO of the database?
If you don't set any user account you will need to give the computer account of your Appvolumes manager DBO on the database so it can eventually create tables.
The update from 2.11.0 to 2.12.0 has worked. (The direct update from 2.11.0 to 2.12.1 has not worked... )
2 people found this helpful
We have a bug ticket open for a similar issue that produces a Server 500 Error after a 2.12.1 upgrade. Ours was caused by having a "Trusted Domains" configuration in Appvol 2.9/2.10/2.11, that causes a failure in the migration scripts used during the 2.12.1 installer. Workaround was to remove the Trusted domain config prior to upgrade.
The migration script fails to move both the primary and trusted domain configs to the new schema format, and then triggers another migration script that attempts to run SQL scripts incorrectly as the local machine account <domain>\<machine$>. We have SQL user authentication configured, so the appvol computer account should not be used.
(Local machine dbo rights are only needed when Windows integrated auth is being used for ODBC, as per the install doco & KB2108131)
As a side note, our testing would see similar server 500 errors when:
- The manager .msi file is launched instead of the setup.exe. Setup.exe runs additional migration/odbc scripts needed during the upgrade (such as svmanager_setup.bat)
- Windows integrated Authentication is being used, and the local computer account does not have access to grant roles/dbo.