Migrating your PVS database

ryanisabelle

If you are planning on upgrading your Citrix deployment and are using PVS. At some point, you may realize that the version of SQL which hosts your PVS database may no longer be supported, or it may be on an OS that is no longer supported. This article will help you migrate your PVS database with minimal downtime (perhaps none if you’re careful). This article covers migrating the PVS database in an environment where the cache type is set to “cache in device RAM and overflow on hard disk”.

No vDisk updates or configuration changes can be made in the PVS console during the migration. Well… I suppose they can be made, but you will have a mess on your hands if you do. Coordinate a change freeze with anyone who may use the PVS console.

Before you begin:

  • Make sure no VMs are caching to the PVS servers. If they are, you will see a VHD file stored at “D:\Cache” or wherever your site is configured to store them.
    • You can find out where by right clicking the vDisk store and going to “Properties”. Under the “Paths” tab are the “Default Store path” (where your vDisks are stored) and the “Default write cache paths” (where Write caches are stored).
    • Note: As mentioned briefly in the first section, there shouldn’t be any VMs Caching on the PVS servers. VMs only cache to the PVS servers if there is not enough space on the WriteCache disk. If they are caching to the PVS server, check to make sure the WriteCache Disk is still attached to the individual VM in XenCenter.
  • It would be beneficial to put a group of servers in maintenance mode the day before for testing PVS Functionality AFTER the database is migrated. (Servers that can be easily rebooted and used to test booting to PVS)
  • If you have a pool of Randomly assigned non-persistent vdisks, then make sure to:
    • Take note of the delivery group’s “Power Management” plan.
    • Increase the total number of available desktops to the maximum supported by your infrastructure.
  • Disable the function “Automate computer account password updates”. If you fail to do this, you run the risk of having passwords reset while the old database is still “draining” which means the password in the new database will be out of sync with Active Directory. This will prevent VDAs from registering once booted on the server using the new database.
    1. In the PVS console, for each server in each site, right-click and go to properties. Select “Options” and uncheck the box. Take note of the value of the frequency of updates.
    2. The stream service will need to be restarted before the change will take effect, so you will need to failover devices a couple times to make sure it takes effect on all servers. You should do this anyway to confirm failover works normally.
  1. Disable “Load Balancing” on each vDisk and set them to boot to one of the servers that you will upgrade LAST. Devices will need to be streamed from half of your servers so that the other half can be moved.
  2. Stop the Stream Service on the other HALF of your servers. This will cause all devices to move to the servers that are still running.
  3. Take a SQL backup of the PVS database and import the backup to your new DB server. Follow normal procedure for backing up and importing a database. Ensure users and permissions are copied over.
  4. Run the PVS Configuration Wizard on one of the servers you disabled to switch to the new SQL database. NOTE: your settings may vary. Just make sure you configure your farm to match your existing environment.
    • Click Next
    • On DHCP Services, keep the default. Click next.
    • On PXE Services, keep the default. Click next.
    • On Farm Configuration select “Join Existing Farm”. Click next.
    • Enter the SQL information.
      • Server name should be a FQDN.
      • Instance name should be the name of the database.
      • While it says the TCP port is optional, this is not the case. The default TCP port  is “1433”.
      • Depending on the configuration, select “Enable Multi-Subnet Failover” if using an Always On Availability Group.
    • Click next.
    • Be sure to join the server to the correct site (if you have more than one). Also make sure “Automate machine account password updates” is checked and time frame is set to 7 days (or whatever it was set to before you disabled it in step 6).
    • Click next.
    • Enter the Credentials for the PVS database service account.
    • Click next through the rest and Finish.
  5. The Stream Service should start on its own after completing the Wizard.
  6. Launch the PVS console. Be sure to connect to one of the servers you migrated.
  7. Change “Load Balancing” on each vDisk on each site to boot to the migrated server.
    • IMPORTANT: Because of the “dissected” state of the PVS servers, you will only be able to change the Load Balancing configuration on the servers that you migrated.
    • Right now you basically have two separate PVS deployments running side by side.
    • If you have the TFTP address load balanced on a NetScaler, you will also need to disable the old servers on the NetScaler’s load balancer TFTP_PVS address to remove them from service. This will force all new connections to go to the new servers.
  8. You will also need to modify the bootstrap file on the migrated servers to remove the IP addresses of the servers still connected to the old database so that VMs do not try to connect to them during boot. If you don’t do this step, PVS will automatically try to offload boot requests to other servers in the list. Which will definitely cause trouble for you.
    • To do this, in the PVS console, go to Sites > “Site Name” > Servers.
    • Right click on the server and click “Configure Bootstrap”.
    • Remove the servers that are still running with the old database (by IP address).
    • Click OK.
    • Repeat these steps for each server that is connected to the new database.
  9. Test booting desktops and/or servers to ensure PVS is functioning on new server.
  10. Once devices have booted to the new server, there should be no need to rollback. If there is:
    • Change Netscaler load balancing to point back to the Server with the old Database.
    • Shut down any servers that booted to the server with the new Database.
    • Re-Run the PVS Installer Wizard and change back to the old DB connection string.
    • Test and confirm.
  11. If all is working normally, you can proactively reboot as many VMs as you can to get them off of the original servers. Otherwise, you will need to wait for the machines to be rebooted. If you have automatic reboot schedules, wait for them to run. If you DON’T, you will need to coordinate reboot of those servers before you can finish the migration. During this time, any configurations or vDisk updates need to be performed on the new database and NOT the old one. Otherwise, your changes will be lost.
  12. Once the servers running from the old database are no longer hosting any VMs, Run the PVS installer Wizard to switch to the new SQL database following the same steps in step 4.
  13. Re-Enable load balancing for each vDisk.
  14. Add all remaining servers to the NetScaler’s load balancer address.
  15. Modify the bootstrap files on all servers to include all migrated servers.
  16. Test booting desktops and/or servers to ensure PVS is functioning on new server.
  17. If VMs are booting properly from all of your servers, you can then rebalance the devices in each site.

Leave a comment