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

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 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 .
•
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 more information, 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 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 .
•
If an Azure or Office 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. For more information, see Multi-Factor Authentication Discovery Credential Limitations .
•
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 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.

Troubleshooting Features in Enterprise Reporter

There are several features in Enterprise Reporter to help you solve problems.

•
Exporting Logs from the Configuration Manager
•
Viewing Information About Your Enterprise Reporter Configuration
•
Viewing Errors and Statistics for Tasks

Exporting Logs from the Configuration Manager

Exporting Discovery Management Logs

Discovery logs can be used to troubleshoot issues with discoveries. Discovery logs are collected from the Reporter server and all of the nodes within a selected cluster, and zipped into files that can be sent to Quest Support to help resolve certain collection problems. The discovery log files are all sent to the Exported Logs folder on the Reporter server. You may have several different .zip files, which may take some time to appear, depending on your configuration:

•
A ServerLogs.zip file containing the logs from the server.
•
A <Computer Name>_NodeLog.zip file for each node in the cluster.
To export discovery logs
1
On the Manage Discoveries pane, select a discovery.
By selecting a discovery first, the correct cluster for the discovery is automatically chosen.
2
Click the Manage Logs button and select Export Logs.
3
If necessary, change the selected cluster.
4
Click Export.
5
Click the link to locate your zip files.
Zip files are all located in the \ProgramData\Quest\Enterprise_Reporter\Exported_Logs folder.
You can now email your log files to your Quest Support representative.
6
Click Close.

 

* 
NOTE: To help diagnose issues, the ServerLogs.zip contains additional files including the DatabaseMaintenance.log file and a SQLLite file containing Enterprise Reporter system configuration information.
Exporting the Configuration Manager Logs

The Configuration Manager logs can be used to troubleshoot issues with the Configuration Manager service. Information is collected from the Configuration Manager service and is zipped into log files that can be sent to Quest Support to help resolve certain Configuration Manager problems. The log files are sent to the desktop on the Configuration Manager computer and may take some time to appear, depending on your configuration:

To export Configuration Manager logs
1
Click System | Information.
2
Under Client Logging Information, click Export Configuration Manager logs.
3
Click Export.
4
Click the link to locate your zip file.
You can now email your log files to your Quest Support representative.
5
Click Close.
Viewing the Configuration Manager Logs

You can unzip and view the Configuration Manager logs using the Log Viewer.

To view the Configuration Manager logs
1
Click System | Information.
2
Under Log Viewer, click View logs to open the Log Viewer.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating