Adding New Users

In a fresh installation of eG Enterprise (be it the Enterprise model or SaaS model), the default admin user alone has user management rights. This user can login to the eG admin interface and can configure additional users/groups.

The first step toward this is to access the Add User page. For this, do either of the following:

• Select the Add option from the User menu in the User Management tile of the Admin menu,(or);
• Click on the icon in the Overview page

Figure 1 then appears. To add a new user/group in a SaaS deployment of eG, follow the procedure detailed in the Tenant Management by Administrators . To add a new user/group in an Enterprise deployment of eG, follow the steps below.

1. The basic information tab page opens by default. From this page, select an Entity type. In the Enterprise model, the following entities are supported:

   • Organizational Unit: Smaller user groups within an organization can be created as Organizational units - eg., departments within an organization, support groups within a technical support cell, the different branches of an enterprise. An Organizational Unit can contain more Organizational Units or individual Users.
   • User: These are individual users who can belong to the Default Organization or an Organizational Unit.
2. Any entity type you create - be it an organizational unit or a user - can belong either to the Default organization or to another organizational unit. From the Belongs to drop-down therefore, pick the grouping to which the entity type you are creating belongs.

3. Next, assign a Role to the new entity. You can choose from any of the default roles discussed below or create a new role and assign it to the entity:

   • OrgAdmin: This role allows an entity to administer and monitor a limited set of infrastructure elements alone. In other words, any entity who is assigned this role will be allowed access to the eG admin interface, so they can download and install agents for monitoring those components that have been explicitly assigned to them by the administrator, discover and manage such components, and configure tests, thresholds, and alarm policies for these components. The role also enables the entity to build new segments, services, groups, and zones for monitoring using the assigned components. The entity can also login to the eG monitoring console to understand the performance and problems pertaining to the components, services, segments, and zones that are part of their specific monitoring scope. The role also allows the entity access to the Configuration Management interface, but does not authorize them to create, modify, or delete additional users/entities/roles.

   • OrgAdminNoConfig: This role enables an entity to perform all activities that an OrgAdmin can, but does not allow the entity access to the Configuration Management interface.
   • OrgAdminWithUserMgmt: In addition to OrgAdmin privileges, this role also enables the entity to perform user management by adding, modifying, and deleting users/roles/entities.
   • OrgAdminWithUserMgmtNoConfig: An entity who is assigned this role is allowed all privileges of an OrgAdminWithUserMgmt, except the right to access the Configuration Management interface.
   • Admin: This role can only be assigned to the Entity type, User. Users who are assigned administrative rights become the super-users of the system. Such users can choose what hardware and application servers are to be monitored by the system, where the agents should be executed to monitor the hosted environment, what tests these agents should run, how often these tests should be executed, and can view the status of the entire monitored infrastructure. The administrative user also has the rights to add, delete, and modify user roles and individual user profiles. The default admin user is assigned the Admin role only.
   • Monitor: This role can only be assigned to the Entity type, User. If the eG license enables the eG Reporter and Configuration Management capabilities, then Monitor users will have access to the monitoring, reporting, and configuration management consoles of eG Enterprise. In these consoles, the monitor user can view the details pertaining to only those components/segments/wi/zones/service groups that have been explicitly assigned to him/her. Each monitor user is associated with an email address to which alarms pertaining to the assigned elements will be forwarded. The user’s profile also includes information regarding his/her alarm preferences - whether alarms have to be forwarded in text or HTML mode, whether a complete list of alarms has to be generated each time a new alarm is added, or whether the new alarm alone should be sent via email, etc. Each monitor user is associated with a subscription period. eG Enterprise allows the monitor users to access the system until this period only.
   • Supermonitor: This role can only be assigned to the Entity type, User. A Supermonitor user has an unrestricted view of the monitored infrastructure. He/she can receive alarms pertaining to the whole infrastructure that has been configured by the administrative user. The default supermonitor user is assigned the Supermonitor role only. A Supermonitor user is allowed access to the reporting and configuration management modules as well, provided the eG license enables the eG Reporter and Configuration Management capabilities.
   • SupermonitorNoConfig: This role can only be assigned to the Entity type, User.This role can only be assigned to the Entity type, User. Users with SupermonitorNoConfig privileges will have unrestricted access to the monitoring and reporting consoles only - such users will not be able to access the configuration management console, even if the eG license enables this capability.

   • AlarmViewer: This role can only be assigned to the Entity type, User. This role is ideal for help desk personnel. The users vested with AlarmViewer permissions can login to the monitor interface, and perform the following functions:

     • View the details of alarms associated with the specific components and services assigned to them
     • Provide feedback on fixes for the alarms
     • View feedback history

     Like Monitor users, users with this role can only monitor the components assigned to them.

• SuperAlarmViewer: This role can only be assigned to the Entity type, User. Users with the SuperAlarmViewer role have all the privileges of the AlarmViewer role. In addition, users with the SuperAlarmViewer role have access to all the components being monitored.
• ServerAdmin: This role can only be assigned to the Entity type, User. The users who have been assigned the ServerAdmin role have all the administrative rights of an Admin user, except the right to user management. Similarly, like a Supermonitor user, a ServerAdmin user can monitor the complete environment, and even change his/her profile.
• MonitorNoConfig: This role can only be assigned to the Entity type, User. The users who have been assigned the MonitorNoConfig role will have access to the eG monitoring and reporting interfaces only, and not the eG Configuration Management interface.
• MonitorWithLimitedAdmin: This role can only be assigned to the Entity type, User. Administrators can create additional users with administrative privileges to configure the monitoring for the components that are assigned to them. These users can configure tests, thresholds, alarm policies and maintenance policies for the components in their purview. The MonitorWithLimitedAdmin role included in eG Enterprise can be used to create such users. This capability allows delegated administration, which is a key requirement for many enterprises and service providers.
• MonitorWithLimitedAdminNoConfig: This role can only be assigned to the Entity type, User. Users with MonitorwithLimitedAdminNoConfig privileges will have unrestricted access to the components assigned to them. This includes administrative access to configure tests, thresholds, alarm policies and maintenance policies for the components assigned to them. Though these users are provided with access to monitoring and reporting consoles, they are denied access to configuration management console, even if the eG license enables this capability.

4. The eG administrative interface provides administrators with a wide variety of options to manage user information. Be it user creation, modification, deletion, or simply viewing user information, any type of user-related activity can be performed quickly and easily using the eG administrative console. Typically, when an eG user logs into the eG Enterprise system, the login is validated by the eG database, which stores the user information. However, in large IT environments that span multiple domains, the Active Directory server functions as the central repository for information related to users spread across domains, and also authenticates domain user logins. To avoid the confusion that might arise when using both the eG manager and the AD server for user authentication in such multi-domain environments, administrators might want the eG manager to integrate with AD; this ensures that the eG manager serves as the single, central, secure console for automatically authenticating logins by eG users, regardless of the size of the environment or the domain to which the user belongs. The first step towards implementing this integration is the creation of the domains and sub-domains. Use the Admin -> User Management -> Domains menu sequence to configure the domains. To know how to create domains, refer to Adding/Modifying/Deleting a Domain. Subsequent to domain creation, if you attempt to create a new user using this page, you will be prompted to indicate the User authentication mode that applies to the new user. If you are creating a domain user/group, whose login requests are to be authenticated by the Active Directory, then select the Domain option. If you are creating a user who is local to the eG Enterprise system, and whose login requests are to be authenticated by the eG database, select the Local option. Upon choosing the Domain option, you will have to select the domain to which the user belongs from the Domain drop-down in Figure 1.

5. Then, indicate what you want to create - whether a domain User , domain user Group - by picking the relevant option from the Operation section.

6. To create a domain User, do the following:
   • Set the Operation flag in Figure 1 to User.

   • Then, specify the ID of the new user in the ID text box, and click the Validate button (see Figure 4). When this is done, the eG manager immediately connects to the Active Directory server and verifies whether the user is a valid domain user or not. If the user is not a valid user, then an error message to that effect appears. On the other hand, if the user is indeed a valid domain user, then the eG manager allows you to proceed with the user creation (see Figure 4). However, you cannot provide a password for the domain user. This is because, the credentials of the domain user are configured in and maintained by the Active Directory server; eG Enterprise therefore, will neither reveal nor allow you to modify the password of the domain user, thus ensuring data integrity. Moreover, subsequently, when you log into the eG management console as a domain user, you will have to make sure that you prefix the user name with the domain name in the format: <<domainName>>/<<Username>>(or <<domainName>>\<<Username>>). Every time a domain user logs into the eG Enterprise system, the login will be authenticated by the Active Directory server that manages the users in that domain.

     

     Figure 1 : Validating a domain user name

7. Apart from individual domain users, you can also create domain user groups using the Add User page. Once a domain group is added to the eG Enterprise system, all domain users who belong to that group will be able to login to the eG Enterprise console, even if their domain credentials have not been explicitly registered in the eG system. Moreover, the access rights, privileges, and monitoring scope defined for the group will automatically apply to the users in the group, thereby saving the time and drudgery of configuring multiple user profiles - one each for every user in an Active Directory group. To create a domain user group, do the following:

   • Set the Operation flag in Figure 4 to Group.

   • Then, proceed to specify the Group name. A domain in AD may consist of many organizational units (OUs). Each OU may be associated with a set of domain user groups. If you know the name of the group you want to register, then proceed to manually type in the name of the group in the Group name text box, and click the Validate button to validate that group name.

     

     Figure 2 : Validating a domain group, the name of which was manually specified

     Alternatively, you can quickly browse the OUs in the chosen Domain to locate the user group of interest to you. For this, first select the Groups (Choose group from a list) option from the Operation drop-down. Then, click the icon to the right of the Group name box.

     

     Figure 3 : Clicking on the icon to browse OUs

     Figure 4 will then appear.

     

     Figure 4 : Choosing a domain user group

   • The left panel of Figure 4 displays a tree structure – while the OUs configured in the chosen Domain appear as the nodes of the tree, the sub-units within an OU appear as the sub-nodes. You can expand an OU node to view the sub-units within. Clicking on an OU/sub-unit in the tree will list all the domain user groups associated with that OU/sub-unit in the right panel. Click on a domain group in the right panel to register that group with eG Enterprise.

     Note:

     By default, the eG manager rediscovers the list of OUs/groups every hour. This means that any new OUs/groups you add to Active Directory will show up in Figure 4 above only at the end of the hour. If you want OUs/groups to be rediscovered more frequently, then do the following:

     1. Login tothe eG manager host.

     2. Edit the eg_mgrmisc.ini file in the <EG_INSTALL_DIR>\manager\config directory (on Windows;on Unix, this will be /opt/egurkha/manager/config directory).

     3. In the [ADGroups_Thread_Settings] section of the file, you will find a ThreadFrequency parameter that is set to 1.

     4. To increase the frequency of discovery, increase the value of this parameter.

     5. Finally, save the file.

     The selected domain user group then appears against Group name , as depicted by Figure 5 below. All users who are part of this AD group will now be allowed access to the eG Enterprise console. The rights and privileges (eg., role, expiry date, email/SMS alert settings, alarm acknowledgement/deletion rights, etc.) defined for the chosen group will govern all users who belong to that group. This saves administrators the trouble of defining separate profiles for each domain user in a group.

     

     Figure 5 : Registering a group that is selected from the list of OUs in an AD server

     Note that the group is not associated with any 'password'. This implies that while a group itself cannot login to the eG management console, a user who belongs to the group can login using the credentials defined for him/her in the AD server. At the time of login, the group user should provide his/her name in the format: <DomainName>\<UserName>. Everytime a group user logs into the eG management console, the solution automatically connects to the AD server to validate the login.

     Note:

     • eG Enterprise can be integrated with Active Directory only if the eG manager is installed using JDK 1.5 or higher. If not, you will not find any of the above-mentioned options in the eG administrative interface.
     • If a domain user group is registered with the eG Enterprise system, and a profile is later created in eG for a particular domain user in that group, then, when that user logs into the eG management console, the user-level settings will override the group-level settings.
     • If a domain user belongs to more than one AD group that is created in the eG Enterprise system, then, when that user logs in, the solution provides him/her with a list of domain groups to choose from. Selecting a group from the list enables the user to automatically inherit the access rights and monitoring scope defined for that group.

8. Upon choosing the Local option, on the other hand, you will be prompted to specify the following:

   • Specify a unique User ID in the ID text box.

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

     

     Figure 6 : Adding a new local user

   • Next, indicate whether/not you want to allow the local user to modify his/her password. Typically, a new local user logs in using the credentials assigned to him/her by the administrator. After logging in, for security purposes, the user may choose to modify the password by editing their profile. If you want to grant the local users the right to change their password thus, then select the Allow user to modify password check box. If not, deselect that check box.

9. The next step in user creation is to provide an Expiry date for the new user. One more added feature of the eG Enterprise 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.

10. Then, click the Next button in Figure 6. Doing so will automatically open the user preferences tab page. Let us begin by discussing the General section of the page, which is depicted by Figure 7 below.

    

    Figure 7 : Defining the settings in the General section of the USER PREFERENCES tab page

11. In the General section of Figure 7, 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.

      To understand time zone association better, take the case of an example. Assume that the user elvis, who has received the email depicted by Figure 8, has been configured to use the time zone, Asia/Calcutta. We can thus conclude that the Start Time of the problem indicated by Figure 8 above has been determined based on the time settings of the Asia/Calcutta zone.

      

      Figure 8 : Email alert of user elvis

      Now, assume that a user named john has been configured to receive email notification of the same problem. However, john has been assigned the Asia/Singapore time zone. Figure 9 depicts the email alert of user john.

      

      Figure 9 : Email alert for user john

      In Figure 9, you can see that while the other problem details remain the same as in Figure 9, the Start Time has changed to reflect the time settings of the Asia/Singapore zone.

      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 of the Mail/SMS Settings section), then the Time Zonespecification 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 Zonesettings. All such alerts will be generated in the eG manager’s local time zone setting.

    • Date format to be used: 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 to be usedlist. 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.

      Note:

      In the Detailed Diagnosis page of the eG monitoring console, the date format chosen here applies only to the measurement period that you see therein. If the detailed diagnosis has columns containing date/time values, then this format will not apply to those columns.

    • Logo preference for Login page, Logo preferences for Admin/Monitor, 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.

      

      Figure 10 : Configuring a custom logo for a user

      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 theLogo/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 (see Figure 10). Then, click the button adjacent to the list box to upload the custom logo to the eG manager. Figure 11 will then appear.

      

      Figure 11 : Uploading the logo to the eG manager

      The type, size and resolution of the logo image should match with the specifications mentioned in Figure 11. Click the Browse button in Figure 11 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 Figure 10.

12. In the Mail/SMS Settings section of Figure 12, specify the following:

    

    Figure 12 : Configuring the Mail/SMS Settings

    • Mail Sender: This option appears if at least one alarm priority is chosen from ‘Alarms by mail / SMS’in the Alert Settings 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 ‘Alarms by mail / SMS’ in the Mail/SMS Settings 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 an SMS manager has been installed in the network, and the eG manager has been configured to work with the SMS manager.

13. In the Alert Settings section of Figure 13, specify the following:

    

    Figure 13 : Configuring Alert Settings

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

    • 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, 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 of Figure 7 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 1field 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 1text box.

      This way, issues that remain unresolved even at Level 1will be escalated to Level 2and so on. You can create up to a maximum of 5 escalation levels. To delete a newly added level, click on the '-' sign at the end of the corresponding Leveltext 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

      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.

    • 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 alertsflag 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 Settings 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 periodssection 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 toYes, 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 (see Figure 14):

      

      Figure 14 : Enabling the ‘Email alerts only during shift periods’ flag

      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 (see Figure 15), which lists the days of the week, select the days on which email alerts need to be sent to the user.

        

        Figure 15 : The DAYS list

      • 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 (see Figure 14).

      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:

      • 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 (see Figure 16). Ensure that the shift timings correspond to the Time zone chosen for the user.

        

        Figure 16 : Specifying the shift time periods

      • 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 (see Figure 16). 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 (see Figure 17).

        

        Figure 17 : Configuring multiple Day-Shift combinations

        The number of day-shift combinations that you can set 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 preferencespage that appears when you click on the Alert Settings option of the Mail Settings menu in the Alerts tile. In the shift periods section, select the Maximum number of day-shift combinations.

        To delete a particular Day-Shift specification from Figure 17, simply click on the circled ‘-‘ button in Figure 17

    • 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 (see Figure 18).

      

      Figure 18 : Configuring shift periods for SMS alerts

      Note:

      In environments where shifts are not relevant, the SMS alerts only during shift periods flag is meaningless. You can therefore ensure that this flag does not appear in the user preferences page by following the steps given below:

      • Select the Alert Settings option from the Mail Settings 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 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 preferencespage. As before, this will bring up the Days and Shifts fields (see Figure 19), 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 (see Figure 19).

      

      Figure 19 : Configuring shift periods for escalation mails/SMS

      Note:

      In environments where shifts are not relevant, the Escalation alerts only during shift periods flag is meaningless. You can therefore ensure that this flag does not appear in the user preferences page by following the steps given below:

      • Select the Alert Settings option from the Mail Settings 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 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 (not shown in Figure 7) 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.

14. Next, in the Monitor section, configure the following:

    

    Figure 20 : Configuring Monitor settings for the new user/group

    • 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 alarmswindow of the monitor interface.
    • 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 MonitorDashboard 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.

    • 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 and Remote control actions flag (see Figure 21). Using the Remote command execution list, you can 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.

      

      Figure 21 : Selecting a command for remote execution

      The Remote control actions flag allows you to specify whether the new user is authorized to run all remote actions associated with all the managed components or to customize the actions that the new user can perform. If you select Associate all actions option, then the new user can perform all remote actions associated with all the managed components. On the other hand, if you select Customize actions option, you will have to associate the remote actions to the new user using the Remote Control Actions (see Figure 22) tab page that appears upon clinking the Update button in the User Preferences page for the new user.

      

      Figure 22 : The Remote Control Actions tab page

      In the Remote Control Actions tab page, first select the type of component from the Component Type drop-down list. This will list the remote actions that are associated with the chosen component type in the Associate actions list box (see Figure 23).

      

      Figure 23 : Associating Remote control actions to the user

      From the Associate actions list box, select the remote actions that you want the new user to perform and click the < button. This will transfer your selection to the Associated Actions list box (Figure 24). Then, click the Assign and Add More button if you want to associate more remote actions associated with different component types to the new user.

      

      Figure 24 : Associated remote actions

      To view the list of remote actions associated with the new user, click the View associated actions button. This will invoke Fig 26.

      

      Figure 25 : Viewing remote actions associated with the new user

      Finally, click the Finish button in the Remote Control Actions tab page to register the changes.

      In addition, eG Enterprise also allows users to directly execute the commands that are not pre-configured along with the pre-configured list of commands. To grant such a right to any user(s), first, you need to do the following:

      • Edit the eg_services.ini file in the <eg_install_dir>\manager\config directory
      • You will find an ExecuteAnyCommand parameter that is set to No, by default. This indicates that, by default, only the admin user is privileged to execute commands other than the ones listed in the pre-configured list.

      • To extend that right to other users, set Yes against the ExecuteAnyCommand parameter:

        ExecuteAnyCommand=Yes

      • Finally, save the eg_services.ini file.

      Enabling this capability will add the Any commands option in the Remote command execution drop-drown list as shown in Figure 26.

      

      Figure 26 : Any commands option

      To allow a user to run the custom commands, the Any commands option should be chosen against the Remote command execution drop-down list while creating the user. Doing so, will add the Execute command option in the Actions list using which the user can run the custom commands.

    • Allow user to create mydashboard: With eG Enterprise, tenants have the option to build a customizable My Dashboard, using which they can graphically compare current and historical performance of multiple applications of interest to them. This dashboard not only allows a tenant to choose the components to focus on, but also pick the measures and even descriptors that should be featured in it. By default, this dashboard capability is enabled for any new tenant. Accordingly, the Allow user to create mydashboard flag is set to Yes by default. If you want to disable this capability for any tenant, set this flag to No.

15. In the Reporter section, specify the following:

    

    Figure 27 : Configuring Reporter Settings for New User

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

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

      Note:

      At any given point in time, you can close any section that is available for configuration in the user preferences tab page by clicking the down arrow button that precedes the section name. For instance, the Reporter section can be closed by clicking the ‘down-arrow’ button adjacent to the section name, Reporter.

17. Finally, click the Update button in the USER PREFERENCES tab page to save the settings.
18. Updating user preferences invokes the Elements Association tab page.

    

    Figure 28 : Associating infrastructure elements with a tenant Organization

19. Using Figure 28, you can associate one/more infrastructure elements such as zones/services/segments/components with the new entity (user/group/organizational unit). Additionally, external agents and remote agents can also be associated with a new entity. To associate external and remote agents with the entity being configured, do the following:

    • First, from the Associate drop-down, pick the type of element that you want to assign to the new tenant. Your options are as follows: Components, Segments, Services, Service Groups, Zones, External Agents, Remote Agents, and Virtual Machines. To assign external agents, pick the External Agents option. The available external agents will then be listed in the External Agents Available list. From this list, select the external agents that the banking environment should use and click the < button. This will transfer your selection to the External Agents Associated list (see Figure 29).

      

      Figure 29 : Associating external agents with the user/organizational unit you are adding

    • With that, external agents are associated with the organizational unit/user being added. Next, proceed to assign remote agents. For that, first click the Assign and Add More button in Figure 29. Then, pick the Remote Agents option from the Associate list, select the remote agent you want to assign from the Remote Agents Available list, and click the < button. Your selection will be transferred to the Remote Agents Assigned list (see Figure 30). This means that the entity being added can now use the chosen remote agents to monitor any component assigned to them.

      

      Figure 30 : Associating one/more remote agents with the tenant Organization

    • Next, let us see how we can add zones to the entity being created. For that, click the Assign and Add More button in Figure 30, and then select the Zones option from the Associate list. The Zones Available list will then be populated with the pre-configured zones.

      Select the zones you want to map to the new entity from the Zones Available list and click the < button (see Figure 31).

      

      Figure 31 : Associating one/more zones to the organizational unit/user you are creating

    • To map an independent component with an entity, first click the Assign and Add More button in Figure 32. Then, select the Components option from the Associate list. A Component type drop-down will then appear. Select the type of component you want to assign from this list. All independent components of the chosen type will then appear in the Components Available list. From this list, select the component that you want to assign to the entity and click the < button.

      

      Figure 32 : Assigning independent components to the organizational unit/user being added

    • Fully-configured business services in the eG Enterprise system can also be assigned to an organizational unit/user. For that, first click the Assign and Add More button in Figure 32. Then, select the Services option from the Associate drop-down, pick the service from the Services Available list, and click the < button. Note that when you associate a service with an entity, all components engaged in the delivery of that service are automatically assigned to that entity.

      

      Figure 33 : Associating a service with the organizational unit/user

    • Likewise, you can assign segments to an entity. This is useful if the target environment comprises of groups of inter-related components, where a problem in one component can ripple and affect the performance of another. For that, first click the Assign and Add More button in Figure 33. Then, select the Segments option from the Associate drop-down, pick the segment of interest to you from the Segments Available list, and click the < button. Note that when you associate a segment with an entity, all components that are part of that segment are automatically assigned to that entity.

      

      Figure 34 : Associating one/more segments with an entity

    • Similarly, virtual machines / virtual desktops can also be assigned to specific entities. This feature is particularly useful for cloud service providers, who often need to provision a VM/desktop on-demand for any customer who requests for it. These cloud consumers (i.e., customers) are only concerned with the availability and internal health of those VMs/desktops that the service provider has provisioned for them, as typically, they will have no knowledge of the virtual servers on which the VMs/desktops operate. This means that these customers may not require monitoring access to the whole virtual server as such. Such customers can be configured as entities in the eG Enterprise system. In the process, the administrator can configure entity-VM/desktop mappings using the eG administrative interface. With the help of these mappings, the cloud service providers will not only be able to track who is using which VM/desktop, but will also be able to provide a customer (i.e., tenant, in eG parlance) personalized monitoring access to the VMs/desktops assigned to them. To assign a VM/desktop to an entity, first click the Assign and Add More button in Figure 34. Then, select the Components option from the Associate list. A Component type drop-down will then appear. Select the VMs/Desktops option from the Component type drop-down. Then, pick a virtualization platform from the Hypervisor Types list. All managed hosts of the chosen hypervisor type will then appear in the Hypervisor Hosts list box. Select the virtual host of interest to you from this list box. If you want to associate only specific VMs on the chosen virtual host with the entity, first select the Associate specific VMs option in Figure 35. The VMs on that host will be listed in the VMs/Desktops Available box. Select the VMs you want to assign to the entity from this box and click the < button. This will transfer the selection to the VMs/Desktops Associated list box.

      

      Figure 35 : Associating specific VMs on a host with an entity

      On the other hand, if you want to associate the entity with only those VMs/desktops that have specific names / name patterns, then select the Associate VMs by Names/Patterns option. Then, specify a comma-separated list of VM/desktop names/patterns in the Names/Patterns text box that appears.

      

      Figure 36 : Associating VMs with specific names/patterns with an entity

      Alternatively, you can assign all VMs on a virtual host to an entity. For that, simply select the All VMs option soon after you pick the virtual host.

      

      Figure 37 : Associating all VMs on a virtual host with an entity

    • The next step is to review the element associations configured thus far, and save them if they are in order. Click the View associated elements button in Figure 37 to check your element associations. Figure 38 will then appear.

      

      Figure 38 : Viewing the element associations

    • Once you are satisfied with your specifications, close the window depicted by Figure 38 and click the Finish button in Figure 33.

Note:

• Independent components that belong to a zone that is associated with a user, will be automatically removed from the Components Availablelist of Figure 32.
• Newly added/managed components belonging to the selected component type do not get associated with the new user immediately. Since this association is mapped as part of the discovery process, there might be a latency equal to the rediscovery period before an association between users and components is updated. If the rediscovery period has not been specified, there will be a latency equal to one day.
• The elements association tab page (see Figure 32) will appear only if the role assigned to the new user allows access to Limited components in the monitored environment. If the new user is assigned a role that allows Complete access, then this page will not appear.
• Say, a user was assigned a role that allowed Limited component access. Assume that a segment named seg-a and a service named online_shop were assigned to this user. If the user role is now modified to allow Complete component access, the access rights of the user will change accordingly - i.e., the user will now have access to all the managed elements in the infrastructure. Say, the user role is now modified once again to allow Limited component access. When this is done, the corresponding user profile will also change, and the segment (seg-a) and service (online_shop) that were originally associated with this user will be automatically reassigned. This indicates that when the access rights of a user role goes from Limited to Complete and then back to Limited, eG Enterprise retains the original assignments of the corresponding user and applies the same eventually.

• Typically, the user activity in high-security environments is periodically audited to ensure compliance with set standards and to enable the swift detection of unauthorized accesses. One of the requirements of such audits is a report that provides a consolidated list of users to the target environment as on the current date, the application(s) they have access to, and the details of the access privileges granted to each user with respect to that application. Such a report enables both the administrators and the auditors to determine if any user has been allowed access to more areas than necessary, thus enabling them to fine-tune their firewall rules.

  As part of this exercise, if administrators want to generate a report for tracking users to the eG Enterprise application alone, then they can enable the user logging capability of the eG manager. To enable this capability, do the following:

  • Edit the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory.
  • Set the UserAudit flag in the [misc_args] section to Yes (default is No).
  • Save the eg_services.ini file.

  Enabling user logging results in the creation of a user_log file in the <eg_install_dir>\manager\config\logs directory. By default, the access permissions of all 'active' user accounts registered with the eG Enterprise system as on the current date, are logged in this file every day. If you want the file to log the permissions of "expired" user accounts too, then, set the LogExpiredUsersPrivilege flag in the [misc_args] section of the eg_services.ini file to Yes.

  The format of the entries in the user_log file is as follows:

  ApplicationNumber, User Id, User Role, Access Permissions

  In the format, ApplicationNumber is a unique identification number that you need to manually assign to the eG Enterprise application. To define an ApplicationNumber for eG Enterprise, edit the eg_specs.ini file in the <eg_install_dir>\manager\config directory, and provide any string/number against the ApplicationNo parameter (in the [misc_args] section). Note that if an Application Number is not defined for eG users in the eg_specs.ini file, then user logging will not occur!

  UserId refers to the name of the user registered with the eG Enterprise system.

  User Role represents the role assigned to the user.

  Access Permissions is a brief description of the specific permissions that have been granted to the user.

  A sample log entry is provided below:

  100, john, testConfigure, testConfigure users have the following abilities: [Admin] configure tests; configure thresholds.

  Here, 100 is the ApplicationNumber, john is the UserId, testConfigure is the User Role assigned to john, and finally, user john is permitted to configure tests and configure thresholds using the eG administrative interface.