Installing and Configuring the eG SuperManager on Windows

The broad steps involved in the eG SuperManager's installation and configuration process are as follows:

  1. Installing the eG SuperManager
  2. Configuring the eG Database
  3. Configuring the Basic Manager Settings

A user-friendly wizard enables you to perform each of these steps seamlessly. A single self-extracting program drives this wizard. Based on what flavor/version of Windows is in use, you have to choose from the following self-extracting programs:

  • The  eGManager_win2008_x64.exe, if you are installing the eG SuperManager on a 64-bit Windows 2008/Windows 7 host;
  • The  eGManager_win2012_x64.exe, if you are installing the eG SuperManager on a 64-bit Windows 8/Windows 2012 host;
  • The  eGManager_win2016_x64.exe, if you are installing the eG SuperManager on a 64-bit Windows 2016/Windows 10 host;
  • The  eGManager_win2019_x64.exe, if you are installing the eG SuperManager on a 64-bit Windows 2019 host;

Once you pick the executable that is ideal for your environment, proceed to install the eG SuperManager.

Installing the eG SuperManager

To begin the installation, double-click on the corresponding executable. The installation wizard that then appears guides you through the installation process.

  1. The Welcome screen appears first. Click the Next button here to continue with the setup.

    Figure 1 : The Welcome screen of the installation wizard

  2. Accept the license agreement that follows by clicking the Yes button therein (see Figure 2).

    Figure 2 : Accepting the license agreement for installing the eG SuperManager

  3. The setup process now requires the hostname and port number of the host on which the eG SuperManager is being configured (see Figure 3). By default, setup auto-discovers the host name and the IP address(es) of the eG SuperManager host, and makes it available for selection inFigure 3. You can pick the host name or any of the IP addresses listed therein to take the eG SuperManager installation forward. If the IP address/host name that you want to use for your eG SuperManager is not discovered for some reason, then, you can choose the Other option in Figure 3. This will invoke Figure 4 where you can manually specifiy the IP address/host name of the eG SuperManager. If the domain name service is used in the target environment, use the full hostname. Otherwise, specify the IP address. However, 7077 is the default port. You can change this port if you so need.

    Figure 3 : Selecting the IP address/host name to use for the eG SuperManager

    Figure 4 : Hostname and port number of the system on which the eG SuperManager will execute

    Note:

    • While specifying the host name/IP address of the manager, please take care of the following aspects:

      1. If the host name is provided when installing the manager, use this name (and not the IP address) for accessing the user interface via the web browser.
      2. If the host name is provided, make sure that forward and reverse lookups for this name are enabled via the DNS service in the target environment.
    • When providing an IP address for the eG SuperManager, note that only an IPv4 address can be provided. To configure the eG SuperManager on a host that has been configured with an IPv6 address, you will have to provide the fully-qualified host name of that host or an alias name, in Figure 4.
  4. The eG Enterprise system provides users with the option to view and key in data in a language of their choice. Different users connecting to the same manager can view data in different languages. However, some languages such as Chinese, Japanese, and Korean, support a double-byte character set. To view data in the eG user interface in Chinese, Korean, or Japanese, the eG SuperManager should be explicitly configured to display and process double-byte characters. In such a case, enable double-byte support for the eG SuperManager by clicking the Yes button in the figure below. On the other hand, for handling the character sets of other languages (example:French, German, Spanish, Portugese, etc.), the eG SuperManager need not be double-byte enabled. At such times, click the No button to disable double-byte support for the eG SuperManager.

    Figure 5 : Enabling double-byte support for the eG SuperManager

    Note:

    For a detailed discussion on how to enable double-byte support for eG Enterprise, refer to Configuring Double-byte Support for eG Enterprise .

  5. Setup then prompts you to indicate if the eG SuperManager is to be SSL-enabled. If so, click Yes. If not, click No.

    Figure 6 : Indicating whether/not to SSL-enable the eG SuperManager

  6. Next, indicate where the eG SuperManager is to be installed. By default, setup installs the eG SuperManager in the C drive. If you want the eG SuperManager installed in a different directory, use the Browse button in Figure 7. Then, click the Next button in Figure 7 to move to the next step.

    Figure 7 : Specifying the location of the eG SuperManager

  7. Figure 8 then appears, using which you can quickly review your install specifications. To proceed, click the Next button in Figure 8.

    Figure 8 : Reviewing the install settings

  8. This will begin the eG SuperManager installation. During this process, setup automatically extracts and deploys the built-in JDK - OpenJDK 12 - for the eG SuperManager's use. Additionally, setup also automatically configures and readies the built-in Apache Tomcat server, so that the eG SuperManager can service web requests to it efficiently. Once the installation completes successfully, the message depicted by Figure 9 will appear.

    Figure 9 : The message confirming the successful eG SuperManager installation

Configuring the eG Database

After installing the eG SuperManager, proceed to configure the eG database. The eG SuperManager stores real-time performance metrics, history of alarms, detailed diagnostics, thresholds, and even performance trends in this database.

If a SQL database pre-exists on Microsoft Azure, you can configure such a database as the eG database. On the other hand, if a Microsoft Azure SQL database is not in use in your environment, then it is essential to ensure that an Oracle / Microsoft SQL server is available to host the eG database. Such a database server can either reside on the eG SuperManager itself or it could be hosted on an external server.

To enable you to easily configure an eG database, setup automatically leads you to a special web page, soon after the successful installation of the eG SuperManager. Using this web page, you can pick a backend for the eG SuperManager, and configure an eG database on it. The sections below elaborately discuss how this web page can be used to perform the following:

  • Configure a Microsoft SQL database (on a Microsoft SQL server or on Microsoft Azure) as the eG database;
  • Configure a database on an Oracle database server as the eG database;

Using Microsoft SQL Database

As soon as the web page opens, the Microsoft SQL Server tab page opens in it by default (see Figure 10).

Figure 10 : Configuring the eG database on a Microsoft SQL Server

If you choose to configure an Microsoft SQL database (on Azure or on a Microsoft SQL server) as the eG backend, then do the following using Figure 10:

  1. First, enter the location of the Microsoft SQL server by specifying the hostname and port on which the server is hosted against Database Server Name/IP. If you have already configured a SQL database on Microsoft Azure and want to use this database as the eG database, then, against Database Server Name/IP, provide the fully-qualified SQL server name that Azure auto-generates when creating a SQL database.

    Note:

    • If the Microsoft SQL server being configured is part of a Microsoft SQL Cluster, then make sure you specify the virtual cluster IP address / cluster name as the hostname / IP address of the Microsoft SQL server in Figure 10
    • If the Microsoft SQL server being configured is part of an SQL AlwaysOn Availability Group, then make sure you specify the name of the availability group listener as the hostname / IP address of the Microsoft SQL server. An availability group listener is the name of the SQL server to which clients can connect in order to access a database in a primary or secondary replica of an AlwaysOn availability group. If such a SQL server is not configured with a listener name, then enter the virtual cluster IP address or cluster name against hostname / IP address.

  2. If the Microsoft SQL server being configured uses named instances, then set the Use Named Instance flag to Yes. Then, specify the name of the instance against the Instance Name field, as depicted by Figure 11.

    Figure 11 : Specifying the name of the SQL server instance to use

  3. On the other hand, if the Microsoft SQL server does not use named instances, then set the Use Named Instance flag to No, and enter the port at which the SQL server listens in the Database Server Port text box (see Figure 10).
  4. Next, indicate what type of authentication is enabled for the target Microsoft SQL server. If Windows authentication is enabled, then set the Windows Authentication flag to Yes. If SQL Server authentication is enabled, then set the Windows Authentication flag to No. Note that if you are configuring a SQL database on Azure as the eG database, you have to set the Windows Authentication flag to No only, as Microsoft Azure SQL Database supports only SQL Server Authentication by default.
  5. If the Windows Authentication flag is set to Yes, then an additional NTLMv2 enabled flag will appear (see Figure 12). In some Windows networks, NTLM (NT LAN Manager) may be enabled. NTLM is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM version 2 (“NTLMv2”) was concocted to address the security issues present in NTLM.If NTLMv2 is enabled for the target Microsoft SQL server, then set the NTLMv2 enabled flag to Yes; else, set it to No.

    Figure 12 : Indicating whether/not the Microsoft SQL server is NTLMv2 -enabled

  6. Then, you need to indicate whether the Microsoft SQL server instance that will be hosting the eG database is SSL-enabled or not. If not, set the SSL enabled flag to No; if it is SSL-enabled, set the flag to Yes. However, when configuring an existing SQL database on Azure as the eG database, you must set the SSL enabled flag to Yes, as the SQL server instance that Azure creates is SSL-enabled by default.
  7. Next, specify whether/not a new database has to be created to host the eG database. To create a new database, set the Create a New Database flag to Yes. To use an existing database instead, set the Create a New Database flag to No. This means that to use a SQL database that pre-exists on Azure, you need to set the Create a New Database flag to No.
  8. If the Create a New Database flag is set to Yes, then specify the name of the new database that you want to create in the eG Database Name text box (see Figure 12). On the other hand, if the Create a New Database flag is set to No, then, in the Existing databasename text box, mention the name of the existing database in which the eG SuperManager will be storing metrics (see Figure 13). When using an existing SQL database on Azure therefore, enter the name you assigned to that database when you created it on Azure, against Existing database name.

    Figure 13 : Using an existing database on the Microsoft SQL server as the eG database

  9. The eG database is created in the Microsoft SQL server’s database using a special user account. Next, specify the user name and password to be used for this account. If you want to create a new database for the eG SuperManager - i.e., if you have set the Create a New Database flag to Yes and have specified a new eG Database Name (see Figure 12) - then you can use either a new user account for creating that database, or an existing user account. However, if you want to use an existing database as the eG database - i.e., if you have set the Create a New Database flag to No and have specified an Existing database name (see Figure 13) - then you should use an existing user account alone for configuring that database. When using the SQL database on Azure therefore, use the user account you associated with that database when creating it on Azure.

    Note:

    When using an existing user account on a Microsoft SQL server, make sure that you use an account vested with DBOwner rights on the specified database.

  10. If Windows Authentication is enabled on the Microsoft SQL server - i.e., if the Windows Authentication flag is set to Yes - then the user should be a valid Windows domain user. Accordingly, provide a valid domain user's name against eG Database User Name, type the password of that user against Password, confirm the password by retyping it against Confirm Password, and specify the Domain Name to which that user belongs (see Figure 14).

    Figure 14 : Specifying the credentials of the special database user, when Windows Authentication is enabled

  11. On the other hand, if SQL Server Authentication is enabled on the Microsoft SQL Server - i.e., if the Windows Authentication flag is set to No - then you will not be required to indicate the domain to which the special database user belongs. In this case therefore, provide a valid user name against eG Database User Name, type the password of that user against Password, and confirm the password by retyping it against Confirm Password (see Figure 15).

    Figure 15 : Specifying the credentials of the special database user, when SQL Server Authentication is enabled

  12. When configuring a Microsoft Azure SQL database, since only SQL Server Authentication is supported by default, you do not have to provide the Domain name. You only need to specify the following:

    • Against eG Database User Name, specify the login name that you provided when creating the SQL database on Azure.
    • In the Password text box, enter the password that you provided for the login name at the time of creating the Azure SQL database
    • Confirm the password by retyping it in the Confirm Password text box.

    Note:

    • Make sure that the eG database user name you provide - whether it is that of a new user or an existing user - does not contain any special characters.

    • Ensure that the password provided for the special database user is a strong password. Strong passwords are defined by the following parameters:

      • Has at least 6 characters
      • Does not contain “Administrator” or “Admin”
      • Contains characters from three of the following categories:

        • Uppercase letters (A, B, C, and so on)
        • Lowercase letters (a, b, c, and so on)
        • Numbers (0, 1, 2, and so on)
        • Non-alphanumeric characters (#, &, ~, and so on)
        • Does not contain the corresponding username

        For instance, if the name of the special database user is egdb, then the password that you set for this user should be a strong password such as, db123$%#@.

        Note that without a ‘strong password’, the eG SuperManager installation will fail.

  13. Only a database administrator is authorized to create a new database on a Microsoft SQL server. Therefore, if you have chosen to configure a new database for the eG SuperManager in step 7 above , then make sure you configure the Database Administrator section in Figure 15 with the credentials of the database administrator. This way, you can make sure that setup has the necessary rights to create the database on the target Microsoft SQL server. For that, first indicate whether/not Windows Authentication is enabled for the database administrator. If it is, then set the Windows Authentication flag to Yes. On the other hand, if only SQL Server Authentication is enabled, then set the Windows Authentication flag to No.
  14. Next, ensure that the credentials of the database administrator are provided. If Windows Authentication is enabled - i.e., if the Windows Authentication flag in the Database Administrator section is set to Yes - then you will have to provide the name of a valid Windows domain user with database administrator privileges against Admin User Name, specify his/her password against Password, confirm the password by retyping it against Confirm Password, and also provide the Domain Name to which the database administrator belongs (see Figure 16).

    Figure 16 : Providing the credentials of a DBA with Windows Authentication enabled

  15. On the other hand, if SQL Server Authentication is enabled - i.e., if the Windows Authentication flag in the Database Administrator section is set to No - you will not be required to indicate the domain to which the database administrator belongs; in this case therefore, you only have to provide the Admin User Name and Admin Password, and confirm the password by retyping it against Confirm Password (see Figure 17).

    Figure 17 : Providing the credentials of a DBA without Windows Authentication enabled

    Note:

    Typically, when providing database administrator credentials, sa user name and password are used. If, due to security concerns, you decide not to use the sa user's credentials, then you can create a user with the following server roles: securityadmin, serveradmin, and public, and then provide that user’s credentials in the Database Administrator section depicted by Figure 17. Figure 18, Figure 19, and Figure 20 depict how to create a new user with the aforesaid privileges using the Microsoft SQL Server Management Studio.

    Figure 18 : Choosing to create a new login

    Figure 19 : Creating a new user

    Figure 20 : Granting the requisite privileges to the new user

    When creating a new DBA, make sure that the user name you provide for the new DBA user does not contain special characters. Also, ensure that either provide a strong password for the user. Strong passwords are defined by the following parameters:

    • Has at least 6 characters
    • Does not contain “Administrator” or “Admin”
    • Contains characters from three of the following categories:

      1. Uppercase letters (A, B, C, and so on)
      2. Lowercase letters (a, b, c, and so on)
      3. Numbers (0, 1, 2, and so on)
      4. Non-alphanumeric characters (#, &, ~, and so on)
      5. Does not contain the corresponding username

      For instance, if the name of the database administrator is egdb, then the password that you set for this user should be a strong password such as, db123$%#@. Note that without a ‘strong password’, the eG SuperManager installation will fail.  

      If you do not want to provide a strong password, then, make sure that the Enforce password policy option is disabled while creating the user profile in the Microsoft SQL Server Management Studio.

  16. You can check the veracity of your database server, database, database user, and DBA configurations by clicking the Validate button in Figure 15. If your specifications are valid, then a message to that effect will appear. If not, an error message will appear, prompting you to check the eGManager_Install log file in the drive that hosts the eG SuperManager, for more details. You can then make changes to your specifications based on the error message logged in the log file.
  17. Once validation is successful, proceed to create the database by clicking the Create Database button in Figure 15. This button will appear only if the Create a New Database flag is set to Yes and a new eG Database Name is provided. On the other hand, if you had chosen to use an existing database by setting the Create a New Database flag to No, then click the Configure Database button to configure that database as the eG database.
  18. Setup will then proceed to create/configure the database and database user account. In the process, if setup finds that the database name and/or database user name provided in Figure 15 already exist on the target Microsoft SQL server, then it will prompt you to confirm whether you want to use the same names or change them. Click the OK button in the message box to proceed with the same names. Click Cancel to return to Figure 15, so you can change the database and/or database user names.
  19. Once database configuration completes successfully, setup will allow you to configure certain basic manager settings, so that the eG SuperManager begins monitoring and alerting in no time! To know what these settings are and how to configure them, refer to Configuring the Basic Manager Settings.

Note:

By default, the eG SuperManager is configured for agent-based monitoring - i.e., when a server is auto-discovered and then managed, it is monitored in an agent-based manner. Administrators have an option to set agentless monitoring as the default for the eG SuperManager.

On Windows systems, the script <EG_INSTALL_DIR>\lib\set_manager_default can be used to set agentless monitoring as the default option for the eG SuperManager. The output of this script is shown below:

Do you want to set the eG Manager for agentless monitoring by default? y/n[n]:y
**************************************************************
Changes to the eG Manager default setting have been successfully made!
**************************************************************

 

Using Oracle Database

If you want to configure the eG database on an Oracle database server, then, click the Oracle tab page in the web page that appears soon after successful manager installation. Figure 21 will then appear.

Figure 21 : Configuring the eG database on an Oracle database server

To configure the eG database on Oracle, do the following using Figure 21:

  1. Enter the name/IP address of the Oracle database server you want to use in the Database Server Name/IP text box.
  2. Against Database Server Port, specify the port at which the Oracle database server listens. By default, this is 1521.
  3. Next, in the Instance (SID)/Server Name text box, specify the name of the Oracle instance the eG SuperManager should use. A Service Name is mandatory if a pluggable database is being used.
  4. The eG SuperManager requires a special Oracle database user account to store its measures. You can either create a new account for this purpose, or use an existing user account. If you want setup to automatically create a new user account on Oracle for the eG SuperManager to use, first set the Create a New User flag in Figure 21 to Yes. Then, specify the name of the new user account in the eG Database User Name text box, provide a Password for the new user, and confirm the password by retyping it in the Confirm Password text box.

    Note:

    If the user chooses not to have the user account created by the configuration process, the user account has to be created manually on the Oracle database server with connect, resource, and select_catalog privileges. To know how to create such a user, refer to the table below, which describes the complete syntax for user creation on different versions of Oracle:

    Version

    Syntax for User Creation

    Oracle 11G

    create user $username identified by $password default tablespace $tspace1 temporary tablespace $tspace2;

    Grant connect, resource to $username;

    Grant select_catalog_role to $username;

    For example:

    create user john identified by john123 default tablespace dtspace temporary tablespace ttspace;

    Grant connect, resource to john;

    Grant select_catalog_role to john;

    Oracle 12C (and above) - Normal Setup

    create user $username identified by $password default tablespace $tspace1 temporary tablespace $tspace2;

    Grant connect, resource to $username;

    Grant select_catalog_role to $username;

    alter user $username quota unlimited on $tspace1;

    For example:

    create user james identified by j@m3s default tablespace jdspace temporary tablespace jtspace;

    Grant connect, resource to james;

    Grant select_catalog_role to james;

    alter user james quota unlimited on jdspace;

    Oracle 12C (and above) - Multi-tenant Setup (PDB and CDB)

    alter session set container=$PDB_Name;

    create user $username identified by $password container=current default tablespace $tspace1 temporary tablespace $tspace2;

    Grant connect, resource to $username;

    Grant select_catalog_role to $username;

    alter user $username quota unlimited on $tspace1;

    For example:

    alter session set container=pdb1;

    create user mary identified by m1r2y container=current default tablespace mardspace temporary tablespace martspace;

    Grant connect, resource to mary;

    Grant select_catalog_role to mary;

    alter user mary quota unlimited on mardspace;

    Note:

    In a 12C Multi-tenant setup, the CDB cannot be used as the eG backend. This is why, in this case, you have to configure a PDB as the eG database.

    To know which PDB to use, you need to first take a look at the available PDBs. For that, log into a CDB and run the query below at the SQL prompt to get the list of PDBs:

    select pdb_name from dba_pdbs where pdb_name not like '%$%';

  5. Once the user account is created, you can then use step 5 below to configure an existing database for the eG SuperManager's use.

  6. If you want to use an existing database user account for the eG SuperManager, first set the Create a New User flag to No (see Figure 22). Then, specify the name of the existing user in the eG Database User Name text box, provide the valid Password of that user, and confirm the password by retyping it in the Confirm Password text box.

    Figure 22 : Configuring an existing database user account for the eG SuperManager

    Note:

    If you set an existing database user as the eG database user at step 5, then before configuring the eG SuperManager to use Oracle as its backend, make sure that connect, select_catalog, and resource privileges are granted to the existing user.

  7. To create a new user account for an Oracle database server, a data tablespace and a temporary tablespace have to be associated with the new user account (as shown in Figure 21). For this purpose, specify the same in the Default Tablespace and Temporary Tablespace text boxes, respectively. On the other hand, if you will be using an existing user account, then make sure that the Default Tablespace and Temporary Tablespace text boxes are configured with the default and temporary tablespace that is already mapped to the specified database user account. The default values for the data and temporary tablespaces values are users and temp, respectively.

    Note:

    • We recommend that when you install the eG SuperManager with an Oracle database backend, the following tablespaces (with the parameters indicated) are specifically created for eG:

      create tablespace egurkhadata01

      datafile ‘C:\Oracle\ORADATA\egurkha\eGurkhaData01.dbf’ size 10240M

      autoextend off extent management local autoallocate;

      create temporary tablespace egurkhatemp01

      tempfile ‘C:\Oracle\ORADATA\egurkha\eGurkhaTemp01.dbf’ size 512M

      autoextend off extent management local uniform;

    • Create rollback tablespaces and rollback segments as needed.
    • The usage of an Oracle backend for the eG SuperManager also necessitates the resetting of the following Oracle initialization parameters.
    • The processes parameter should be set to a minimum of 100
    • The open_cursors parameter should be set to a minimum of 200.

    These parameters might have to be tuned further based on an increase in server load.

  8. Database administrator privileges are required for creating a new database user. Therefore, if you have chosen to create a new database user - i.e., if the Create a New User flag is set to Yes - then, you will have to use the Database Administrator section of Figure 21 to configure the credentials of the database administrator. For that, type the name of database administrator against Admin Name, specify the password of the database administrator against Password, and confirm the password by retyping it against Confirm Password. On the other hand, if you want to use an existing user account for the eG SuperManager, then you will not have to provide database administrator credentials. In this case therefore, the Database Administrator section will not appear (see Figure 22).
  9. To check the veracity of your configuration, click the Validate button in Figure 22. If your specifications are valid, then a message to that effect will appear. If not, an error message will appear, prompting you to check the eGManager_Install log file in the drive that hosts the eG SuperManager, for more details. You can then make changes to your specifications based on the error message logged in the log file.
  10. Once validation is successful, proceed to create the new database user by clicking the Create Database button in Figure 21. This button will appear only if the Create a New User flag is set to Yes and a new eG Database User Name is provided. On the other hand, if you had chosen to use an existing database user account by setting the Create a New User flag to No, then click the Configure Database button (see Figure 22) to configure the specified database user account for use by the eG SuperManager.
  11. Setup will then proceed to create/configure the database user account. In the process, if setup finds that the database user name provided in Figure 21 or Figure 22 already exists, then it will prompt you to confirm whether you want to use the same user name or change it. Click the OK button in the message box to proceed with the same user name. Click Cancel to return to Figure 21, so you can change the user name.
  12. Once database configuration completes successfully, setup will allow you to configure certain basic manager settings, so that the eG SuperManager begins monitoring and alerting in no time! To know what these settings are and how to configure them, refer to Configuring Basic Manager Settings.

Configuring the Basic Manager Settings

Once the eG database is successfully configured, setup automatically opens the Manager Configuration page (seeFigure 23). This page enables you to indicate what type of environment your eG SuperManager deployment needs to monitor. Depending upon the type of environment, you can even turn on/off certain key capabilities of the eG SuperManager using this page. This way, you can custom-define how your manager performs monitoring and alerting, enforce organizational security policies, and enable the auditing of supermanager operations, without even logging into the eG management console!

Figure 23 : Configuring the basic manager settings

Using Figure 23, do the following:

  1. First, choose Our organization (Enterprise) as the deployment model for the eG SuperManager.

    • Enterprise:This model is ideal if your eG SuperManager will be monitoring only your organization's IT infrastructure. In this case, eG's agent-based/agentless monitors will be deployed on and will pull metrics from the components in your infrastructure only. The employees of your organization will be the primary stakeholders and consumers of the performance data so collected.

      Such a model is typically, administrator-driven. In other words, an administrator will be responsible for performing all administrative activities related to the eG SuperManager - this includes, installing agents, managing the components, configuring thresholds, tests and alerting, managing users, building segments and services, defining zones, and more. The other stakeholders - i.e., the employees - will usually be vested with only monitoring rights, or in some special cases, very limited administrative rights, as the administrator deems fit.

  2. Next, specify the Mail ID for admin user. The admin user is one of the default users of the eG Enterprise system. This user is automatically created by the eG Enterprise system, soon after an eG SuperManager is deployed. This user has unrestricted administrative and monitoring powers. If you login to the eG management console as user admin (with default password admin), you can configure your environment for monitoring, and also view performance and problem statistics pertaining to your environment. Typically, an administrator's mail ID is assigned to the default admin user. This way, the admin user can receive email notifications whenever the eG SuperManager detects issues in any core component of the eG architecture - say, the eG database - or in any component of the monitored IT infrastructure. This enables the admin user to keep tabs on the health of the eG Enterprise system and that of the monitored environment.

  3. Using Figure 23, you can also enable/disable audit logging for your eG SuperManager. An audit log can be best described as a simple log of changes, typically used for tracking temporal information. The eG SuperManager can be configured to create and maintain audit logs in the eG database, so that all key configuration changes to the eG Enterprise system, which have been effected via the eG user interface, are tracked.

    The eG audit logs reveal critical change details such as what has changed, who did the change, and when the change occurred, so that administrators are able to quickly and accurately identify unauthorized accesses/modifications to the eG Enterprise system.

    By default, audit logging is disabled. To enable it, set the Enable auditing? flag to Yes (see Figure 23).

  4. Users with administrative rights to the eG Enterprise system can allow other users access to the eG management console, by configuring a dedicated profile in eG for each user. Using the profile, the administrator assigns login credentials - i.e., login user name and password - to a user. At any given point in time, the administrator or the corresponding user can change his/her login password.

    In some high-security environments, password policies are often defined, which dictate how long and how strong a login password should be. If, for security reasons, you want to define and enforce a password policy for the login passwords of eG users, you can do so using the options provided by Figure 23.

    For instance, in the Minimum password length text box of Figure 23, specify the minimum number of characters a login password should contain. When creating/modifying the password of an eG user, you need to make sure that at least this many characters are present in the password;if not, eG will automatically reject the password and insist that you specify another one.

    You can also define the password strength, by selecting the checkboxes you need under Password complexity. For example, if you want the login password of an eG user to compulsorily contain some lowercase characters and numbers, then select the Lowercase alphabets and Numbers checkboxes in Figure 23.

    Note:

    Password policies set here apply only to local users of eG Enterprise, and not domain and SAML users.

  5. By default, the Mail Server Settings are not supported for the eG SuperManager. You can skip this configuration and click the Next button to proceed further.

    • If you have configured an Oracle database backend for the eG SuperManager, then Figure 24 will appear.

      Figure 24 : Confirming whether/not the Oracle DB license enables support for Partitioning feature

      'Partitioning' is a licensed capability, which is available only for Oracle 12c (and above). If your Oracle database server license enables partitioning support, then you can have the eG SuperManager store performance and configuration metrics in partitions on the eG database. If you have configured Oracle database server 12c (or above) as the eG backend, and if your Oracle DB license enables the 'Partitioning' feature, then click Yes in Figure 24 to confirm support. If you confirm support, then setup will automatically create a partition and store metrics in it. On the other hand, if the SuperManager is not configured to use an Oracle database server 12c (or above) as its backend, or if your DB license does not support the 'Partitioning' feature, then click the No button in Figure 24. In this case, data insertions on the Oracle backend will be done based on available space – i.e., data will be inserted into any space available anywhere in a table.

    • Figure 25 will then appear, displaying the URL using which the eG SuperManager should be accessed. The default URL will be of the format http://<eGSuperManagerIPorHostName>:<eGSuperManagerPort>or https://<eGSuperManagerIPorHostName>:<eGSuperManagerPort>, depending upon whether/not the SuperManager is SSL-enabled. If your eG SuperManager is behind the NAT, then you may want to replace the default URL with the externally accessible URL. Then, click the Update button.

      Figure 25 : The URL that will be used for accessing the eG SuperManager

    • Figure 26 will then appear informing you of the successful installation of the eG SuperManager. If you have a valid eG license, then set the Do you have a valid license? flag to Yes. Then, specify the full path to the license file against Choose a license file text box. You can even use the Browse button to locate the license file. Finally, click the Upload License button.

      Figure 26 : Uploading the license file

      On the other hand, if you do not have a valid license file, then set the Do you have a valid license? flag to No (see Figure 27). In which case, you can write to support@eginnovations.com requesting for a valid eG license. Once you receive the license file, make sure you copy it to the <EG_INSTALL_DIR>\bin folder. Then, start the manager.

      Figure 27 : Requesting a valid license