Chatee ahora con Soporte
Chat con el soporte

Enterprise Reporter 3.2.1 - Configuration Manager User Guide

Product Overview Configuring the Configuration Manager
Starting the Configuration Manager Finding Answers and Getting Help An Overview of Enterprise Reporter Communications and Credentials Required Logged In User Details Setting Up Your First Collection Computers Modifying your Deployment Improving the Performance of Your Discoveries What does the status of a node or cluster indicate? Using the Credential Manager Changing the Credentials used by the Enterprise Reporter Server Configuring Global Settings Global Discovery Settings
Understanding Discoveries Creating Discoveries
Step 1. Create the Discovery Step 2. Choose what to include in your discovery (Scopes) Step 2a. Choose scopes for your discoveries
Choosing your Active Directory Scopes Choosing your Computer Scopes Choosing Your Exchange Scopes Choosing Your File Storage Analysis Scopes Choosing Your Microsoft SQL Scopes Choosing Your NTFS Scopes Choosing Your Registry Scopes
Step 2b: Choose scopes for your Office 365 discoveries Step 3. Schedule your Discovery Step 4: Review the summary
Managing Discoveries Troubleshooting Issues with Enterprise Reporter Appendix: PowerShell cmdlets Appendix: Encryption Key Manager Appendix: Log Viewer

Changing the Size of the Node Log Files

Enterprise Reporter writes to log files. By default, the node logging level is set to Warning and the cumulative size of the log files is set to 1000 MB. You can manage the log files within each discovery cluster by setting the node logging level and the cumulative size of the log files. For information on changing the node logging level, see Changing the Node Logging Level .

To change the size of the node log files
1
In the Manage Discovery Clusters pane, select the cluster.
2
On the Cluster Details tab in the bottom pane, change the size of the log files.
The default is 1000 MB and the maximum is 2000 MB. The increments can be set from 100 MB to 2000 MB.
3
Click Apply.

Scope Enumeration Issues

When selecting scopes in an on-premises discovery such as NTFS or Active Directory, the credentials in use determine the available scopes. Depending on your discovery, you may be:

•
using the default node credentials, in which case your logged in user account determines the available scopes.
•
using alternate credentials, in which case these credentials determine the available scopes.

If you are using alternate credentials, and no scopes are available, this may indicate a DNS issue. Ensure the credentials you are using are fully qualified.

Data Collection Issues

You may run into situations where not all of your data is collected, or even no data at all. The first thing you need to determine is what tasks in the discovery are failing. Once you have located the problem tasks, you can use the errors and statistics generated to pinpoint the problem. There are several other things you can examine:

•
The errors generated for a task provide a good starting point for troubleshooting. For more information, see Viewing Errors and Statistics for Tasks .
•
If your discovery fails for all tasks, it is possible that your shared data location is the problem. The shared data location may no longer exist, or the node may not have adequate access to it. Check the errors on the discovery task to investigate. For more information, see Viewing Errors and Error Suppressions . If this is the issue, ensure the shared data location belonging to the cluster exists and is properly permissioned. Shared data locations are not used for Active Directory, Exchange, or NTFS discoveries.
•
If your discovery fails for a particular task:
•
The node may not have access to that server. Check your credentials, and change them if necessary. For more information see Node Credential and Alternate Credential Details for On-Premises Discoveries and Modifying Node Credentials .
•
If you have used alternate credentials for the discovery, ensure that they are permissioned properly. For more information, see Node Credential and Alternate Credential Details for On-Premises Discoveries and Detailed Permissions for Enterprise Reporter Discoveries .
•
WMI and the SQL Server Browser service may be disabled or your credentials are inadequate. WMI and the SQL Server Browser service are used to query for SQL instances that are not broadcasting.
•
The task may have been rejected. If a task is rejected, it means that it is currently being collected by another discovery. Due to the way the Enterprise Reporter collects data, collecting from a SQL Server® in more than one discovery can result in data loss. You could only create one discovery for each SQL scope.
•
A discovery can fail if it runs at the same time attributes are being extended for that discovery type. Run the discovery again once the extension has been processed.
•
If a particular task is timing out, you can increase the amount of time allowed to connect to the database or process a command. A task may fail because the target computer cannot be pinged. The ping setting is available for computer, Exchange, NTFS and registry discoveries. If a target computer cannot be pinged, for example due to network settings or firewall configurations, or if you know that all computers in the discovery are online and available, you can disable the ping. However, if you have added a domain or OU as your scope, and there is a chance that any computer in the container is not available, setting the ping time ensures that no time is spent preparing to collect from these computers. If a computer unexpectedly fails a ping check, try increasing or disabling the ping for the discovery.
•
If your reporting users are experiencing unexpected data fluctuation, check your discovery configuration. If the same target (computer) is in more than one discovery, the data available for reporting reflects the last configuration that was run. Enterprise Reporter’s recommended practice is to include a target in only one discovery of a given type. If you have accidentally included a target in more than one place, remove it from all but the desired discovery, and then run that discovery. If for some reason you choose to leave the target in more than one discovery, you can mitigate this issue by using the same settings in both discoveries.
•
The node may be running an unsupported operating system. Check the system requirements, and if necessary, remove the node from the cluster, then rerun the discovery.
•
If your Enterprise Reporter database is hosted on a SQL cluster which has experienced a node failure, this can occasionally result in a task that cannot finish processing. In this case, you may need to recreate the discovery.
•
Try running the discovery, and monitoring the Activity column in the Processing Tasks view, or looking at the history of the discovery. This may help you identify the specific activity that is causing performance or data collection issues with the discovery. For more information, see Viewing the Tasks for a Processing Discovery , and Viewing the History of a Discovery .
•
If your scheduled discovery does not run, there may be system issues that prevent the job from being created based on the schedule. In this case there is no error reported in the Configuration Manager. To address this issue check that your Enterprise Reporter server service is running, validate your license and check the state of any nodes on the system.
•
If a discovery disappears, it is likely that another administrator deleted it. You will have to recreate the discovery.

See also:

•
Computer Discovery Errors

Computer Discovery Errors

This section outlines some of the errors that may occur during collection and some suggested approaches for resolving them.

 

Table 42. Computer Discovery Errors
Error Message
Resolution

Retrieving addresses: access is denied

- OR -

Retrieving cached logon count: Requested registry access is not allowed

 

The service account, or the alternate credentials used in the Computer discovery does not have administrator access on the remote server. The account requires local Administrator rights on each target.

To verify, run regedit.exe as the service account (by holding shift and right-clicking on the executable to run with different credentials) and attempt to connect to the remote server.

 

 

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación