Free 30 Day Trial
Find the root-cause of your cloud, hybrid-cloud
or on-prem performance issues
|
||
|
Configuring Manager Settings
To configure manager settings, select the Manager option from the Settings tile. Figure 1 will then appear with a manager settings panel to its left. Clicking on any option in the manager settings panel will invoke a list of parameters in the right panel that you can configure.
Clicking on the General Settings option will open a general SETTINGS page in the right panel (see Figure 1).
Using the general SETTINGS page, you can configure the following settings:
Next, indicate how user logins to the eG management console are to be authenticated. By default, the login credentials of each eG Enterprise user are stored in the eG database. Every time a user attempts to login to the eG management console, their credentials are validated by the eG database. This is why, eG Enterprise is set as the default Authentication provider for login. You can override this default setting by choosing one of the other options, which are as follows:
Clicking on the Manager Notification option in the manager settings panel will invoke a manager notification page (see Figure 2) in the right panel.
Using the Manager Notification page, you can configure the type of alerts you want displayed in the manager notification window that pops out as soon as you login to the eG administrative interface or when you click the Manager Notification icon () in the Admin tool bar available at the right, top corner of the Admin interface.
If you click on the Test Configuration option in the manager settings panel, a test configuration page will appear in the right panel (see Figure 3).
Using the test configuration page, you can define the following:
Finally, click the Update button.
Note:
If the Is host editable? flag is set to Yes, then the host parameter for all tests – both internal and external – will become editable. However, this capability, when enabled, is most useful when configuring external tests, as it allows administrators the flexibility to run the test on a remote host and collect metrics.
Clicking on the Threshold Configuration option in Figure 3 will invoke a threshold configuration page in the right panel (see Figure 4).
eG Enterprise is capable of automatically computing the thresholds of performance using historical data. This auto-thresholding capability eliminates the need for determining the norms of performance manually in dynamic environments where measure values vary with time. eG Enterprise uses tried and tested statistical quality control techniques to analyze past values of the metrics, and automatically sets the upper and lower bounds for each of the metrics based on this analysis. With the help of the threshold configuration page, you can configure the 'past values' to be considered for automatic threshold computations.
By default, to perform the threshold computation, the values reported by a measure during each day of the last 14 days is used. This is why, the Automatic threshold computation policy is set to Daily, and the Lookback period to compute automatic thresholds is set to 14, by default. According to these default settings, the threshold for a measure for 8 AM to 9 AM on August 18, will be automatically computed using the actual values reported by that measure during 8 AM to 9 AM on each of the 14 days prior to August 18.
In some environments, mandatory operations - for example, data backup operations or virus scanning operations - may occur on one/more servers once a week. This in turn may increase the activity levels on those servers during that time window. In some other environments, such routine operations may be scheduled to take place at a specific time every month. If threshold computations in such environments are based on Daily data collections, then the resulting thresholds may not reflect the weekly/monthly deviations in usage, thus causing false alerts. In such a case, you can set the Automatic threshold computation policy to Weekly or Monthly (as the case may be), and specify the number of past weeks/months to be considered for computing thresholds in the Lookback period to compute automatic thresholds. For instance, say that the Automatic threshold computation policy is set to Weekly and the Lookback period is configured as 2. In such a case, to compute thresholds for 8 AM to 9 AM on August 18, the actual measure values reported on the same day and time in the last 2 weeks will be considered - this will be 8 AM - 9 AM on August 11 and 8 AM - 9 AM on August 4. Similarly, assume that the computation policy is set to Monthly and the Lookback period is set to 2. In such a case, to compute thresholds for 8 AM to 9 AM on August 18, the actual measure values reported on the same date and time but in the last 2 months will be considered - this will be 8 AM - 9 AM on July 18 and 8 AM - 9 AM on June 18.
Note:
If the Monthly computation policy is chosen and the date for which thresholds are to be computed is not available in the previous month - say, thresholds are to be computed for July 31, but the previous month of June has only 30 days - then, the data collected during the last day of the previous month will be used for threshold computation. In the case of our example therefore, the data collected on June 30 will be used.
Click on the Command Execution option in the manager settings panel to view the command execution section in the right panel (see Figure 5).
Figure 5 : Configuring command execution on alert generation
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. The eG manager will invoke this custom script with a fixed set of parameters, namely - ComponentType, ComponentName, LayerName, Desc, StartTime, Priority
Note:
This capability is also supported in a redundant eG manager configuration. In case of the redundant manager configuration, if the primary manager is up and running, it will perform script execution. If the primary manager is down for any reason, the secondary manager will perform script execution.
Using the command execution page, you can configure the details of these scripts as follows:
To execute the script for every alert that is generated, set the Separate execution flag to Yes. This means that when the script executes, the details of only a single alert will be included in the script output. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to Yes.
31/08/2011 11:06:51 USER admin COMMAND echo PARAMS -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 31, 2011 11:05:18" -Priority "Critical"
31/08/2011 11:06:51 INFO -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 31, 2011 11:05:18" -Priority "Critical"
As you can see, for a single alert, two lines have been logged in the mailexec.log file.
The first line is the script invocation. It displays the user who will be receiving the alarm intimation, the syntax of the command that is being executed by the script, and the params - i.e., the input parameters/arguments - that the command takes while executing. In the sample provided, echo is the command executed by the script. Therefore, the params tag in our extract is followed by the input parameters required by the echo command. As you can see, every parameter of the echo command consists of two components: the parameter name and its value at runtime. While the param name begins with a - (hyphen), its runtime value is enclosed within "double quotes". Take for instance the parameter, -ComponentType "Host system". Here, -ComponentType is the parameter, and the "Host system" is its value.
The second line logs the output of the command - in the case of our example, this will be the output of the echo command. The command output typically begins with the tag info, and will be followed by the details of the alert being sent. Like its input, the output of the echo command too is a combination of the parameter name and its value at runtime. While the parameter name indicates what type of information is being sent, the actual information itself is contained within "double quotes" and forms the parameter value. The parameters included in the output of the echo command have been discussed in the table below:
Parameter | Description |
---|---|
ComponentType |
The problem component type |
ComponentName |
The name of the problem component |
LayerName |
The name of the problem layer |
Desc |
A brief description of the problem; typically, for the echo command, a problem description includes the following:
|
StartTime |
The problem date/time |
Priority |
The problem severity |
If the Separate execution flag is set to No on the other hand, the script will be executed only once for all alerts raised simultaneously. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to No.
30/08/2011 12:13:27 USER admin COMMAND echo PARAMS -ComponentType "Microsoft SQL" -ComponentName "sql100:1433" -LayerName "MS SQL Service" -Desc "-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77" -StartTime "Aug 30, 2011 12:10:26" -Priority "Critical" # -ComponentType "Windows" -ComponentName "win77" -LayerName "Windows Service" -Desc "-|WindowsServices|Availability|Service not up|eGAgentMon|win77" -StartTime "Aug 30, 2011 12:10:41" -Priority "Critical" # -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 30, 2011 12:11:18" -Priority "Critical" # -ComponentType "Host system" -ComponentName "vdi136" -LayerName "Network" -Desc "-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67" -StartTime "Aug 30, 2011 12:11:23" -Priority "Critical"
30/08/2011 12:13:27 INFO -ComponentType "Microsoft SQL" -ComponentName "sql100:1433" -LayerName "MS SQL Service" -Desc "-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77" -StartTime "Aug 30, 2011 12:10:26" -Priority "Critical" # -ComponentType "Windows" -ComponentName "win77" -LayerName "Windows Service" -Desc "-|WindowsServices|Availability|Service not up|eGAgentMon|win77" -StartTime "Aug 30, 2011 12:10:41" -Priority "Critical" # -ComponentType "Host system" -ComponentName "esx150" -LayerName "Operating System" -Desc "-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67" -StartTime "Aug 30, 2011 12:11:18" -Priority "Critical" # -ComponentType "Host system" -ComponentName "vdi136" -LayerName "Network" -Desc "-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67" -StartTime "Aug 30, 2011 12:11:23" -Priority "Critical"
In this case again, only two lines will be logged in the mailexec.log. The first line will display the user name, command syntax, and the command params (with their corresponding values). Since multiple alerts will be clubbed in the command output, the first line will include the params for all alerts. '#' (hash) will be used to separate the parameter-value pairs of one alert from the other.
The second line, which begins with the tag info, will display the combined output of all email alerts generated simultaneously - each alert in the output will also be separated by the hash (#) symbol.
Note:
The Separate execution flag setting will take effect only if a user is configured to receive Newalarm intimations alone - i.e., if the Type of notification is set to New for a user in the add user page. For users who are configured to receive the Complete Listof alarms, details of multiple alarms will always be clubbed in a single script execution, regardless of this flag setting.
Next, indicate the type of scripts that eG Enterprise should execute by running the configured command. The default list includes .exe, .com. .bat, .wav, .wsf, .vbs, .prn, .sh, and .perl. You can override the default list by appending new script types to it or removing existing ones. For instance, if you want eG Enterprise to support powershell scripts as well, then your specification should be:
.exe,.com.,.bat,.wav,.wsf,.vbs,.prn,.sh,.perl,.ps1
eG Enterprise is capable of integrating with trouble ticketing systems such as Autotask, ServiceNow, etc.. Vide this integration, eG alerts will be automatically routed to the third-party TT system, resulting in the automatic creation, modification, or closure of trouble tickets. Likewise, eG Enterprise can also readily integrate with chat/collaboration systems such as HipChat, Slack etc. This results in eG alerts being automatically circulated to all users connected to a configured chat room/channel. For instance, if help desk personnel are part of a single chat room on HipChat, you can have eG Enterprise integrate with that chat room. This way, help desk personnel are instantly notified of problem conditions, and can effectively work together for a speedy resolution.
To integrate with each of these tools, eG Enterprise employs a variety of mechanisms from a proprietary CLI to vendor-provided mail interfaces, web hooks, and even REST API. To enable integration with a specific tool, click the ITSM/Collaboration Integration node in the tree-structure in the left panel.
Figure 6 : Integrating with TT systems / collaboration tools
The right panel then displays the TT systems / collaboration tools that eG can integrate with, and a few generic technologies that you can use for integrating with such third-party systems. To integrate with a tool or to use a particular technology for integrating, click on the corresponding option in the right panel. For technology- or tool-specific details, refer to the Integrating eG Enterprise with Trouble Ticketing Systems
Note:
This section will appear only if the Trouble Ticket Integration capability is enabled by the eG license.
Clicking on the Log Settings option in the left panel of Figure 6 will open the log settings page in the right panel (see Figure 7).
In the LOG SETTINGS section of this page, the following settings can be defined:
Clicking on the Auditing option reveals an auditing page in the right panel (see Figure 8).
Define the following in the auditing page:
For configuring advanced manager settings, click on the Advanced Settings option in manager settings panel. This will result in the display of the advanced settings page (see Figure 9).
You can configure the following in the advanced settings page:
Typically, whenever a user manually changes a configuration file (.ini file) of the eG manager, he/she would have to restart the eG manager for the changes to take effect. To make sure that changes to configuration files are effected even without a manager restart, then, soon after you make modifications to one/more configuration files, set the Update Manual Config Files flag in Figure 9 to Yes, and click the Update button. This will automatically update the eG manager with the configuration changes. Once the updation is complete, the status of the Update Manual Config Files will automatically switch to No.
Note:
The Update Manual Config Files flag cannot be used to update the eG manager with changes to language files. Gor changes to language files to take effect, you will always have to restart the eG manager.
The Metric Aggregation capability of the eG Enterprise allows administrators to group one or more components of a particular type and monitor that group as a single logical entity termed as an aggregate component. This aggregate component provides a collective view of the performance of all the components that are grouped together. Aggregates can be used to represent all the components of a specific type, or all components of a type in a geography or in a business unit.
Different organizations may want to view performance in different ways - some by type, some by geographies, and some by business unit. To provide administrators with maximum flexibility, and help them to configure any number of aggregate components without being constrained by the licensing of the eG monitors, eG Enterprise performs metric aggregation using external agents. By default, the Agents for aggregate components flag is set to External indicating that the default external agent bundled with the eG Enterprise is capable of monitoring an aggregate component. This helps the administrators to add any number of aggregate components depending on the views of their infrastructure they desire without needing additional licenses. In case, if you wish to monitor the aggregate components using a remote agent, then set this flag to Remote.
Note:
If you are already monitoring aggregate components using an external agent and now, if you wish to monitor the same aggregate components using a remote agent, then, you are required to purchase the premium licenses accordingly. If enough licenses are not available, then a message as shown in Figure 10 will be displayed and the external agent will continue to monitor the aggregate components.
Figure 10 : A message displaying that there are not enough premium licenses available
To enable administrators to easily and effectively study the historical trends in performance and accurately assess future capacity requirements, the eG Reporter offers a dedicated Capacity Planning Reports category. By default, eG Reporter does not allow users to generate Capacity Planning reports. Clicking on the Capacity Planning option in the manager settings panel will invoke the capacity planning page in the right panel (see Figure 11).
To enable the generation of this category of reports, do the following in the capacity planning page:
To configure the automatic generation of a virtual topology, click the Virtual Topology option in the manager settings panel of Figure 11. The right panel will then change to reveal the virtual topology page (see Figure 12).
eG Enterprise is capable of automatically determining the mapping of applications to virtual hosts. This is why, the Virtual topology mapping flag in Figure 12 is set to Auto by default. This default setting ensures that eG Enterprise intelligently discovers which managed applications are actually executing on the VMs of a virtual host and automatically maps these applications to that virtual host in the Virtual Topology preview in the eG monitoring console. This mapping of applications to virtual hosts is important for root-cause diagnosis - for example, a problem with the virtual host (e.g., excessive disk slowdowns) can impact the performance of all the applications running on that host’s virtual machines.
If you set the Virtual topology mapping flag to Manual, then, when adding applications for monitoring in an environment where one/more hypervisors are already monitored, you will have to explicitly indicate whether/not the application being added is executing on a virtual host. If so, you will have to additionally pick the managed virtual host with which that application is associated.
Use the Manager Model option to change the deployment model of the eG manager. At the time of manager installation, you are required to indicate the deployment model of the eG manager. If, post manager installation, you want to switch to a model different from the one chosen earlier, you can do so using the Manager Model option. Clicking on this option in the left panel, provides the following options in the right panel:
Enterprise: This model is ideal if your eG manager 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 manager - 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.
If you want to deploy the eG manager for Enterprise, then select the Our Organization (Enterprise) option in Figure 13.
SaaS: This model is ideal if you are a Managed Service Provider (MSP), providing infrastructure hosting and management services to multiple customers. Monitoring is quiet often a cloud-based service that an MSP offers to each of their customers. If you are an MSP, you will want the eG manager to not just monitor your infrastructure, but also that of your customers. This means that an eG manager centrally deployed in the MSP infrastructure will be managing agents deployed in the customer infrastructure as well.
The SaaS model also helps where a single eG manager manages agents used by different departments (eg., Development, Testing, Support etc.) / support groups (Europe Support, EMEA Support, USA Support etc.) / IT domains (Network administration, Database administration, Windows administration etc.).
With the SaaS model, eG Enterprise fully supports mult-tenancy. Unlike the Enterprise model, in SaaS, the administrator will not be the sole custodian of administrative rights. Instead, these rights will be delegated to the individual tenants - say, MSP customers, department heads/workers, support personnel who are part of different support groups, or IT domain experts. The tenants are thus empowered to deploy the agents they want, manage the components they wish to monitor, and customize accesses, monitoring, and alerting based on the requirements of their infrastructure. The central administrator will continue to hold unrestricted administrative rights, which will enable him/her to manage monitoring licenses of the tenants, oversee performance and problems across tenant infrastructures, and even override a tenant's monitoring configuration if required.
If you want to deploy the eG manager for SaaS, then select the Our Organization and our customers (SaaS) option in Figure 13.
In a SaaS deployment, tenants are by default allowed to self-register with the SaaS manager. This is why, if the Our Organization and our customers (SaaS) option is chosen as the deployment model, an Allow users to self-register flag will appear, which will be set to Yes by default. In some SaaS environments, for security reasons, the administrator may prefer to completely control tenant registrations, instead of allowing tenants this flexibility. In such a case, the administrator can set the Allow users to self-register flag to No. If this is done, then only an administrator will be able to register a tenant by creating a profile in the eG Enterprise system for that tenant.
In order to protect the eG Enterprise system from misuse by malicious users, the eG manager automatically locks out a user if he/she consistently fails to login to the eG management console. You can set when the lockout should occur, how long a user should remain locked out, and can even disable the locking capability, using the Account Lockout option in the manager settings panel of Figure 12. Selecting this option invokes the account lockout page in the right panel, as depicted by Figure 14. To know how set an account lockout policy, refer to the Account Lockout topic.
You can also define a policy for the password you set for local (not domain) users to the eG management console. For this, select the Password Policy option from the manager settings panel in Figure 14. This will invoke the password policy page in the right panel (see Figure 15). To know how to define a password policy using this page, refer to the Password Policy topic.
One of the growing concerns in the web world is security! New security threats/vulnerabilities keep cropping up each day, putting web applications and the confidential/sensitive data they handle at risk.
To enable application developers/architects to keep track of such threats/vulnerabilities, a non-profit organization called OWASP - Open Web Application Security Project - periodically publishes a Top-10 report. This is an 'awareness' report, which outlines the most critical security risks for web applications. The risks highlighted in the latest Top-10 report include Injection, Cross-site scripting (XSS), Broken Authentication, Security misconfiguration, Insufficient Logging etc.
Since eG manager is a web application, the security threats that are featured in OWASP's report apply to the eG manager as well , and can greatly impact its stability and reliability. This is why, the eG manager is pre-hardened against many of the security vulnerabilities listed in OWASP's report!
The security filters of the eG manager are turned on by default, so that, as soon as the eG manager is installed and configured, it is automatically protected against the following vulnerabilities:
Vulnerability |
Description |
SQL Injection |
An injection attack that executes malicious SQL statements to control a database server behind a web application |
Cross-Site Scripting (XSS) |
A client-side code injection attack that executes malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or web application. |
Cross-Site Request Forgery (CSRF) |
An attack against authenticated web applications using cookies where the attacker is able to trick the victim into making a request that the victim did not intend to make. |
Clickjacking |
An attack that tricks a user into clicking a webpage element which is invisible or disguised as another element. |
TCP Time Stamp Vulnerabilities |
The TCP timestamp response can be used to approximate the remote host's uptime, potentially causing attacks. |
Hacking of Browser Cookies |
Many web applications have cookie related vulnerabilities that lead to user impersonation, remote cookie tampering, XSS and more |
If you want to disable these security filters, then first click the Security Filters option in the Manager Settings panel . Then, when the Enable Security Filters flag comes up in the right panel, set the flag to No. Finally, click the Update button.
eG Enterprise supports two-factor authentication - a.k.a two-step verification - for validating user logons to the eG management console. This requires the user to validate with a unique code in addition to user name and password.
Using two-step verification, eG Enterprise:
Boosts user productivity and instills user confidence in the eG Enterprise system, by dispelling their fears of data breach
To enable support for two-step verification, click the 2-Step Verification option in the MANAGER SETTINGS panel. A 2-Step Verification section will then appear in the right panel (see Figure 17). To know how to use Figure 17 to enable 2FA support, refer to the Two-Step Verification topic.
By default, any user with administrative rights to the eG Enterprise system can login to the eG admin interface and make configuration changes, regardless of where he/she is coming from.
High security environments may consider this a vulnerability, as any user on the internet who can hack the login credentials of an administrative user, can gain access to the eG admin interface and make unauthorized changes to the eG Enterprise system! To protect admin user accesses from such security risks, eG Enterprise allows strict administration policies to be configured and enforced.
Using an administration policy, you can ensure that admin user access is allowed only for those users who connect to the eG management console from 'known' / 'reliable' / 'safe' locations. These 'secure locations' are indicated by an IP address, a range of IP addresses, or IP address patterns.
Where an administration policy is set, eG Enterprise allows a user to login to the eG admin interface only if:
The IP address from which the user is connecting belongs to the list of IP addresses configured under an administration policy.
To configure an administration policy, first click the Administration Policy option in the MANAGER SETTINGS panel. An Administration Policy section will appear in the right panel (seeFigure 18). To know how to configure an administration policy using Figure 18, refer to Administration Policy topic.
If you want, you can have eG Enterprise automatically delete the infrastructure elements (eg., components, services, zones etc.) associated with an organizational unit as soon as that organizational unit is deleted. This capability is most useful in a SaaS deployment of the eG manager. In a SaaS deployment, tenants often self-register with the eG Enterprise system. Such tenants are automatically granted the privileges of an 'organizational unit' and are allowed to choose which infrastructure elements they want monitored. Because tenants service their own monitoring needs, an administrator may not know what elements were managed by which tenant.
Later, if a tenant chooses not to use the monitoring service any longer, the administrator may delete the organizational unit that corresponds to that tenant from the eG Enterprise system. Doing so however, does not automatically deprovision the removed tenant's monitored environment from the eG Enterprise system. This means that eG Enterprise will continue to monitor the environment of a deleted tenant, until such time the administrator manually identifies and removes the managed elements from the eG Enterprise system. Since administrators often have little knowledge of a tenant's monitoring scope, this exercise could take hours! In the meantime, eG agents will be unnecessarily monitoring an environment that does not exist! To put monitoring resources (eg., agents, licenses) to better use and to reduce administrator workload, you can configure eG Enterprise to automatically delete a tenant/organizational unit's environment as soon as that tenant/organizational unit is deleted.
Additionally, you can also instruct eG Enterprise to auto-delete expired user accounts. This helps you to declutter and focus on only those user accounts that are actively used.
To achieve all of the above, first click the Deleted User Accounts option in the MANAGER SETTINGS panel. The right panel will then change as depicted by Figure 19.
Figure 19 : Configuring the automatic deletion of elements associated with an organized unit and expired user accounts
In Figure 19, specify the following:
To enable an eG manager to communicate with an eG SuperManager,
the details of the eG manager should be configured in the eG SuperManager and
the details of the eG SuperManager should be configured in every manager reporting to it.
Figure 20 : Enabling automatic registration of eG SuperManager in eG manager
To simplify the registration of the eG SuperManager, you can use the SUPERMANAGER page (see Figure 20) that appears when you click the SuperManager Settings option in the MANAGER SETTINGS panel. Setting the Allow auto registration from eG SuperManager flag to Yes will automatically enable the eG SuperManager to register with each of the eG managers reporting to it. Once the eG SuperManager automatically registers with the eG manager, the details of the eG SuperManager will be automatically populated in the SUPERMANAGER SETTINGS page of the eG manager. By default, this flag is set to No.