The XenApp 6 PowerShell SDK has been released! Download at: http://community.citrix.com/display/xa/XenApp+6+PowerShell+SDK

XenApp 6 is a major platform change that brings a lot of configuration flexibility to XenApp. Those used to XenApp 5 or prior will find that the way in which things are configured has changed dramatically in order to accommodate that flexibility.  In a series of blogs, I’ll cover the changes that we’ve made to our public SDKs and SDK strategy for XenApp as part of this new platform.

To start off, it will be helpful to explain the fundamental shift in the platform that occurred between XenApp 5 and XenApp 6.  In XenApp 5 and previous versions, all XenApp settings were stored in the farm configuration database, as part of our Independent Management Architecture (IMA). Farm and server settings were stored and configured independently, and for the most part there was a two-level hierarchy of configuration.  By that I mean that you could set a setting at the farm level, or at a single server level, but no other granularity was allowed.  Additionally, setting changes took effect instantaneously; when a setting was changed, affected servers immediately adopted the new setting.

Starting in XenApp 6, farm and server settings are now stored in computer policies.  This allows very flexible, hierarchical configuration. It also enables Active Directory administrators to set policies across their existing AD management scopes that affect Citrix servers within that scope.  Finally, it allows settings to be configured that affect multiple Citrix products at once.  For instance, an organization can now set a Citrix license server in an Active Directory GPO and apply it at a site level; then all Citrix farms within the site, whether they are XenApp or XenDesktop, will automatically inherit the license server setting without any further steps required.  In addition, the user policies that used to be confined to the XenApp Advanced Configuration console have also been moved into Active Directory policies so that they can also apply to multiple products and to multiple farms.

Another improvement in management flexibility comes from the new Worker Groups feature.  Whereas in the past you would associate applications directly with individual servers in the farm, now you can associate applications with Worker Groups.  This is a huge improvement in the application virtualization model because it means that changing the user capacity of an application or a group of applications only requires changing the number of servers that are within a Worker Group. Since the Worker Groups themselves are associated with Active Directory OUs, and the farm and server settings are also associated with Active Directory OUs, this means that bringing up a new machine and placing it into an OU automatically sets the XenApp settings and publishes the appropriate applications on that machine.

The tradeoff with Active Directory configuration is that setting changes are not immediate.  It may take up to an hour or more for a setting change to be adopted by any individual server, although you can force a change to be adopted more quickly by running the “gpupdate” command.

I should also make clear that we are fully committed to provide functional, flexible, and powerful configuration for administrators who do not wish to or cannot use Active Directory. To that end we provide policies within IMA that function the same as Active Directory policies, but with an implicit farm scope.  This “farm GPO” is available whether or not you use Active Directory so administrators can decide on an individual setting level whether they wish to configure the setting across AD management scopes, or within the farm policy scope.  Farm policies can be associated with worker groups, which can define arbitrary server groupings, so it is possible to create fully hierarchical configuration without at all requiring an Active Directory infrastructure.

Since settings are now so flexible, the SDK model that XenApp 5 and prior used is no longer possible to support.  In those past releases, you could simply “set” or “get” settings based on individual objects.  In the new management model, you “set” settings into a GPO or a filtered policy – never on an individual object.  You also cannot “get” settings in the same straightforward manner; rather, you can either get a policy report which shows you what settings were most recently applied as a result of policy hierarchy processing (gpupdate), or you can generate a policy modeling report which shows you the expected outcome the next time policy hierarchy is processed.

When we started working on XenApp 6 we soon realized that it would not be possible to support MFCOM in any meaningful way.  We analyzed the methods and objects that MFCOM exposed and found that almost nothing could remain functional in the same way it was in past releases.  We also analyzed the scripts that some of our internal administrators and customers used MFCOM for, and found that almost none could remain unchanged once we shifted to the new management model.  We knew that a new SDK, and a new SDK paradigm, would be required for the new platform.

Since a new SDK is a costly investment for customers, we wanted to make sure that the new SDK was future-proof, fully functional, very powerful, and easy to use.  Microsoft also introduced a mandate that all of their internal server products provide PowerShell configuration interfaces as part of their Common Engineering Criteria program.  We therefore settled on PowerShell as the basis of our new SDK. We tried to make sure that our SDK makes all of the most common tasks as simple as possible, and what we found in the end is that most of our scripts that used to be hundreds of lines of code can now be accomplished in a single line of PowerShell.  In addition the new SDK is simple enough to use that we expect it to move beyond the realm of programmers and gurus, and be usable by most or all Citrix administrators.  We built extensive help into the SDK to make it as easy as possible to pick up and use.

That SDK is available in XenApp 6 RTM.  You can access the SDK and use it immediately by running PowerShell and adding the Citrix snap-ins: Citrix.Common.Commands, Citrix.Common.GroupPolicy, and Citrix.XenApp.Commands.  However, if you wish to have additional documentation, better support for remote configuration, and better support for programmatic use of the SDK, you can download the XenApp 6.0 PowerShell SDK release from http://community.citrix.com/display/xa/XenApp+6+PowerShell+SDK. This package can be installed on a XenApp 6 server, or on any client machine that you wish to use the XenApp 6 SDK from.

As XenApp continues to mature, the SDK will continue to be enhanced as well.  We look forward to community feedback to refine our SDK and make it even better over time.

[Edit: fixed the links to the SDK download page]