Virtual Apps and Desktop Servers (VDAs) with Power State Unknown are considered by the broker for session brokering, albeit at a lower priority than VDAs with known power states. In a deployment with VDAs in both known and unknown power states – the Broker will prefer VDAs in the following order: 
1.    VDAs in power state ON 
2.    VDAs in power state OFF 
3.    VDAs in unknown power state 

In #1 above, controllers broker sessions to the VDAs with power state ON until all these VDAs reach their maximum capacity (100% / full load based on configured Citrix Load Management Policies).  Once the VDAs with power state ON are at full load, the controllers will begin to broker to VDAs with other power states.

 In #2 above, in a power managed environment where there are VDAs in a power state OFF (More information on Power Managed machines found here), the controllers will begin to power on these VDAs next (#2 above) and broker connections to them until they reach full load.  If the environment is not power managed, #2 is skipped. 

In #3 above, controllers will begin to broker to VDAs that are in power state Unknown.  

If a deployment is frequently observing VDAs with unknown power states, setting up aggressive load management policies can potentially speed up the inclusion of such VDAs for session launches. 

Related Best Practice:
It is critical that the administrator performs performance and scalability testing on the Virtual Apps and Desktops site and configures the appropriate Load Management Policies based on that testing.

Default Load Management policies are applied to all Server OS delivery groups. The default settings specify the maximum number of sessions a server can host at 250 and do not consider CPU and Memory usage. Capping session count does not provide a true indication of load, which can lead to an overburdening of Server OS delivery groups resulting in a degradation of performance or an underutilization of Server OS delivery groups resulting in an inefficient usage of resources.

Citrix Consulting recommends creating unique “custom” Load Management policies for each Delivery Group based on performance and scalability testing. Different rules and thresholds can be applied to each Delivery Group depending on the different resource bottlenecks identified during testing. For more information on the available Load Management policy configurations refer to Citrix Docs – Load Management policy settings .

Example Scenario with a Basic Load Management Policy:
A Virtual Apps and Desktops environment hosts one critical application.  Performance and scalability testing has shown that when the VDA’s CPU exceeds 60% average utilization, this critical application begins to exhibit performance degradation resulting in an impact to user productivity.  Testing has also shown that the performance of this application is not affected by other resource limitations such as disk and memory usage.  Implement a Load Management Policy based on CPU load where the server will be considered at full load when the CPU reaches 61% average utilization.  Create the policy and apply the policy to the Virtual Apps and Desktop servers hosting your critical application.

Refer to Citrix documentation for guidance on creating policies . 

This example policy should appear as shown in the screenshot below:


Expected Result:
Once the average CPU utilization on these VDAs reaches 61%, the VDAs will be considered at full load and the controllers will begin to attempt to power on VDAs that are off (in a power-managed environment) and broker connections to those servers.  If those VDAs that were recently powered up also reach full load, the controllers will then begin to broker new sessions to VDAs that are in an unknown power state.
Note:  In the screenshot of the example policy, there is a “Related settings” section.  This section references other settings that can be configured and enabled into a more comprehensive Load Management Policy.  Be aware that if any of these other settings are combined with the CPU setting in the example, the VDA may be considered to be fully loaded before the CPU reaches 61% average CPU utilization.  For example, if “maximum number of sessions” is set to “10,” the server will be considered fully loaded when the 10th user is logged in to the server despite the fact that the CPU might only be at 30%.  If you want 61% to represent a full load, ensure the other options in “related settings” are not enabled with the CPU setting.