If you would like to read the other parts in this article series please go to:
- Installing and Configuring Citrix Provisioning Services 7.6 (Part 1)
- Installing and Configuring Citrix Provisioning Services 7.6 (Part 2)
- Installing and Configuring Citrix Provisioning Services 7.6 (Part 3)
In the previous articles I described the installation and configuration of the Citrix Provisioning Services back-end servers. After that we created a vDisk via the Master Target Device. After the creation we added a Target Device, which got his operating system via OS streaming by Citrix Provisioning Services. In this article I will go one step further to discuss some advanced configuration options including the update possibilities of the vDisk.
Advanced Load Balancing
As described in one of the earlier articles, Citrix Provisioning Services (PVS) has built-in load balancing. By default PVS load balances the Target Devices between all available PVS servers within the PVS Site. So step one of advanced load balancing is to set-up several sites and add specific PVS servers per site. However the same result can be achieved configuring the standard Load Balancing with some additional configuration. When selecting the Load Balancing option within the right mouse button menu on a vDisk you can configure some the load balancing algorithm.
Figure 1: Load Balancing algorithm
Within the load balancing algorithm there is a subnet affinity option. By default this is configured with the option “None”. With this setting all PVS servers within the site can offer the streaming service to the Target Devices. Besides “None” there are two other settings available: Best Effort and Fixed. When Best Effort is chosen, the load balancing first checks the IP subnet of the Target Device and determines if one or more PVS servers are available within the same IP subnet. If that is the case the Target Devices are redirected to a server within the same IP range with the least load. If no server is available within the same subnet an arbitrarily available PVS server is chosen (with the least load). Logically you need to have a set-up where both the PVS Target Devices as well as the PVS Servers (which should be the primary contact point for that VLAN) should be located in the same IP range (VLAN). The second option is Fixed, which almost works the same as Best Effort for the first phase. With Fixed the load balancing first checks the IP subnet of the Target Device and determines if one or more PVS servers are available within the same IP subnet. If that is the case the Target Devices is redirected to a server within the same IP range with the least load. If no server is available, the Target Device will not connect to the PVS infrastructure. This is similar to using several PVS sites.
At the same configuration part as the Load Balancing you can also configure (per vDisk) automatic rebalance. With rebalance enabled the PVS infrastructure checks every five minutes if the Target Devices are proportionally divided between the available PVS servers.
Figure 2: Rebalance Enabled
If the spread is higher than the percentage configured the PVS infrastructure a rebalance will be triggered to distribute the load equally again.
Using the automated rebalance has both advantages and disadvantages. Advantage is that the system administrator don’t have to take care of the load balancing at all. However there are situations that is probably not a good idea that a server with almost no load will service target devices again. Probably the server has issues and it’s not a good idea that the server will serve target devices again.
Delegation of Control
Within PVS, delegation of control can be configured. Separation in the available rights can be configured at farm, site and device collection level. At Device Collection there are two roles available: Device Operator and Device Administrator. Configuring the delegation of control is a bit different than in other products. First you need to add the persons and/or groups within the product via the Groups tab within the Farm properties.
Figure 3: Adding groups to PVS for adding delegation of control.
The persons/group added there can be selected at the Security tabs at the different levels.
Figure 4: Configure Delegation of Control
One other strong point of PVS is the auditing feature. With the auditing feature enabled (configurable via the Farm properties). The real strong point of this auditing option is that the changes are shown at each level within the console. For example when choosing the auditing of one PVS server only the changes of that specific server are shown. However PVS goes one step further, by choosing the button changes, you can exactly see which settings are changed including the previous and current value.
Figure 5: Auditing options
One other nice feature within PVS is the Auto Add feature. With this auto add feature new devices are automatically added to the PVS infrastructure when the device connects to one of the PVS servers. Based on the Device Collection properties the target device is automatically created and configuration is copied from a template target device.
Figure 6: Auto Add configuration at Device Collection level
Remember that the configuration for auto add is available on three levels. On Farm level you enable Auto add and configure which site should be used, on site level you specific which device collection should be used and lastly on the device collection level you specify the template and naming convention.
Also be careful with enabling the auto-add feature especially when using PXE. Every device that connects via PXE with the PVS server is automatically added and I can imagine that is not desirable.
Last but not definitely least is the vDisk update options. In previous version (before version 6.x) the update mechanism was pretty complicated, rebuilding a new vDisk and then configuring the vDisk exactly the same. Updating via a new vDisk is still one of the possibilities however within PVS there is now a version functionality available. Within the vDisk, right-mouse menu there is an option called version.
Within this option you can create a new version. This version is automatically set in in maintenance mode. Within this mode you can make changes to the vDisk for example adding a new installation, installing security updates, remove an application or installing application updates.
Figure 7: vDisk versions
This is accomplished by starting one of the target devices connected to this maintenance vDisk version. Therefore the Target Device should be set as Type Maintenance. The target device with type maintenance will have a boot menu where the maintenance version can be chosen. When the Target Device is booted, the changes can be made and the Target Device can be shut down (remember that some of the preparations should be done again, like creating unique registry keys for supporting applications).
Figure 8: Type Target Device
After the shutdown the vDisk version can be changed to test. In this state the vDisk is again read only (after a reboot changes made are gone). Next step is to configure a Target Device as type Test and start this Target Device from the test version. On the target device you can confirm/test that all changes made in the maintenance version are available and working correctly.
If no issues were found in the test phase, we can promote the version to the state production. You can specify that this change is effective immediately or at the configured date. Luckily the active devices are not rebooted directly, but when they are restarted they will use the new version. In this way you can easily make changes to the production. Also one advantage is that in the case something is wrong in this version, you can easily roll-back. In that case we will revert the version to a previous state (test or maintenance) and the old version is active/production again. However active Target Devices using the version that is reverted will be shut down. This can cause down time and should be considered thoroughly including communication to the active users.
Those steps can be automated using vDisk Update Management. First your Target Devices need to be virtual machine running on Citrix XenServer, VMware ESX or Hyper-V, secondly for configuring the updates you need to have WSUS, SCCM or self-written scripts. When this is set-up, task will autorun using the versions. However the default time is pretty short (30 minutes) and you cannot test it accurately in advance. Therefore I don’t see this option really used in production environment. To be fully in control use the manual version steps (which can be automated using PVS PowerShell cmdlets as well).
Figure 9: vDisk Update Management
In this fourth and last part of the article series about Citrix Provisioning Services I discussed some advanced configuration options like Load Balancing, delegation of control, auto add, rebalance and auditing. Last topic was describing the basic steps of updating the vDisk using the versions functionality.
If you would like to read the other parts in this article series please go to: