User Preference - Add User
Once the basic information is provided, the User preference tab will invoke. This page helps the user to set preference to the specific roles.
Specify a unique User ID.
Provide a Password for the new user, and then, confirm the password by retyping it in the Retype password text box. This is because, in case of users who are local to the eG Enterprise system, it is the eG database which maintains the user information, and not the Active Directory. Therefore, whenever a local user is created using this page, a password has to be explicitly provided, so that both the user name and password of the local user credentials are stored in the eG database. Moreover, when a local user logs into the eG management console, his/her Username need not be pre-fixed by the domain name. The User ID and Password that the local user provides while logging in will be validated by the eG database that manages the local users.
The rest of the user creation steps are common to both the authentication modes - domain and local - and to both domain users and domain user groups. The next step in user creation is to provide an Expiry date for the new user. One more added feature of the eG Enterprise suite is that it checks the validity of the user. A user is granted permission to monitor the services associated with him/her only for a stipulated period of time. Clicking on the Calendar button next to the Expiry date label will result in the display of a calendar from which the administrator can choose the validity date for a new user. Beyond this date, the user is regarded as an invalid user. Optionally, you can click on the No expiry check box, if a new user has to remain valid for an indefinite period of time.
Then, click the Next button in the BASIC INFORMATION tab page. Doing so will automatically open the USER PREFERENCES tab page.
In the General section of the USER PREFERENCES tab page, specify the following:
Time Zone: eG Enterprise is often deployed to manage servers in different geographies and time zones. For example, a large enterprise may have a central eG Enterprise management console to which agents from different locations can be reporting. In a managed service provider environment, multiple customer infrastructures can be monitored from the same eG manager. In such situations, users (administrators in different geographies, customers of an MSP in different regions) prefer to see the performance metrics reported in their respective time zones. eG Enterprise allows time zones to be associated to each user's profile. By default, all users are associated with the local time zone of the location where the eG manager is hosted. However, an administrator can change the time zone preferences of a user to suit that user's requirements. For this, when creating a user profile, the administrator can pick a Time zone for that user. When that user logs into the eG Enterprise console, all the metrics, alerts, and reports that the user accesses will be displayed in the respective local time zone. This new capability ensures that eG Enterprise users receive a completely ‘local’ experience, regardless of which part of the world the eG manager is located in.
Note:
While configuring a time zone, remember the following:
When normal mails are generated by the eG manager, the Start Time displayed in such mails will also be based on the TIME ZONE setting for the corresponding user.
If a user is configured to use multiple email IDs (i.e., a comma-separated list of mail IDs has been provided in the TO, CC, and/or BCC columns), then the TIME ZONE specification for that user applies to all the configured email IDs. In other words, every user can have a separate TIME ZONE, but every mail ID configured for a user cannot have a separate TIME ZONE.
When mail alerts are being escalated, the time zone settings will be derived from the user account that the alarms pertain to. In other words, each escalation level will NOT have a separate TIME ZONE - the time zone setting for the user account will apply to escalated mails as well.
Any alerts generated by the eG manager to report an unusual situation with the eG manager itself (e.g., database not working, agent not running, etc.) will not be affected by this TIME ZONE settings. All such alerts will be generated in the eG manager's local time zone setting.
Date format: The default date format for the eG user interface is MMM dd, yyyy. This date format can be changed depending upon the country in which the user being created lives, by selecting a different format from the Date format list. Whenever this user logs in, the eG user interface will display dates in the chosen format only. This is particularly useful in MSP environments, where customers of the MSP could be separated by geographies and may require performance and problem reports of their hosted enivonments to be delivered in the date format that applies to their geography.
Logo preference for Login page, Logo preferences for Admin/Monitor module, and Apply the chosen logo for other modules: Typically, using the Logo/Messages menu option in the Settings tile, an administrator can configure a custom logo for the login screen and for every module that is enabled in the eG license - i.e., the Admin, Monitor, eG Reporter, and/or the eG Configuration Management module. MSP environments typically create a user profile in eG for each customer environment they host. While administrative rights to the eG Enterprise system will generally lie with the MSP, the customers may be granted access to one/more of the other consoles. Each of these customers may want to have their company's logo appear when they login into a console, as opposed to the MSP's logo. The General section of the USER PREFERENCES tab page enables the configuration of user-specific logos - one for every user registered with the eG Enterprise system - so that MSP customers see their company logo in the modules they have access to.
By default, the Default logo will be assigned to the login page and the Admin/Monitor modules. The Default logo is the logo configured for the login page and for the Admin/Monitor using the Logo/Messages option in the SETTINGS panel of the MONITOR SETTINGS page. To define a custom logo for a user, select the Custom option against the module for which you want to set the custom logo. Then, click the button adjacent to the list box to upload the custom logo to the eG manager. The FILES TO BE LOADED window will then appear.
The type, size and resolution of the logo image should match with the specifications mentioned in FILES TO BE LOADED window. Click the Browse button to browse for the custom logo image, and then click the Upload button to upload the image. When the user logs into a specific module of the manager, the logo customized for that user for that module will get displayed.
If the logo chosen for the Admin/Monitor module has to be applied to all the other modules of the eG management console (i.e., the eG Reporter and Configuration Management modules), then select the Apply the chosen logo for other modules check box.
In the Mail/SMS Alerts section, specify the following:
Alarms by mail / SMS: The eG manager is capable of alerting users as and when problems occur. The alarms are classified into critical, major, and minor. By choosing one or more of the check boxes corresponding to the Alarms by mail / SMS field, a user can indicate his/her preference in terms of the priority of problems for which he/she wishes critical priority alarms alone and not the other types. If no alarm priority is chosen, then the user will not receive alerts by email / SMS.
Note:
Typically, email alerts are sent to a user based on the Alarms by mail / SMS setting of that user. By default, only alarms of those severity levels that have been explicitly chosen for email alerting using the Alarms by mail/SMS setting will be sent to the user. This default behavior was causing users to miss out on correlated alerts. For instance, if a user is configured to receive only Critical alarms, then such a user will not receive email alerts for a critical issue, the priority of which was bumped down to Major owing to eG's correlation logic. As a result, many genuine problem conditions were going unnoticed. To avoid this, you can now configure specific measures for which email alerts are to be sent to specific users, regardless of the alarm priority setting of those users. For this, insert an entry of the following format in the [ALWAYSSENDALERTSFORMEASURES] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory):
<Internal_test_name>:<Internal_measure_name>=yes
For example, if email alerts are to be sent out for the Availability measure of the NetworkTest, regardless of which abnormal state (Critical/Major/Minor) that measure is in, then your entry should be as follows:
NetworkTest:Availability=yes
Then, proceed to indicate to which users email alerts are to be sent for the measures configured above, regardless of the state of the measure. For this, insert an entry of the following format in the [ALWAYSSENDAVAILABILITYALERTS] section of the eg_services.ini file:
<Username>=yes
For instance, if you want the user john to receive email alerts of issues reported by the measures configured in the [ALWAYSSENDALERTSFORMEASURES] section, then your entry in the [ALWAYSSENDAVAILABILITYALERTS] section will be as follows:
john=yes
This capability is not available to domain users and domain user groups.
Mail Sender: This option appears if at least one alarm priority is chosen from the ‘Alarms by mail / SMS’ section. By default, eG Enterprise sends email alerts from the eG Administrator Mail ID configured in the MAIL SERVER SETTINGS page in the eG administrative interface. In MSP environments typically, different support groups are created to address performance issues relating to different customers. These support groups might prefer to receive problem intimation from customer-specific mail IDs instead of the global admin mail ID, so that they can instantly identify the customer environment that is experiencing problems currently. Moreover, this way, every support group will be enabled to send status updates on reported issues directly to the concerned customer, instead of overloading the admin mailbox. To facilitate this, the MAIL SERVER SETTINGS page allows the administrator to configure multiple Alternative mail sender IDs - normally, one each for every customer in case of an MSP environment. Moreover, while creating a new user, the administrator can select one of these configured sender IDs from the Mail Sender list and assign it to the new user, so that all email alerts received by the user are generated by the chosen ID only. Moreover, the EG ADMINISTRATOR MAIL ID specified in the MAIL/SMS SETTINGS page will also be added to the Mail Sender list in this page, and will be the default selection.
Mail ID/Mobile number: This option will appear only if at least one check box is selected from the ‘Alarms by mail / SMS’ section. The Mail ID/Mobile number option allows a mail account(s) / mobile number(s) to be associated with a user. When multiple mail IDs are specified, an administrator can specify which mail address(es) need to be in the To: field of the mail alarm and which ones should be in the Cc: and Bcc: fields. In the same way, you can even provide mobile numbers in the To:, Cc:, and Bcc: fields.
If a mobile number(s) is specified then a compact alarm report that is ideal for a mobile phone console is generated. The first line of this report comprises of the following information, separated by slash (/).
IP address and port of the problem component
The component type
The second line of this report would consist of the following information (separated by slash):
The name of the test that generated the problem measure(s)
The name of the problematic measure
The name of the service; this would be NONE if the problem component does not host any service
Given below is a sample report transmitted via SMS:
192.168.10.8:7077/Web_server
ProcessTest/Num_procs_running/HTTPD/NONE
In the above example:
192.168.10.8:7077, represents the IP address and port of the component which has encountered a problem
Web_server is the type of component
ProcessTest is the name of the test that generated the problem measures
Num_procs_running is the name of the problematic measure
HTTPD is the name of the descriptor
NONE denotes that the web server does not host any service
Note:
eG alarms will be forwarded to a mobile phone only if the NowSMS Lite SMS manager or the eG SMS Manager has been installed in the network, and the eG manager has been configured to work with the SMS manager.
Command to be executed for alerts: Like email IDs / mobile numbers, you can associate one/more custom scripts with users to the eG Enterprise system. Whenever alarms are raised/modified/closed for a specific user, the associated custom script will automatically execute, so that the details of the alarms are routed to third-party customer relationship management systems or TT systems, and trouble tickets automatically created (or closed, as the case may be) for the corresponding user. The custom scripts thus provide a mechanism by means of which eG alerts are integrated into CRM/TT systems. These custom scripts can be configured in addition to or instead of email / SMS alerts. To associate the command that executes the custom script with a specific user's profile, specify the command in the Command text box.
Note:
The Command to be executed for alerts text box will appear only if the Enable Command Execution flag in the COMMAND EXECUTION section of the MANAGER SETTINGS page (that appears when the Manager option is chosen from the Settings tile) is set to Yes.
Escalation mail ID / mobile number: To ensure the continuous availability of mission-critical IT services, it is essential that problems be detected at the earliest and remedial action be initiated immediately. Naturally, the performance of an IT operations team is assessed by its ability to proactively isolate problems and by the speed with which the identified issues are fixed. As most IT operations teams are required to support strict service level guarantees, problems that remain unnoticed or unresolved for long periods of time could result in service level violations, warrant severe penalties, and ultimately even impact the reputation of the service provider.
The eG Enterprise suite, with its patented correlation technology and its multi-modal (email/SMS/pager/console) problem alerting capability accurately identifies potential issues in the monitored environment, and intimates the concerned IT operators before any irredeemable damage is done. To enable IT managers to proactively track the performance of their operations teams, eG Enterprise also includes a time-based alarm escalation capability. With this capability, when a problem remains unresolved for a long time period, the eG Enterprise manager automatically escalates the alarm to one or more levels of IT managers. The alarm escalation is based on a pre-defined escalation period, which is configured by the administrator of eG Enterprise.
The escalations are personalized for each user - i.e., each user in the eG Enterprise system is associated with multiple levels of managers. When an alert that has been sent to a user is not resolved within the escalation period, the alert is forwarded to the first level of management. If the problem remains unresolved for another escalation period, the second level of management is informed, and so on. By hierarchically escalating problems to IT managers, eG Enterprise ensures that the management staff stays informed of the state of the mission-critical IT services they control, and that they can intervene in a timely manner to ensure quick and effective resolution to key problems.
The Escalation mail ID section is where the different levels of escalation need to be specified. A comma-separated list of mail IDs/mobile numbers can be specified for the Level 1 field to indicate the first level of escalation. You can, if you so desire, define additional support levels by clicking on the ‘+’ sign that appears at the end of the Level 1 text box. This way, issues that remain unresolved even at Level 1 will be escalated to Level 2 and so on. You can create upto a maximum of 5 escalation levels. To delete a newly added level, click on the ‘-’ sign at the end of the corresponding Level text box.
Note:
Alarm escalation will work only if you configure the following:
The duration beyond which the eG Enterprise system needs to escalate a problem to the next level
The alarm priorities to be escalated
Type of notification: By choosing the New option, an administrator can indicate to eG Enterprise that when alerting a user via email/SMS, the system should send the details of newly added alarms only. On the other hand, if the Complete option is chosen, the user will receive a complete list of current alarms every time a mail/SMS message is generated.
Message mode: This option governs the format in which an alarm is reported in an email message. If the HTML option is chosen, the alarm details are formatted as HTML text whereas the Text option formats the alarm details as plain text.
Note:
If HTML is chosen as the Message mode, then alarms sent by mail will carry a hyperlink named HOME at the right top corner. The destination of the hyperlink can be configured using the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory. The [MISC_ARGS] section of the eg_services.ini file contains a MailHomeURL parameter that is left blank by default. In this case, clicking on the HOME link will connect you to the eG manager and open the login screen. By providing a specific URL against MailHomeURL, you can ensure that monitor users are lead to the specified URL upon clicking the HOME hyperlink.
Include measure details in mail alerts: By default, the No option is chosen from the Include measure details in mail alerts list, indicating that the email alerts to a user will not include any measure details. However, if you want the email alerts to a user to include a time-of-day graph of the problem measure plotted for the last 1 hour (by default), then, pick the Graph option from this list. If you want the email alerts to a user to include the data plotted in a 1-hour measure graph, then, pick the Data option from this list.
Include detailed diagnosis in mail alerts: By default, this flag is set to No. This implies that, by default, the detailed diagnosis (if available) of the problem measure will not be sent along with the email alerts to users. If you want the email alerts to a specific user to include detailed diagnosis information as well, then, set the Include detailed diagnosis in mail alerts flag to Yes. This information will enable users to move closer to the root-cause of the problem condition.
Email alerts only during shift periods: Some environments - especially the ones that span geographies - could have operators working in shifts; for instance, an MSP environment could comprise of one/more user groups, which might work only in the nights, in order to provide help-desk services to the customers in a particular geographic region. These users naturally, would want to receive email alerts of issues only during their working hours; during the rest of day, they may prefer to be alerted via SMS. To facilitate this, eG Enterprise allows you to configure shift periods for individual users. Separate shift periods can be configured for receiving email alerts, SMS alerts, and escalation mails.
For instance, if you want to indicate on which days and at what times a user needs to receive email alerts of issues, then he/she should first enable the Email alerts only during shift periods flag, by setting it to Yes.
Note:
In environments where shifts are not relevant, the Email alerts only during shift periods flag may be meaningless. You can therefore ensure that this flag does not appear in the USER PREFERENCES tab page by following the steps given below:
Select the Alert Settings option from the Mail Alerts menu of the Alerts tile.
Select the Shift Periods node from the Settings tree in the left panel of the page that appears.
When the SHIFT PERIODS CONFIGURATION section appears in the right panel, set the Allow shift period configuration flag to No. By default, this flag is set to Yes.
Finally, register the changes by clicking the Update button in that page.
Upon setting the flag to Yes, you will be required to specify the Days on which the user should receive email alerts; also, in the Shifts field alongside, you need to mention the specific time periods on the chosen Days at which the user should receive email alerts
To select one/more Days, do the following:
First, click on the Calendar control (
) next to the Days field.
From the DAYS list that pops out, which lists the days of the week, select the days on which email alerts need to be sent to the user.
To choose more than one day from the list, select a day by clicking on the left mouse button, and then, with the Ctrl button on your keyboard pressed, click on another day to select it. Similarly, multiple days can be selected. To add your selection to the Days field, click the Add button in the DAYS list. You will thus return to the USER PREFERENCES tab page where the selected days will be listed against the Days field.
First, click on the Calendar control (
) next to the Shifts field. Doing so invokes the SHIFTS window, wherein you can specify a From time and To time for your shift. Ensure that the shift timings correspond to the Time zone chosen for the user.
To provide an additional time slot, click on the circled ‘+’ button at the end of the first row. Another row then comes up wherein you can provide one more time period. In this way, you can associate a maximum of 5 shift periods with the chosen Days.
To remove a shift period from the SHIFTS window, simply click on the circled ‘-’ button against the corresponding specification. Finally, to add these time periods to the Shifts field, click on the Add button in the SHIFTS window. You will thus return to the USER PREFERENCES tab page, where you can find the time period(s) that you specified appear against the Shifts field.
With that, one Day-Shift specification is complete.
To add another Day-Shift specification, just click on the circled ‘+’ button at the end of the first row. Another row will then appear, where you can specify a few more Days and Shifts. This way, a number of Day-Shift specifications can be associated with a user.
This number is configurable, and can be any number between or equal to 1 and 10. To configure this number, go to the SHIFT PERIODS CONFIGURATION section of the MAIL ALERT PREFERENCES page that appears when you click on the Alert Settings option of the Mail Settings menu in the Alerts tile. In the SHIFT PERIOD CONFIGURATION section, select the Maximum number of day-shift combinations.
To delete a particular Day-Shift specification, simply click on the circled ‘-’ button.
Next, using the Shifts field, provide the specific time periods at which email alerts should be sent out to the user on the chosen days. For that, do the following:
SMS alerts only during shift periods: Similar to email alerts, SMS alerts can also be configured to be sent out only during specified time periods on specific days of the week. The first step towards this is to enable the SMS alerts only during shift periods flag by selecting the Yes option in the USER PREFERENCES tab page. Using the Days and Shifts fields that appear subsequently, you can configure one/more Day-Shift combinations in the same manner as discussed for email alerts.
Note:
In environments where shifts are not relevant, the SMS alerts only during shift periods flag may be meaningless. You can therefore ensure that this flag does not appear in the USER PREFERENCES tab page by following the steps given below:
Select the Alert Settings option from the Mail Alerts menu of the Alerts tile.
Select the Shift Periods node from the Settings tree in the left panel of the page that appears.
When the SHIFT PERIODS CONFIGURATION section appears in the right panel, set the Allow shift period configuration flag to No. By default, this flag is set to Yes.
Finally, register the changes by clicking the Update button in that page.
Escalation alerts only during shift periods: Like email and SMS alerts, the eG manager can be configured to send escalation mails/SMS' also at pre-defined days and time slots. To enable this capability, first, turn on the Escalation alerts only during shift periods flag by selecting the Yes option in the USER PREFERENCES page. As before, this will bring up the Days and Shifts fields, using which you can configure the days on which and the times at which alerts are to be escalated to the specified individuals. The procedure for configuring the Day-Shift combinations is the same as that for email and SMS alerts.
Note:
In environments where shifts are not relevant, the Escalation alerts only during shift periods flag may be meaningless. You can therefore ensure that this flag does not appear in the USER PREFERENCES tab page by following the steps given below:
Select the Alert Settings option from the Mail Alerts menu of the Alerts tile.
Select the Shift Periods node from the Settings tree in the left panel of the page that appears.
When the SHIFT PERIODS CONFIGURATION section appears in the right panel, set the Allow shift period configuration flag to No. By default, this flag is set to Yes.
Finally, register the changes by clicking the Update button in that page.
Execute commands only during shift periods: As mentioned already, the Command to be executed for alerts text box can be configured with the command to run a custom script. This script will be automatically executed when an alarm is newly created/modified/deleted for a specific user, and will route the details of the alarms to third-party customer relationship management systems or TT systems. If need be, you can have this custom script run only during specific time slots on specific days. To enable shift-based execution of the specified Command, set the Execute commands only during shift periods flag to Yes. As before, this will bring up the Days and Shifts fields, using which you can configure the days on which and the times at which the specified Command needs to run. The procedure for configuring the Day-Shift combinations is the same as that for email and SMS alerts.
Both these parameters can be configured using the ALARM ESCALATION section ins the MAIL ALERT PREFERENCES page that appears when the Alert Settings option is selected from the Mail Settings menu of the Alerts tile.
Note:
By default, where multiple levels of escalation are configured, the eG manager does not consider the changes that may occur in the priority of an alarm between two levels of escalation. For instance, if the priority of an alarm changes from Major to Critical after the first level escalation alert is sent, the second level escalation alert will be sent for the Critical alarm only. Recipients of the second level escalation alerts will hence have no knowledge of the original state of that alarm. Similarly, recipients of the first level escalation alerts will not know that the alarm priority has changed. In the absence of complete problem information, the recipients of escalation alerts may not be able to perform effective problem diagnosis and provide accurate solutions. To avoid this, you can now configure the eG manager to reset escalation levels if a state transition occurs. This way, if the alarm priority changes after the first level escalation, the escalation cycle will begin all over again - i.e., escalation alerts related to the modified alarm will first be sent to the first level recipients and then the next level and so on.
Next, in the Monitor section:
Alarm display: By selecting one or more options provided against this field, you can associate specific alarm priorities with the user being created. When this user later logs into the eG monitor interface, alarms of the chosen priorities alone will be displayed in the CURRENT ALARMS window of the monitor interface.
Remote control: Using this option, you can indicate whether the new user is to be provided access to the managed components. This capability, when enabled, allows monitor users to remotely manage and control components from a web browser itself. By default, this capability will be Disabled for a new user. To enable this capability for a particular user, select the Enable option. Doing so invokes a Remote command execution list, using which you need to indicate whether the new user is authorized to execute any command remotely, or is only allowed to choose from a pre-configured list of commands.
Allow alarm deletion: To allow the new user to delete alarms from the CURRENT ALARMS window in the eG monitor interface, select the Yes option from the Allow alarm deletion section.
Allow alarm acknowledgement: Optionally, specific users can be configured to acknowledge an alarm displayed in the eG monitor interface. By acknowledging an alarm, a user can indicate to other users that the issue raised by an alarm is being attended to. In fact, if need be, the user can even propose a course of action using this interface. In such a case, a user with Admin or Supermonitor privileges (roles) can edit the acknowledgement by providing their own comments/suggestions on the proposed action. The acknowledgement thus works in three ways:
Ensures that multiple members of the administrative staff do not unnecessarily invest their time and effort in resolving a single issue;
Serves as a healthy forum for discussing and identifying permanent cures for persistent performance ills;
Indicates to other users the status of an alarm
To enable the alarm acknowledgement capability for the new user, select the Yes option from the Allow alarm acknowledgement section in this page.
Monitor Home Page: By default, the Monitor Dashboard appears as the home page of the eG monitoring console - i.e., as soon as a user logs into the monitoring console, the Monitor Dashboard appears as the first page by default. eG Enterprise however, allows administrators to set any page they deem fit as the Monitor Home Page for individual users to the eG monitoring console. This way, every user, upon logging into the eG monitor interface, is enabled to view straight up the information that interests him/her the most, thereby saving time and minimizing the mouse clicks that may be required to navigate to that information!
The home page preference is typically driven by the monitoring needs of specific users and the roles assigned to them. For instance, a service manager, who is responsible for minimizing/eliminating service outages, would want to know on login how all the critical services in the environment are performing currently, and which services are in an abnormal state. For this purpose, administrators may want to set the Service List as the home page of such users.
In the Reporter section, specify the following:
Maximum timeline for reports: Typically, eG Enterprise permits multiple users to simultaneously access the eG Reporter console and generate a wide variety of reports spanning any timeline of their choice. While this imparted tremendous flexibility in report generation, when concurrent users generate reports for broad time periods, report generation could slow down a little. In order to avoid this, administrators can set the maximum timeline for which each user can generate reports, by selecting an option from the Maximum timeline for reports list in the ADD NEW USER page. By default, 1 month will be selected here. This implies that the user being created can generate reports for a maximum timeline of 1 month only, by default. The other options in this list are as follows: 1 day, 2 days, 3 days, 4 days, 5 days, 6 days, 1 week, 2 weeks, 3 weeks, and 4 weeks. Besides ensuring that unauthorized users are denied access to more historical information than necessary, this timeline restriction also greatly reduces the strain on the eG database.
Note:
The default users - admin and supermonitor - are not governed by this maximum timeline setting; these two users therefore can generate reports for any timeline.
In the Associate segments/services/service groups/zones/components section, indicate the following:
Auto-associate to other users: eG Enterprise allows administrators to assign specific segments/services/components/zones to a new user for monitoring. If one/more other existing users share the same assignment, then you can automatically associate all the infrastructure elements chosen for one user with other users to the eG Enterprise system. To achieve this, first select the Auto-associate to other users check box. Doing so invokes an Available user(s) list from which you can select the users to whom the same set of segments/services/components/zones need to be assigned.
Note:
The Associate segments/services/service groups/zones/components section will appear only when the User role chosen allows access to Limited components in the monitored environment. If the role chosen allows Complete components access, this section will not appear.