Citrix Director: Configuring,Managing Alerts and Notifications

If you are a XenDesktop admin and 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.

  1. 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.

    Director Configure

  2. The Email Server Configuration Page – in this page, you need to enter all of the mandatory values like-

  • 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 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
  1. Before saving the settings it is 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.

    send test message

  2. 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

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.

For 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. The instructions below state how to configure such a policy.

peak connected sessions

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.

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.

Assign Delivery Group

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 configured 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.
  • 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-triggered6

Note: You can use the “Reset Value” link is to clear modifications done on an unsaved policy. Once it’s saved, it will reset to the last saved value and not default initial value. Hence, once the policy is saved, you can modify the threshold values but resetting brings it to the last saved value..

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.

Group Policy

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

Get Notified

Visualizing your alerts

If there is any issue you will be notified immediately on the Director web console and also receive an email.

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.

Data updated every minute - Director

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.

Alerts - Director

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.


If you subscribe 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.

Citrix Director

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

Directory Policy

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.

Director Dashboard Alerts

Managing alerts

If you want to know more about an alert, 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.

Manage Director Alerts

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.

Citrix Alerts

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.

Director - All Alerts

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

Director - All Alerts Menu

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.

All Alerts - Director

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.

Choose End Date

You can choose a custom end date and time too.

All Alerts Director

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

User-added image

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.

Note: Proactive Notification and Alerting are Platinum features. More information about features and editions can be found in the links below. Please see Additional Resources.


Resolved Advisory: Sophos Email Appliances may be sending automatic alerts indicated data update install failures

Sophos was receiving a high number of automated alerts from Sophos Email Appliances indicating data update install failures.

Applies to the following Sophos product(s) and version(s)

Sophos Email Appliance

This may cause a delay with data updates being applied and alerts to be generated by the Email Appliance. This has no impact on mail flow.

Update 22-05-2019

Continued monitoring has shown the number of automated alerts drop off and appliances that previously generated alerts are now successfully installing subsequent updates.

This has been investigated and a fix has been implemented to resolve the issue. It may take a a short time for this fix to be detected and installed by appliances. We are continuing to monitor this to ensure that this is resolved

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.


SEP SBE Alerts email content

I need a solution


I have SEP SBE antyvirus, i get alerts email from it. example ([hidden] – i just hidden contect):

A high-risk intrusion was detected on [hidden] within group [hidden] on 5/6/2019 10:21:21 AM.

IPS Alert Name
Web Attack: Fake Tech Support Website 295


Attack Signature

Targeted Application

Attacking IP

Targeted IP

Targeted Port Number

Targeted Host Name

i have question about “Attacking IP” – How norton know the attaking ip? in my alerts “attacking ip” is ip the domain controler computer in cloud.



The PXE service is not running on the PVS server

To resolve this issue:

1. Launch the Services console: Click **Start** and then type **Services**.

2. Verify the PXE service is present, restart the service, and check the Event Log for any errors: From the Services console, right-click **Citrix PVS PXE Service** and select **Start**.

Note: If you are not using PXE booting with Provisioning Services, click **Hide Alert** to prevent this alert from appearing. You can show this alert again by clicking **Site Options > Show Hidden Alerts**. For more information, see Manage Smart Check alerts and notifications in the product documentation


  • No Related Posts

History of Automation Policy results

I need a solution


we created an Automation policy to send an email with a list of computers with a lower version of Firefox application. And it generates an email daily so that we keep upgrading the computers found in that alert. Now, is there a way to get the history of all the alerts thrown by the policy for a week? if this is not possible, can someone suggest a better report to get the history results of application changes in a date range.

Thanks & Regards,




How to configure Alerting on a PowerMax

An essential part of Array management is monitoring for specific events or error conditions. When an event or error does occur Unisphere displays an alert and, if configured to do so, notifies you of the alert by the way of Email, SNMP or Syslog. If you wish to find out more about configuring SNMP and the Syslog please refer to this guide.

Alert Policies

To begin with let’s start with the Alert Policies section. In the following examples we have focused on a 5977 PowerMax array. To navigate to here please select the Settings button as displayed by a “cog” icon in the upper right hand corner of Unisphere.

alert policies.PNG.png

When you install Unisphere some of these categories come enabled by default. However in order to capture a complete picture of the health, capacity and behaviour of the array we would recommend the following categories you can see to be enabled:

  • Array Component Events
  • Array Events
  • Device Config Change
  • Director Status
  • Hotspare Invoked
  • Port Link Status
  • Port Status
  • SRDF Link Status
  • Storage Pool Projection Alert

You can see here that the notifications turned on is email. It can also be via SNMP or the syslog.


To configure these please select the Notifications on the left hand side navigation:


Here select the configure button below email in order to set it up. You can configure email addresses to which notifications, alerts, and reports are sent. You can configure a single email address for all notification instances, or you can use different email addresses for different notifications on different storage systems.

configure email.PNG.png

In the Outgoing Mail Server (SMTP) section you need to specify the IP Address or Host and also the port you are using. In the User Information you will need to provide a sender email address that will make sense and here we have just called it out as You select create to configure an email address that will receive the alerts, in general it will be the storage team monitoring this so would be a valid and relevant mail address.

Finally select which array and category which is relevant to you so here we have selected System, Performance and reports as we want to be alerted on these.

Compliance Alert Policies

This section is concerned with monitoring the service level compliance state of our storage groups.

compliance alerts.PNG.png

Here we have selected all the storage groups on array 0111 and the state we wish to monitor for is marginal or critical as we are not concerned with a stable SG state.

compliance alerts1.PNG.png

As you can see here we can have enabled email notifications for a certain number of SG’s if their state goes marginal or critical.

Performance Threshold and Alerts

This category will allow you to monitor the overall performance of the array and alert on it accordingly.

performance tresholds and alerts.PNG.png

In this example we are focused on the 0111 Array. Here we are focused on the array category which will allow us to track and alert when we go over a certain number in terms of a threshold across a variety of categories that we can see on the list. You can see that this list includes the KPI’s and generally the KPI’s that we pre-configure for the customer will satisfy most people’s needs but you may want to adjust the values based on your own preference.

As well as Array there are 5 other categories such as Storage & Hosts, Directors & Ports, Storage Resources, Data Protection and System Internals.

So I wanted to show a use case example here so I will select Storage & Hosts > Storage Groups.

performance tresholds and alerts-SGs.PNG.png

So for this example I am very sensitive about the Response Time of my SG’s on this array so I choose the pencil icon next to RT so I can edit it.

edit performance treshold alert.PNG.png

The default values were 20 and 30 so I have reduced them to 10 and 20. Next I select the trigger alert on the lower part of the screen.

trigger alert.PNG.png

I have selected the checkbox for trigger an alert and my first threshold is just a warning but the 2nd is a critical alert. The number of occurrences in the data samples which must happen before the alert is triggered. For example, if the threshold is breached 3 times out of 5 samples, an alert is imitated. The number of occurrences in the data samples which must happen before the alert is triggered. For example, if the threshold is breached 3 times out of 5 samples, an alert is initiated.

As I stated previously most people are happy to accept the pre-configured thresholds that are automatically setup when you install Unisphere. If you do wish to change these you have that ability and we have shown you a practical example above.

Symmetrix Threshold Alerts

These are set of alerts based on certain categories such as capacity consumption, Meta Data Utilization and Local Replication Utilization.

symm treshholds and alerts.PNG.png

In this example the array is a 0111 PowerMax box so we have 6 categories Storage Resource Pool Utilization, Storage Container Utilization, Frontend Meta Data Usage, Backend Meta Data Usage, Local Replication Utilization and System Meta Data Utilization. There are different categories for older arrays such as Fast and thin pools but are not applicable to the newer arrays.

In terms of the 3 various thresholds Warning, Critical and Fatal we have gone with the default values. We can of course customize these if we wish also and in terms of notifications we have again chose email but SNMP and syslog are also available.

Following these guidelines will enable you to successfully monitor your array’s performance. I hope you have found this blog helpful and if you have any questions please feel free to reach out with questions.


ViPR SRM How to configure alert notifications between Unisphere for VMAX and ViPR SRM

This procedure explains how to configure Unisphere for VMAX to notify ViPR SRM when a storage system generates an alert. This information is also available in the Unisphere for VMAX online help guide.

Procedure to configure SNMP in Unisphere for VMAX:

1. Log on to Unisphere for VMAX

2. From the System Selector, click Home

User-added image

3. Select Home > Administration > Alert Settings > Notifications to open the Notification page

User-added image

4. In the Types panel, click Enable next to SNMP you want to use to deliver the notification

5. Type IP address of the SNMP server (ViPR SRM primary backend)

6. Type the port on the SNMP server (2041 for ViPR SRM)

User-added image

7. Once SNMP has been enabled, the following page displays

8. Select the desired alert severity.

User-added image

User-added image

9. Navigate to All Symmetrix > Home > Administration > Alert Settings and click on Symmetrix Thresholds Alerts

to view the various utilization alerts.

User-added image

10. Select the desired utilization alert and Click on “Notify” to define notification via SNMP. Click OK.

User-added image

11. The last step is to enable the alert policy

User-added image


Re: Can VNX template deployment be scripted?

Sorry, I should have been specific… Notification templates for alerting. We’ve removed some of the alerts as 100 machines create an incredible amount of noise for our NOC. We have a dedicated monitoring team, storage team, and a NOC. The NOC really only needs to get critical alarms whereas our storage team reviews non-critical messages each day. So I’ve created two alert templates, one with critical alerts that notifies our NOC and EMC and another template with all the alerts that notify EMC, our monitoring team (who tracks tickets) and our storage teams

The point is .to avoid sending non-critical alerts to the NOC.

Now that I’ve committed to this I realized the herculean effort that pushing two new alert templates out to every machine is going to be…

I was hoping there was a better (faster) way to do this.


  • No Related Posts

Improve reporting

I need a solution


I was trying to find a report that would give me details on all of the alerts I’ve been receiving by email on one of our computers. The closest I got was exporting the alerts report but I was looking for the report to include the details of the ports and computers being attacked and the ip addresses of the attackers as well but none of the reports you have available export that data. I can only get the ip addresses and port info by going to the history of the computer and clicking on each individual alert to find the window that pops up with those details. 

Any chance you can improve the alert report to include this data?





OneFS Events and Alerts

The OneFS Cluster Event Log (or CELOG) provides a single source for the logging of events that occur in an Isilon cluster. Events are used to communicate a picture of cluster health for various components. CELOG provides a single point from which notifications about the events are generated, including sending alert emails and SNMP traps.

Cluster events can be easily viewed from the WebUI by browsing to Cluster Management > Events and Alerts > Events. For example:


Or from the CLI, using the ‘isi event events view’ syntax:

# isi event events view 2.370158

ID: 2.370158

Eventgroup ID: 271428

Event Type: 600010001

Message: The snapshot daemon failed to create snapshot ‘Hourly – prod’ in schedule ‘Hourly @ Every Day’: error: Name collision

Devid: 2

Lnn: 2

Time: 2018-04-09T17:01:33

Severity: warning

Value: 0.0

In this instance, CELOG communicates on behalf of SnapshotIQ that it’s failed to create a scheduled hourly snapshot because of an issue with the naming convention.

At a high level, processes that monitor conditions on the cluster or log important events during the course of their operation communicate directly with the CELOG system. CELOG receives event messages from other processes via a well-defined API.

A CELOG event often contains the following elements:




Events are generated by the system and may be communicated in various ways (email, snmp traps, etc), depending upon the configuration.


Specifiers are strings containing extra information, which can be used to coalesce events and construct meaningful, readable messages.


Extra chunks of information, such as parts of log files or sysctl output, added to email notifications to provide additional context about an event.

For example, in SnapshotIQ event above, the event text contains a specifier and attachment that has been mostly derived from the corresponding syslog message:

# grep “Hourly – prod” /var/log/messages* | grep “2018-04-09T17:01:33”

2018-04-09T17:01:33-04:00 <3.3> tme-sandbox-2 isi_snapshot_d[5631]: create_schedule_snapshot: snapshot schedule (Hourly @ Every Day) pattern created a snapshot name collision (Hourly – prod); scheduled create failed.

So what happens under the hood? CELOG is a large, complex system, which can be envisioned as a large pipeline. It gathers events and statistics info on one end from isi_stats_d and isi_celog_monitor, plus directly other applications such as SmartQuotas, SyncIQ, etc. These events are passed from one functional block to another, with a database at the end of the pipe. Along the way, attachments may be generated, notifications sent, and events passed to a coalescer.

On the front end, there are two dispatchers, which pass communication from the UNIX socket and network to their corresponding handlers. As events are processed, they pass through a series of coalescers. At any point they may be intercepted by the appropriate coalescer, which creates a coalescing event and which will accept other related events.

As events drop out the bottom of the coalescer stack, they’re deposited in add, modify and delete queues in the backend database infrastructure. The coalescer thread then moves onto pushing things into the local database, forwarding them along to the master coalescer, and queueing events to have notifications sent and/or attachments generated.

The processes of safely storing events, analyzing them, deciding on what alerts to send and sending them is separated into four separate modules within the pipeline:


The following table provides a description of each of these CELOG modules:




The first stage in the processing pipeline, Event Capture is responsible for reading event occurrences from the kernel queue, storing them safely on persistent local storage, generating attachments, and queueing them by priority for analysis.


Extra chunks of information (log file extracts, sysctl output, etc) are added to alert notifications to provide additional context about an event.


The Reporter is the third stage in the processing pipeline, and runs on only one node in the cluster. It periodically queries Event Analysis for changes and generates alert requests for any relevant conditions.


The Alerter is the final stage in the processing pipeline, responsible for actually delivering the alerts requested by the reporter. There is a single sender for each enabled channel on the cluster.

CELOG local and backend database redundancy ensures reliable event storage and guards against bottlenecks.

By default, OneFS provides the following event group categories, each of which contain a variety of conditions, or ‘event group causes’, which will trigger an event if their conditions are met:


Say, for example a chassis fan fails in one of a cluster’s nodes. OneFS will likely capture multiple hardware events. For instance:

  • Event # 90006003 related to the physical power supply
  • Event # 90020026 for an over-temperature alert

All the events relating to the fan failure will be represented in a single event group, which allows the incident to be communicated and managed as a single, coherent issue.

Detail on individual events can be viewed for each item. For example, the following event is for a drive firmware incompatibility.

Drilling down into the event details reveals the event number – in this case, event # 100010027:


The “Open Event Help” link on each event group detail window will bring up the specific info page for each event from the OneFS help guide.


OneFS events and alerts info is also available online at the following URL:


The Event Help information will often provide an “Administrator Action” plan, which, where appropriate, provides troubleshooting and/or resolution steps for the issue.

For example, here’s the Event Help for snapshot delete failure event # 600010002:


The OneFS WebUI Cluster Status dashboard shows the event group info at the bottom of the page.


More detail and configuration can be found in the Events and Alerts section of the Cluster Management WebUI. This can be accessed via the “Manage event groups” link, or by browsing to Cluster Management > Events and Alerts > Events.