- Zones (XenApp/XenDesktop 7.7 and newer)
- Zone Preference (XenApp/XenDesktop 7.11 and newer) 💡
- Machine Creation Services
- Delivery Group Published Apps and Desktops in 7.8 and newer
- RDSH Scheduled Restart
- Allow one user to have Multiple Sessions
- Static Catalog – Export/Import Machine Assignments
- Monitor Number of Free Desktops
- Published Applications
💡 = Recently Updated
This section details how to create zones and put resources in those zones. In 7.9 and older, there’s no way to select a zone when connecting. In 7.11 and newer, NetScaler and StoreFront can now specify a zone and VDAs from that zone will be chosen. See Zone Preference for details.
- Zones at docs.citrix.com.
- Citrix Blog Post Deep Dive: XenApp and XenDesktop 7.7 Zones
- Citrix Blog Post Zones, Latency and Brokering Performance
There is no SQL in Satellite zones. Instead, Controllers in Satellite zones connect to SQL in Primary zone. Here are tested requirements for remote SQL connectivity. You can also set HKLM\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions to throttle launches at the Satellite zone.
From Mayunk Jain: “I guess we can summarize the guidance from this post as follows: the best practice guidance has been to recommend a datacenter for each continental area. A typical intra-continental latency is about 45ms. As these numbers show, in those conditions the system can handle 10,000 session launch requests in just under 20 minutes, at a concurrency rate of 36 requests.”
If Satellite zone loses connectivity to SQL, then the Connection Leasing feature kicks in. See docs.citrix.com Connection leasing and CTX205169 FAQ: Connection Leasing in XenApp/XenDesktop 7.6 for information on Connection Leasing limitations (e.g. no pooled virtual desktops, 2 week-old leases, etc.).
The following items can be moved into a satellite zone:
- Controllers – always leave two Controllers in the Primary zone. Add one or two Controllers to the Satellite zone.
- Hosting Connections – e.g. for vCenter in the satellite zone.
- Catalogs – any VDAs in satellite catalogs automatically register with Controllers in the same zone.
- NetScaler Gateway – requires StoreFront that understands zones (not available yet). StoreFront should be in satellite zone.
Do the following to create a zone and move items into the zone:
- In Studio 7.7 or Studio 7.8, expand the Configuration node and click Zones.
- If you upgraded from an older XenApp/XenDesktop and don’t see zones, then run the following commands:
cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig' Import-AdminRoleConfiguration –Path .\RoleConfigSigned.xml
- Right-click Zones and click Create Zone.
- Give the zone a name. Note: Citrix supports a maximum of 10 zones.
- You can select objects for moving into the zone now, or just click Save.
- Select multiple objects, right-click them, and click Move Item.
- Select the new Satellite zone and click Yes.
- To assign users to the new zone, create a Delivery Group that contains machines from a Catalog that’s in the new zone. There is no Zone Preference and Failover option in this release.
- If your farm has multiple zones, when creating a hosting connection, you’ll be prompted to select a zone.
- If your farm has multiple zones, when creating a Manual catalog, you’ll be prompted to select a zone.
- MCS catalogs are put in a zone based on the zone assigned to the Hosting Connection.
- The Provisioning Services XenDesktop Setup Wizard ignores zones so you’ll have to move the PvS Machine Catalog manually.
- New Controllers are always added to the Primary zone. Move it manually.
XenApp/XenDesktop 7.11 adds Zone Preference, which means NetScaler (11.0 build 65 and newer) and StoreFront (3.7 and newer) can request XenDesktop Controller to provide a VDA in a specific zone.
However, 7.11 does not have any offline database capability. If you are stretching a farm across datacenters, I still recommend separate farms in each datacenter. Hopefully offline database is addressed in a future release of XenApp/XenDesktop.
To configure zone preference:
- Create separate Catalogs in separate zones, and add the machines to a single Delivery Group.
- You can add users to one zone by right-clicking the zone, and clicking Add Users to Zone. If there are no available VDAs in that preferred zone, then VDAs are chosen from any other zone.
- Note: a user can only belong to one zone.
- You can delete users from a zone, or move users to a different zone.
- If you edit the Delivery Group, on the Users page, you can specify that Sessions must launch in a user’s home zone.
- For published apps, on the Zone page, you can configure it to ignore the user’s home zone.
- You can also configure a published app with a preferred zone, and force it to only use VDAs in that zone. If you don’t check the box, and if no VDAs are available in the preferred zone, then VDAs can be selected from any other zone.
- Or you can right-click on a zone, and configure multiple Applications to use that zone as preferred.
- NetScaler can specify the desired zone by inserting the X-Citrix-ZonePreference header into the HTTP request to the StoreFront 3.7 server. StoreFront 3.7 will then forward the zone name to Delivery Controller 7.11, which will select a VDA in the desired zone. This functionality can be combined with GSLB as detailed in the 29 page document Global Server Load Balancing (GSLB) Powered Zone Preference. Note: only StoreFront 3.7 and newer will send the zone name to the Delivery Controller.
MCS – Full Clones
In XenApp/XenDesktop 7.9 and earlier, Persistent Linked Clones are created by selecting Yes, create a dedicated virtual machine in the Create Catalog wizard. Please, never do this in 7.9 or earlier, since you can’t move the machines once they’re created. A much better option is to use vCenter to do Full Clones of a template Virtual Machine. Then when creating a Catalog, select Another service or technology to add the VMs that have already been built.
In XenApp/XenDesktop 7.11 and newer, you can create MCS Full Clones. Full Clones are a full copy of a template virtual machine. The Full Clone can then be moved to a different datastore (including Storage vMotion), different cluster, or even different vCenter. You can’t do that with Linked Clones.
For Full Clones, simply prepare a Master Image like normal. There are no special requirements. There’s no need to create Customization Specifications in vCenter since Sysprep is not used. Instead, MCS uses it’s identity technology to change the identity of the full clone. That means every full clone has two disks: one for the actual VM, and one for identity (machine name, machine password, etc).
During creation of a Full Clones Catalog, MCS still creates the master snapshot replica and ImagePrep machine, just like any other linked clone Catalog. The snapshot replica is then copied to create the Full Clones.
In 7.11 and newer, during the Create Catalog wizard, if you select Yes, create a dedicated virtual machine:
After you select the master image, there’s a new option for Use full copy for better data recovery and migration support. This is the option you want. The Use fast clone option is the older, not recommended, option.
Since these are Full Clones, once they are created, you can do things like Storage vMotion.
During Disaster Recovery, restore the VM (both disks). You might have to remove any Custom Attributes on the machine, especially the XdConfig attribute.
Inside the virtual machines, you might have to change the ListOfDDCs registry value to point to your DR Delivery Controllers. One method is to use Group Policy Preferences Registry.
In the Create Catalog wizard, select Another Service or technology.
And use the Add VMs button to add the Full Clone machines. The remaining Catalog and Delivery Group steps are performed normally.
MCS – Machine Naming
Once a Catalog is created, you can run the following commands to specify the starting count:
Set-AcctIdentityPool -IdentityPoolName "NAME" -StartCount VALUE
MCS – Memory Caching (XenApp/XenDesktop 7.9 and newer)
Memory caching in MCS is very similar to Memory caching in PvS. All writes are cached to memory instead of written to disk. With memory caching, some benchmarks show 95% reduction in IOPS. Here are some notes:
- You configure a size for the memory cache. If the memory cache is full, it overflows to a cache disk.
- Whatever memory is allocated to the MCS memory cache is no longer available for normal Windows operations, so make sure you increase the amount of memory assigned to each virtual machine.
- The overflow disk (temporary data disk) can be stored on shared storage, or on storage local to each hypervisor host. Since memory caching dramatically reduces IOPS, there shouldn’t be any problem placing these overflow disks on shared storage. If you put the overflow disks on hypervisor local disks then you won’t be able to vMotion the machines.
- The overflow disk is uninitialized and unformatted. Don’t touch it. Don’t format it.
- For a good overview of the feature, see Citrix Blog Post Introducing MCS Storage Optimization 💡
- Andrew Morgan Everything you need to know about the new Citrix MCS IO acceleration details the performance counters that show memory cache and disk cache usage.
Memory caching requirements:
- XenApp/XenDesktop 7.9, VDA 7.9, and newer
- Random Catalogs only (no dedicated Catalogs)
Studio needs to be configured to place the temporary overflow disks on a datastore. You can configure this datastore when creating a new Hosting Resource, or you can edit an existing Hosting Resource.
To create a new Hosting Resource:
- In Studio, go to Configuration > Hosting, and click the link to Add Connection and Resources.
- In the Storage Management page, select shared storage.
- You can optionally select Optimize temporary data on local storage, but this might prevent vMotion. The temporary data disk is only accessed if the memory cache is full, so placing the temporary disks on shared storage shouldn’t be a concern.
- Select a shared datastore for each type of disk.
Or you can edit an existing Hosting Resource:
- In Studio, go to Configuration > Hosting, right-click an existing resource, and click Edit Storage.
- On the Temporary Storage page, select a shared datastore for the temporary overflow disks.
Memory caching is enabled when creating a new Catalog. You can’t enable it on existing Catalogs. Also, no AppDisks.
- For virtual desktops, in the Desktop Experience page, select random.
- Master Image VDA must be 7.9 or newer.
- In the Virtual Machines page, allocate some memory to the cache. For virtual desktops, 256 MB is typical. For RDSH, 4096 MB is typical. More memory = less IOPS.
- Whatever you enter for cache memory, also add it to the Total memory on each machine.
- Once the machines are created, add them to a Delivery Group like normal.
- The temporary overflow disk is not initialized or formatted. From Martin Rowan at discussions.citrix.com: “Don’t format it, the raw disk is what MCS caching uses.”
MCS – Image Prep
From Citrix Discussions: When a Machine Creation Services catalog is created or updated, a snapshot of the master image is copied to each LUN. This Replica is then powered on and a few tasks are performed like KMS rearm and Personal vDisk enabling.
From Citrix Blog Post Machine Creation Service: Image Preparation Overview and Fault-Finding: here are some PowerShell commands to control what Image Prep does: (run
asnp citrix.* first)
Set-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps -Value EnableDHCP
Set-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps -Value OsRearm
Set-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps -Value OfficeRearm
Set-ProvServiceConfigurationData -Name ImageManagementPrep_DoImagePreparation -Value $false
If multiple excluded steps, separate them by commands:
To remove the excluded steps, run
Remove-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps
From Mark Syms at Citrix Discussions: You can add one (or both) of the following MultiSZ registry values
The values are expected to be an executable or script (PoSh or bat), returning 0 on success
Citrix CTX140734 Error: “Preparation of the Master VM Image failed” when Creating MCS Catalog in XenApp or XenDesktop: To troubleshoot image prep failures, do the following:
- In PowerShell on a Controller, run:
asnp citrix.* Set-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown -Value $True
- On the master image, set the DWORD registry value HKLM\Software\Citrix\MachineIdentityServiceAgent\LOGGING to 1
- If you now attempt catalog creation, an extra VM will be started; log into this VM (via the hypervisor console, it has no network access) and see if anything is obviously wrong (e.g. it’s bluescreened or something like that!). If it hasn’t there should be two log files called “image-prep.log” and “PvsVmAgentLog.txt” created in c:\ – scan these for any errors.
- When you’ve finished doing all this debugging, remember to run:
Remove-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown
Delivery Groups in 7.8 and newer
In XenApp/XenDesktop 7.8, when creating a Delivery Group, there are new options for publishing applications and publishing desktops.
On the Applications page of the Create Delivery Group wizard, From start menu reads icons from a machine in the Delivery Group and lets you select them. Manually lets you enter file path and other details manually. These are the same as in prior releases.
Existing is the new option. This lets you easily publish applications across multiple Delivery Groups.
You can also go to the Applications node, edit an existing application, change to the Groups tab, and publish the existing app across additional Delivery Groups.
Once multiple Delivery Groups are selected, you can prioritize them by clicking the Edit Priority button.
On the Desktops page of the Create Delivery Group wizard, you can now publish multiple desktops from a single Delivery Group. Each desktop can be named differently. And you can restrict access to the published desktop.
There doesn’t seem to be any way to publish a Desktop across multiple Delivery Groups.
It’s still not possible to publish apps and desktops across a subset of machines in a Delivery Group. But the new method of publishing apps across multiple Delivery Groups should make it easier to split your machines into multiple Delivery Groups.
RDSH Scheduled Restart
- Once an RDSH Delivery Group is created, you can right-click it and click Edit Delivery Group.
- The Restart Schedule page lets you schedule a restart of the session hosts.
- XenApp 7.7 and newer lets you send multiple notifications.
Or use a reboot script:
- Shaun Ritchie – XenDesktop 7 Rolling Reboot Script
- Dane Young – Citrix Chained Reboot Scripts, now supporting XenApp 5, 6, 6.5 and XenDesktop 7.0, 7.1, 7.5, and 7.6!
- Citrix Blog Post – XenApp 7.x Reboot Schedules
- Citrix Blog Post – XenApp & XenDesktop 7.x Server OS VDA Staggered Reboot Framework v2 💡
- Citrix Blog Post – XenApp and XenDesktop 7.x Server OS VDA Staggered Reboot
From Configure session roaming at docs.citrix.com: By default, users can only have one session. On XenApp 7.6 (experimental support) and XenApp 7.7+ (full support), you can configure SessionReconnection setting available via PowerShell. On any Server OS delivery group, run:
Set-BrokerEntitlementPolicyRule <Delivery Group Name> ‑SessionReconnection <Value>
Where <Value> can be:
- Always – This is the default and matches the behavior of a VDI session. Sessions always roam, regardless of client device.
- DisconnectedOnly – This reverts back to the XenApp 6.x and earlier behavior. Sessions may be roamed between client devices by first disconnecting them (or using Workspace Control) to explicitly roam them. However, active sessions are not stolen from another client device, and a new session is launched instead.
- SameEndpointOnly – This matches the behavior of the “ReconnectSame” registry setting in XenApp 6.x. Each user will get a unique session for each client device they use, and roaming between clients is completely disabled.
This will change the roaming behavior for desktop sessions. For app sessions, use:
Set-BrokerAppEntitlementPolicyRule <Delivery Group Name> ‑SessionReconnection <Value>
Static Catalog – Export/Import Machine Assignments
It is sometimes useful (e.g. DR) to export machine assignments from one Catalog/Delivery Group and import to another.
From Adil Dean at Exporting Dededicated VDI machine names and user names from catalog in Xendesktop 7.x at discussions.citrix.com:
Hopefully this is what you are after, it turns out you don’t actually need PowerShell as the functionality is built into the tool.
- In Studio, click Delivery Groups on the lefthand menu
- Right click Edit delivery group
- Select Machine allocation tab on the left
- Click Export list
- Select a file name > Click Save
- Create the new machine catalog
- Right click the delivery group > Click Edit
- Select Machine allocation tab on the left
- Click Import list..
- Select the list you exported in step 4
- Click Apply
Your clients will now have users re-assigned to machines.
Monitor the Number of Free Desktops
Sacha Thomet wrote a script at victim of a good reputation – Low free pooled XenDesktops that polls Director to determine the number of free desktops in a Delivery Group. If lower than the threshold, an email is sent.