• Change Organization Owner

    As part of the creation of any ControlUp Organization, a specified user is assigned to be the organization owner. That user is generally the first user to install the ControlUp license and open the ControlUp console. The organization owner has certain privileges managing the organization, such one-time passcode (OTP) authentication settings and audit log settings.

    Only the organization owner can transfer ownership to another user in the organization (and subsequently, no longer be the owner). We recommend assigning an Active Directory group as the organization owner so that if an organization owner is no longer an employee of the company, there is no problem with access to the ControlUp organization owner privileges. 

    If, for any reason, the organization owner is not able to transfer ownership, contact support@controlup.com to assign a new organization owner.

    To change an organization owner:

    1. Log into the ControlUp console as the organization owner and open the Security Policy pane from the bottom of the screen.
    2. Click Manage Roles in the Home ribbon, the Security Settings screen appears.
    3. In the New Owner box enter the user you want to be the organization owner. We recommend selecting an Active Directory group of users as the organization owner.
      If there isn't an existing group of users appropriate for this role, create one in your Active Directory and then assign this role.
    4. Click Apply and the organization owner is changed.
  • Audit Log


    The Audit Log feature is available from version 8.2 and above.

    The Audit Log enables you to see:

    • Changes made to ControlUp’s configuration settings, such as adding a new hypervisor.
    • Remote operations performed on managed assets through ControlUp, such as rebooting a virtual machine or killing a process on a managed computer.

    The Audit Log does NOT collect information on setting changes to personal preferences, such as column presets, and any user management activities, such as user signing in/out.

    These logs are primarily used in corporate environments. The audit log uploads data to the ControlUp cloud or can be configured to save to a local SysLog server. The Audit Log is by default, configured to enable centralized auditing in hybrid cloud environments.

    Auditing Methods

    Group Actions

    The auditing is carried out separately for each OBJECT on each TARGET and includes all details and completion status for each audit log entry.

    Auditing Optimizations

    The initialization and completion records carry only the relevant data to save storage and traffic.

    The initialization record contains all data except the output, while the completion record contains the output, status, and the error message if the action failed. 

    In the case of mass/group activity in public configuration, we have separate 'initialized' audit log entries for each object and one common 'completion' entry for all objects in the group because in such case the action is completed successfully for all objects or failed for all objects.

    The Audit Log documents up to ten automated action executions, per trigger, per minute in the organization. If the number of executions exceeds the limit, the automated actions run without auditing, even if the enforced mode is enabled.

    The following audit log entry is added to document the exception in CA: 
    "The amount of audit log entries generated by the trigger exceeds the permitted limit and will be silenced for a while."

    Storing the Audit Logs

    The Audit Logs may be stored in the following ways:

    • ControlUp cloud: This is the default configuration for hybrid cloud environments. Once support for the cloud data-store is implemented, it is possible to view an audit log report in SOLVE. The data is retained in this log for a period of a year after it was first recorded. This option is NOT available for on-premises implementations.
      For complete information on viewing Audit Logs, see here.
      The following is an example of the Audit Log stored in SOLVE.
    • SysLog: The contents of the SysLog data-store can be viewed using any standard SysLog reader (e.g. Splunk). On-premises implementations can only store audit logs on their SysLog Servers.
      The following is an example of the Audit Log stored on a Syslog Server.

    Actions are reported in the Audit Log as two separate entries; once for initialization of the action and once for completion of the action. 

    Audit Log Settings

    Only the organization owner can modify the audit log settings. The organization owner is displayed and managed in the Security Settings pane in the consoled.

    Go to the Audit Log tab by clicking Audit Log from the Settings ribbon and the Audit Log page appears.


    • Enable Centralized Auditing - For enabling/disabling the audit log data-storage in the hybrid cloud environment.
      • Fail action if auditing fails - Enforced mode. Prevents actions from being executed if the auditing was not completed properly. Not available in SysLog.
    • Send to SysLog Server -Enables you to save the auditing records to a SysLog server by entering its:
      • IP/hostname - Enter the IP address or hostname of the SysLog server.
      • Port - Enter the port to use to connect to the SysLog server.
      • Protocol Select the protocol to use to connect to the SysLog server – UDP or TCP

    Once you have finished making changes to the settings, click Apply to save the changes or OK to save the changes and close the window.

    Audit Logs Data

    For each entry in the audit logs, the following information is stored: 




    The ID of the performed action. All audit entries related to the same event have the same unique identifier.

    This is a hidden field but is essential for matching between the initialized and completed entries.


    The ID of an event performed as a group. All audit entries related to the same grouping-command have the same grouping unique identifier.

    This is a hidden field but is essential for matching records that belong to the same group-command.


    Date and time of the event.


    The source of the event (Web client, Console, PowerShell, automated action, Insights, etc.).


    The status of the event (initiated, completed, aborted, error, etc.)

    Requesting Computer

    The hostname or IP address of the computer from which the event was initiated. This can be:

    • The computer used.
    • The console, if the user performed an action from the console.
    • The monitor where the AA/cmdlet was executed.
    • The SOLVE/Insights (if available) if an action was performed manually from SolVE/Insights.

    Requesting User 

    The user account of the user who initiated the event.


    The user account that was used to execute the command.

    Note: If this is the same as the Requesting User, this field is left blank.


    The type of action that was performed (kill a process, add a computer, etc).


    Additional information that is specific to the command.

    Object Type

    The type of object on which the command was executed.


    The output of the operation.

    Executing Computer

    The name of the object on which the command was executed (computer hostname, hypervisor name, Netscaler name, organization name, username, etc).


  • ControlUp Integration with IGEL

    ControlUp can monitor IGEL endpoints via the “Linux Data Collectors” feature. This exciting combination of ControlUp and IGEL gives administrators the ultimate in visibility to their environment. From the actual user to the backend, you can see it all.


    In order to enable complete integration, ControlUp requires some configuration changes to your IGEL endpoints.

    Note: If your ControlUp is unable to connect to the IGEL device, ensure that you can connect with PUTTY using the same account you have configured for ControlUp. When you connect with PUTTY, you should end at a prompt. If you get disconnected immediately, then the same will happen to ControlUp and the integration will be unsuccessful.

    • A ControlUp Monitor Cluster is highly recommended for monitoring your endpoints.
    • IGEL OS 10+ with Enterprise Management Pack.
    • In the Agent Settings > Enable "Allow users to add machines that are running unsupported Linux flavors"


    1. Download and extract the ControlUp Integration pack here
    2. On your IGEL UMS server, import the two ControlUp files.
    3. Create a new Profile and assign it to your IGEL endpoints.|
      1. Ensure that your Mount Point field is /custom 
        This is case sensitive.IGEL_Integegration1.png
      2. Ensure that the Initializing Action field is /custom/ControlUp/linuxInstall.sh 
        This is case sensitive.IGEL_Integegration2.png
    4. Add the IGEL endpoints to the ControlUp Console.
      1. Linux Data Collector.
        • Create a new Linux Data Collector.
        • Add the shared credentials.
        • Add the IGEL devices. This can be done via a text file with the DNS resolvable name of all the IGEL devices or via IP address or range (DNS must resolve to these devices).
      2. Devices that have already been added to a Linux Data Collector.
        • If you have added your IGEL endpoints to your ControlUp console you can watch the installation of the integration in ControlUp.

    ControlUp Management Pack for IGEL

    ControlUp has created an initial set of Management Script Actions that can be used on IGEL devices. The scripts that can be run are as follows:

    Machine Actions:

    • Get Machine Details
    • List Assigned Profiles
    • Reboot
    • Send Wake Up
    • Shadow Terminal
    • Update configuration from UMS

    Session Actions:

    • Get Machine Details

    These script actions are natively integrated into the Console when it detects an IGEL operating system. You can activate the script actions in two ways.

    1. Right-click on the name of the IGEL device and choose “Recommended Actions”.
    2. If you have “Show Recommendations for Non-Stressed Metrics” enabled in “Display”, then clicking the “image2.png” icon will reveal the Top Recommended Actions menu.

    Happy Monitoring!

  • Notification Templates

    June 2019

    Notification Templates


    This summary briefly explains how to create custom notification templates in ControlUp for use with Incident Triggers. All steps are performed from a ControlUp Console. More detailed information about creating notification templates and assigning them to Incident Triggers can be found in the rest of this guide.

    Step 1.
    In the Trigger Settings window, select Templates. The Template Settings dialog box opens, and lists the currently defined notification templates (see Creating a New Template).

    Step 2.
    Select an existing template to use as the basis for the custom template, and then select Duplicate. A copy of the existing template opens.

    Step 3.
    Under Template Name, enter a name for the custom template.

    Step 4.
    Modify the Subject and Body fields as required.
    Note: To see a list of variables that can be used in these fields, select variables.

    Step 5.
    Select OK. The template is created.
    Note: For information about assigning the template to an Incident Trigger, see Assigning a Template to a Trigger.


    Notification templates are used by ControlUp to create follow-up notifications when Incident Triggers are activated. They are used either to create e-mail notifications or to insert a log entry in the Windows Event Log, and can be assigned to the following types of triggers:

    • Send an e-mail alert
    • Record an event in the application log
    • Send an e-mail alert via a local SMTP server
    • Run an action

    Templates can include both text and variables; the variables are replaced by specific information about the trigger in the actual notification text. The message body may also include other text, before and/or after the template text, that is predefined by ControlUp and cannot be modified or removed (e.g., “This is an automated alert...”).

    In older versions of ControlUp, templates were all predefined by ControlUp. Beginning with ControlUp v7.4, you can also create custom templates. Thus, you can add additional information to a notification or create a notification whose text is in French.

    Predefined templates cannot be edited or deleted, but they can be duplicated, and the duplicates can be modified or deleted. This is, in fact, how all custom templates are created – by making a duplicate of an existing template and modifying it.

    Using Variables in a Template

    Variables that can be used in notification templates have the form $(…), where the name of the variable is in the parentheses. For example: $(ObjectName) is a variable whose name is ObjectName, and it is used to insert the name of the object whose behavior generated the trigger into a notification. Variables can be included anywhere in the subject line or the body of a template. For example, the template body could include this line:

    The $(ObjectName)object has been disconnected from monitoring.

    In the actual notification, it would then say something like:

    The my-pc.domain.com object has been disconnected from monitoring.

    Not all variables are relevant to all triggers. For example, if the trigger is related to computer stress, no process is directly connected to it, so the $(ProcessName) variable is not defined. A complete list of supported variables, including descriptions of each variable and the contexts in which it is defined, is available from the link below. This list is presented as a spreadsheet in which the first four columns define and explain the variable, and the remaining columns show the contexts in which the variable is defined.

    Note: Variable names are not case-sensitive.

    List of variables: Link


    Variable list ( mceclip4.pngin a column indicates the variable is defined in the context of that column)

    Multi-Counter Variable

    In addition to the variables described above, another type of variable exists. This variable, ListOfColumns, is a special variable that is invoked multiple times in multi-counter incidents – once for each counter involved. The variable is only for use with Stress Level or Advanced triggers, because these are the only triggers that can include multiple conditions.

    The ListOfColumns variable has a special syntax, in which you can include the text and variables you would like to see for each counter involved in the incident. All of the text must be placed within the variable’s parentheses, after a colon and between quotation marks (e.g., $(ListOfColumns: "my text…”)). In addition, certain variables exist only for use with the ListOfColumns variable:










    Note: The variables in this category are also marked as such in the variable list. 3.png $(ListOfColumns) variables in the variable list

    The following is a sample of template text that uses the ListOfColumns variable:

    $(ListOfColumns:"          Column: $(Column)
    Value changed from $(ColumnValueBefore) to $(ColumnValueAfter)
    On ($(Timezone)): $(ColumnTimestamp)
    Threshold crossed: $(ColumnCrossedThreshold)

    If two columns – CPU and Name – were involved in this incident, the output of this code in the notification would look like this:

    Column: CPU 
    Value changed from 13% to 25%
    On (UTC +3 Jerusalem Standard Time): 13/05/2019 16:19:27
    Threshold crossed: 20%

    Column: Name
    Value changed from CPUSTRES.EXE to CPUSTRES.EXE
    On (UTC +3 Jerusalem Standard Time): 13/05/2019 16:19:27
    Threshold crossed: CPU*

    Creating a New Template

    Each template has three components:

    • Template Name: The name of the template that identifies it in the list of available templates
    • Subject: The title that will appear in the notification – in an e-mail, this is the subject line; in a log entry, this is the first line
    • Body: The text of the notification

    The Subject and Body fields of the template can include variables.

    In order to create a new template, you begin by duplicating an existing template, and then modifying it. You can select any existing template to duplicate. If you create a new template by selecting Add, the ControlUp Advanced Trigger template is duplicated.

    11.pngTo create a new template:

    1. In a ControlUp Console, in the My Organization screen, in either the Home or the Settings ribbon bar, select Triggers. The Settings window opens with the Trigger Settings tab displayed.


    Settings window with Trigger Settings tab displayed

    1. Select Templates. The Template Settings dialog box opens, and lists the currently defined notification templates. Predefined ControlUp templates are identified by a mceclip1.png icon, while user-defined templates are identified by a mceclip0.png icon. Only user-defined templates can be edited; ControlUp templates are not editable.


    Template Settings dialog box showing the list of currently defined templates

    1. Select an existing template to use as the basis for the custom template in one of the following ways:
      • Select Add. The Edit Template window opens a copy of the ControlUp Advanced Trigger template.
      • Select an existing template, and then select Duplicate. The Edit Template window opens a copy of the selected template.


    Edit Template window

    1. Under Template Name, enter a name for the custom template.
    2. Modify the Subject and Body fields as required.

    Note: To open the list of variables that can be used in these fields (see above), select variables.


    Template edited

    1. When you are finished creating the template, select OK. The Edit Template dialog box closes, and the template is added to the list of available templates in the Template Settings dialog box.

    Assigning a Template to a Trigger

    Once you have created a template, you can assign it to any trigger. This is done in the trigger’s settings.

    Note: For the Run an action follow-up action, if you choose to send an e-mail notification, you must ensure that the trigger also has the Send an e-mail alert or the Send an e-mail alert using a local SMTP server follow-up actions configured. This is because the recipients of the Run an action e-mail notification are not specified in the Run an action settings – rather, they are copied from the settings of the Send an e-mail and the Send an e-mail alert using a local SMTP server follow-up-actions.
    When the trigger is activated, the Send an e-mail and the Send an e-mail alert using a local SMTP server follow-up actions are implemented immediately; the Run an action notifications are sent to the same recipients, but after the Run an action follow-up action is completed (successfully or not).
    If no Send an e-mail and no Send an e-mail alert using a local SMTP server follow-up-actions are defined along with a Run an action follow-up action, no notification e-mails are sent for the trigger.

    11.pngTo assign a template to a trigger:

    1. In the Settings window, in the Trigger Settings window, do one of the following:
      • Select Add Trigger to create a new Incident Trigger.
      • Select an existing Incident Trigger, and then select Edit to edit an existing trigger.

    The trigger-configuration wizard opens.

    1. Define or modify the trigger settings as required until you get to the Follow-up Action screen.
    2. In the Follow-up Action screen, under Type, select the type of follow-up action. Template assignment is supported in any of the following follow-up action types:
    • Send an e-mail alert
    • Record an event in the Application Log
    • Send an e-mail alert using a local SMTP server
    • Run an action


    Selecting a follow-up action

    1. Under Template, select the template to use for the notification.
      Note: Depending on the follow-up action you chose, the fields in this screen will vary, but a Template field is included for all follow-up actions that handle notifications.
    1. If you are configuring a Run an action follow-up action, in addition to configuring the settings for the Run an action follow-up action, as you just did, you must also configure a Send an e-mail alert and/or a Send an e-mail alert using a local SMTP server follow-up action.

      To do this, repeat steps 3-4 above: This time, select Send an e-mail alert or Send an e-mail alert using a local SMTP server. Configure all of the settings. Under Template, you can select any template that is appropriate for the e-mail notification; it does not have to be the same template that you selected in the Run an action settings (Two e-mails will be sent to each recipient whenever the trigger is activated – the one that is selected here, and the one that is selected in the Run an action settings). When you are finished, both follow-up actions should appear in the list:


    Both Run an action and Send an e-mail alert configured for a trigger

    1. Configure the rest of the settings for the trigger as necessary, and then, select Finish. The trigger is configured and the notification will be generated whenever the trigger’s conditions are met.


    1. A variable appears in a notification instead of the value of the variable.
      The variable does not exist. This is most likely caused by a typo in the template, in the name of the variable. Check the variable list above to ensure the variable name is correct.
    1. A blank space appears in a notification instead of the value of the variable.
      The variable name is defined, but it has no value when this type of trigger is activated. This occurs when you include a variable in a template that is not defined in the context of the incident. Check the variable list above to ensure all variables included in the template are defined in the context of the incident (look green cells with ‘v’ in the variable list).
  • How to create a Linux Data Collector

    How to create a Linux Data Collector

    1. In a ControlUp Console, in the Home ribbon bar, select Linux Data Collector. The Linux Data Collector window opens in Add mode.


    Note: Alternatively, you can open this window from the Organization Tree. To do so, from the context menu of the organization or, if other LDCs already exist in your organization, from the Linux Data Collectors container object, select Add > Linux Data Collector.


    1. Under Name, enter a name for the LDC.


    Note: The name must be unique; multiple LDCs in a single organization cannot have the same name.

    1. Under Credentials for Data Collector, open the dropdown list and select the credentials the LDC should use to connect to each of the Linux computers that will be assigned to it. All Linux computers you assign to this LDC must be accessible using the credentials you selected.


    Note: These credentials will only be used for monitoring; privileged credentials are not required.

    1. If you want to assign computers to the LDC at this time, under Computers, select Add. The Add Computers window opens. For information about using this window to assign computers to the LDC, see Assigning Linux Computers to a Linux Data Collector.


    Note: It is not necessary to add computers to the LDC at this point. You can do so later, as necessary.

    5. Select OK. The LDC is created and appears in the Organization Tree under the Linux Data Collectors folder. If no other LDCs existed at the time this LDC was created, the Linux Data Collectors folder is created at the same time.

  • Adding Linux Computers to a Linux Data Collector

    Linux computers can be added to a Linux Data Collector (LDC) when the LDC is created or at any time afterward. For details, see How to create a Linux Data Collector. They can be added:

    • individually by IP address
    • as a group from a range of IP addresses
    • as a group from a list in a text file

    Linux machines are recognized by their IP address and their domain names. When you enter the IP address, the machine must be able to successfully pass a reverse lookup to resolve the domain name. Both the machine on which the ControlUp console is installed and the machine assigned as the Linux Data Collector must be able to resolve the reverse DNS lookup. The most efficient way to do this is to ensure that there is a DNS server that can return the domain name value based on the IP address entered.

    Note: A workaround to having a reverse DNS resolution is to edit the %windir%\System32\drivers\etc\hosts file on both the ControlUp Console server machine and the Linux Data Collector machine. 


    If you want to add Linux computers using a list in a text file, the file can include either the hostname, IP address, or FQDN of each computer. Separate computers in the list with line breaks, commas (,), semi-colons (;), or colons (:). E.g:

    To add Linux computers to an LDC:

    1. In the Home ribbon bar, select Add Computers. The Add Computers window opens with the Search Active Directory tab selected.
    2. Open the By IP address tab
    3. Select the Linux Data Collector machine that you want to add the computers to.

    4. The Ping Timeout and Connection Timeout values control how long the system waits for a response from each Linux computer during computer discovery and SSH connections. By default, the timeouts are 200ms for Ping and 1,000ms for connections. To modify these values, in the Connection Settings area, in the Ping Timeout and Connection Timeout fields, change the values as required.

    Note: If the Ping Timeout and Connection Timeout fields are not visible, to the right of the Connection Settings field, select the arrow to drop the menu down.

    5. Once you configure the IP range & other settings, select Scan and wait for the machines to be discovered and checked. During this entire process, a progress bar appears below the table (#2 below). When the process is completed, the progress bar disappears.

    The system lists all of the computers in the table. It then launches a discovery process for each of the computers in the list, and, for those it detects, attempts to connect via SSH, using the specified credentials. During this process, color-coded icons, indicating the connection status of each computer in the list, appear in the left column (#1 in the illustration below). If the system succeeds in connecting to a computer Done appears in the Description column.

    The Linux Data Collector begins installing the required RPMs on the selected machines. When the installation process is complete, the Linux computers are attached to the Linux Data Collector. In addition, they are added to the list of managed computers at the bottom of the organization tree.

  • Configuring Shared Credentials

    The ControlUp Console allows you to set a Shared Credential for use with your configured Hypervisor, XenDesktop, and Netscaler connections. 

    In order to configure a Shared Credential, go to Settings > Monitors then click the Settings button.

    If the credential you want to share is already configured, simply check the box under the "Shared" column to share it with your users. 

    If not, click "Add Credential Set" to add the credential to the Monitor.

    Add the account information for the new Shared Credential, checking the "Share credentials with authorized users" box.

    Organizational Users can not use a Shared Credential. You must create a Security Role in order to grant permission to use the shared credential. Once you've saved your credential as a shared credential, on the bottom of your Console click the Security Policy Pane and open the permissions tree for "Perform organization-wide actions"

    Scroll down to the bottom of the Organization-wide permissions tree to "Shared Credentials Store" choose the Security Role you wish to grant permissions to, and set that permission to "Allow"

    Once you have created the Shared Credential, and granted permissions to users to make use of it, it will become available to set in the Connection Settings of your Hypervisors, XenDesktop Sites, Cloud, and Netscaler Connections.

    Notes on Shared Credentials: 

    • The Shared Credentials metadata (including the friendly name, username and domain name) is stored in the organization public configuration store.
    • The shared password is stored in the private configuration store (located in the %AppData% folder of the Monitor network service or the console user profile) encrypted with DPAPI encryption (https://en.m.wikipedia.org/wiki/Data_Protection_API) and never leaves the customers premise 
  • Display Settings

    This tab allows you to select display preferences, such as whether you would like to show or hide system sessions, full computer names and navigation history.

    Also, you have an option to change Theme Color (Dark\Light)

    Enable Grouping – shows the grouping bar above the information grid, which allows for dragging any column header to the bar to group records by that column

    Show System Sessions – by default, the “System(1)” and “Services(0)” sessions are hidden on server machines in ControlUp, so the only sessions you see are real human users. Enable this checkbox to display the system and services sessions.

    Show Full Computer Names – this checkbox determines whether the Organization Tree should show full computer names (FQDNs) or flat names.

    Show Navigation Bar – display the “Back” and “Forward” buttons above the information grid.

    Show Navigation History – display the “History” dropdown above the information grid.

    Show Actions Task Pane – display available management actions in a separate pane on the right.

    Show Configuration Error Balloon – in case of an error during an update to the central configuration, display a balloon in the status bar indicating that not all changes may be saved.

    Show Disconnected Computers – if you disable this checkbox, computers will not be displayed in ControlUp unless they are in the “Ready” state, meaning that disconnected computers will disappear from the information grid.

    Show Parent View Record – when this option is enabled and a record is double clicked or focused on, the information grid will display the parent record information on top of the grid as well as its child objects below.

    Show Computers with Errors – display computers on the information grid even if their connection status is currently in error. This option can be disabled to support scenarios in which not all computers are accessible or powered on.

    Show Powered Off Computers – display computers for which the hypervisor layer has reported a “Powered Off” status.

    Show Agentless Managed VMs – display computers discovered via hypervisors, XenDesktop or AWS, to which ControlUp Agent has not been deployed.

    Show Agentless Managed Sessions – display sessions discovered via XenDesktop, hosted on computers to which ControlUp Agent has not been deployed.

    Show the option to add XenDesktop – display “Add XenDesktop” button in the ribbon (under the “Home” tab).

    Show Published Applications – display XenDesktop Published Applications in the Application View. Unchecking both this option and the “Show Applications” option - will empty the Applications View.

    Show Applications – in the Applications View, display aggregation rows for processes discovered by ControlUp Agent.

    Note: ControlUp includes a full screen mode, which can be invoked by pressing F11. If you would like ControlUp to open in full screen mode automatically, specify the “/fullscreen” command line parameter in the shortcut used for launching the console executable.


  • Agent Settings

    The Agent Settings tab of the Settings window allows you to select your preferred agent installation options:

    • Deploy agents automatically - When this option is checked (Default) the ControlUp agent automatically deploys when computers are added to the console. In addition, when the console version is different than the agent version, the agent automatically upgrades to the console version. If a computer is defined in the console tree but the agent doesn't exist on the endpoint, the monitor also reach out and tries to deploy the agents.
      Note: For this to work, the AD account used by the monitor would need admin rights on the computers to deploy the agent. 
      You can select to install agents manually if you don't want resources used to automatically check for and install updates on the monitored machines. 
    • Check ping – By default, all selected computers are pinged before agent distribution to ensure connectivity. If your managed computers do not respond to ICMP traffic, you may uncheck the “Check Ping Reply” checkbox in the Add Computers window.
    • Prerequisites check – By default, all selected computers are tested for .Net Framework presence before agents are distributed. This test may be bypassed by unchecking the “Check Pre-requisites” checkbox.
    • Default TCP port (40705 by default) - You may select a custom TCP port number for client communications using the “Listen on port” field in the bottom right corner of the window. Please ensure the port number you select is not utilized for any other applications on your network
    • Auto-Connect Interval – Determines the time span between attempts to reconnect to agents if the “auto-connect” checkbox is enabled.
    • Agents will be uninstalled automatically when not used - When this option is enabled, the agent is automatically uninstalled if the console or monitor is not connected to the agent for 5 min.
      Note: If the computer is a ControlUp Monitor, the agent will not uninstall.
    • Linux monitoring:
        • You can select to install missing packages on Linux machines for agentless data collection.
        • You can allow users to add machines that are running unsupported Linux flavors.
          Note: We highly recommend not to add machines for these unsupported Linux flavors because this could disrupt data collection. Do so at your own risk.
    • Customized icon for chat window - You can add a customized icon if you are using the chat functionality. Select this option and browse the local machine to locate and upload the icon's image file.
    • Use only encrypted communication - For details on this option, see Agent Security Options in Agent Settings.
    • Download Agent MSI – Use this link to download standalone MSI packages for agent installation if you selected not to deploy agents automatically.
    • Agents authentication key - For details, see Agent Security Options in Agent Settings.


  • Proxy Settings

    If your network policy requires the use of a proxy server to reach the Internet, this is the place to configure your proxy server settings and authentication credentials, if applicable.

    Note: ControlUp doesn’t support proxy auto-configuration (PAC) files. Please provide your proxy server settings manually.

  • AD Connections

    The AD Connections tab allows you to add managed domains and configure the credentials to be used to connect to these domains. If you are running ControlUp as a domain user, this list may be empty. This means that your current domain credentials are used whenever needed. If you start ControlUp as a local (non-domain) user, you will be prompted for the FQDN of your Active Directory domain and valid domain credentials, which are mandatory for working with ControlUp.

    Domain connections are required for two principal reasons. First, the default method of adding computers is by browsing the Active Directory and domain membership is a mandatory prerequisite for managed computers. Second, ControlUp uses your Active Directory logon information to determine the rights and permissions that will be applied to your console. The Security Policy of ControlUp is based exclusively on Active Directory accounting.

    ControlUp supports managing computers from different Active Directory domains and forests. Even computers that belong to multiple untrusted Active Directory domains and forests can be managed within the same console, provided that you have sufficient credentials to manage computers in those domains and forests. All that is needed is an Active Directory connection, which consists of a domain FQDN and valid credentials.

    The AD connections tab of the Settings window can also be used to enable ControlUp organizations to span multiple Active Directory forests. Every time you log into ControlUp, the list of available organizations is determined based on the Active Directory forest by which your Windows session is currently authenticated. If you create a new ControlUp organization from forest A and then later open ControlUp from a computer logged into forest B, that organization will not be visible on the logon wizard. To enable the display of that organization in forest B, perform the following steps:

    • Open ControlUp in a Windows session logged into forest A
    • Log into your ControlUp organization
    • Using the AD Connections tab of the Settings window, create an AD connection to forest B while providing valid credentials. Click OK.
    • Edit the newly created AD connection. Select the Trust tab and enable the checkbox next to “Allow users from “<forest B>” to login to organizations created in “<forest A>”. Click OK.
    • Now open ControlUp in a Windows session logged into forest B. Your ControlUp organization should be visible on the organizations drop-down list.

    DNS name resolution is a mandatory prerequisite for accessing Active Directory domains with ControlUp. If an untrusted domain is located on your local network (e.g. for testing purposes) but is inaccessible using its FQDN, ControlUp will be unable to verify your credentials and add computers from that domain. In such a case, it is recommended to configure a DNS forwarder to allow access to the DNS namespace of the untrusted domain from your existing AD infrastructure.

  • Credentials Store

    ControlUp supports saving credentials for future reuse. The Credentials Store tab of the Settings window can be used to configure, validate and edit saved credentials.

    Scenarios for Utilizing Saved Credentials

    There are several ways in which ControlUp utilizes saved credentials:

    1. AD Domain Connections may be configured to use a saved set of credentials. This is useful in case your environment includes several AD domains or forests which require different credentials. When an AD connection is configured with a set of saved credentials, those credentials will be utilized when deploying or manipulating ControlUp Agent instances on computers from the respective domain or forest. For more information on AD connections, please refer to this page.
    2. Some management actions support choosing a set of saved credentials when executing the action. For example, when using the “Run Process As” action to execute a process on a managed computer, you can select a set of credentials to use when launching the process.
    3. Remote Desktop connections can be configured to use a saved set of credentials, both individually by using the connection properties, and for entire folders. For more information, please refer to the Remote Desktop Pane section.
    4. When configuring a hypervisor connection, saved credentials are mandatory for enabling data collection from the virtualization layer. Additionally, all ControlUp users need to save the same service account credentials in their credentials store in order to enable data collection from the hypervisors. For more information, please refer to the Connect to the Virtualization Infrastructure section.


    Sharing Credentials between ControlUp Users

    Your saved credentials are stored securely in your Windows user profile directory and are accessible solely using your own Windows user account, even when using shared configuration or when copying your ControlUp settings to another user.

    In version 7.1 we have introduced Shared Credentials Store - ControlUp now allows to manage credentials centrally so all authorized users can use shared credentials sets. This enables for a more streamlined management of credentials and a quicker onboarding process for new ControlUp users which does not require them to know the service usernames and passwords.

    In online ControlUp environments, credentials stay personal and are never sent to the cloud services or shared with other users. In offline environments, when the centralized configuration feature is not available, sharing the configuration tree and other organization-wide settings between ControlUp users is achieved by copying the %AppData%ControlUp folder between colleagues. It is important to note that this operation does NOT transfer saved credentials between users. When your colleagues start ControlUp with the %AppData%ControlUp copied from your user profile, they will be prompted to reconfigure all saved credentials.

    ControlUp Monitor and Saved Credentials

    If a ControlUp Monitor instance is configured in your organization, please note that its configuration needs to include saved credentials. They are required in order to access all managed computers in your environment. For more information, please refer to the ControlUp Monitor section.

    Local Computer Credentials

    When saving a set of credentials, the domain drop-down allows you to select the “Local Computer” option in order to save non-Active Directory credentials. Use this option in the following scenarios:

    1. You would like to save a username and password for a local (non-domain) Windows user. These credentials can be used for Remote Desktop connections and for management actions that do not require domain access.
    2. Your environment includes a hypervisor connection that requires the use of non-Windows credentials (e.g. XenServer root account).
    3. You regularly connect using Remote Desktop to computers which belong to third-se Active Directory domains, the domain controllers of which are not accessible from your local network. For example, consider an off-site server which belongs to AD domain external.com, for which you have valid AD credentials. You cannot save a set of credentials for the external.com domain in ControlUp, because the DCs for that domain cannot be accessed from your local network in order to validate those credentials. As a workaround, you can pick “Local Computer” from the domain drop-down and enter external.comusername in the User field. This way, the credentials set will be treated as local and will be saved without undergoing local validation.
  • Export Settings

    Using this setting, ControlUp may be configured to auto-export any information grid view to a CSV file on a scheduled basis. This goal is achieved performed by configuring export rules that instruct ControlUp to write the contents of the information grid to the disk.

    Note: The export rules you configure in the ControlUp console will only operate when a copy of the console is active. In order to configure ControlUp for continuous export, it is recommended that any export rules will be created on an instance of the ControlUp Monitor service. If you have already configured any export rules using the console, ControlUp will suggest you to move those rules to the first instance of ControlUp Monitor that you install in your organization. For more information on ControlUp Monitor, please refer to this page.

    When creating an export rule, the following information should be provided:

    Export View The name of the view to be exported from ControlUp’s My Organization pane. Every rule may only export one view.
    Days of the week The weekdays during which the export rule should be activated.
    Start time Time of day on which the export rule should begin operating.
    End time Time of day on which the export rule should stop operating.
    Interval A time period that should elapse before a new export file is created.
    Output folder The location to which the exported files will be saved.
    Delete files older than

    The retention period for old export files.

  • Events Settings

    The Events Pane gathers “Error” and “Warning” events from all of your managed computers. Use the following settings to configure the type of events you would like to see:

    Events Retention Period – by default, ControlUp only keeps events in memory for an hour. Use this setting to modify the retention period.

    Note: a drastic increase of the retention period may result in performance degradation.

    Event Type – select the types of event you would like to gather (default – Error, Warning and Audit Failure)

    Excluded Events – configure which events you would not like to see anymore by creating a new filter.

    Frequent Event Filter – by default, when the same event type (by Source and Event ID) appears more than 100 times, ControlUp stops gathering this event. Use this setting to configure the event filter so that you do not see many repetitive events.

  • Alerts Settings

    Trigger alerts for the following stress levels – select the Stress Levels for which you would like an alert to be triggered, by ControlUp view.

    Play a sound alert in the console – if enabled, the console will play sound alerts as follow-up actions defined in incident triggers.

    Display stress level alert bubbles – if enabled, notification bubbles will be shown whenever a record reaches a Stress Level, according to the setting above.

    Log stress level alerts – using this setting, you can configure ControlUp to record a message in the Application Event Log when your resources cross a preconfigured stress level. You can then use Windows Scheduled Tasks or your favorite monitoring solution to attach e-mail alerts to these events.

  • Remote Assistance

    RA Password – this is the default password used to create Remote Assistance


    ICA – this is the .ica template file used for ICA session shadowing

  • Stress Settings

    As a comprehensive real-time monitoring solution for multi-user environments, ControlUp is capable of displaying a complex and flexible measure of system health, called “Stress Level”, for every monitored resource, be it a folder, computer, user session or process. Stress Level is a numeric column, which is displayed in ControlUp’s grid with the following ranges: None, Low, Medium, High and Critical. Using this column, you can quickly determine the health of your resources, for example by sorting the grid so that highly stressed resources are on top. In this chapter, you will learn how to configure the Stress Level column to optimally represent the current health status of resources in your environment.

    Stress Settings tab layout

    All Stress Level-related settings are configured using the Stress Settings tab of the Settings Window. As seen in the image above, this tab contains a folder tree (1),
    which is identical to the tree displayed in “My Organization” pane, a navigation bar (2)
    for switching between resource types, a counter selection area (3),
    an “Applies To” are for configuring filters (4),
    a Settings area for configuring the computation of the Stress Level value (5)
    and a “Stress Levels” area (6)
    for configuring the boundaries between different levels.

    About Stress Level Inheritance

    Default Settings

    By default, every ControlUp organization contains a single set of Stress Level settings, configured on the root folder of the organization. Unless configured otherwise, these settings are inherited by all child folders and the computers within them.

    Subfolder Inheritance

    ControlUp’s folder tree is designed to allow the user to arrange computers in folders according to their type. For example, you might want to separate your workstations from your servers, and further segment the servers folder into subfolders containing different types of machines. This type of arrangement is generally convenient, and is especially useful for configuring different Stress Level settings for different types of computers.

    Filter Inheritance

    Besides segmenting resources into subfolders, ControlUp also distinguishes between resources automatically, allowing to configure performance counter thresholds which are optimal for each monitored resource. This is done by using filters, which are pre-configured criteria configurable in the counter area.


    You may configure different thresholds for each computer type using the filter area of each counter configuration. ControlUp distinguishes between the following computer types:

    General Purpose Server – a computer running a server-class Operating System, with no Terminal (Remote Desktop) Services installed. This could be a file server, an Exchange server, a Web server or an SQL server. These computers typically host a limited number of user sessions for administrative purposes, and have most of their resources consumed by background services.

    RDS – a computer running a server-class Operating System with Terminal (Remote Desktop) Services role installed. These computers typically host multiple end-user sessions, running virtualized applications or full-desktop environments.

    Workstation – a computer running a client Operating System, such as Windows 7, 8 or XP. A computer of this type typically hosts a single user session with foreground processes (applications) consuming most of the computer’s resources.

    By default, all filters within every counter inherit its default thresholds. By clicking on the filter name on the left, you can customize the thresholds for each filter, as described below.

    Configuring the Stress Level Computation

    The counter area of the Stress Settings tab allows you to configure which metrics contribute to the computation of the Stress Level column for each resource in ControlUp.

    Per-Counter Configurations

    The counter area includes a row for every column included in each of ControlUp’s views (Folders, Computers, Sessions, Processes, Accounts and Executables). Please note that each view supports a different set of columns. You can switch between views using the navigation buttons on top of the grid.

    Each counter row includes several settings which configure the contribution of that counter to the total Stress Level of the record.


    Every counter has a Yellow and a Red zone, with configurable numeric boundaries. In the example above, a computer “CPU” column’s default settings are 80% for Yellow and 90% for Red. Once a computer’s CPU usage climbs to 85%, the cell in its CPU column will become yellow. If the CPU usage drops below 80% again, this cell will go back to green. These changes in the grid should be instantaneous.

    Note: Some counters (such as Free Disk Space) have reverse zone boundaries, i.e. Red values will be lower than Yellow values, since in these cases a lower value indicates a more severe condition.


    Once a Yellow or a Red boundary is crossed, ControlUp tracks the time the value of the counter stays above that boundary. You can configure ControlUp to increase the resource’s Stress Level when this happens, specifying how long should the value stay above the threshold. For example, you may decide that if a computer’s Disk Queue Length value stays over 1 for 1 minute, this may indicate an I/O bottleneck and should affect the computer’s Stress Level, and if the value exceeds 2 for a minute it may indicate a severe I/O issue you might want to be displayed in red, as shown:


    The “Load” value determines how many points should be added to the value of the record’s Stress Level column when a threshold is crossed for the time duration described above. For example, in the Disk Queue example above, if the value stays between 1 and 2 for a minute, the Stress Level will be incremented by 1 point. If the value is above 2, the Stress Level will be incremented by 2 points.


    To change the value used by the information grid to display the performance data of a column and modify the cell color accordingly, select a computation method from the “Severity by” drop-down list. The following values are available:

    • Current Value – the column will display the present point value of the counter. This is recommended for counters such as “Memory Utilization” or disk free space, for which knowing the most current present value is most valuable.
    • Max – the maximum value recorded in the counter since its sampling started. Valuable mainly for peak analysis and capacity planning.
    • Min – same as the above, referring to the minimum value.

    Note: ControlUp’s performance counters maintain a buffer of samples that were significantly different from previous samples. The number of stored values depends on the variance of the sample. While the computation formulas are beyond the scope of this document, while changing the default computation method for columns, you should keep in mind that “In History” values are computed in relation to more recently received data.

    • Max In History – the maximum value of the counter’s current buffer.
    • Average – the average value computed on all values recorded by the counter since its sampling started. Valuable mainly for long-term analysis and establishing baselines.
    • Average In History – the average value of the counter’s current buffer. Valuable mainly for rapidly fluctuating counters, such as Page Faults/sec and CPU usage.

    In order to illustrate the usage of the above values, let us consider the case of a computer’s “CPU” column. If you select “Average In History” in the “Severity by” drop-down list, you may witness a situation in which the counter will be colored red, while its displayed value is in the “green” range. The reason for this is the fact that the displayed value is based on the current value (e.g. 5%), while the severity color code is based upon the “Average In History” value, which may be high (e.g. 90%). This type of configuration makes sense in most environments, since a momentary peak of CPU usage is usually no cause for alarm, while a prolonged CPU load detected by the “Average In History” value my indicate a performance issue and justifies a color coded severity alert. It is highly recommended that you take extreme care when customizing the counter thresholds and their calculation sources. It is best to consider the variance and fluctuation rate of each counter when planning a change to these values.


    Some counters have a complex computation mechanism, which may fail under certain conditions. For example, when a value of a performance counter cannot be retrieved. For each of the metrics collected by ControlUp, you may decide that a failure to collect a counter’s value in itself represents an issue and should change the color of the column to yellow or red. For example, the XenApp Load.

    Configuring boundaries between Stress Levels

    Using the Stress Levels panel on the left side of the Stress Settings pane, you can customize the numeric boundaries between ControlUp’s stress levels.

    By default, all resources in your organization inherit the following default stress levels boundaries:

    • (No Stress) < 1
    • 1 <= Low < 2
    • 2 <= Medium < 3
    • 3 <= High < 6
    • 6 <= Critical

    Just like the stress level computation settings, these boundaries are configurable on a folder basis, which means that a resource (computer, session or process) with a stress level of 7 may be considered Critical in one folder and Medium in another, according to the needs of your environment.

    In order to customize the Stress Level boundaries for a subfolder:

    1. Switch to the Stress Settings tab of the Settings Window.
    2. Click on the desired subfolder in the organization tree.
    3. Uncheck the “Default Configurations” checkbox in the “Stress Levels” panel just below the tree.
    4. Adjust the numeric boundaries using the sliders or by typing the numbers into the fields corresponding to each level.
    5. Click “Apply Settings” on the Home ribbon.

    In order to reset default Stress Level boundaries for a subfolder:

    1. Switch to the Stress Settings tab of the Settings Window.
    2. Click on the desired subfolder in the organization tree.
    3. Check the “Default Configurations” checkbox in the “Stress Levels” panel just below the tree.
    4. Click “Apply Settings” on the Home ribbon.

    Receiving Stress Level Alerts

    You can configure ControlUp to alert you when resources in your environment reach a configured stress level. For more information, please refer to the Trigger Settings section.

  • Trigger Settings

    Incident Triggers are definitions of significant events that should be recorded by ControlUp. Each trigger includes a list of conditions which specify when the incident will be recorded and which follow-up actions will be performed at that time. The Trigger Settings window is used to define these triggers, while the Incidents Pane is used for viewing and analyzing the resulting incidents.

    Cloud Analytics Triggers

    ControlUp offers built-in incident triggers supplied by ControlUp Cloud Analytics. These triggers are based on vendor recommendations and industry best practices. For example, a “Citrix XenApp Events” trigger delivered by Cloud Analytics defines all event log entries recommended for monitoring by Citrix. From time to time, these triggers are updated to include new known issues and best practices. The idea behind Cloud Analytics is to provide ControlUp users with information about events that are known to correspond to known issues.

    User-defined Triggers

    ControlUp users can configure their own incident triggers to record irregularities, errors, performance issues and other events specific to the monitored environment. Incident triggers are stored in the organization’s public configuration set, meaning that there is only one set of triggers shared by all users in a ControlUp organization. In order to make changes to the triggers, the user needs the Configure Incident Triggers organization-wide permission.

    Creating and Modifying an Incident Trigger

    Step 1: Selecting an Incident Type

    To create an incident trigger, in the Trigger Settings window, click Add Trigger. A New Incident Trigger wizard opens.

    The first stage in creating a trigger is choosing the incident type. The following incident types are supported:

    • Stress Level – captures an increase in a record’s Stress Level value. This type of incident applies to all record types in ControlUp (Folders, Hosts, Computers, Sessions, Processes, Executables and Accounts). Choose this trigger to capture all types of performance issues, such as excessive resource consumption.
    • Windows Event – captures entries recorded in the operating system event logs of your managed computers. Select this trigger in order to record Windows event log entries for later analysis or troubleshooting.
    • Machine Down – this trigger is activated when a computer monitored by ControlUp becomes unavailable, for any reason.

    Note: incidents of this type are only recorded by ControlUp Monitor, because continuous monitoring is required in order to detect a “Computer Down” event and ControlUp Console is not intended for continuous monitoring.

    • Process Started – this trigger is activated when a process matching a defined set of criteria is started on any of the managed computers.
    • Process Ended– this trigger is activated when a process matching a defined set of criteria is terminated on any of the managed computers.
    • User Logged On – this trigger is activated when a user logs on to one of your managed computers.
    • User Logged Off– this trigger is activated when a user logs off from one of your managed computers.
    • Session State Changed – this trigger is activated when a user session’s state changes on one of your managed computers.
    • Advanced - This trigger is activated when a custom set of conditions applies to a row in ControlUp's information grid. Use this trigger type to capture a scenario that is not covered by any other trigger type.
    • Scheduled: This trigger is an action that can be scheduled by you. It can be set to occur at a time of your choice, either once or recurring, and in combination with other parameters. For details, see Introducing Scheduled Triggers for v8.5.  

    Step 2: Configuring Incident Details

    For Stress Level triggers, configure the following details:

    • Record type – the kind of ControlUp record to which the trigger applies (Folder, Computer, Session, Process, etc.).
    • Stress Level – the minimum Stress Level threshold to trigger the incident.
    • Duration – the minimum period during which the record needs to stay above the configured stress level in order for the trigger to be activated (range: 3 seconds – ∞).

    For Computer Down triggers, configure the following details:

    • Record an incident – the reason the computer is down (normal shutdown, ControlUp Agent service stopped, the Monitor cannot connect to the computer, or any of these)
    • Minimum duration – the minimum period during which the computer must be down in order for the trigger to be activated (range: 3 seconds – ∞)

    Note: if the computer goes down more than once in a five-minute period, and the first time it does so, the duration is less than the minimum duration specified in the trigger settings, the trigger is not activated during that five-minute period. (This is because the Monitor normally polls managed computers once every five minutes, unless a trigger incident occurs whose duration is at least the minimum duration specified. In this case, no trigger incident of this duration is detected during the normal polling, so polling only resumes five minutes later.)

    For Session State Changed triggers, configure the following details:

    • From State – the state of the user session before the change
    • To State – the state of the user session after the change
    • Minimum duration in new state – the minimum period during which the session must be in the new state in order for the trigger to be activated (range: 3 seconds – ∞)

    For Advanced triggers, configure the following details:

    • Record type – the kind of ControlUp record to which the trigger applies (Folder, Computer, Session, Process, etc.).
    • From State – the state of the record before the change (optional; defined using filter criteria – see Step 3)

    Note: To include new items with no initial state, select the Include… checkbox.

    • To State – the state of the record after the change (defined using filter criteria – see Step 3)

    For Scheduled triggers, configure the following details:

    • Record type: The type of record to which the trigger applies (Folder, Computer, etc.).
    • Schedule: When the trigger will be activated.
      Scheduled triggers can either be one time or hourly (recurring) with a 1-24 interval range. Set the start and end date and time.

    Step 3: Adding Filtering Criteria

    For every trigger, you may configure an advanced filter using any combination of criteria, which will be evaluated against all the properties of the affected records. For example, you might want to configure a Stress Level trigger that only captures the activity of processes with a certain name or a Windows Event trigger that only captures specific event IDs.

    The Filter Editor is a window in which you can configure your criteria. This window is similar to the Item Level Targeting filter control used in Microsoft Windows Group Policy Management Console (GPMC), and uses the same logic.

    Note: When configuring search criteria on a string attribute, you can include wildcards using the * (asterisk) symbol.

    Search string Will match
    test test
    test* test1
    (or any other string in which “test” is followed by one or more characters)
    *test 1test
    (or any other string in which “test” is preceded by one or more characters)


    For scheduled triggers, click Filter editor > New Item and select one or more options from the list. Configure the conditions for your filter (“equals”, “greater than or equal to”, “less than or equal to”).

    Select the minimum duration in new state. This means that the action will be performed for the defined number of seconds (default = 3) before the start time defined in the previous step. For example, if the start time is 29/05/2021 at 08:00, the trigger will be activated on that date at 07:59:57.

    Step 4: Configuring Trigger Scope and Schedule

    In the Scope drop-down box, you can select which folder the trigger applies to. The Include all child folders checkbox controls whether this setting applies to the entire folder structure under the selected folder. By default, any newly created trigger applies to the entire organization.

    The Schedule drop-down box allows you to select when an incident will be active. By default, any newly created triggers are active at all times (All Days schedule). Using the Add New Schedule option, you can define a new time pattern.

    Step 5: Adding Follow-up Actions

    Every trigger may include one or more follow-up actions. The following actions are available:

    • Send an e-mail alert – delivers an e-mail with the incident details to the selected recipients. A valid recipient is a ControlUp user in your organization who has verified their e-mail address by activating their ControlUp account. This follow-up action uses ControlUp Hybrid Cloud services for the delivery of alerts and does not require a local mail server.
    • Send a mobile push notification – delivers an alert to your mobile devices using ControlUp Mobile Apps. For more information please refer to the Mobile Apps documentation page.
    • Dump view/s to disk – when the incident is triggered, this follow-up action will save the contents of the selected ControlUp views to the disk as a comma-delimited file.
    • Record an event in the Application Log – will create a new log entry in the Windows Application Log of the computer that detected the incident.
    • Play a sound alert in the console – if ControlUp Console is open when the incident is detected, the console will play the selected sound file.
    • Send an e-mail alert using a local SMTP server – delivers an e-mail alert with the incident details to any number of valid e-mail addresses, via a user-configured SMTP server. This will occur only if your organization includes an active instance of ControlUp Monitor which has been configured with sufficient connection details and credentials to send messages using the SMTP server.
    • Run an action – runs a Script Action automatically
    • Wait before repeating - the trigger won't repeat for subsequent triggers within the set time. The default time is five minutes.

    Incidents are recorded in your organization’s incidents database for later analysis, even if no follow-up actions are configured except for scheduled triggers which are not reported as incidents.

    For Scheduled triggers, four follow-up actions are available:

    • Dump view/s to disk
    • Record as event in the Application Log
    • Send an e-mail alert using a local SMTP server
    • Run an action – Script Action

    Note: Follow-up actions for scheduled triggers are also not reported as incidents.

    Step 6:  Set a Name and Description for the Trigger

    A name and description are automatically generated for every trigger. It is recommended that you review the name and description  to ensure that you are able to identify the trigger when you receive alerts or analyze incidents.

  • Schedule Settings

    The Schedule Settings tab of the Settings window enables ControlUp users to create and manage a list of predefined schedules which can be used with incident triggers and follow-up actions.

    Each schedule you create is added to the list of schedules available for selection in the following contexts:

    • When configuring an incident trigger, you can choose a schedule to restrict the incidents to the specified days and times defined in the schedule.
    • When adding a follow-up action to an incident trigger (such as sending an email alert), the schedule can be used to determine whether or not to perform the follow-up action when the trigger is activated.

    Each entry in this list is a matrix of hours and days of the week, specifying whether to enable incident recording for each of the time slots defined.

    For example, you may want to create a schedule and record incidents during peak hours of the work week and not record incidents during the weekend. You would select Monday through Friday, 9:00am through 5:00pm, select Record incident and be sure give the schedule an immediately recognizable name like "Peak working days/hours".

    To add a schedule entry:

    1. In the Settings tab, click Schedule. The Manage Schedules dialog opens.
    2. Click Add Schedule. The Alert Event Schedule dialog opens.
    3. In the Schedule name field, enter a name for your schedule (e.g. “All Week Except Saturday Downtime”).
    4. Use your mouse to highlight and select the days and times when you want incidents recorded. 
    5. Select Record incident for the timeslot you just highlighted. The timeslot selected appears blue. 
    6. If there are times during this timeslot that you do not want incidents recorded, highlight those times with your mouse, and then select Do not record incident. Those timeslots, even if they appear within the original timeslot now appear white.
      Tip: Check that the days/times when you want incidents recorded appear in blue and the days/times when you don't want incidents recorded appear white.schedule_settings_1.png
    7. Click OK to save your schedule. You should see your schedule listed in the Name column, with the days/times you highlighted in the Schedule column next to it. 



  • Monitors Settings

    This tab displays all ControlUp Monitor instances installed in your organization, while allowing you to review their current status, remove, stop, start or reconfigure existing Monitor instances, and to install new Monitor instances.

    For more information about installing and configuring ControlUp Monitor, please refer to the ControlUp Monitor chapter of this documentation.

  • Insights Access

    This settings tab defines the security restrictions and configurations applied to users accessing the ControlUp Insights portal.

    Two-factor authentication

    ControlUp Insights can be configured to send a secondary authentication code whenever a user provides a valid email / password combination on the sign-in page of the ControlUp Insights portal. The objective of this code is to enhance sign-in security by offering proof that the user attempting to sign into ControlUp Insights is indeed the legitimate owner of the user account. This option is disabled by default, which means that two-factor authentication is not required to sign in.

    When this option is enabled, ControlUp servers will send a numeric authentication code to the email address activated by the user after creating their ControlUp user account. Optionally, the secondary authentication code can also be delivered by using a mobile push notification to any mobile device on which ControlUp Mobile App was downloaded and activated.

    Portal sign-on restrictions

    This section allows you to configure two additional restrictions that are intended to enhance the security of ControlUp Insights sign-in process.

    One restriction is a list of email address suffixes (email domains), which can be validated to ensure that portal sign-in is granted exclusively to users who own a corporate email account. When used in tandem with two-factor authentication, this option further enhances the security of ControlUp Insights sign-in  by performing this verification every time a user signs into the portal.

    The second restriction is a list of source IP addresses against which ControlUp servers will validate the source public IP address from which ControlUp Insights portal is accessed. This option can be used in order to ensure that ControlUp Insights is always accessed from legitimate corporate locations.

    Single sign-on for Insights Access

    This mechanism is used to leverage your existing ControlUp credentials to sign you on automatically, without the need to provide a username and password. Single Sign-On is activated when the ControlUp Insights button on the Home ribbon is clicked. This setting allows for disabling the Single Sign-On mechanism and requiring all users to provide a valid email and password when signing in.

  • Branch Mapping

    This tab provides the ability to configure a list of IP subnets utilized on your network and map them to names of geographical locations, buildings or organizational branches. As a result of this configuration, ControlUp will be able to assign a source branch name to every user session and populate the “Branch Name” column with this name.

    For example, in an organization in which the New York office uses the subnet and the Chicago office uses the subnet, the mapping table should be configured to map those subnet addresses to the branch names. As a result, the Branch Name column of the sessions view will be populated with the value of “New York” for all user sessions established from client IP addresses in the range, and with the value of “Chicago” for the range.

    The list of subnets and branch names can be configured manually or imported using a CSV file by clicking the Import button. Here’s an example content of a supported CSV file for reference:

    Name,Site,Chicago,Chicago,Amsterdam,Servers Subnet,Test Workstation

    If your Active Directory has subnet objects already linked to the sites representing the geographical topology of your organization, you can use the Active Directory Sites and Services to export a CSV file which can be imported directly into ControlUp. To do so, perform the following steps:

    1. Open Active Directory Sites and Services
    2. Expand the Sites container in the tree view
    3. Right-click the Subnets container and click Export List…
    4. Save the file as “Text (Comma Delimited) (*.csv)”
    5. Open the Branch Mapping tab of the Settings window in ControlUp
    6. Click Import
    7. Browse to the file exported in the steps above

    In case the client IP address does not belong to any of the subnets configured in the mapping table, the Branch Name column can be left empty or populated with a custom value. This behavior can be configured using the “Unrecognized IP Addresses” area in the Branch Mapping tab of the Settings window.

  • Data Upload Settings

    This tab provides access to settings that define how ControlUp uploads data to the cloud servers.

    Incidents Reporting

    The “Incidents Reporting” checkbox defines whether incident triggers defined in your ControlUp organization cause entries to be recorded in the cloud database. When this setting is enabled, ControlUp records an incident entry in the cloud Incidents database every time a condition is detected that matches one of the triggers defined in your organization. This enables for investigating past incidents using the Incidents pane, and for receiving alerts by email or by using the ControlUp Mobile App.

    This checkbox is checked by default. When this option is unchecked, incidents are not reported to the cloud, and all alerting and historical analysis of incidents are disabled.

    Insights Activity Data Upload

    The “Upload historical activity for display in ControlUp Insights” checkbox defines whether ControlUp Monitor instances in your organization upload activity data for the purpose of displaying reports in ControlUp Insights.

    This checkbox is checked by default. When this option is unchecked, no data will be uploaded to ControlUp Insights and no data will be shown in the reports.

    Upload Bandwidth Limit

    The “Upload bandwidth limit” area provides a means to configure a bandwidth limit for the activity data upload process. By default, upload bandwidth is unrestricted.

    The “Daily upload statistics” area provides the average and maximum volumes of data uploaded to the Insights portal.

    Upload Schedule

    The Upload Schedule dropdown enables for a schedule definition to be applied to the upload process. The schedule definition can be selected from a list of schedules created in the Schedule Settings tab of the settings window. By default, upload schedule is unrestricted, meaning that activity data is uploaded automatically as needed.

    Please note that restricting the upload schedule and limiting the upload bandwidth may cause ControlUp Insights to fail to display up-to-date information. In extreme cases, if schedule and bandwidth are insufficient to upload activity data in a timely manner, ControlUp might discard activity data which will cause report data to be lost permanently. Therefore, it is recommended that you consult with ControlUp Support before modifying those settings.

  • App Load Time

    An important measure of user experience is the amount of time it takes for user mode applications to initialize fully before their user interface becomes accessible (clickable) by the user. Applications that are slow to load may indicate system issues, resource bottlenecks, and user frustration.

    ControlUp has the ability to measure the time it takes any user-mode application to become available for the end user. This is an experimental feature that needs to be enabled and configured explicitly (for detailed instructions, see below). When configured, the application’s load time in seconds is displayed in the Processes view.

    By default, the list of monitored applications includes Microsoft Office applications, Internet Explorer and Google Chrome.

    In order to add an application for App Load Time monitoring, click on the Add Rule… button and provide the following parameters:

    • Process name/s, one per line - the name of the processes for which you would like to enable app load time monitoring. For every rule you create, it is recommended to enter process names that belong to a specific application or suite of applications, to enable for easier management of each application’s monitoring settings independently of other applications.

    Note : The parameters below are advanced settings with recommended default values. It is not recommended to modify those values without thoroughly testing the effect of those changes on your production workloads.

    • First sample after (default: 20 s, accepted values: 2-180 s) - determines how long after the process is started will ControlUp first try to assess the load time of the application. For applications that are particularly slow to load, this parameter may be increased.
    • Threshold sensitivity (default: 7, accepted values: 2-12) - determines the sensitivity of the algorithm that detects a decline in the rate of activity generated by the process. You can try lowering this value if ControlUp fails to detect an application that appears fully loaded from the user’s perspective.
    • Stop measuring after (default: 180 s, accepted values: 2-180 s) - when this period elapses after the process start time, ControlUp will stop timing the process load duration. Set this value to the maximum duration that you would like to wait for the process to load. This setting also determines the maximum value you will see in the App Load Time metrics in ControlUp.
    • Data Sample Interval (default 20 ms, accepted values 5-20 ms) - determines the precision of the mechanism (lower = more precise) and its demand for CPU cycles (lower = more CPU activity).
    • Include I/O rate (default: enabled) - determines whether ControlUp should consider I/O activity when determining application load time. If unchecked, ControlUp uses only the DLL load rate.

     For application load time troubleshooting, please refer to this article - Application Load Time


  • Enable Browser URLs

    ControlUp has the ability to display a users active Internet Explorer URLs within the Console. This feature needs to be enabled within the Console Settings and configured. This visibility into browser activity allows administrators the ability to identify run away browser processes and problematic websites. 

     In order to enable viewing Browser URLs in the Console Grid follow these steps:

    1) Go to Settings -> Browser URLs


    2) Check the box "Monitor URLs for browser processes"


    Once you have checked the box to enable the setting you will begin seeing URLs for new IE tabs or browsers opened within the Processes tab of the Console Grid. 

    Note: If you've installed the Agent in the middle of the session, in order to see URL's you'll need to restart your session. 

    Browser URL feature uses the AppLoadTimeTracer.exe process as well.


    The only active wildcard in the browser URL feature is * and can be used to replace full section. 

    Supported rules\methods:

    -  *.ControlUp.com
    -  www.*.com
    -  *.com

    Unsupported rules\methods:

    - *ControlUp*.com
    - *ControlUp*
    - *www.*ControlUp.com


  • Contextual Navigation Rules

    Contextual Navigation is a set of rules based on our Virtual Expert, intended to create a smoother, faster troubleshooting experience within the ControlUp real-time console.

    Identifying an issue and clicking to drill down will create a customized path to the most relevant view and present the appropriate preset view.
    For example, if you click on a RAM cell then contextual navigation will take you to the appropriate view (e.g., sessions view) and display the RAM preset views so that all the relevant metrics are shown immediately. This optimizes and accelerates your troubleshooting process and skips any redundant stages along the way, getting to the root cause using the minimal amount of time and effort.

  • Audit Log Settings for v8.1 and Below

     NOTE: The Audit Log feature is currently under development. Only some of its planned capabilities are functional in this version of ControlUp (v. 7.2), and these features are experimental.

    Internal audit logs document changes within a system and actions performed by the system remotely, enabling system administrators to monitor those changes and activities. Such logs are primarily used in corporate environments.

    ControlUp is currently developing an Audit Log feature. When the feature is completed, it will be capable of logging information in its internal logs about two types of events:

    • Changes made to ControlUp’s configuration settings, such as creating a new user or adding a new hypervisor
    • Remote operations performed on managed assets through ControlUp, such as rebooting a VM or killing a process on a managed computer

    In its first phase of development, the ControlUp Audit Log feature can only record information about service operations initiated by ControlUp, and only SysLog and local-disk log storage are supported.

    The Audit Log feature is optional, and by default is not activated. If IT staff want to use it, they must turn it on and configure it, as explained below.

    Where Are the Audit Logs Stored?

    When the Audit Log feature is activated, it can save log data in up to three distinct data stores:

    • ControlUp cloud: The Insights database on the ControlUp server (mandatory, when supported)

    NOTE: This functionality is not yet available. However, once it is available, it will be activated automatically whenever the Audit Log feature is turned on, and it will not be possible to opt out of it.

    • SysLog: A SysLog server within the organization’s network (optional)
    • Local disk: A CSV file stored locally on the Console or Monitor machine from which ControlUp’s actions were initiated (optional)

    What Data Is Included in the Audit Logs?

    At present, only service operations (start service, stop service, restart service, edit service properties, etc.) are logged by the Audit Log system. In the future, all ControlUp actions – both changes within ControlUp and changes to resources managed by ControlUp – will be logged.

    For each entry in the audit logs, the following information is stored: 




    Date and time when the event was initiated.


    The source of the event (Web client, Console, PowerShell, automated action, Insights, etc).


    The status of the event (initiated, completed, aborted, error, etc).

    Requesting Computer

    The hostname or IP address of the computer from which the event was initiated

    Requesting User 

    The user account of the user who initiated the event


    The user account that was used to execute the command.

    Note: If this is the same as the Requesting User, this field is left blank.


    The type of action that was performed (kill process, add computer, etc).


    Supplementary information that is specific to the command.

    Object Type

    The type of the target object (process, session, computer, host, netscaler, organization, folder, datastore, vDisk, etc).

    Object Name

    The name of the target object (computer hostname, host name, netscaler name, organization name, username, etc).

    Target Type

    The type of object on which the command was executed.

    Target Name

    The name of the object on which the command was executed (computer hostname, hypervisor name, Netscaler name, organization name, username, etc).


    The output of the operation.

    Data Snapshot

    All metrics of the target object at the moment of the event

    All metrics of all target object predecessors (parent objects) at the moment of the event

    All metrics of all target object successors (child objects) at the moment of the event

    For each metric at the moment of the vent we save Current value + Average in history + Max in history

    Executing computer

    The computer where the operation was executed (CU Console / CU Monitor / CU Agent).


    Modes of Operation

    The Audit Log feature supports two alternative modes of operation:

    • Regular mode (default): Each operation is logged in a single entry when it is executed.
    • Enforced mode: Operations cannot be executed until they are logged. No operations can be executed until acknowledgement is received from the relevant data stores that the entry was successfully recorded.

    NOTE: The SysLog system does not support the sending of acknowledgements. Because of this, even when Enforced mode is selected, and the SysLog option is also activated, ControlUp does not require an acknowledgement from the SysLog before allowing an operation to be executed. In ControlUp v.7.2, since the cloud data store is not yet functional, this means that Enforced mode has no effect unless the Local Disk storage option (see Where Are the Audit Logs Stored?) is activated.

    In Enforced mode, if the system fails to open an audit-log entry for an operation after three attempts, the operation is cancelled, and an error message is returned.

    Configuring and Activating the Audit Log Feature

    The Audit Log feature can be configured and activated in the ControlUp Console settings.

    To configure and activate the Audit Log feature:

    1. In the ControlUp Management Console, under Settings, select the Audit Log button. AuditLog1.jpg The Audit Log settings open.


    Audit Log settings


    2. Configure the settings as follows:



    Enable Audit Logging

    Select this option to activate the Audit Log system.

    Note: In the future, selecting this option will automatically activate the cloud audit-log. Currently, since the cloud log is not yet functional, if you want a log to be created, you must also select Save to local disk and/or Send to SysLog server.

    Fail action if auditing fails

    Select this option to turn on Enforced mode, which prevents actions from being performed if they are not successfully logged first (see Modes of Operation).

    Save to local disk

    Select this option to save a local audit-log on each ControlUp Console or Monitor machine. Each log will save information about the ControlUp actions that were initiated from that machine.

    Send to SysLog server

    Select this option to save a central audit log to a SysLog server in the organization.

    After you select this option, fill in the following fields:

    · IP/hostname: Enter the IP address or hostname of the SysLog server.

    · Port: Enter the port to use to connect to the SysLog server.

    · Protocol: Select the protocol to use to connect to the SysLog server – UDP or TCP.

     3. Select OK (or Apply). The Audit Log feature is activated with the settings you specified.

    Viewing the Logs

    Each of the three logs is accessed in a different way:

    • ControlUp cloud: Once support for the cloud data-store is implemented, it will be possible to view a report in the ControlUp Insights portal. Data will be retained in this log for a period of a year after it was first recorded.
    • SysLog: The contents of the SysLog data-store can be viewed using any standard SysLog reader (e.g., Splunk).
    • Local disk: Local audit logs are stored in the form of up to ten rotating files, named csv, CUAudit1.csv, CUAudit2.csv, … CUAudit9.csv, each of which contains a maximum of 50 MB of data. The CUAudit.csv file contains the newest data; the higher the numbers in the names of the other files, the older the data those files contain. When all of the files are full, the oldest one is deleted, and the numbers in the names of all the others are incremented by one.
      The audit-log files are stored in the folder in which the Console or Monitor executable itself (ControlUpConsole.exe or cuMonitor.exe) is stored (e.g. C:\Program Files\Smart-X\ControlUpMonitor\Version for the Monitor). The files can be opened using any application that can handle CSV files (e.g., MS Excel).


    Audit Log stored locally in a CSV file, opened in MS Excel

  • Advanced Monitor Settings

    This tab of the Settings Window defines performance management options that may help conserve system resources on the computer running the console. This can be achieved by configuring the following settings:

    Regulating the rate of performance updates

    ControlUp can be configured to pull performance updates from the managed computers instead of receiving push updates. This enables a degree of control over the number of updates received by the console, thus decreasing the amount of CPU cycles and RAM required in order to process updates.

    Note: It is recommended that you contact ControlUp Support before changing this setting. Our support engineers will suggest recommended values for the data collection parameters after assessing the size of your environment and the available resources.

    Disabling process views

    The Processes view is the most densely populated view in ControlUp, which may contain millions of records in large organizations. This setting enables you to disable updates for processes, which dramatically decreases the number of records which the console is required to process.

    Disable views that depend on process-level information

    When this option is enabled, the Processes view will be disabled, which means that you will not be able to see all processes in your organization in a single flat list. The Accounts and Applications views will no longer include rows that represent groups of processes. You will still be able to drill down into the process level of a selected computer or session. ControlUp Monitor will continue gathering process-level information for alerting and activity recording.