With Director 7.7, you have the capability of configuring policies, rules and conditions that will alert you when the configured threshold has reached in your XenDesktop 7.7 environment. You can configure and manage proactive alerts and notifications either through the Director UI or using Powershell cmdlets.

In this post, we will take a look at how to configure, visualize your alerts, manage them, analyze their details and historically track alert trends.

Configuration

Let’s assume that you are a XenDesktop admin and you are trying to understand the usage of your XenDesktop deployment. You need to be alerted when the number of concurrent sessions crosses a threshold value.

Before you even get to configuring alerts and notifications, you need to configure your notification subscription. With this, you can add an SMTP exchange server which can be later used to send emails from when there is an alert.

For this, you need to navigate to the Email Server Configuration page. On the dashboard click on the Alerts tab at the top and then in the Alerts page click on the Email Server Configuration sub-tab to get there.

Once you are in the page, you need to enter all of the mandatory values.

Protocol: Choose which protocol your email server supports. Director supports multiple protocols to connect with your SMTP server. They include SMTP, SMTP-SSL and SMTP-TSL

Host: The host name or the IP address of the SMTP server

Port: The port with which you want to connect to with your SMTP server

Sender Email: The email address from which you want to send email from incase of an alert. It’s best advised to create a separate email address on the email server and name it as CitrixDirectorAdmin@xyz.com and use it to send your alert emails.

Does SMTP server require authentication: In case your SMTP server does not require authentication, you can set the value to NO and you would not need a username and password.

Username and Password: Credentials required to authenticate the SMTP server connection

Before you save your settings it is best advised to test it by sending out a test email. Click on the “Send Test Email” button and verify if you get a test email to the email address you provided in the Send Test Email wizard.

In case you do not get an email, recheck the configuration parameters and use the “edit” button to modify any incorrect values.

Note: You cannot configure more than one SMTP server.

If you want to remove an existing notification subscription, click on the Remove Settings button.

Configuring a policy

Since you are done creating a notification subscription in the previous step, let’s focus on creating a policy. The first thing that you need to do is navigate to the Create Policy Page. On the dashboard, click on the Alerts tab and then on the Create Policy sub tab. If you do not see this tab then you do not have sufficient privileges to create a new policy. Let’s start with an example. You want to create a policy that has a condition that, if the number of “Peak Connected Sessions” goes above 10, a warning alert is generated and when the number of “Peak Connected Sessions” is above 15 a critical alert is generated.

Now let’s see how we can configure such a policy!

The main components of a policy are:

Name: The name of the policy that you want to create

Description: A brief description about the policy and its conditions. Limit your description to less than 50 words

Scope: The entity on which the policy will be applied on. For e.g.:- If my policy has a condition; “Alert me when the peak connected sessions hits 90 on all the machines in my delivery group xyz”, then here, the delivery group xyz is the scope.

In general, alert policies can be targeted at three different scopes:

1. Site – Will apply to all the machines in the entire site and the alert threshold will be applied on the aggregate value of all the machines included.
2. Delivery Group – Will apply to all the machines in the entire delivery group and the alert threshold will be applied on the aggregate value of all the machines included.
3. Server OS – Will apply to all the machines in the delivery group but the alert threshold value will be applied to individual machines.

Notification Preference: Who should be notified with an email when there is an alert for this policy?

Conditions: A list of conditions that you can choose to create a policy. A policy can have multiple conditions or just one.

Condition Type	Condition Checked
Peak Connected Sessions	Detected when an instantaneous (one minute samples) number of peak connected sessions for the entire site of a particular delivery group exceeds a configured count threshold.
Peak Disconnect Sessions	Detected when an instantaneous (one minute samples) number of peak disconnected sessions for the entire site of a particular delivery group exceeds a configured count threshold.
Peak Concurrent Sessions	Detected when an instantaneous (one minute samples) number of peak concurrent (total) sessions for the entire site of a particular delivery group exceeds a configured count threshold.
Connection Failure Count	Detected when the number of connections in a configurable time period fail across the entire site of a particular delivery group exceeds a configured count threshold.
Connection Failure Rate	Detected when the ratio of connection failures to connection attempts in a configurable time period across the entire site of a particular delivery group exceeds a configured percentage threshold.
Failed Desktop OS Machines	Detected when an instantaneous (one minute samples) number of desktop OS machines in a failure state for the entire site of a particular delivery group exceeds a configured count threshold.
Failed Server OS Machines	Detected when an instantaneous (one minute samples) number of Server OS machines in a failure state for the entire site of a particular delivery group exceeds a configured count threshold.
Average Logon Duration	Detected when the average session logon time in a configurable time period across the entire site or for a particular delivery group exceeds a configured duration threshold.
RDS Load Evaluator Index	Detected when the configured threshold of  load index value is sustained consistently for 5 minutes. For e.g. If we configure a threshold of 68 % then an alert will be triggered only when the threshold is above or = 68% for 5 minutes without a dip in between.

Since you have understood the components of a policy, let’s try creating one. Go ahead and click on create policy and select a Site policy and give in the name, description, notification preference and the condition of your choice. The scope by default would be the name of the Site and hence it would be pre-selected for your ease.

Note: Alert polices are site specific! An alert policy cannot be applied across multiple XenDesktop sites

Note: While adding the notification preference you can choose the name of the user whom you want to send the email to and the email address would be automatically added. In case you want to add an email address of an user outside you domain simply type in the complete email address in the search box and click on the add button!

Note: You will not be able to add notification preference unless you have configures an Email SMTP server

When it comes to the conditions remember to follow these mandatory rules without which you will not be able to save your policy.

1. The warning threshold should always be less than that of the critical threshold
2. Both the warning and critical thresholds are mandatory
3. Warning and critical thresholds cannot be zero or in negative.
4. Certain conditions like “Peak Connected Session” do not accept fractions or decimal values
5. The Alert re-notification and Alarm re-notification periods would be by default specified. In case you want to change them, go ahead. You can reset to the default values later using the “Reset Value” button.

• Alert Re-notification – Duration after which the warning notification will be re-triggered
• Alarm Re-notification – Duration after which the critical notification will be re-triggered

6. Once all of the mandatory rules are followed you will get a green tick next to your condition and if not you will get a red cross next to the conditions that are incorrect.

Note: In cases where there are multiple conditions in a policy, none of the conditions will be saved until all the errors are corrected.

Once you hit on save you have created your first policy.

Get Notified

Visualizing your alerts

Once you are done creating the set of policies and conditions for you XenDesktop environment, it’s time to sit back and relax. If your environment hits choppy seas you will be notified immediately on the Director web console and you would get an email as well.

The notification tip and slide bar

Once there is an alert, may it be warning or critical, an admin will be notified on the notification tip. The notification tip will be available on all the paged except on the user details page.

The notification tip gives you the number of active alerts. In case you have configured SCOM along with proactive alerts and notifications, you get a sum of both the active alerts on the notification bar.

When you click on the notification tip you get the notification slide. The notification slide gives you the option of classifying your alerts based on the source i.e. Director or SCOM and also based on the severity i.e. Critical or Warning. If you want to know more about how to configure SCOM alerts on Director, please refer this blog.

The notification slide bar will give you a list of all the active alerts including details like the time when it occurred and the rule and condition that triggered it.

Emails

If you are subscribes to the notification preference of a condition that triggered an alert, then you would receive an email. The email is localized and you will get it in the language you prefer.

Managing

Managing your policy

Once you are done creating policies you now need to know how to manage them. In case you need to modify a policy, navigate to the policy page, search for the name of the policy using the search box provided and click on the EDIT button.

When your XenDesktop site is in a maintenance period and you do not want any alerts, you can use the DISABLE button to disable the policy. This will prevent any new alerts from being created. Once you are done with the maintenance work, you can go ahead and ENABLE these policies.

If there are any old policies that you want to get rid of, choose the policy and click on the DELETE button.

Note: Deleting a policy will not delete the history of alerts that were triggered prior. You can still see them on the Alert Summary page

Managing your alerts

When there is an alert, you get notified on the notification tip. You can click on the notification tip to get a slide bar that will have brief details of the alert. You can also group them into warnings and critical alert

If you want to know more about an alert, simply click on it and that would take you to the alert details page. The alert details page gives you a picture of the alert, its history and its present condition. You can edit the policy that created the alert from this page too.

If you do not want this alert to be shown as active, then you can go ahead and DISMISS it. Dismissing an alert is an irreversible action. Only when the condition becomes healthy and then breaches the warning or critical thresholds will you get an active alert. Till then you will not be notified.

Note: If you dismiss a critical alert, you will not receive warning alerts. But if you dismiss a warning alert, you will be notified when the condition breaches the critical threshold

If you want to view the history or the summary of all the alerts triggered, then you can use the alert summary page. The alert summary page lets you filter alerts based on the time period, the scope and the present condition of the alert. To navigate to the alert summary page, click on the Alert tab on the dashboard and then on the Citrix Alerts sub-tab.

Note: If a delivery group is deleted, you will still find it listed in the scope. This is to make sure history of alerts that were triggered with that particular delivery group as scope are not lost.

In the alert summary page, you can DISMISS an alert, navigate to the details of the alert (alert details page) and also export the data.

You can search for history of alerts by using the filters provided.

Source: You get to choose the scope on which the rule was applied. In case of delivery group or server OS you get to search for the particular scope and apply your condition on it.

Category: The category of policies for which you want to see the alerts

State: You get to choose between four different kinds of severity; Critical, Warning, Dismissed and Healthy. This will help you group your alerts, and action upon the required ones.

Time Period: You can choose a time frame from last 2 hours, last 24 hours, last 7 days and even last month. When you select the end date as now, you will be shown the active alerts exactly till the moment you hit on apply.

You can choose a custom end date and time too.

Now let us take a look at the grid shown in the alert summary page.

Time: Time and date when the alert was first triggered

Action: Any action that has to be performed. e.g.: Dismiss

Status: The current status of the alert. Is it healthy, critical, and warning or is it dismissed. If the policy that triggered the alert is deleted, then the history of the alerts will still be available but will be shown in the dismissed state.

Alert Policy Name: The name of the alert policy that was given when the policy was created

Scope: Where was the policy applied on? Was it on a delivery group level, was it on the site level or was it on a server OS level?

Source: The drilled down source that actually triggered the alert.

Category: What king of policy was it? It reflects the template that you took while creating the alert rule.

Description: Gives you a brief of what was the exact condition that triggered the alert.

That’s all, folks!

Hope this helps you to easily configure polices, visualize your alerts, manage them, analyze their details and historically track alert trends.