The most common request we get for Power and Capacity Manager is the support for other power management APIs... With XenApp 5.0 Feature Pack 2, we only support Wake-on-LAN and XenServer API. We will extend this list in upcoming versions.

In the meanwhile, your only option is to use WMI events to trigger power-on commands to your computer management infrastructure.

I've tested the following using Powershell V2. The script has to run in the Concentrator:

Register-WmiEvent -Namespace "ROOT\Citrix\XenAppPCM" -SourceIdentifier "PowerEventAction" -Query "Select * from __InstanceModificationEvent within 10 where TargetInstance ISA 'Server' and TargetInstance.PowerActionState=4" -Action {
   $servers = Get-WMIObject -Namespace "ROOT\Citrix\XenAppPCM" -Query "Select * from Server Where PowerActionState=4"
   foreach ($s in $servers)
   {
     #Launch power action command to the server management infrastructure here
     Write-Host $("Server: " + $s.Name + " MAC: " + $s.MacAddress)
   }
}

PCM classes in WMI are registered under ROOT\Citrix\XenAppPCM namespace. The script above registers a listener that triggers when PCM changes a server "PowerActionState" attribute to 4 – this state indicates PCM needs additional capacity for a workload.

Another interesting event in PCM WMI is "NotEnoughCapacityEvent". This event triggers when all servers in the workload are on-line, but policies would require additional servers to become on-line. You could use this to trigger provisioning of additional servers in that workload.

PCM WMI classes are pretty feature rich. In fact, all console operations issue WMI operations under the covers. You can find the MOF files after installing the Concentrator, at %WINDIR%\System32\WBEM\PCMConcentrator_v2.0.50727.mof and %WINDIR%\System32\WBEM\Framework\root\Citrix\XenAppPCM\PCMConcentrator_SNVersion_1.0.2.0.mof

You may also take a look at the Powershell WMI Explorer from thepowershellguy.com (link), it's a pretty decent WMI browser using nothing but Powershell!

Yesterday I've posted Part 1 of this series, talking about Capacity Estimation. Today I will describe the Power Management schedule policies. PCM use these policies to determine how many servers should be powered down, how sessions will consolidate or spread among the online servers, and when to power on additional servers to handle unexpected load.

The load policies for a workload vary during the day - you need more capacity during working hours than over the weekend. PCM configurations are entered over a weekly table period. Each entry has a start time four settings described below.

You will find this configuration on the PCM console. Select any workload, and then the "Schedule" tab. Each entry configures the following policies:

Minimum session capacity (Min Capacity): specify how many sessions, connected or not, should be on-line. The minimum session capacity is probably the easiest policy to understand and define. It describes the typical session utilization of that workload over time. For example, if you expect 1000 users connected to a workload during the day, and 250 over night, you will configure Min Capacity to 1000 from 8 to 5, and 250 from 5 to 8. It's that simple.

PCM will start as many servers as needed to support the Min Capacity policy. Servers are selected randomly, although you may control the selection order using the server tiers - I will cover tiers in more details at another post.

The session capacity is the sum of the estimated capacity of each online server in that workload. See Part 1 for in-depth description of load estimation.

Min Capacity is ignored if "Power Management" is disabled for that workload.

Minimum available servers (Min Servers): specify how many servers will handle logon requests. At first glance this seems similar to Minimum session capacity, but there's more to it.
PCM works its magic by setting the IMA load index to 20,000 value, indicating to IMA load balancer that the server is not available to take additional sessions. In the PCM console, you can see each servers selection state - select a workload and the "Servers" tab. At the left side of the "Sessions" column, you will find a small icon that can be:

• Circle: Load consolidation has disabled logons on this server. The IMA load index is set to 20,000.
• Green Triangle: Load consolidation has enabled logons on this server. The IMA load index is calculated based on the Load Evaluator.
• Yellow Triangle: Load consolidation has enabled logons on this server, but the load is higher than the optimal load. The IMA load index is still calculated based on the Load Evaluator.

The Min Servers policy defines how many servers with "green triangles" you will see in that workload - servers with enabled logons and under the optimal load. In the picture, I have Min Servers set to 1. Server 1 is draining, Server 2 is accepting logons, and Server 3 is above the optimal load (of 70%).

The value of this parameter should be related to expected user logon concurrency. If you set this value too low, then a small number of servers have to process too many logon requests, increasing the average logon time. If you set Min Servers too high, then sessions will spread to too many servers.

As a rule of thumb, you should set Min Servers to a higher number just before a shift starts - say, at 7:00AM - and reduce it after the logon peak has passed.

But how should I estimate this value? Well, you may start with a conservative high number and work your way back until user logons are impacted. Edgesight is a terrific way to get this data. Another way is to calculate the expected concurrent logons per server, based on peak logon rate and the logon time. For example, if average logon time is 30 seconds, and peak logon rate is 2 users/second, you should expect 15 concurrent logons if Min Servers is set to 1 (30 seconds/logon divided by 2 users/second). If you want to limit servers to process at most 5 concurrent logons, you will need Min Servers set to 3.

Min Servers policy is ignored if you disable load consolidation in the workload.

Online session reserve (Session Reserve): specify how many sessions should be available at on-line servers. Available sessions are calculated as "Session Capacity" minus connected sessions. For example, if a server has session capacity of 100 and 30 sessions, available sessions would be estimated as 70.

PCM counts all server sessions, including console and disconnected sessions.

Session reserve is used to create a buffer of available sessions for unexpected session influx. Servers take a while to boot, therefore you need to start powering on servers before the workload is fully loaded.

When the session reserve policy is violated, PCM will start sufficient number of servers to bring the policy back to compliancy.

Session Reserve can be estimated based on server power on time, and the maximum unexpected connections influx you have to support via SLA. For example, let's say your servers take 5 minutes to power on, and your DR strategy requires the workload to take up to 60 users/minute if a site fails. Your session reserve has to be set to 300 - the expected number of sessions before the 1st offline server can become available.

In the example above, PCM may issue additional power-on commands before the 1st server comes online. Let's say each offline server can take 100 sessions. When the number of available session falls under 300, the 1st server is started. If connections continue to come in, and available sessions fall under 200, the 2nd server is started, since the 1st server alone wouldn't be sufficient to get the session reserve policy back into compliancy.

Online session reserve is ignored if you disable power management in the workload.

Maximum session capacity (Max Capacity): specify a high water mark for capacity in the workload. This is an advanced setting, most workloads won't have to bother (default is "infinite"). This is used if you want to specify a session reserve, but stop adding servers after a certain point.

For example, assume your servers have session capacity of 100. A workload has 400 sessions at peak utilization. You have an SLA to support up to 600 sessions during DR events. You also have 7 servers assigned to this workload, but you can only power on 6 at a time due to power constraints - the 7th is there in case any other breaks. In this case, you may define Maximum session capacity as 600. Even if the session load gets above 500 (breaching the Session Reserve policy) PCM will not start the 7th server as it would violate the maximum capacity policy.

OK, that completes the PCM weekly schedule policy configuration. Next, in Part 3, I will talk about sites, tiers, and computer managers.

Power and Capacity Manager (PCM) is a feature of XenApp 5.0 Feature Pack 2. In this multi-part post, I will deep-dive on PCM configuration and trade-offs. I will assume you have basic understanding of the feature, please look here for an introduction.

To use Power and Capacity effectively, you will have to define the power management and load characteristics of your workloads. You have to strike a balance: if you are too aggressive, you may overload servers or cause connection failures. If you are too conservative, you will limit the manageability gain and power cost savings.

All PCM policies are defined per "workload". A workload is a group of computers that publish the same set of applications. You configure the PCM workload name during the agent installation, and you can modify it editing HKLM:\SOFTWARE\Policies\Citrix\XenAppPCM\WorkloadName

There are two important set of configurations in PCM: the Session Capacity estimation and the Weekly power management schedule. I will describe Capacity Estimation in this post, and the Weekly Power Management schedule in Part 2.

PCM policies are based on "Session Capacity" of each server and workload - i.e., how many sessions each server in a workload can host. The most basic concept in PCM is "Load Consolidation": instead of spreading sessions to all servers in the workload we load a few servers up to an "optimal load". Optimal load is defined as a percentage of the server session capacity, so we must estimate the later accurately. Also, most PCM policies reference "session buffers" and "available sessions", both require server capacity estimation.

Our first attempt was to use the server Load Evaluators to estimate capacity. XenApp uses load evaluators to determine which server will process a connection request. The Load Index varies from 0 (no load) to 10,000 (maximum), so couldn't we use the load index (divided by 100) as load percentage? Not really. A server with 50 sessions and a load index of 5,000 won't necessarily behave well with 100 sessions. The key problem is that load index is only used to find the least loaded server, and the session capacity is irrelevant most of the time. Therefore most XA environments stick to the Default Load evaluator (cap at 100 sessions), even though the servers never host more than 30-40 sessions.

We felt that overloading the load evaluator to estimate capacity was dangerous. We wanted a "soft" estimation, that wouldn't cause problems if it was underestimated. Therefore PCM defines a new configuration called "Typical Session Capacity", which tells PCM how many sessions to expect for a particular hardware specification.

In the PCM console, select a workload, then the "Capacities" tab. Over there you will see one row per hardware specification - for example, in my XenServer setup I see "VM: Intel Xeon E5345 @ 2.33 GHz, 1 core, 512 MB". Select the hardware spec, then "Server Profile Properties..." in the actions pane.

You should configure the typical load as the number of sessions you know a server can host without impacting user performance. PCM will force IMA to load a few servers up to an optimal load, so this number has direct impact on how much sessions will consolidate. The safest way to estimate this value is to start with the session high-water mark on your existing servers, and work your way up if you believe the server can handle more.

As an example, let's say you define typical load at 50 sessions. If you left the default optimal load configuration (70%), PCM will load servers up to 35 sessions before enabling other servers. Once all servers reach the optimal load, the load balance will behave as before - finding the least loaded server. Therefore, there's little risk in underestimating the typical load - at worst you will be back to pre-PCM load balancing!

OK, but what happens if the IMA load index gets to 10,000 before the server hit the optimal load? Good question! PCM constantly adjust the server capacity based on the IMA load index. For this dynamic estimation, we assume the load index is linear: each session contribute the same way to the index, and that new sessions will continue to do so - i.e, capacity = 10,000 * Current Sessions / IMA Load Index . PCM then use the smallest of the static and dynamic estimations. In the example above, if IMA load index was 5,000 with 10 sessions, PCM would reduce the capacity estimation to 20.

We have also exposed an advanced configuration if you want to use the IMA load index as the primary method to determine server load. This requires a more careful construction of the load evaluator - you have to adjust it so that the load index grows smoothly from 0 to 10,000. You would use this method if the session capacity varies too much - say, it's usually 100, but sometimes it can go up to 150. You would be wasting the last 50 sessions using the previous approach.

To model such load pattern, go to the "Server Profile Properties" and select the "Advanced" checkbox. Enter the "Estimated Session capacity limit" - it would be 150 in this example. Now PCM will use the Typical session capacity only when the server is off-line or with zero sessions. Otherwise, it will use the IMA load index and the "estimated session capacity limit".

Why not set the typical session capacity to 150 in the example above? Well, if most of the time servers get loaded at 100, then PCM will over-estimate the server capacity when servers are offline. This will cause some grief during unexpected load events, when servers must be powered on to cover unexpected incoming sessions. So keep the "typical" value to what is the norm, and use the "estimated limit" to get an extra mile adjusting load evaluators.

Stay tuned for Part 2, with a deep-dive on the PCM power management schedule!

 Update: Part 2 (Policies) posted here.

Learn more about Citrix XenApp 5 Feature Pack 2

• Official Press Release - http://citrix.com/English/NE/news/news.asp?newsID=1857726
• XenApp 5 Feature Pack 2 release Web Site - http://citrix.com/xenapp/featurepack2
• XenApp 5 Feature Pack 2 Executive Video - http://citrix.com/xenapp/fp2/video
• XenApp Expert Series videos for this release - http://citrix.com/xenapp/fp2/expertseries
• XenApp 5 Feature Pack 2 Blogs- http://community.citrix.com/blogs/tag/xa5fp2
• Download XenApp technology previews - http://citrix.com/xenapp/techpreviews
• XenApp Product Page - http://citrix.com/xenapp/

Follow XenApp on | | |

We've recently announced a cool new feature for XenApp, called Power and Capacity Management (PCM). Here's a video demonstrating PCM in action:

Architectural Overview

Power and Capacity Management uses an agent/manager architecture. The agent is installed at all XenApp servers you wish to power manage. The manager - called the Concentrator - is responsible for monitoring, storing data, and issuing power operations to the agents. The Tech Preview doesn't have high-availability implemented yet, so you should install only one concentrator. In the final version you can have multiple concentrators to enable high availability. Another thing to note is that we've decided to implement Power and Capacity Management outside of XenApp IMA (Independent Management Architecture) partially because we wanted PCM to manage multiple XenApp farms. You can install the PCM concentrator alongside your Data Collectors if you only want to manage a single farm.

Installation and Communications

During agent installation, you will be asked for a farm and workload name. The concentrator manages a single Power and Capacity Management farm - note that this is not the XenApp IMA farm name, it's just a namespace for PCM. This setting is stored at HKLM:/Software/Policies/Citrix/XenAppPCM, which is good if you want to install the agent using dummy data and then use an ADM/X file and Group Policies to manage this setting across multiple XenApp servers later on. We plan on integrating this configuration into the XenApp configuration interface and SDK's as well.

The other configuration setting for the agent is the workload name. This represents a server silo or group. All configuration for Power and Capacity Management is related to a workload, so you want to make sure all XenApp servers in the same workload have similar or even identical configuration. You can also define tiers of servers within a workload, telling PCM which servers should be powered on first, and which ones to power on only when necessary.

Once you install the agent on your target XenApp server(s), it will register with the concentrator and its defined workload group will automatically appear in the PCM console. This is possible because the concentrator creates a Service Connection Point (SCP) under the computer Active Directory (AD) account during installation. This is done using the computer network account, so no special AD authority is required. The agent queries AD for these SCP to find the its concentrators. Since all PCM communications are Windows Communication Foundation (WCF)-based, all power-managed XenApp servers computers must be in the same domain as the concentrator that is controlling the farm they are joined to.

Configuration

Before Power and Capacity Management can manage the servers you've added to the workload, you need to enter the server capacity and policy schedule. The server capacity is related to the Load Evaluator, but they don't have to be the same. You will enter how many sessions are expected for each "hardware specification" in the workload. The hardware specification is automatically displayed when the agent registers, you just have to enter the capacity value. This setting is used to calculate the "session buffer", i.e., how many new sessions are currently available on the workload. If you under-estimate this number, then PCM will start more servers than necessary. If you over-estimate this number, PCM may not realize that the workload is running out of capacity. The Tech Preview version requires this manual configuration, at product release we plan to introduce some automatic adjustments to simplify this configuration.

The last piece of configuration is to define a policy schedule. You will enter the policy configuration and how it will vary during the day and throughout the week. The policy defines the minimum number of servers that must be online and how many spare sessions to maintain. Spare sessions are calculated as the difference of the workload server capacity and the number of connected sessions. Spare sessions are a buffer of capacity. The higher the number, the more idle capacity you will have on your servers. this is good when you have a very active user base or during times when many users login very rapidly. The lower the number the less idle capacity you will have. Setting the number too low may result in reduced performance or response while users wait for additional capacity to power on.

That's it! Now select the workload and "Enable Power Management" and PCM will start enforcing the policy schedule. You might notice that some servers power down immediately. That is normal operation if the current policy settings require less capacity than what is currently powered on.

Stay tuned for more posts from me on Power and Capacity Management. In the coming days and weeks, I'll go in depth on more advanced features like load consolidation, SDK's and some interesting possibilities that are afforded to us and that we are considering developing with PCM.

Download the technology preview of power and capacity management at the XenApp Technology Preview Center. Also, stay updated by following XenApp on Twitter.

Follow me on Twitter: http://www.twitter.com/jmaldaner

In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time. 
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.

However, creating a new farm from scratch is not realistic in many environments. The reasons:

• Farm configuration documents may not exist, or be out-dated.
• Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
• The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.

We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:

• The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
• The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
• If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
• You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
• Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.

At this point, you will have a fully configured, although empty new farm. Over time, you will:

• Add more users to the new farm filter
• Remove servers from the old farm
• Upgrade XenApp software in the server (or re-image)
• Assign the server to the new farm Organizational Unit.

This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.

This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.

Hello, this is my first post in this community, so let me start with a brief introduction: my name is Juliano Maldaner, a product architect on the Presentation Server team. One of the areas I'm working on is the simplification of Presentation Server management experience for upcoming releases. We're introducing some exciting new concepts and would like to hear your feedback!

Managing a Presentation Server farm requires much more than configuring Presentation Server components: Operating System and Application settings are as important. A successful environment must maintain PS, Operating System, and Application settings correctly configured and consistent across all servers in the farm. Maintaining this consistency throughout the farm life cycle is one of the major challenges for PS Administrators.

The Windows platform provides an outstanding tool to address these configuration management challenges: Active Directory and Group Policy. An overwhelming majority of PS deployments use Group Policy in some capacity. Integrating PS settings into GPO is possible with MFCOM scripts, but far from ideal. Most use GPO for Windows and Application settings, and Citrix management consoles for PS configuration. Because all settings must be synchronized, we realized that the management experience would be greatly simplified if PS Session Policies and Server settings were within Group Policy Objects themselves!

Presentation Server settings/policies embedded into Group Policy Editor

The main benefit of this integration is the creation a single management template for platform, applications and Citrix configuration. All operations performed with Group Policy Management Console will include Presentation Server parameters as well. Resulting Set of Policy reports will show all Citrix and platform configuration - a great help for troubleshooting and planning. Backup, Restore, and Migration will allow saving and moving configurations from farm to farm, making replication of environments much easier than what it is today.

Another key benefit is the separation of PS settings and servers. Group Policy Objects are associated with Organization Units, and not with individual servers or users. Common management operations - adding capacity to a silo; repurposing a server; or replacing a broken server - are greatly simplified: simply change the server OU membership, and the settings associated with that silo will automatically apply to the server.

Application Publishing 

The Group Policy integration will NOT require Active Directory schema changes. For this reason, PS objects such as Applications and Administrators will continue to be managed via Citrix management consoles. Application Publishing will be modified to allow association of Applications with Active Directory Server Groups and Organization Units. This way, apps will be automatically published as soon as the server is assigned to the correct Organizational Unit.

Policy Filters 

Presentation Server Group Policy extension will improve GPO filtering capabilities to include all filters existing on CPS 4.5 session policies - including SmartAccess. These filters will only apply to the Citrix part of the GPO, platform configuration will apply regardless of the filter result.

The Citrix policies within GPOs will also allow filtering on a per-setting level - native Group Policy only allow filtering per-policy level. Some Presentation Server features require complex filtered settings, for example: proximity printing based on client IP address. This feature will allow the configuration of such policies within a single GPO.

What about environments without Group Policy? 

There are some important scenarios where Group Policies cannot be used:

• Environments using other Directory services;
• Applications that require anonymous (local) accounts;
• Organizations that restrict or deny AD delegation to PS administrators.

To support these environments, IMA will provide a global Group Policy Object, applied to all servers in the farm. This farm-wide GPO replicates the existing Farm Default settings. Per-server override is possible by configuring the server's Local Group Policy Object.

Our goal is to maintain feature parity with PS 4.5 if Group Policy is not used. However, the Administrator's experience will be optimized for Active Directory and GPO scenarios.

Active Directory and Group Policy are fundamental for a successful Presentation Server environment. Group Policy integration will bring major improvements to management experience, leveraging existing IT infrastructure and knowledge. The feedback we've received so far has been very positive, please let us know what you think!