Chat now with support
Chat mit Support

Enterprise Reporter 3.5.1 - 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

Effectively Deploy Remote Nodes

You can deploy nodes from the Configuration Manager or manually. When you are deploying a node to a remote computer, factors such as firewall configuration and network latency can cause problems. In this case, you can deploy a node manually on the host computer. For more information, see Node Deployment Issues . You can also supply alternate credentials to be used for Node service deployment. This account must have permission to copy files in the Admin$ share folder and to install and run services.

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
Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen