Chat now with support
Chat with Support

Enterprise Reporter 3.2.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

Restoring a Connection to the Enterprise Reporter Server

There are a number of reasons why a Enterprise Reporter server may be down. When a console loses its connection to the server, it becomes unusable and must be restarted. All users connected to the Enterprise Reporter server are affected. You should check the following connections:

•
Ensure that the computer hosting the server is turned on and running properly.
•
Ensure that the Enterprise Reporter server service is running. If necessary, restart it using the Services console.
•
Ensure that you can reach the host computer over your network.
•
Ensure that the server host computer meets the minimum system requirements.

If the server has gone down and been restored since you last logged in, then the next time you connect, you will be informed that the server went down. If you are the main Enterprise Reporter administrator, this allows you to be aware that your server has had issues. Intermittent failures over time may be due to instability in your network, problems on the server’s host computer, or your SQL Server® deployment.

Restoring a Connection to the Enterprise Reporter Database

If your server has lost its connection to the database, you can still open a console and connect to the server, but functionality will be limited. You will be unable to create discoveries, run reports or modify your configuration. Ensure that the SQL Server® hosting the Enterprise Reporter database is running, and that the server can access it.

The Report Manager maintains a direct connection to the SQL Server® database, so ensure that the console’s computer can also access the SQL Server®.

Troubleshooting Connection Timeouts

As Enterprise Reporter processes your requests, constant communication with the database is required. Depending on your network configuration, your Enterprise Reporter deployment, and the power of your SQL Server® host, the solution for timeout issues may vary.

You can fix timeout issues by either increasing the timeout in Enterprise Reporter, or by investigating any systemic or deployment issues. For example, perhaps your SQL Server® where the database is hosted is underpowered, or you have located your Enterprise Reporter server physically distant from your SQL Server®.

There are two places in the Configuration Manager where you can control the database timeouts:

•
Server timeout
You can increase the timeout between the server and the database. If a timeout occurs, you will see a warning dialog box, indicating that this has occurred. For more information on changing the server timeout, see Configuring Global Settings.
•
Cluster timeout
You can increase the timeout between the nodes in the cluster and the database. This is useful when a collection fails due to a timeout, which is indicated by an error on the Errors tab for the discovery. For more information, see Modifying a Cluster.

There are two settings for each timeout configuration:

•
Connection timeout
This is the amount of time given to make the initial connection to the database each time communication is needed. This is less likely to need adjustment. Timeouts are more likely due to SQL Server® or network issues than Enterprise Reporter specific problems. However, if you continually are seeing timeout errors, try increasing this setting.
•
Command timeout
This is the amount of time allowed for the database to process requests. If you are getting timeout error messages during data collection, increase this setting.
•
Report command timeout
This is the amount of time allowed for report generation. If you are getting timeout errors messages during report generation, for interactive or scheduled reports, increase this setting.

Troubleshooting Credential Change Failures

Each credential in the Credential Manager has three parts—an account name, a password and an optional description—and you can change any of them. While most changes should be processed smoothly, occasionally issues in the network environment may prevent changes from being applies. When a change fails, you need to determine the reason, and then manually make the changes.

•
If you have to manually change a credential on a node, you should ensure that there are no discoveries running or queued before making the change. Change the credentials using the Services console on the host computer, then restart the service. Verify that the node started in the bottom pane of the Manage Discovery Clusters page. Restart any discoveries you canceled.
•
If a node fails to start after changing the credentials, ensure the credentials have local administrator access on the node host computer, and check that the credentials you provided are valid.
•
If a discovery fails after changing a credential, ensure that the new credentials have read access on the targets of any discovery. Check the discovery to see if it using the default node credentials or if credentials are specified. Ensure that the credentials you provided are valid.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating