This is part 2 of my blog post series about new application and desktop publishing. Part 1 explained how the application publishing works, part 2 will focus on desktop publishing.
Why do we need this?
XenApp 7.12 has been an exciting release — it has closed all the important gaps from the older IMA architecture and, with a lot of new XenApp 7.x features (MCS-based single image management for XenApp Enterprise customers being my favorite), I don’t really see a reason for anyone to stay on the old XenApp 6.5 anymore. Don’t agree? Let us know in the comments after you finish reading this blog post.
In my opinion, the most important feature that XenApp 7.x was missing at launch was the ability to assign applications and desktops to specific servers. Granular assignments are nice to have during the early stages of implementation (design, pilot or build phase), but they are a critical feature for daily support and operations.
When you are responsible for Citrix environment support and receive a complaint from a user, one of the first steps you take is to log on to the server where the user is experiencing the issue. In the previous versions of XenApp, you can create separate desktop icons for all XenApp servers to easily logon to any server you needed. In XenApp 7, most customers have achieved this by publishing the RDP client, but this method is not always the most effective; not only are you losing the benefits of using an HDX protocol, but also this method is only partially usable for troubleshooting, as RDP session can behave differently than HDX session.
In XenApp 7.12, we’ve added an ability to publish desktops for restricted set of machines. This allows you to simply create as many desktop icons as you want and assign them to any servers that you want.
Tag Restrictions
Compared to application publishing discussed in my previous blog post, desktop publishing is much simpler. You create a tag, assign it to a machine or machines, create a published desktop and filter it using a specific tag.
To quickly summarize what you’re seeing in the diagram above:
- Desktop(s) are created in Delivery Group
- Desktop(s) are filtered using tag
- Tag is applied to servers
Each desktop supports only a single filtering tag to avoid a situation where complex publishing could slow down the enumeration process. However, servers can have multiple tags assigned to them. It is common to have one desktop that is load balanced across all servers and have one desktop for each of the machines.
Fig 1: Desktops created for each of the XenApp workers
How to implement this feature
Instead of writing few pages of instructions, I’ve decided to create a short video where I’ll show you the implementation details of publishing.
https://youtu.be/e8rL7i5xCH0
Script to create desktop icon for each XenApp server
You can have environment with hundreds or even thousands of XenApp servers. In such environments, it’s not very practical to manually create all icons and you might want to automate the process. It is also not very practical to publish desktops ad-hoc, because you should try to minimize the time to resolve the problem and not waste it by publishing of a new desktop. That is why I have created a script: XA-CreateDesktopsForVDAs.ps1. This script will automatically create a direct desktop icon for each of your XenApp servers.
What this script is doing:
- Load all delivery group that contains XenApp servers
- Load all machines that doesn’t have published desktop assigned to it
- Create new tag for each machine (“ServerTag_<MachineName>”)
- Create new desktop for each machine (“MachineName”)
- Configure the desktop to point to single machine only
Usage is very simple – simply run the script with following options:
- DesktopGroupName (default *) – if you want to specify only a single delivery group, configure it here.
- UserGroups (array) – all accounts that should have access to published desktops.
For example:
XA-CreateDesktopsForVDAs.ps1 -DesktopGroupName “DG-RDS-Main” -UserGroups “CDZ\CTX_RES_Admins”
If you add more machines to your delivery group, simply run the script again – it will detect these new machines only and generate desktops for them.
Summary
- With tag filtering, you can assign applications and desktops to specific servers
- Application needs to be a member of App Group
- App Group needs to be assigned to Delivery Group
- Tag is applied to App Group. AG can have only a single tag filter.
- Tag is applied to server within a Delivery Group. Server can have multiple tags.
I would also like to thank Paul Morey and Doug Paterson for their support and ideas. It’s easy to write blog posts like this if you have a superstar team to support you.
Do you find this blog post, video or script useful? Make sure to leave a comment; it’s always appreciated.
As always, standard disclaimer applies here (download the script here):
“This software application is provided to you “as is” with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.”
Martin Zugec Follow @martinzugec
