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

Emails

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.

Related:

messagelabs.com blocking our mail even though our reputation is good

I need a solution

Hi, we are unable to send mails to a user that has symantec mail cloud security. 

 Sender identification U=intermepro D=intermepro.com S=horacio@intermepro.com
Connecting to cluster3.eu.messagelabs.com [46.226.52.99]:25 … connected
  SMTP<< 501 Connection rejected by policy [7.7] 26308, please visit www.messagelabs.com/support for more details about this error message.

We believe this might be an error as we dont see any spam issues on the server, and the IP is totally clean.  (108.170.21.50  / 108.170.21.51 )

Could you please help us identifying the problem to work towards a resolution?

Thanks!

0

Related:

lost connection with cluster8.eu.messagelabs.com[46.226.52.194] while performing the EHLO handshake

I need a solution

Hi,

we cannot send emails (several users are experiencing this) to any server under clusterXX.eu.messagelabs.com

Our IPs are not blacklisted, but still getting our mail hold in the queue with message:
(lost connection with cluster8.eu.messagelabs.com[46.226.52.98] while performing the EHLO handshake)
or
(lost connection with cluster3.eu.messagelabs.com[85.158.142.99] while performing the EHLO handshake)

Can you please give a look?

Thanks,

F:

0

Related:

7022903: Multi-tenant SMTP redirection logic

Note: This page applies to systems updated to SMG after April 2018 update. Prior versions did not have the same architecture.

This page provides details of how the SMG SMTP interface manages connections between sender and recipient servers, with particular attention to how messages are handled when the sender and recipients exist within the same SMG environment.

For most situations, where email comes in, or goes out of an SMG system, the expected behavior of SMG being a middleman process between the relevant SMTP end points will occur. In these core cases messages will be defined as inbound or outbound as expected for the purpose of selecting policies to use for filtering.

The two situations identified in the diagram with red lines indicate unusual or mis-configured situations. In the case of external direction, this implies relay protection is not enabled if email is allowed. In the case of sender/recipient share OU, this should not be a configuration scenario, as it suggests an email server is sending its own mail with a loopback through SMG. Although both are possible and acceptable, having mail delivery in either of these situations should be well understood.

The specific case where multi-tenant logic overrides the regular flow of connectivity is where a message is sent between two domains hosted by an SMG system, where the two domains exist in separate OUs. In this situation, there are two separate sets of policies that need to be considered. For the sender, the outbound policy of their OU must be used. For the recipient, the inbound policy of their OU must be used. The implementation of this is performed through a loopback mechanism with SMTP.

When a loopback message is encountered, on the first hop, SMG treats the recipient as external for the purpose of direction and next-hop connectivity. The next-hop ignores the locally defined addresses and instead looks up the MX record of the target domain. It is useful to understand that when multiple MX records exist, this may cause the message to come back through a different SMG server than the one that has received the original connection. During this connection phase, the SMG server will detect that the next-hop system is an SMG server by the presence of the ESMTP EHLO keyword ‘X-SMGFLAGS’. If the loopback server responds as expected, the MAIL command is given the parameter ‘X-SMGReentrant=1’ to indicate to the next hop that the message being received must be treated as if it were coming from an unknown sender.

When the second hop SMG server receives a connection that indicates hat the sender is external, by way of the ‘X-SMGReentrant=1’ flag being present on the MAIL line, the sender is treated as unknown and the direction is defined accordingly based on the recipient address. The address should be to a known address within the system and be treated as inbound. If the sender is not internal, which would only occur by either MX misconfiguration or direct attempt to add the parameter, the message will be rejected as an attempted relay (presuming relay prevention is correctly configured).

The net result of this inter-OU handling process is that policies are process independently and in order by each OU. Rejection at either the sender or recipient OU will chain correctly via the SMTP protocol. Isolation of domains and OUs through the SMTP protocol also helps to locate issues where inter-OU mail flow occurs.

Related:

Problem In Sending Email to Messagelabs

I need a solution

Hi,

We are a email service provider. Suddenly all of our customer having problem in sending email to messagelabs. Below is the bouncing message. Could you advise how to fix this? Our email sending IP is 203.194.220.41. This is different from the  website server IP 203.194.220.53. Thanks.

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its

recipients. This is a permanent error. The following address(es) failed:

 xxxxxx@tokiomarineasia.com

    all hosts for ‘tokiomarineasia.com’ have been failing for a long time (and retry time not reached)

Reporting-MTA: dns; jumphk3.net

Action: failed

Final-Recipient: rfc822;xxxxxxxxx@tokiomarineasia.com

Status: 5.0.0

=============

Mail delivery failed: returning message to sender

From

Mail Delivery System

To

xxxxxxxx@ibnrinsurance.com

Date

Today 08:11

Message Body

This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:   xxxxxxx@hkfi.org.hk     all hosts for ‘hkfi.org.hk’ have been failing for a long time (and retry time not reached)  xxxxxxx@hkfi.org.hk     all hosts for ‘hkfi.org.hk’ have been failing for a long time (and retry time not reached)   xxxxxx@hkfi.org.hk     all hosts for ‘hkfi.org.hk’ have been failing for a long time (and retry time not reached)   selina@hkfi.org.hk     all hosts for ‘hkfi.org.hk’ have been failing for a long time (and retry time not reached)   xxxxxx@hkfi.org.hk     all hosts for ‘hkfi.org.hk’ have been failing for a long time (and retry time not reached)

Reporting-MTA: dns; jumphk3.net Action: failed Final-Recipient: rfc822;xxxxxx@hkfi.org.hk Status: 5.0.0

0

Related:

“501 Connection rejected by policy”

I need a solution

Hello!

We are a company offering various hosting services.

Recently, one customer have complained over Mail delivery failed: returning message to sender

Server ip  162.210.98.151 (deszr.com)

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
 
SMTP error from remote mail server after initial connection:
501 Connection rejected by policy [7.7] 5608, please visit www.messagelabs.com/support< http://www.messagelabs.com/ support>
 

I would appreciate if anyone could help to this matter.

Thank you very much and good day.

0

Related:

A non-delivery report with a status code of number was generated for recipient address (Message-ID message id). Causes: A looping condition was detected. (The server is configured to route mail back to itself). If you have multiple SMTP Virtual Servers configured on your Exchange server, make sure they are defined by a unique incoming port and that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers. Solution: Check the configuration of the virtual server??s connectors for loops and ensure each virtual server is defined by a unique incoming port.

Details
Product: Exchange
Event ID: 3017
Source: MSExchangeTransport
Version: 6.5.6940.0
Component: Microsoft Exchange Transport
Message: A non-delivery report with a status code of number was generated for recipient address (Message-ID message id). Causes: A looping condition was detected. (The server is configured to route mail back to itself). If you have multiple SMTP Virtual Servers configured on your Exchange server, make sure they are defined by a unique incoming port and that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers. Solution: Check the configuration of the virtual server??s connectors for loops and ensure each virtual server is defined by a unique incoming port.
   
Explanation

This Error event is logged when a non-delivery report (NDR) is generated because of a detected message looping condition. This typically indicates that the server is configured to route mail back to itself.

   
User Action

If you have multiple SMTP virtual servers configured on your Exchange server, make sure that they are configured with a unique incoming port and that the outgoing SMTP port configuration is valid. Make sure that all of the connectors are correctly configured. For example, make sure that no connectors have the address space of the local organization, unless you share the domain, and that you do not select Use DNS to route to each address space on this connector.

For more information, see the following articles in the Microsoft Knowledge Base:

Related:

A non-delivery report with a status code of number was generated for recipient %2 (Message-ID id). Cause: The maximum hop count was exceeded for this message. This non-delivery report can also be caused if a looping condition exists between sending and receiving servers that are not in the same Exchange organization. In this situation, the message bounces back and forth until the hop count is exceeded. A configuration error in the e-mail system can also cause the message to bounce between two servers or to be forwarded between two recipients. Solution: The maximum hop count is a property set on each virtual server and you can manually override it. The default maximum hop count is 15. Also, check for any situations that might cause loops between servers.

Details
Product: Exchange
Event ID: 3005
Source: MSExchangeTransport
Version: 6.5.6940.0
Component: Microsoft Exchange Transport
Message: A non-delivery report with a status code of number was generated for recipient %2 (Message-ID id). Cause: The maximum hop count was exceeded for this message. This non-delivery report can also be caused if a looping condition exists between sending and receiving servers that are not in the same Exchange organization. In this situation, the message bounces back and forth until the hop count is exceeded. A configuration error in the e-mail system can also cause the message to bounce between two servers or to be forwarded between two recipients. Solution: The maximum hop count is a property set on each virtual server and you can manually override it. The default maximum hop count is 15. Also, check for any situations that might cause loops between servers.
   
Explanation

This event is logged when a non-delivery report is generated because a message exceeded the maximum hop count. The default maximum hop count for SMTP virtual servers in Exchange Server 2003 is 30. The hop count to use depends on the organization’s Exchange topology. The default value is generally large enough for most Exchange environments. This event can also be logged if a looping condition exists between sending and receiving servers that are not in the same Exchange organization.

   
User Action

To resolve this error, try one or both of the following:

  • Examine the Exchange routing topology and make sure that no looping condition exists.
  • Increase the hop count on the appropriate SMTP virtual servers.

Related:

The originating IP address of message with ID could not be determined based on its Received headers.

Details
Product: Exchange
Event ID: 7519
Source: MSExchangeTransport
Version: 6.5.7638.0
Component: Microsoft Exchange Transport
Message: The originating IP address of message with ID <%1> could not be determined based on its Received headers.
   
Explanation

This event indicates that Sender ID filtering is not able to correctly process a message. This error may occur if one of your servers is issuing non-standard receive headers. This error may also occur if you have not correctly configured the list of internal servers.

   
User Action

To resolve this error, do one or more of the following:

  • Ensure that the servers in front of the servers in your perimeter network are configured to correctly issue received headers.
  • Ensure that you have correctly configured the list of IP addresses to exclude from Sender ID filtering. Use the following procedure to specify the list of servers.
  • To specify IP address configuration data for Sender ID filtering:

  1. Start System Manager. Click the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.
  2. Double-click Global Settings.
  3. Right-click Message Delivery, and then click Properties.
  4. On the General tab, click Add.
  5. Under Perimeter IP List and Internal IP Range Configuration, click Add.
  6. In Sender ID and Connection Filtering Configuration Settings, the IP addresses that you configured to be excluded from Sender ID filtering and connection filtering are displayed. If an IP address on the e-mail message received by the Sender ID or connection filtering deployment server is found on this list, Exchange Server will skip the IP address without running Sender ID and connection filtering validation on it. You can add up to 196 IP addresses to list. To add an IP address to this list, click Add.
  7. In IP Address (Mask), specify the IP addresses that you want to exclude from IP address validation. You must include all servers in your Exchange organization that process incoming SMTP mail. You must also include all servers that route mail to the Sender ID and connection filtering deployment servers. If any of the servers that process SMTP mail are located on the perimeter, you should include all perimeter IP addresses of these servers. You can specify individual IP addresses or groups of IP addresses.

    • Click Single IP address to specify an individual IP address to be excluded from Sender ID filtering and connection filtering. In IP address, type the IP address of the computer you want to exclude from Sender ID filtering.
    • Click Group of IP addresses to specify an entire subnet to exclude from Sender ID filtering and connection filtering. In Subnet address, specify the subnet address of the subnet you want to exclude. In Subnet mask, type the subnet mask for the subnet you want to exclude.
  8. Restart the Simple Mail Transfer Protocol (SMTP) service.

For information about how to configure Sender ID filtering, see “Configure Sender ID Filtering” in the Exchange Server 2003 SP2 Online Help.

Related:

Anti-spam agents are enabled, but the list of internal SMTP servers is empty. If there are any MTAs between this server and the Internet, populate this list by using the Set-TransportConfig cmdlet in the Exchange Management Shell.

Details
Product: Exchange
Event ID: 1022
Source: MSExchangeTransport
Version: 8.0
Symbolic Name: InternalSMTPServerListEmpty
Message: Anti-spam agents are enabled, but the list of internal SMTP servers is empty. If there are any MTAs between this server and the Internet, populate this list by using the Set-TransportConfig cmdlet in the Exchange Management Shell.
   
Explanation

The Warning event indicates that Microsoft Exchange Server 2007 anti-spam agents are enabled and the list of internal Simple Mail Transfer Protocol (SMTP) servers is empty.

In some organizations, the Hub Transport server role or Edge Transport server role that is running connection filtering is installed on computers that don’t process SMTP requests directly on the Internet. In this scenario, the Exchange 2007 transport server is behind another front-end SMTP server that processes inbound messages directly from the Internet. The Connection Filter agent must be able to extract the correct originating IP address from the message. To extract and evaluate the originating IP address, the Connection Filter agent must parse the Received headers from the message and compare those headers with the known SMTP server in the perimeter network.

When an RFC-compliant SMTP server receives a message, the server updates the message’s Received header with the domain name and IP address of the sender. Therefore, for each SMTP server that is between the originating sender and the Exchange 2007 transport server, the SMTP server adds an additional Received header entry.

   
User Action

To resolve this warning, you must specify all internal SMTP servers on the transport configuration object in the Active Directory directory service forest before you run connection filtering.

Specify the internal SMTP servers by using the InternalSMTPServers parameter on the Set-TransportConfig cmdlet. For more information, see Set-TransportConfig.

For more information about how to configure connection filtering see Configuring Connection Filtering.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related: