Chat now with support
Chat with Support

Enterprise Reporter 3.2.2 - Installation and Deployment Guide

Product Overview Installation Considerations for Enterprise Reporter Installing and Configuring Enterprise Reporter Managing Your Enterprise Reporter Deployment Troubleshooting Issues with Enterprise Reporter Appendix: Database Content Wizard Appendix: Encryption Key Manager Appendix: Log Viewer

Deploying a Node to a Trusted Domain

When deploying a node to a trusted domain, the remote domain must trust the domain where the Enterprise Reporter Server is installed because the account that runs the node service has to authenticate to the Enterprise Reporter Server.

We strongly recommend deploying the Enterprise Reporter Node software on a computer that is local to the discovery targets - in this case, in the remote domain.

The Enterprise Reporter Service Account requires Local Administrator access to the remote node computers to deploy the node using the Configuration Manager.

The Enterprise Reporter Node service account has the following requirements.

•
It must be from the same domain as the Enterprise Reporter Server service account.
•
It requires sufficient rights to the Enterprise Reporter database (member of the Reporter_Discovery_Nodes group is sufficient).
•
It requires Local Administrator rights on the node computer.

When deploying a node to a trusted domain, the port requirements are the same as when deploying a node to a local domain. For more information, see Port Requirements .

Optimize Data Transfer

When you run a discovery for the first time, all of the data is collected and written to the database. For subsequent runs, only the changes are written. Determining the changes requires some processing, and you can choose the data source against which to compare the new data. You have two choices, and you may need to experiment to find the best setting for each cluster:

•
Compare to a local copy of the data
The shared data location is a network share, used by all nodes in the cluster. When data is collected, a copy of the data is stored in the shared data location. Subsequent runs of the discovery are compared to this data, and once the comparison is complete, only changes are sent to the SQL Server®. This reduces traffic across the network and load on your SQL Server®.
* 
NOTE: Not all discovery types utilize the shared data location. For example, Active Directory®, Exchange™, and NTFS, do not use the shared data location to optimize on the number of collection tasks generated to collect the data in a more efficient manner.
•
Compare to the main database
For subsequent runs of a discovery, the comparison can be made directly against the Enterprise Reporter database, instead of the shared data location. This can be faster if the node is physically close to your SQL Server®, or if the SQL Server® is lightly loaded.

Discovery Considerations

The following sections can help you get the most out of Enterprise Reporter:

•
Divide Discovery Targets According to Cluster Structure
•
Collect Only the Data Needed
•
Plan Discovery and Reporting Schedules
•
Optimize Nested Group Membership Collection

Divide Discovery Targets According to Cluster Structure

Clusters contain the nodes that actually collect data from the targets of the discovery. The closer your nodes are to your targets, the faster the collection will be. Because Enterprise Reporter is scalable, you can modify your deployment at any time to suit your needs. Consider these approaches for ensuring effective target distribution across your deployment:

•
If you have a full understanding of your data collection needs, design your clusters and nodes to fit. For example, if the bulk of your collection targets are located in your head office, and you only have small collections in other areas, you could create a large cluster in your head office, and a single node cluster in each of the areas where other collections occur.
•
If you know where some of your targets are, but not the amount of data that will be collected, start by creating a single cluster in the major geographical areas and then when creating discoveries, group targets accordingly. For example, create a small cluster in each network branch, and when discoveries are created, group the targets and assign the cluster accordingly. You can scale up your cluster at any time if the nodes cannot keep up to the data collection.
•
Grow your deployment on demand. Create a single node cluster for your first collection. As your discoveries grow, scale this cluster up for targets in the same geographical location, or add new clusters when targets become physically removed from your node.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating