Some monitors and rules have default thresholds that might need additional tuning to suit your environment. You should evaluate monitors and rules to determine whether the default thresholds are appropriate for your environment. If a default threshold is not appropriate for your environment, you should adjust the threshold by overriding it.
See the Reference Guide for a complete list of monitors and rules available in Citrix SCOM Management Pack for XenApp and XenDesktop
For this purpose, you must import the optional Citrix Management Pack for XenApp and XenDesktop SLA Dashboards management pack into SCOM. It provides service level objectives (SLA and SLO objects) for XenApp and XenDesktop environment monitoring.
The Citrix Management Pack for XenApp and XenDesktop SLA Dashboards management pack has the following dependencies:
The Citrix Management Pack for XenApp and XenDesktop SLA Dashboards management pack requires Microsoft System Center Operations Manager 2012 R2.
For instructions on how to import the unsealed management pack, see Manually importing included management packs into SCOM. The management pack is located in the %ProgramFiles%\Citrix\XenDesktop MP folder in the Comtrade.XenApp.And.XenDesktop.SLADashboards.xml file.
Citrix Management Pack for XenApp and XenDesktop SLA Dashboards is an example of how SCOM 2012 SLA dashboards can be used together with the Citrix SCOM Management Pack for XenApp and XenDesktop which collects all the information needed to create useful and personalized service level objectives for your environment. This sample management pack includes the following pre-set definitions for service level objectives:
In real world scenarios, you would create different service level tracking rules for each Site and delivery group in your organization. You may also want to include other parameters for setting the service level objectives.
Note: The management pack also provides two service level views which report on service level objectives defined in service level tracking rules. For a complete list available monitors and performance collection rules that can be used to set service level objectives, see Citrix SCOM Management Pack for XenApp and XenDesktop Reference Guide, available from Tuning thresholds for monitors and rules.
Once the management pack is imported, locate the views in the Monitoring view in the SCOM Operations console as seen in the following figure.
The Delivery Group SLA Dashboard and Site SLA Dashboard views are not configured by default, so you must select one or more service level tracking rules for each of the views.
To configure the Delivery Group SLA Dashboard view, do the following:
4. In the Update Configuration wizard window, click Next.
5. In the Scope page, click Add.
6. In the Add SLA dialog box, in the Service Level column, select Desktop OS Group Health and click Add.
7. Repeat step 6 for Server OS Delivery Group Health.
8. Click OK to close the dialog box.
9. In the Scope page, adjust the time interval for the SLA.
10. Click Finish to close the wizard.
Once the view is refreshed, it shows the delivery group service level objective report for the time period selected, as shown in the figure that follows.
To configure the Site SLA Dashboard view, do the following:
4. In the Update Configuration wizard window, click Next.
5. In the Scope page, click Add.
6. In the Add SLA dialog box, in the Service Level column, select Site Health and click Add.
7. Click OK to close the dialog box.
8. In the Scope page, adjust the time interval for the SLA.
9. Click Finish to close the wizard
Citrix Management Pack for XenApp and XenDesktop SLA Dashboards also includes some general service level target rules that may be used as an example. To make the SLA dashboards useful in practice, you must create your own SLAs that are tailored to your needs.
Following the steps below, a new SLA for a Site named "Boston" will be created, and it will check whether we are crossing maximum allowed number of concurrent users, since we only have 1,000 concurrent licenses available.
Perform the following:
5. Click Next.
6. In the Objects to Track page, click Select.
7. In the Select a Target Class dialog box, from the Search result filter drop-down list, select All.
8. In the Target column, select XAXD Site and then click OK to close the dialog box.
9. In the Objects to Track page, from the Select destination management pack drown-down list, select a custom management pack where this SLA will be stored. If no such management pack exists, create a new one.
10. Click Next.
11. In the Service Level Objectives page, click Add and select Collection rule SLO.
12. In the Service Level Objective (Collection Rule) dialog box, type a display name in the Service level objective name text box.
In our example, type Maximum Concurrent Users.
13. Under Targeted class, click Select. In the dialog box, in the Target column, select XAXD Site Data Collector and then click OK to close the dialog box.
14. Under Performance collection rule, click Select. In the dialog box, in the Name column, click Number of Concurrent Users (Performance DB DW) and then click OK to close the dialog box.
15. Under Aggregation method, click Max.
In our example, we do not want more users at any time.
16. From the Service level objective goal drop-down list, select Less Than and then type 1000 in the text box.
17. Click OK to close the Service Level Objective (Collection Rule) dialog box.
18. In the Service Level Tracking wizard window, click Next.
19. In the Summary page, click Finish.
Once the new SLA is created, you can use it in the SLA dashboards as explained in Configure dashboards with default SLAs.
You can use the procedure in this section to create personalized SLAs for sites, delivery groups, or any other object that the Citrix SCOM Management Pack for XenApp and XenDesktop discovers. For a complete list of performance rules and availability monitors that can be used to configure service level objectives, see Citrix SCOM Management Pack for XenApp and XenDesktop Reference Guide, available from Tuning thresholds for monitors and rules.
To monitor large XenApp and XenDesktop environments, you can configure the SCOM Connector to be used for transferring data related to the discovered objects from the agent to the SCOM Management server. This includes the number of Delivery Groups, Server OS machines, applications, and application folders.
Note: Environments with more than 100 Delivery Groups, 600 Server OS machines, and 1,500 applications are considered large.
To configure the SCOM Connector, you must set up the SCOM Administrator account in the XenApp and XenDesktop MP Configuration tool and enable the Applications Discovery and Delivery Groups and Hypervisor Connections Discovery rules. For more information, see the Configuring SCOM Administrator section in Install and configure.
The credentials of this account are used by the SCOM Connector to connect to the SCOM server. The SCOM Connector uses SCOM's SDK service and the Operations Manager Connector Framework to fetch data related to discovered objects from the XenApp and XenDesktop environment. This includes the number of Delivery Groups, Server OS machines, applications, and application folders. This enhancement increases the size of data that can be transferred from the agent to the SCOM server compared to earlier versions, significantly increasing the scale of the environment that can be discovered.
Before any desktop or application can be brokered by XenApp and XenDesktop, Virtual Delivery Agent (VDA) installed on the desktop or server machine has to register with one of the Delivery Controllers in a XenApp and XenDesktop Site. This is done each time a machine is started. If the machine is not registered correctly, it cannot be used. Thus, these situations may have a big impact on the number of available machines in a delivery group.
There are many causes why a registration may fail, including no VDA being installed on a desktop or server machine, DNS problems, firewall configuration, time synchronization, and so on.
Citrix SCOM Management Pack for XenApp and XenDesktop monitors via the Failed Registrations in Delivery Group monitor if a certain machine in a delivery group could not register itself with the XenDesktop broker. If a failed registration is detected, the corresponding delivery group health status changes to Warning and alert is generated and displayed in the Alerts view and in the Failed Registrations view in Machines folder. Both views also contain alerts for each failed registration of a machine, with details on a machine name, a delivery group name, and a Site name. Additional details may also be found in the Event view, where all Citrix-related Windows events are logged.
Failed registrations are monitored only for the powered-managed virtual machines and not for managed physical machines.
Machine and session monitoring functionality enables an insight into performance of server OS machines, server OS sessions, and desktop OS sessions. You have the possibility to receive alerts when a specific machine or session metric crosses a threshold, and you can generate reports.
Note: Alerts based on performance thresholds are generated only when the product's Machine Agent is installed and configured.
The following reports are available:
Performance metrics of this report are available only when Machine Agent is installed and configured.
When Citrix SCOM Management Pack Agent for XenApp and XenDesktop is installed on one or more computers, referred to as proxy nodes, machine and session performance data can be collected. Data is collected remotely by using Windows Remote Management (WinRM). Machine Agent first communicates with a XenApp and XenDesktop Delivery Controller to get a list of the registered machines. It then utilizes WinRM to collect performance data from the machines.
Proxies use WinRM with Kerberos authentication to communicate with machines and Delivery Controllers. All WinRM communication is done in the context of an account that is configured for the Citrix MPXAXD Machine Agent service on the proxy node. For this communication to work all machines (server OS and desktop OS) must have WinRM 2.0 installed and enabled (default TCP port: 5985, enabled Kerberos authentication).
In advanced scenarios, you can use different accounts for WinRM communication for different machines. In the XenDesktop MP Configuration tool, you can specify machine hostname mask and account pairs. For any machine matching specific machine hostname mask, the corresponding user account is used for WinRM communication. For machines without matching hostname mask, the Citrix MPXAXD Machine Agent service user account is used.
Each instance of Citrix SCOM Management Pack Agent for XenApp and XenDesktop (each proxy node) can be configured to monitor machines for one or more Delivery Controller instances. However, every Delivery Controller can be monitored by no more than one Machine Agent instance.
Important: In a multi-Site environment, if a Machine Agent instance monitors multiple Delivery Controllers, these Controllers must belong to the same XenApp and XenDesktop Site.
Possible Machine Agent configurations (deployments) therefore are:
Best practice is to configure Machine Agents (on proxy nodes) to monitor performance of no more than 2,000 concurrently running server OS or desktop OS machines. In environments where the number of machines registered with each Delivery Controller is smaller, you can configure one proxy node to handle multiple Deliver Controller instances. As a general rule configuration with one proxy node per Delivery Controller is appropriate for any type of XenApp and XenDesktop environment.
For examples of proper Machine Agent deployment for Sites with different number of concurrently running machines, see the following figures.
Proxy nodes sizing - for Site with 1,000 machines and two Controllers
Proxy nodes sizing - for Site with 3,500 machines and two Controllers
Proxy nodes sizing - for Site with 5,000 machines and three Controllers
Size of the Operations Manager database depends on the size of the XenApp and XenDesktop environment. Citrix SCOM Management Pack for XenApp and XenDesktop installs additional datasets to Operations Manager data warehouse database. It provides better, more comprehensive as well as more optimized data collection and data processing for better XenApp and XenDesktop architecture and end-user analysis, planning, and troubleshooting.
The maximum database space consumption for a few sample environments with default database grooming is presented in the table that follows.
|Users (approximate number)||500||2,000||10,000|
|Desktop OS delivery groups||2||4||6|
|Server OS delivery groups||3||4||6|
|Server OS machines||10||50||500|
|Concurrent application sessions||400||1,500||7,000|
|Concurrent desktop sessions||100||500||3,000|
|Sizes (in MB):
DB / DW / Total
|Working hours: 8x5||57 / 443 / 500||98 / 1405 / 1503||295 / 6956 / 7215|
|Working hours: 24x7||57 / 1031 / 1088||98 / 3756 / 3854||295 / 18705 / 19000|
Important: In large environments with numerous concurrent sessions, increasing the retention interval may have significant impact on the SCOM data warehouse database.
Citrix SCOM Management Pack for XenApp and XenDesktop consists of two custom datasets: Machine dataset and Session dataset. Each dataset provides tables for performance data and tables for stale or discovery data. Grooming for tables is specified in number of days and the default values are provided in table that follows.
Machine dataset grooming
Session dataset grooming
To change grooming settings, do the following:
For general instructions about how to import management packs into SCOM, see the How to Import an Operations Manager Management Pack webpage on the Microsoft TechNet website.
To import the sealed Citrix SCOM Management Pack for XenApp and XenDesktop manually, do the following:
Customization of the sealed management packs that XenApp and XenDesktop Management Pack provides is similar to the default SCOM management pack customization. For details, see the Microsoft TechNet website: