Author ryanisabelle

Migrating your PVS database

ryanisabelle Leave a comment

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.

Upgrading ShareFile Storage Zone Controller

ryanisabelle Leave a comment

This post is going to be a little short. I’m going to go over the basic upgrade process for “Citrix ShareFile Storage Controllers”. This is really only necessary if the data you’re sharing is hosted on prem. If you use Citrix Cloud storage zones, you don’t have to do any of this. Also, these steps are for MINOR upgrades from 5.x. to 5.y.

Occasionally you will need to upgrade the Storage Zone Controllers either due to either being outdated, or a critical hotfix that Citrix has released to address security concerns. Follow these steps to create a backup of the configuration and upgrade the controllers to the latest version. Log into one of your ShareFile controllers. You will need to determine which one is currently the “Primary” controller.

  1. Launch Internet Explorer and enter the URL http://localhost/ConfigService/login.aspx
  2. Log in using your ShareFile credentials.
  3. Under “Primary Zone Controller” it will either say http://localhost… Or http://SharefileSZC1…(or whatever your server is named)

Next, you’ll want to make sure you’re logged into whichever controller is the primary. Go ahead and do that before proceeding. Then we’ll want to take a backup of our configuration. Just in case the worst should happen. For this, you will need SysInternals’ PSexec.exe available on the server. I have mine saved to “C:\Temp\”

  1. Launch PowerShell on the primary controller and enter the following commands. You may need to change focus to “C:\temp\” (or wherever you saved PSexec.exe).
  2. Enter the following command(s).
    • PsExec.exe -i -u “NT AUTHORITY\NetworkService” C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell
    • NOTE: If you’re environment is using a domain service account instead of the builtin “Network Service” account, you will want to update this command accordingly. See the Citrix documentation here.
  3. This will open a new PowerShell console under the context of the Network Service account. Enter the following commands to take your backup. Each bullet below is one command.
    • Import-Module “C:\inetpub\wwwroot\Citrix\StorageCenter\Tools\SfConfigBR\ConfigBR.dll”
    • Get-SfConfig -PrimaryZoneController “localhost” -Passphrase “passphrase” -FilePath “filepath”

The passphrase parameter is your “ShareFile” passphrase. This was set up when it was configured. You’ll have to figure that one out. The filepath parameter, is simply the location you want your backup stored.

 Once your backup is complete, run the installer to upgrade the “Storage Zone Controller”. You will mainly click “Next” through most of the installation.

  1. Accept the EULA.
  2. When prompted, choose the option “Do not close applications. A reboot will be required.” And click “OK”.
  3. You may get an error that looks like this…
If you see this error, do what it says BEFORE you click “OK”. It won’t wait for you otherwise.
  1. Do what it says BEFORE clicking “OK”. Navigate to \\fileserver\sharename and copy “SCKeys.txt” and save it somewhere safe.
  2. Once the file has been backed up safely, Click “OK”.
  3. When prompted, uncheck the “Launch StorageZones Controller Configuration Page”. And click “Finish”.
  4. You may be prompted to reboot. Click yes.
    • If you’re not prompted, you should reboot anyway. Restart the server.

Once the server has been rebooted, you should DEFINITELY consider testing ShareFile to make sure everything is working properly and your Storage Zones are still accessible.

Once you have tested to your satisfaction, you can begin upgrading the other server. There’s no need to take a backup of the config again, since you already have one. Just run the installer following the same steps as before.

Once both servers have been upgraded and rebooted, run iisreset from the command prompt on both servers (one at a time).

  • Not really sure the reason for this. Everything seems to work fine without it. But that’s what the official Citrix documentation recommends. So DO IT.

You should obviously have verified that ShareFile still works as expected by now. But if you haven’t, do it now. And if you HAVE, you should probably do it again. Just to be safe.

That’s all there is to upgrading ShareFile Storage Zone Controllers. If these steps don’t work for you, or don’t seem right, see the Citrix Documentation. Linked below.

Thanks for reading!

Decommissioning Citrix XenApp 6.5

ryanisabelle Leave a comment

We’re going to start off this blog with something that everyone wants. Shutting down your XenApp 6.5 Delivery Controllers for good! If you haven’t moved on from XenApp 6.5 at this point, you should definitely start thinking about it.

Before you move ahead, you need to first work on migrating all of your VDAs to Citrix Virtual Apps and Desktops 7. Or you can just decommission the VDAs instead. Of course, only if you don’t need them anymore. If you haven’t done this yet, you shouldn’t
be reading this. If you decommission your Xenapp 6.5 environment before you migrate or decom your VDAs, you’re going to have a bad time. Once you’re sure that all apps and VDAs have either been migrated or decommissioned, you may proceed.

  • NOTE: As with any Citrix maintenance, you should make sure your License server is up to date. I don’t see how an outdated license server could cause a problem, but you never know. Better safe than sorry.

Now, first things first…Whatever you do, DON’T start by removing the Delivery Controllers from the Citrix Gateway. You must first remove the Delivery controllers from Web Interface and/or Storefront. Otherwise you’re going to have a bad time. And YES, I’m speaking from experience.

Citrix Web Interface: If “Citrix Web Interface” is not being used, lucky you! Skip ahead to Citrix Storefront.

  1. Log into your Web interface servers (all of them) and launch Citrix Web Interface Management console. These steps must be performed manually on each server.
  2. Under “XenApp Web Sites”, select each individual site and perform the following.
  3. Right Click and select “Server Farms”.
  4. Select the farm you are retiring and click “Remove”
  5. Click OK to return to the main console.
  6. Right click and select “Secure Access”.
  7. If using the access method “Gateway Direct”, click “Next” twice. Otherwise click “Cancel” and skip to step 10.
  8. Select the Delivery controllers you are removing and Click “Remove”.
  9. Click Finish.
  10. Repeat from step 2 for each “XenApp Web Site” and “XenApp Services Site”.
  11. Don’t forget to repeat these steps on your second Web Interface server.

Citrix Storefront: Log into one of the Citrix StoreFront servers. These steps only need to be done on one server, but must be propagated to the second server by selecting “Server Group” and clicking “Propagate Changes”. Also, make sure no other administrators are making changes.

  1. Launch “Citrix Storefront”.
  2. Under each store right click and select “Manage Delivery Controllers”.
  3. Select the farm to be decommissioned and click “Edit”.
  4. Add the new DDC’s FQDN to the list of Servers.
  5. Click Ok twice.
  6. Do this for all Stores.
  7. On the right-hand “Action Pane” select “Manage NetScaler Gateways”.
  8. Select the appropriate gateway and click “Edit”.
  9. Choose the “Secure Ticket Authority” tab on the left.
  10. Make sure your XA6.5 delivery controllers are not listed here.
  11. Do this for all Gateways that use this DDC, if any.
  12. Don’t forget to propagate the changes to the other Storefront node.

Great. Now all requests directed to either Storefront or Web Interface will all be handled by your Citrix Virtual Apps and Desktops 7 Farm. Now we just need to update Citrix Gateway’s STAs or “Secure Ticket Authority”.

Citrix Gateway: Once all of the references to the XenApp 6.5 environment have been removed from Web Interface and/or storefront, it is safe to remove the Delivery controllers from the Citrix Gateway.

  1. Go to “Citrix Gateway > Virtual Servers” and select your Gateway.
  2. Scroll down until you find the “Published Applications” section. Click on “# STA Servers”
  3. Select the Delivery controllers you are decommissioning and click “Unbind”.
  4. Be sure that you didn’t break anything at this point by thoroughly testing your environment. Test launching apps directly from storefront, web interface, and Citrix Gateway. Make sure they all work individually.
  5. Commit your changes.

Congratulations. You can now safely shutdown your delivery controllers. If you are still using EdgeSight, you can shut this down as well. I recommend holding off a few days to a week before completing the decom process. Although, I’m sure any issues will become apparent fairly quickly when you shutdown the Delivery Controllers. Once you’re comfortable, follow your organizations Decommissioning process. This typically would include deleting the VM, deleting the AD account, and DNS entries, etc.