I've never done it, but there shouldn't be any problems, in these cases For app volumes you can edit the local odbc and point to the correct database or just uninstall app volumes and reinstall it pointing to the new database. You need to precopy the database and make sure you update the permissions correctly, appvolumes uses the computer account to connect and not a user account. Horizon view should be the same, just copy the database create the user and give it the same permissions on the new server. Basically outside of creating the new database everything else here should apply
1 person found this helpful
I've just recently had to address the same issue in my environment and also had difficulty in finding documentation. I did find this: Supporting Always On Availability Groups (SQL Server) with App Volumes - VMware Blogs which provided some useful information. The steps I completed were:
1. I stopped the "App Volumes Manager" service on the App Volumes Manager server
2. Our DBA migrated the App Volumes Database
3. On the App Volumes Database server I opened "ODBC Data Source Administrator (32-bit)"
a. On the "System DNS" tab I selected "svmanager" for the 32-bit platform and clicked "configure"
b. In the next screen I updated the server name
c. We are using SQL server authentication, so I provided the Login ID and Password on the following screen
d. From there I kept all of the remaining defaults.
e. After clicking finish I tested the connection to verify
4. I restarted the "App Volumes Manager" service
just be sure that you install the SQL native client same version as the one used the sql server