High Availability for Enterprise Reporter 2.0
Following are some considerations for High Availability of Enterprise Reporter (ER) 2.0. While ER 2.0
currently does not have High Availability built into the product, the following suggestions go a long way
to ensuring High Availability where needed. In this document, we will look at certain High Availability
areas and how to configure ER to cover those areas.
What is High Availability?
High Availability can mean a number of things, but basically, for the purpose of this document, it is what
can be done to reduce of the loss of data and what can be done to continue to access this data.
We will look at areas, including, but not limited to, the following:





How does the product handle situations when one of its components (SQL Server databases,
server, node, or agent) becomes unavailable?
What can be done for contingency planning to minimize the loss of data and unavailability of
the service provided by the product?
What about Access Explorer managed host agents? If they go down, can they recover and
catch up on changes to permissions that were made during their unavailability?
What if the ER server goes down? Do all discoveries stop working?
Can several installations of ER have the same AM agents or nodes on the same computers?
Basic Features of Enterprise Reporter for High Availability
As a standard procedure, it is recommended that multiple nodes be deployed for each Cluster created
so that if one node goes down, the others can take over. This also load balances the work of the
discoveries. Nodes can be deployed to virtually any Windows operating system. See the Quick Start
Guide or Installation and Deployment Guide for a list of operating systems supported.
It is also recommend that the databases be installed into a clustered SQL server system for high
availability of the collected data. This type of configuration is extremely useful for keeping the ER
databases available for use. If one component of the cluster goes down, the cluster is switched to the
other cluster component and the database is available for use. The switch can be considered rapid and
there is no loss as the ER databases have already been replicated to the secondary component each
time data has been written to the primary.
Backup and Restore of Enterprise Reporter
A backup strategy is highly recommended for Enterprise Reporter (ER) as a common practice for High
Availability (AH) in your organization. Without a Backup/Recovery plan for ER, data that has been
collected on your environment, possibly over a considerable length of time, will be lost in the event of
an ER database failure.
With a good backup and recovery setup as part of your normal Disaster Recovery planning, ER will
continue to provide the valuable information your organization needs. A specific paper concerning
disaster recovery of ER has been written and published on the ER community page. It is recommended
that you obtain this document and follow the procedures outlined therein.
Behavior of Enterprise Reporter on Failure of Specific Components
How does the product handle situations when one of its components (SQL Server databases, server,
node, or agent) becomes unavailable?
As mentioned, Enterprise Reporter (ER) uses two SQL Server databases. One database, named
dbReporter, is used by the Discovery Manager and the second database, named
dbReporter_AccessExplorer, is used by Access Explorer. If these databases are not available because the
SQL Server fails, ER no longer functions as all necessary data is kept in the databases. If the computer on
which ER is installed should fail, again ER is no longer available for collecting data or generating reports.
If a Node should fail, discoveries will not be processed. If an Access Explorer agent should fail, data
through the Explorer tab in the Report Manager will not be available for the computer on which the
agent is installed.
High Availability Solutions to Component Failure in Enterprise Reporter
Following are suggestions to provide High Availability (HA) for Enterprise Reporter (ER) and the data
collected for reports. These suggestions have been tested in a lab environment and have demonstrated
real solutions to HA problems.
Databases should be backed up as a matter of routine. This will protect against the loss of data. Placing
the database on a SQL Server Cluster is highly recommended for HA because of the obvious advantages
of the cluster.
High Availability for Enterprise Reporter Clusters and Nodes
As mentioned, Nodes in Enterprise Reporter (HA) do all of the work for discoveries. Nodes are assigned
to Clusters as they are created. Discoveries are assigned to Clusters when they are created. If the nodes
assigned should fail, the Cluster has failed, and any discoveries associated will not run. At this time, ER
2.0 does not allow you to change a discovery to another Cluster. You need to delete the discovery and
create a new one.
Following are suggestions to provide High Availability (HA) for ER clusters and nodes. These suggestions
have been tested in a lab environment and have been demonstrated as a real solution for HA problems.
More than one Cluster can be created in ER. A second cluster can be given nodes installed on
computers that are different than main cluster. When a discovery is created, a replica of that discovery
can also be create and assigned to the second cluster. This second discovery does not need to be given
a schedule and sits as a dormant discovery until the first, or main, cluster fails because the nodes are
down or off line.
While it has been tested that discoveries on both the first and second clusters can, without issues, run at
the same time while collecting data and placing it into the database, it is not recommended that you do
this. Wait until the nodes of the first cluster are no longer working before starting the discoveries on the
second cluster.
Access Explorer Agents
Access Explorer agents are installed onto a computer/server through Managed Computers in
Configuration Manager. This agent is very robust, and there is very little that can cause the agent to
have problems. The agent is installed as a service and communicates with the ER server through port
18530. Most of the communication is one-way. The agent gathers the permissions for a specific Active
Directory user of files or folders and reports them back to ER.
The agent also communicates with the ER server approximately every four (4) minutes. This heart beat
is used to confirm that the communication between the agent and the server is still active. If the heart
beat is not successful, the agent will try to re-establish communications through a number of processes.
If, for example, a system which has an agent installed is rebooted, the system will be reported as not
configured; however, within 4 minutes of the agent’s service restarting, the computer will indicate that
data is available. If an agent does not report that data is available after 15 minutes, the agent should be
removed and reinstalled.
The Managed Computers’ agents are used in the Explorer tab in Report Manager for live permission
information for a specific user account. The agent does not suffer any loss of data when it is down or
off-line. When the agent is up and working correctly, and a request for explicit permission is made for a
user, the agent scans the files for the information at the time of the request (real time).
The data is not retained or stored. A report for explicit permission information is done through a
discovery of NTFS data.
This completes the High Availability instruction for Enterprise Reporter 2.0.