We have several components in a Horizon environment that utilize databases, and there are also quite a few situations when those use external databases. With external databases, it is often that organizations are using Microsoft SQL Server databases. And with external databases, like any others btw, requirements might change or lifecycle management of MSSQL or underlying Windows requires the databases to be migrated. And with that…. what better way to write this all down in a post.

Before starting your migration be sure to do an Interoperability check with your to be solution. Horizon, or other VMware products for that fact, versions don’t always have the newest support from other vendors. This takes some testing and certifications and might take a while. But after all is checked, and also with other components that might consume these, we will start the migration.

Migrating Horizon Event Database and Composer Database

Yes, there might be a few more, but for this post let us start here. If there happen to be some others I will link to this post and you will see. Just like I am now linking to my own article on moving vCenter from SQL Express to SQL Server (Windows) for example purposes only.

Before starting any migration a good procedure is to take a backup so you can rollback if something goes amiss. It is advised that when for example migrating the composer database, you should take a backup of:

Horizon, do a VDM backup (command line or via View Configuration – Servers – Connection Servers – Backup now).

Composer Database, via database backup.

vCenter database, either via database backup or the appliance.

Note: That’s a TLDR from this VMware KB article: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008046.

Next up is preparing your destination server with all VM, OS, and MSSQL database instance application details. For the composer database server, the migration goes with reinstalling for similar build numbers so try to keep up with source and destination when migrating. For some information decyphering MSSQL build numbers: https://buildnumbers.wordpress.com/sqlserver/. If you change build numbers too much you might have to reinstall the composer server. And the same goes with backup and restore of the Event DB, they will not always restore, backup restore on backward version is not an option for example).

And get migration accounts ready, accounts that can control SQL for backup/restore, SQL users and offline/online of a database on the old and the new server. And can transport files between the old database server and new database server (admin on Windows for example).

Great but we will start with the Event Database.

Migrate the Event Database

The Event Database will be configured on the Horizon Administrator Console and in vROPS for Horizon (V4H) Broker configuration on the connection server that is paired with vROPS. Get your information and user accounts ready from your configuration workbooks and password managers.

For the migration of the Event Database we do the following:

Log on to the current database server and take the database offline (Tasks – Take Offline). Note: do not detach for now. If for some reason the new server isn’t as ready as you thought it was, or the restore fails, then you can put this database back online quickly. Check activity monitor if the offline task runs too long. Close connections and try again. Note about note: don’t leave it attached and offline too long as this may fail backup and maintenance plans still configured to use this database. Backup the current Event database. Transport the backup to the destination server or a location accessible to the destination server. Restore the backup of the Event Database you just took on the destination server. Create the SQL user and map to the database. You will have to first remove the user mapping in the restored event database itself (security). Change the values in the Administrative Console. Reconfigure/Change and restart the vROPS Broker Utility.

Note: You can also use the copy database wizard instead of backup – restore if you want the above steps combined in a ready job for you. As long as the accounts used to run the package have access to move the files.

Note: if just changing the Even Database configuration – System Health will show the old database server name. But it will show the updated server name in the details. If you look with SQL Activity Monitor you will notice SQL user connections on the new MSSQL server from the connection server.

Migrating the Composer Database

Yes even with the possibility of Instant clones, we will still find a lot of linked clones around. And thus in result also Composer servers with their composer databases. This can influence your environment a bit more. Get your information and user accounts ready from your configuration workbooks and password managers.

For the migration of the Composer Database we do the following:

Disable provisioning on the desktop pools. Stop the composer service on the composer server. Log on to the current database server and take the database offline. Note: do not detach. If for some reason the new server isn’t as ready as you thought it was, or the restore fails, then you can put this database back online quickly. Note about note: don’t leave it attached and offline too long as this may fail backup and maintenance plans still configured to use this database. Backup VDM (it is advised to have the same moment of backup of VDM, Composer, and vCenter). Backup the current Composer database. Transport the backup to the destination server or a location accessible to the destination server. Restore the backup you just took on the destination server. Create the SQL user and map to the database. You will have to first remove the user mapping in the restored event database itself (security). On the View Composer server, open up the Data Sources (ODBC) 64-bit tool. Click the System DSN tab. Click Configure. Here you change the Server from the old MSSQL Server to the new. If you have used the same password insert it here as well and next, next, next to till you can test, and test. Finish. Start the provisioning service. That’s it! Well, do also re-enable provisioning of the desktop pools.

Note: You can also use the copy database wizard instead of backup – restore.

Validation

Do a few tests to confirm things are as they should be. Like logging on to pools, logging off, refreshing, recomposing (if set to refresh or delete at login, this will be tested with the pools), adding desktops to pools and so on.

Delete the database on the old location after you have confirmed everything is working. We don’t want to leave behind legacy stuff.

– Enjoy your migration!

Sources: vmware.com