XenApp PowerShell Scripting with Get-XASession

I was working on a PowerShell script in XenApp today to quickly view active sessions by user, server, application, and session duration. Having focused most of my PoSH time in recent years to the XenDesktop SDK, I was somewhat disappointed with the limited flexibility (and official documentation) of the XenApp SDK, specifically with the Get-XASession cmdlet.

My main complaint is that Get-XASession doesn’t have many ‘Required’ parameters, which means that queries are limited to a subset of session details:

Get-XASession

For example, if I want to find all sessions that are ‘Active’, I have to pipe the results of Get-XASession and evaluate each returned object. So, the following pipeline evaluation is required if you wanted to see all active sessions:

Get-XASession | Where-Object { $_.State -match 'Active'}

Using this as a foundation to find Active sessions, I took it a step further by using an input parameter (application name) to list sessions by application, and then formatted the output of the session details to get me what I’m looking for:

param ([String]$app)
foreach ($session in (Get-XASession | Where-Object { 
$_.BrowserName -match $app -and $_.State -match 'Active'} | 
select AccountName, ServerName, LogonTime, ConnectTime, CurrentTime, SessionID | 
Sort-Object LogonTime -Descending))
{
 $logon = (Get-Date) - $session.LogOnTime
 $connect = (Get-Date) - $session.ConnectTime
 "$($session.AccountName) logged on to $($session.ServerName) {0:00}:{1:00}:{2:00}" 
 -f $logon.Hours,$logon.Minutes,$logon.Seconds + " ago."
}

This script returns a active sessions by user name, connected to $app, the server on which it’s running, and the elapsed time (in ascending order) since they logged on (just subtract the $_.LogonTime date/time object from Get-Date). Notice how the $session object is compiled of properties of the sorted Get-XASession output by way of piping the output through several filters, which lets you create your own objects that can be easily manipulated and cross-referenced in the script. I also did some date/time formatting with {0:00}:{1:00}:{2:00}” -f $logon.Hours,$logon.Minutes,$logon.Seconds, though you can present this time duration in any way that makes sense.

Well, I hope this was worth a quick read, have a good weekend!

Windows 8.1 DPI Scaling Causes ‘older’ Applications to be scaled/blurred

Since Windows 8.1 reached GA today, I loaded it up first thing this morning on my Ativ Book 7 to enjoy the much anticipated tweaks that make this Ultrabook even more ultra! However, once I got the update installed, I opened a few applications, including Chrome, and a XenDesktop 7 ICA session using Receiver for Windows and immediately noticed that these apps were blurrier than the desktop or Modern Apps.

As you can see in this screen clip, there’s a slight blur on the seamless ICA desktop (110%ish scaled), as is the CDViewer taskbar icon:

Image

I quickly found that Microsoft decided to enable dynamic display scaling on non DPI Aware programs for high-DPI displays. If you’re interested (like I was) to know more about why Microsoft made this decision in 8.1, you should check out this blog which goes into detail on the topic.

The short of it is that the ‘..additional scaling capability provides two distinct advantages for high-DPI displays on Windows 8.1:

  1. UI can scale larger which makes readability better and touch/mouse interactions easier.
  2. 200% scaling enables pixel-doubling for up-scaling which provides a clear and crisp appearance for images, graphics, and text.

Since the Ativ 7 crams a 1080p display into a 13.3″ panel, it falls under the category of a high DPI display at about 165 PPI. To change this behavior for a particular application, you have to adjust the executable’s compatibility settings to ‘Disable display scaling on high DPI settings':

Disable Display scaling on large DPI displays

Disable display scaling on high DPI settings

By doing this for CDViewer.exe, for example, I was able to get the ‘Desktop Viewer’ to launch in native DPI, which is blur free (and displayed in normal DPI). If I need to get a more readable/usable DPI, I can always adjust the same settings on the virtual desktop side:

sharp

This setting can be also be disabled via the registry by setting an AppCompatFlags\Layers Reg_SZ value named as the executable in question, with the string set to HIGHDPIAWARE (in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers):

UseDPIScaling

You can also disable DPI scaling for all applications on a particular display by checking the ‘Let me choose one scaling level for all my displays’ in the ‘Display’ control panel item, and setting the scaling ratio to 100% (Smaller):

The only caveat to this approach is that DPI scaling is also disabled for Explorer, so the taskbar and desktop will be small as well.

Thanks for the thought Microsoft, but please give us an option to do without this feature!

XenDesktop 7 Session Launch – Part 3, Brokering

In my last post I talked about the ways that the Citrix client/WI enumerates XenDesktop resources by way of NFuse transactions to the site’s XML broker. The XML broker is responsible for telling the StoreFront server which published resources were found for a particular user. For more technical detail on NFuse transactions, check out my XML Broker Health Check post which gives a good example of NFuse transactions by way of some pretty straightforward XML requests sent through PowerShell.

The next major piece of the session launch process is what’s known as Brokering. This process allows a user to click a desktop or app resource, and have a ‘worker’ selected and readied for an inbound ICA connection. XenDesktop 7’s brokering functionality is mostly unchanged from that of XenDesktop 5, the only main difference being that it now includes multi-user RDS workers.

Conceptually, this factor doesn’t change how the Citrix Connection Brokering Protocol works, it simply adds multi-user support for Windows RDS servers. This functionality has actually existed with limited capabilities since XenDesktop 5.6 for CSPs (Hosted Server VDI), so it’s certainly not a huge leap in terms of changes to the broker agent. The XenDesktop brokering process consists of several key components, including:

  • Citrix Desktop Service (CDS / VDA) – This component provides a bridge between the ‘Delivery Controller’ and the ‘Worker’ and is commonly referred to as the ‘Virtual Desktop Agent’ or VDA. In XD5 this was the WorkstationAgent.exe process, though in XD7 the process was renamed to BrokerAgent.exe. However, the directory still reflects the VDA designation, so I still like to refer to it as the VDA:

CDS

  • Citrix Broker Service – The Broker Service is responsible for negotiating session launch requests with ‘workers’. The Broker service communicates with the CDS over a protocol that Citrix refers to as CBP (connection brokering protocol) to validate a worker’s readiness to fulfill a session launch request, gather the necessary details (IP address or host name), and send the details back to the StoreFront site to be packaged and delivered as an .ICA launch file that’s consumed by the Receiver.
  • Connection Brokering Protocol – This protocol behaves much like NFuse, though it uses .NET WCF endpoints to exchange a series of contracts to communicate registration and session launch details between a worker and delivery controller. This protocol was designed with the following key requirements as it’s functionality is highly critical to reliably providing on-demand desktop sessions:
    • Efficient: information should be exchanged only if and when required (just in time). Limiting the data exchange to a minimum also reduces the risk of leaking sensitive data.
    • Versioned: It must be possible for both workers and controllers to evolve concurrently and out of step without breaking protocol syntax or semantics.
    • Scalable: The delivery controller is a key piece of infrastructure, and its performance must not be impacted by unprompted messages and data from workers, as can happen in IMA, for instance during “election storms”.
    • Flexible: the protocol should allow the architecture to evolve over time, by not building key assumptions into the protocol’s foundation code. Factoring independent operations into separate service interfaces is one example of how a protocol can allow for increasing controller differentiation in future.
    • Compliant: Standards-based mechanisms (WCF) are used instead of proprietary technologies (IMA).
    • Secure: Security is critical, and the protocol must support appropriate mechanisms to ensure confidentiality, integrity (WCF contracts), and authenticity (NTLM/Kerberos auth) of data exchanged between workers and controllers.

The XenDesktop brokering process makes the following basic assumptions about CDS workers:

  • Desktops are either Private or Shared
  • Each desktop is associated with a single delivery group
  • Each desktop is backed by a single worker
  • Each worker is individually associated with a hosting unit, with a null unit index value indicating an unmanaged worker (existing or physical catalog types)
  • Desktops within a private desktop group can have permanent user assignments. The association may comprise one or more users, or a single client IP address
  • Multiple desktops within a private desktop group may have the same user assignments
  • Desktops within a shared desktop group may temporarily be assigned to a single user for the duration of a session
  • Multiple desktops within a shared desktop group may be assigned to the same user concurrently
  • Automatic assign-on-first-use behavior involves the broker selecting a desktop within a private desktop group with no assignment, and assigning it to the currently requesting user; the desktop’s group will not change by virtue of user assignment
  • The assignment of a desktop to its assignee(s) in a private desktop group can only be undone by an administrative user through the PoSH SDK

In a nutshell, the Delivery Controller is responsible for negotiating session launch requests by locating and preparing workers to accept ICA sessions that were requested by a StoreFront server via the XML broker.

XD7brokering

The broker service finds a worker to fulfill the session request, powers it on if needed, waits for it to become ready if a power action was sent. Once the worker is ready, the DDC sends the requisite connection details to the StoreFront server to build and deliver the ICA file, which is sent to the Receiver for consumption by the ICA client.

Hopefully this was a decent enough explanation of brokering. While I didn’t get a chance to go into a lot of detail about how a worker is found, and how CBP interacts with the ICA stack, I think this at least gives a good high level overview of the concept to know what components are involved and what their general interactions with each other are.

My next part in this series will look at the ICA stack, and how a connection is established between ICA clients and servers.

XenDesktop 7 Session Launch – Part 2, Enumeration

In my last post I talked about how the Citrix Receiver authenticates to a StoreFront server. In this post, I want to talk about resource enumeration with Citrix Receiver <> StoreFront <> XenDesktop deployments.

Before I go into the technical aspects of the way Citrix enumerates published resources, I want to briefly explain the history behind the Citrix XML Broker, as well as how the Citrix client enumerates published resources. In case anyone is interested in a broader history of Citrix, I encourage you to check out the 20 years of Citrix History publication that was published in 2009.

Citrix NFuse and the XML Portal Server

Back in 2000, Citrix signed a licensing deal with Sequoia Software (whom they later acquired in 2001) to integrate the NFuse as the foundation for providing an extensible application portal for MetaFrame. The XML Portal Server (XPS) technology was then built around NFuse to provide the ability to dynamically enumerate and present resources to end users. This integration was critical in giving Citrix the ability to stand apart from the competition (terminal services), and was the reason the next version of MetaFrame had the XP designation:

xpsnfuse

Since it’s introduction back in 2000, the NFuse protocol has remained at the core of every Citrix desktop/application virtualization product by way of the ‘XML Broker’ service. This service was included in all future releases, including all versions of XenApp & XenDesktop. Until XenDesktop 5 was released, the XML broker service ran as it’s own standalone service. During the XenDesktop ‘Storm’ site architecture rework (now called FMA, aka NOT IMA) the XenDesktop product team decided to relocate the XML broker service to run as a ‘virtual’ service by piggy-backing on the XenDesktop Broker service. Other than this move to virtualize the XML broker service, the service remains as NFuse capable as the XML broker service used in MetaFrame.

Because of the NFuse protocol, resource enumeration has remained compatible as MetaFrame evolved into XenDesktop. In other words, the old MetaFrame Web Interface Server would still enumerate published desktops from a XenDesktop 7 DDC, and a StoreFront 2.0 server would enumerate published applications from a MetaFrame XP XML broker service (theoretically at least!), as long as the requests are NFuse compatible.

One of the main reasons the NFuse protocol is so durable is that it’s able to negotiate capabilities. In this example, a StoreFront site contacts a XenDesktop XML broker to determine what capabilities it has, and what resources are published to the authenticated user:

enumeration

In this process, the web front-end server sends an XML message to the configured XML broker to request a list of capabilities. The XML broker then responds with an XML formatted list of the types of resources it has access to. StoreFront will then request any compatible resources for the the authenticated user account. The XML broker then works with the XenDesktop broker and controller services to find out what resources are assigned to the user. The enumerated resources are consumed by StoreFront and presented to the end user.  This figure from the NFuse Classic 1.7 is still mostly relevant, just different companion components:

nfuse

StoreFront & Receiver

With Citrix Web Interface, the results of application enumeration were presented all at once to the authenticated user (optionally sorted into tabs and/or folders). In other words, all resources published to a user would be shown to them, though you could hide resources as needed. StoreFront with Receiver added the functionality that was originally introduced with Citrix Merchandising Server and Dazzle, which is to allow a user to pick their ‘favorite’ resources, providing Self-Service ‘App Store’ functionality and allowing a user’s favorite resources to follow them across multiple client devices and device types.

Prior to Dazzle/Receiver, applications were either enumerated in a web browser using a Web Interface ‘Web’ site, or enumerated directly by the Citrix client agent through a ‘Services’ site. In the past three years the Citrix client has evolved from the ‘Online Plug-in’ to the Receiver for Windows.

clients

The concept of client-side agent enumeration began with the ‘Program Neighborhood’ client (pre Online Plug-in), which would access a Services site (hence the default name PNAgent), and looked like this:

Program-Neighborhood-12

Until XenApp replaced Presentation Server, this was the way users would typically connect to applications, as the web portal wasn’t nearly as solid as the old WI server running in IE 5/6. By the time XenApp was released, Citrix decided to rework the ‘PNAgent’ to display resources as a system tray icon jump menu (which remains a fan favorite, quick, easy, intuitive) in what was first called the XenApp Plug-in, and later renamed to the Online Plug-in when XenDesktop was released:

DRXDBoth

However, around the time the Apple App Store was released, and Windows Vista changed some application UI design consideration, Citrix decided to create a self-service framework by way of Dazzle and Merchandising Server. As a result of this they decided to do away with the notification icon ‘jump-menu’ since it didn’t align with Microsoft’s general UI design recommendations for Windows Vista/7. When Receiver was launched, this legacy ‘PNAgent’ functionality was taken out of the standard ‘Receiver’, and moved to only be included in the ‘Enterprise’ flavor of the Receiver, which is really just a nice way to say that they’re accommodating ‘Enterprise’ customers who still want/need to use this legacy functionality.

As of Receiver Enterprise (the black icon) PNAgent enumerated shortcuts are only available in the start-menu or desktop (according to the site/farm settings):

PNA

Citrix’s current preferred method of displaying shortcuts to end-users is using Receiver 3/4 to connect to a StoreFront Store, which uses the ‘Dazzle’ framework to present shortcuts:

receiverwindow

The StoreWeb StoreFront site aims to provide the same look and feel for users that aren’t enumerating via the ‘Receiver’ agent:

receiverweb

Connecting from mobile receivers maintains this consistency of favorite resources:

androidreceiver

I could go on and on about the technical details of enumeration, but am out of time for today. I encourage readers to check out my previous post on the XML broker for a technical example of NFuse transactions.

In my next post I go into more detail about how enumerated resources are brokered to the receiver.

XenDesktop 7 Session Launch – Part 1, Authentication

The process of enumerating, brokering, and connecting to a XenDesktop resource involves quite a few moving parts, and can be a daunting task to troubleshoot for someone who isn’t familiar with the product. There are several key components involved in the session launch process including authentication, enumeration, registration, ticketing, and display/session handling.

In this post I’d like to briefly explain how the Citrix Receiver authenticates to a XenDesktop 7 application or desktop. To keep it simple, I’m only going to talk about StoreFront (no WI) and XenDesktop (no XenApp/IMA). So just Receiver <> StoreFront <> XenDesktop.

The first step to launching a XenDesktop session is to authenticate to the StoreFront Store that the XenDesktop resource is connected to. In this step, a user connects to the StoreFront server and:

  1. Authenticates to a StoreFront virtual directory via Citrix Receiver:
    • The Receiver is connecting to a StoreFront Store, StoreWeb, StoreDesktopAppliance, or PNAgent IIS virtual directory. IIS allows anonymous authentication since the StoreFront .NET services (Citrix.Storefront.exe & Citrix.StoreFront.PrivilegedService.exe) handle authentication:

storefront-IIS

    • To configure a StoreFront server’s authentication methods, use the Citrix Studio MMC to open the Authentication TreeNode of the Citrix StoreFront deployment. Here you can specify which authentication methods to allow on Stores hosted by that server:

storefront-authmethods

    • There are four authentication methods available as of StoreFront 2.0:
      • User name and password: Similar to windows basic auth in IIS, or explicit authentication in Citrix Web Interface Server.Prompts the user to enter their credentials at logon.
        • In this scenario, the broker passes the user’s credentials to the target ICA server on behalf of the client
      • Domain Pass-through: Similar to Integrated Authentication in IIS, and
        • Allows Receiver for Windows endpoints automatically log on using the local session’s logged on user domain account (via NTLM)
        • In this scenario, the client sends credentials (via ssonsvr.exe) directly to the target ICA server
        • For pass-through authentication to work, you must use the /includesson switch when installing Receiver (per CTX133982), which tells the meta-installer to include the ‘SSON’ component (ssonsvr.exe) that is needed to capture the user’s domain credentials at logon. Receiver relies on the SSON component to send the user’s domain credentials to the StoreFront server’s StoreWeb (via browser), Store (via Receiver), or legacy PNAgent (via Online Plugin / Receiver Enterprise) virtual directory.
          • There is currently a bug with XenDesktop 7 published desktops using pass-through authentication to provide ‘FlexCast’ functionality (enumerate and launch published apps from the published desktop) where ssonsvr.exe wouldn’t run (crashed at login) because pnsson.dll wasn’t playing nice with the ICA stack at session logon.
          • Citrix has provided a provisional test-fix to customers with an open case, and will soon be releasing a public hotfix. As of this post, pass-through authentication doesn’t work on XenDesktop 7 published desktops running Receiver 3/4 without this fix in place.
      • Smart Card: Allows smart card pass-through
        • Thankfully I don’t work with this method very often, so I’ll refrain from digging in. Just know that it’s required if smart-cards are used in the environment
      • Pass-through from NetScaler Gateway: Allows a NetScaler Gateway virtual server to handle user authentication on behalf of the user
        • Requires Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true to be set on the DDC/XML broker)
        • Use the Configure Delegated Authentication option to specify that the NetScaler send logon credentials directly to the remote Windows session

delegatedauth

    • There are also client-side registry values that control whether or not to allow pass-through authentication, and can even lock down the feature to only work with StoreFront sites in specified Internet Explorer Security Zones (aka Client Selective Trust). The easiest way to adjust this is to use the ADM template in %ProgramFiles%\Citrix\ICA Client\Configuration\icaclient.adm

Image

In my next post on XD7 session launch I’ll talk about resource enumeration, including details about the virtual XML broker and XenDesktop broker services.

XenApp/PVS Global Farm Overview

Since there was a lot of interest in the last Visio I posted, I thought I’d share another.

These diagrams outline high level overviews of a global XenApp w/PVS deployment, with XenApp zones and PVS sites in each datacenter. Each XenApp zone has two data collectors/XML brokers, PVS-Streamed OU-based worker groups. Each geographic region has a corresponding StoreFront Store (directed by host name):

XenAppGlobal

 

The PVS farm configuration is very similar, consisting of sites in each datacenter to stream XenApp workers for each XenApp zone in that datacenter, with the master database homed in the US datacenter:

PVSGlobal

 

The intent of these overviews are mainly to demonstrate how the XenApp and PVS farms interact in a global zone/site architecture. I’ll share some overview diagrams of XenApp zones and PVS sites in another post. Hope you enjoy!

Citrix Receiver for Windows 4.0.1 – Goodbye unnecessary logon prompts!

For those of you out there who are delivering XenApp/XenDesktop through StoreFront, you should definitely make sure to update your Receiver for Windows 4 clients to the latest 4.0.1 hotfix. While this update only contains one fix, it solves a very visible, miserable, and annoying problem.

If you’ve ever connected to a StoreFront Store via Receiver 4.0 through a remote site, you’ve probably seen this window pop up every 10 minutes or so:

Image

Receiver 4.0.1 addresses this very annoying behavior by only prompting for credentials after the expiration timeout period if and when a resource is launched through Receiver.

I’m sure many of you already knew about this fix, but I thought I’d help to spread the word in hopes of sparing others from this frustration on Receiver 4.0 RTM.

SiteDiag v1.2 for XD7

I think I’ve gotten SiteDiag working pretty well for XD7 now, and feel comfortable to share it as a stable release. I also did some basic testing on XD5, and there doesn’t appear to be any noticeable regressions. As of version 1.2 (10/2/13) I added application icons into the tool using the Get-BrokerIcon cmdlet to convert the Base64 strings to images in the TreeView.

I’ll continue working to build out the functionality of the tool on XD7, so stay tuned for updates as progress is made.

Click here to download the latest stable build.

SiteDiagXD7

XenDesktop 7 Service Instances – What’s New?

Since XenDesktop 7 was built using the same service framework architecture as XenDesktop 5 (aka the ‘FlexCast Management Architecture’), the additional functionality introduced in XD7 was added as services, each with multiple service instances. These services are handled much in the same way as XenDesktop 5, and XenDesktop 7 sites use version 2 of the Citrix.Broker.Admin PowerShell SDK to return information on registered service instances using the cmdlets of the same name as XD5 (Get-ConfigRegisteredServiceInstance, Register-ConfigServiceInstance, etc.).

In XenDesktop 5, each DDC in a site has 5 services, with 12 total service instances that correspond to the various WCF endpoints used by each service. If the DDC is also running the Citrix License Server, there would be a total of 13 instances. For this reason, it’s a fairly straightforward process to find and register missing service instances.

XenDesktop 7 is quite different in this regard. Since it has optional FMA services, such as StoreFront, the number of service instances in any given site depends on which components are installed, and whether or not SSL-is in use.

For example, my single-DDC site running StoreFront 2.0 with SSL encryption has 10 services with 43 total service instances:

XenDesktop 7 Services

If StoreFront wasn’t installed, for example, there would be at least three less services (some of the Broker services would likely not be registered). There are also duplicate service instances for SSL encrypted services, such as the virtual STA service. Here’s a quick PoSH script to tell you what service instances are registered in your site (for XD5 & XD7):

asnp citrix.Broker*
Get-ConfigRegisteredServiceInstance -AdminAddress na-xd-01 | %{ 
"ServiceType: " + $_.ServiceType + " Address: " + $_.Address; $count++}
"Total Instances: " + $count

You could take this a step further to see how many instances are in each of the 10 possible service types:

New-Alias grsi Get-ConfigRegisteredserviceInstance
 $acct = grsi -AdminAddress na-xd-01 -serviceType Acct; "$($acct.Count) ADIdentity service instances"
 $admin = grsi -serviceType Admin ; "$($admin.count) Delegated Admin service instances"
 $broker = grsi -serviceType Broker; "$($broker.count) Broker service instances"
 $config = grsi -serviceType Config; "$($config.count) Configuration service instances"
 $envtest = grsi -serviceType EnvTest; "$($envtest.count) Environment Test service instances"
 $hyp = grsi -serviceType Hyp; "$($hyp.count) Hosting Unit service instances"
 $log = grsi -serviceType Log; "$($log.count) Configuration Logging service instances"
 $monitor = grsi -serviceType Monitor; "$($monitor.count) Monitor service instances"
 $prov = grsi -serviceType Prov; "$($prov.count) Machine Creation service instances"
 $sf = grsi -serviceType Sf; "$($sf.count) StoreFront service instances"
 "$($acct.Count + $admin.Count + $broker.Count + $config.Count + $envtest.Count + $hyp.Count + $log.Count + $monitor.Count + $prov.Count + $sf.Count) Total service instances"
XenDesktop 7 Service Instance Count

XenDesktop 7 Service Instance Count

Because of this nuance, I’m working on a more intelligent way of enumerating and validating service instance registrations in SiteDiag for XD7. Hopefully these scripts are helpful in illustrating the difference between XD5 & XD7. Also, here’s the latest nightly build of SiteDiag that has the beginnings of the additional logic needed to properly count, and fix, registered service instances in a XenDesktop 7 site.

XenDesktop 7 – Environment Test Service

If you’ve had a chance to review the XenDesktop 7 PowerShell SDK documentation, you might have noticed a few new snap-ins that provide the site interactions for the new services included with XenDesktop 7 (as part of the FlexCast Management Architecture). These new snapins are the designated as V1 on the cmdlet help site, and include StoreFront, Delegated Admin, Configuration Logging, Environment Tests, and Monitoring.

Out of these new services, the Environment Test Service sounds the most appealing to me, as it provides a framework to run pre-defined tests and test suites against a XenDesktop 7 site. However, I found that the SDK documentation didn’t provide much/any guidance on using this snap-in, so I thought I’d share a quick rundown on the meat of this new service, along with some sample scripts using the main cmdlets.

The most basic function of this service is to run predefined tests against various site components, configurations, and workflows. As of XD7 RTM, there are 201 individual TestID’s, which can be returned by running the Get-EnvTestDefinition cmdlet:

TestId 
------ 
Host_CdfEnabled 
Host_FileBasedLogging 
Host_DatabaseCanBeReached 
Host_DatabaseVersionIsRequiredVersion 
Host_XdusPresentInDatabase 
Host_RecentDatabaseBackup 
Host_SchemaNotModified 
Host_SnapshotIsolationState 
Host_SqlServerVersion 
Host_FirewallPortsOpen 
Host_UrlAclsCorrect 
Host_CheckBootstrapState 
Host_ValidateStoredCsServiceInstances 
Host_RegisteredWithConfigurationService 
Host_CoreServiceConnectivity 
Host_PeersConnectivity 
Host_Host_Connection_HypervisorConnected 
Host_Host_Connection_MaintenanceMode...

The tests are broken down into several functional groups that align with the various broker services, including Host, Configuration, MachineCreation, etc, and are named as such. For example, the test to verify that the site database can be connected to by the Configuration service is called Configuration_DatabaseCanBeReached.

Each test has a description of it’s function, and a test scope that dictates what type of object(s) can be tested. Tests can be executed against components and objects in the site according to the TestScope and/or TargetObjectType, and are executed by the service Synchronously or Aynchronously, depending on their InteractionModel. You can view all of the details about a test by passing the TestID to the Get-EnvTestDefinition cmdlet; for example:

PS C:> Get-EnvTestDefinition -TestId Configuration_DatabaseCanBeReached

Description : Test the connection details can be used to 
 connect successfully to the database.
DisplayName : Test the database can be reached.
InteractionModel : Synchronous
TargetObjectType : 
TestId : Configuration_DatabaseCanBeReached
TestScope : ServiceInstance
TestSuiteIds : {Infrastructure}

TestSuites are groups of tests executed in succession to validate groups of component, as well as their interactions and workflows. The Get-EnvTestSuite cmdlet returns a list of test suite definitions, and can be used to find out what tests a suite is comprised of. To get a list of TestSuiteIDs, for example, you can run a Get-EnvTestSuite | Select TestSuiteID, which returns all of the available test suites:

TestSuiteId 
----------- 
Infrastructure 
DesktopGroup 
Catalog 
HypervisorConnection 
HostingUnit 
MachineCreation_ProvisioningScheme_Basic 
MachineCreation_ProvisioningScheme_Collaboration 
MachineCreation_Availability 
MachineCreation_Identity_State 
MachineCreation_VirtualMachine_State 
ADIdentity_IdentityPool_Basic 
ADIdentity_IdentityPool_Provisioning 
ADIdentity_WhatIf 
ADIdentity_Identity_Available 
ADIdentity_Identity_State

Each of these suites can be queried using the same cmdlet, and passing the -TestSuiteID of the suite in question. Let’s take DesktopGroup as an example:

PS C:\> Get-EnvTestSuiteDefinition -TestSuiteId DesktopGroup

TestSuiteId         Tests 
-----------                  ----- 
DesktopGroup   Check hypervisor connection, Check connection maintenance mode, Ch...

One thing you’ll notice with the results of this cmdlet is that the list of tests are truncated, which is a result of the default stdout formatting in the PowerShell console. For that reason, my preferred method of looking at objects with large strings (ie descriptions) in PowerShell, is to view them in a graphical ISE (PowerGUI is my preference) and explore the objects in the ‘Variables’ pane.

For example, if you store the results of  Get-EnvTestSuiteDefinition -TestSuiteId DesktopGroup into a variable ($dgtest) in PowerGUI, each Test object that comprises the test suite can be inspected individually:

The DesktopGroup EnvTestSuite object

The DesktopGroup EnvTestSuite object

To start a test task, use the Start-EnvTestTask, passing the TestID or, alternatively, the TestSuiteID, and a target object (as needed). For example:

PS C:> Start-EnvTestTask -TestId Configuration_DatabaseCanBeReached

Active : False
ActiveElapsedTime : 11
CompletedTests : 1
CompletedWorkItems : 11
CurrentOperation : 
DateFinished : 9/16/2013 11:33:31 PM
DateStarted : 9/16/2013 11:33:20 PM
DiscoverRelatedObjects : True
DiscoveredObjects : {}
ExtendedProperties : {}
Host : 
LastUpdateTime : 9/16/2013 11:33:31 PM
Metadata : {}
MetadataMap : {}
Status : Finished
TaskExpectedCompletion : 
TaskId : 03f5480d-68e8-410a-9da4-5e65d96ac393
TaskProgress : 100
TerminatingError : 
TestIds : {Configuration_DatabaseCanBeReached}
TestResults : {Configuration_DatabaseCanBeReached}
TestSuiteIds : {}
TotalPendingTests : 1
TotalPendingWorkItems : 11
Type : EnvironmentTestRun

Once you know what tests there are, what they do, and what types of results to expect, health check scripts can easily be created using this service. Combinations of tests and test suites can, and should, be leveraged as needed to systematically validate XenDesktop 7 site components and functionality.

I plan on using these cmdlets to some extent in SiteDiag, and expect to get some good use out of this new service in the field. I’m interested to hear from anyone else who’s started using this snap-in, and if they’ve come up with any useful scripts.