Wisdom-Fu: E-mail Alert when your TS logins are disabled


XenApp server maintenance is a necessary part of managing a Citrix farm (unless you are using Provisioning Services?).  We use Wisdom (which I will detail in a later post) to perform an elaborate, reoccurring maintenance reboot job on our servers.  Part of the maintenance job is to disable Terminal Server logins when the job starts and enable them when the job completes.  Naturally, Murphy’s Law is in effect all the time when it comes to Citrix servers, so the maintenance job will not complete on a couple of servers and they will have their logins disabled when users start to login.  For this post, I’m going to detail a simple Wisdom module that you can schedule to run ‘in the morning’ that will send you an e-mail alert for any servers that have their logins disabled.

Wisdom Module Overview

The module consists of 2 actions:


With these module parameters:


  • SERVERNAME will be set to the %COMPUTERNAME% environment variable of the server the module is run against.
  • SecurityContext is used for the E-mail task
  • LoginsDisabled is a conditional parameter that we use to determine whether to send an e-mail or not.

Wisdom Module Detail

Query Registry Settings

The first task simply examines the WinStationsDisabled value for the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

If the value is 1, then we’ll set our Wisdom parameter LoginsDisabled to 1, otherwise, it is 0.


Send E-mail

The second task runs if the LoginsDisabled parameter is equal to 1, otherwise skip this task.


Here are the e-mail settings so you can see how the SERVERNAME parameter is used:


Building block available here.  You can also follow more discussion at the Res Software User Group forums.



AppSense: Dueling Personalization Servers

AppSense user personalization is one of the more powerful parts of the AppSense suite.  It allows a user’s customizations (desktop and application) to move with the user to their pc, laptop, or virtual desktop.  The AppSense Environment Manager handles this function.  We are stepping up a production AppSense environment and I ran into a conflict between the production and lab AppSense environments.  In this blog post we’ll look at Auditing and Sites in the AppSense consoles to control where the user’s custom settings go.


In the AppSense Management Console, you can activate auditing for each Deployment Group.


Each section, which obviously governs a different aspect of the AppSense suite, contains many events that report on the various functions/actions of AppSense.  Here’s the Environment Manager list of events:


Toggling the check boxes allows you to view events in the console (surprisingly, under the Events section).


You can modify how this information is logged in the Environment Manager console.

When you’re looking at the Policy Configuration and click on the Auditing button you’ll get the following:


These settings govern how the events appear on the local device that has the installed agent.  Here, you can choose which log the events are written to , whether to make them anonymous, and even the log format.  You can also pick which events locally logged on the client device.

NOTE: Auditing should only be used for troubleshooting.  Leaving this on will impact the performance of AppSense.


Now that you are logging these events you can see if your configuration is recording them.  In my situation, I was seeing these events, but when I ran the Personalization Analysis I did not get any user or application data.  I found that when I connected to our lab personalization server which was setup first, I could see the data I was expecting.  This was due to the Default Users and Default Sites settings present in the lab personalization server configuration and that this original configuration was imported into the new environment.  This required us to change the configuration in both the old and new configuration to explicitly list with servers or Group Policy OU they resided in.

In my new configuration I created a new Site and named it Migration.  I added my new EM server and also added a Computer OU membership that included all my servers I wanted to discover applications from.


To make sure the old configuration did not continue to gather data from my servers, I added a new site (called Migration for consistency sake), added my new EM server, and added the same computer OU membership to it.

Now when I run Personalization Analysis on my production Personalization groups, I can see user and application data.


AppSense: Automated CCA Install and Self-Registration

Once you have your AppSense server and databases created, you can proceed with AppSense Agent installation.  In this post we’ll cover a command-line install of the Client Communications Agent and getting the device to Self-Register.

AppSense provides all their install components as MSI files (located under \Software\Products).  Here is an example of a silent install of the Client Communications Agent which is required on all servers that you wish to manage via AppSense.

msiexec.exe /qn /i "<MSI file path>\CommunicationsAgent.msi" WEB_SITE="https://<Management Server Name>" GROUP_NAME="<DeploymentGroup>"

NOTE: Above quotes are needed.

After installation, your system will join the default Unassigned Computers deployment group, it will then Self-Register to another Deployment Group if wanted.  To set this up, you must put the Deployment Group in the above command-line installation.  You must also check the following box on the Settings Section of your Deployment Group:

Deployment Group Settings

Once part of a custom Deployment Group, it will install the other AppSense agents and configurations that are part of it using your installation schedule settings.