立即与支持人员聊天
与支持团队交流

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

Dealing with unassociated nodes

An unassociated node is one that has been either manually installed, or left behind from a previous installation of Reporter. You can either uninstall the node, or associate the node with a cluster.

To uninstall a node
•
Use the Control Panel, and uninstall Quest Enterprise Reporter Node.
To associate a node with a cluster
1
In the Manage Discovery Clusters pane, select the cluster.
2
In the Unassociated Nodes pane, select the node.
3
Click Associate Node(s) with Selected Cluster.
4
In the confirmation dialog box, click Yes.
5
If necessary, close the Unassociated Nodes pane.
The node appears associated with the cluster in the Initializing state until it is deployed.

Problems deleting a node

If you are deleting a node, you may see an error message indicating that the discovery node installation failed, for example:
"An error occurred copying the discovery node installation program Quest.Reporter.Core.Server.MsiInstaller.exe to \\servername\ADMIN$\Quest.Reporter.Core.Server.MsiInstaller.exe."

This indicates that there was a problem connecting to the host computer. Check your node credentials, ensure that the firewall is not enabled on the host, and ensure that the computer can be reached on the network. Once you have resolved the connection issue, you can attempt to remove the node again.

Creating a Node Debug Log File

If you are experiencing difficulty, the support staff may ask you to change the logging level for nodes in a cluster. The default setting for node logging is Warning, which also includes Fatal and Error. You can increase the logging level to Information or Debug to help them troubleshoot your issue. You also should increase the size of the node log files temporarily to accommodate the increased data collection.

* 
IMPORTANT: Use caution when increasing the logging level. We recommend that you do not increase the level permanently, as it may affect node performance. The logging levels are cumulative, so Debug contains debug, information, warnings, errors and fatal errors.
To create a node debug log file
1
In the Manage Discovery Clusters pane, select the cluster.
* 
NOTE: The cluster must be enabled to change the node logging level.
2
On the Cluster Details tab in the bottom pane, change the node logging level to Debug.
3
Increase the size of the node log files.
4
Click Apply.

Data Collection Issues

You may run into situations where not all of your data is collected, or even no data is collect 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 that you can examine:

•
The errors generated for a task provide a good starting point for troubleshooting. For more information, see Viewing Statistics .
•
During an Active Directory discovery, if collection issues are related to overloaded domain controllers, disable Create multiple tasks for each domain and specify multiple domain controllers for the domain instead. For details, see AD Discovery: Optionally select one or more domain controllers .
•
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 details, see Node credential and alternate credential details for on-premises discoveries .
•
If you have used alternate credentials for the discovery, ensure that they are permissioned correctly.
•
If an Azure or Microsoft 365 discovery fails, indicating that the objects could not be collected using a multi-factor authentication credential, retry the discovery with a non-multi-factor authenticated credential.
•
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. For more information, see Troubleshooting Connection Timeouts .
•
A task can 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 information about discoveries, see the Enterprise Reporter Configuration Manager User Guide.
•
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.
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级