Table of Contents
When you receive the error,
Sorry, there was a problem with your last request!
Either the site is offline or an unhandled error occurred. We apologize and have logged the error. Please try your request again or if you know who your site administrator is let them know too.
you need to determine the underlying error when you report it on the Zimbra forums to help debug the issue. You can either retrieve the error from the Exceptions log in the Control Panel or temporarily disable friendly error messages and reproduce the error.
Note: if you have access to the console of the machine on which Zimbra Social is running (that is, you are NOT using shared hosting) then the web.config file is configured so that you can view the errors simply by viewing the site directly on the machine where Zimbra Social is hosted.
Most errors causing this message are logged in the Exception log within the Zimbra Social Control Panel. To retrieve the error, open Tools > Exception log. Use the criteria options to attempt to locate the error that occurred at the time that you encountered the message above. If the error occurred recently, change the Sort By field to Last Occurred and check the Include Unhandled Exception check box before clicking Go. The latest error will be shown first.
You can also clear the Exception log, reproduce the error, and view the exceptions that were logged via the Exceptions report. You can clear the exception log by searching for exceptions and clicking Delete All.
If you cannot retrieve the error from the Exceptions log, you can disable friendly error messages by editing the web.config file.(However, note that this means that raw exception errors and stack traces will be exposed to users.)
- Edit the web.config file in the root of your site
- Edit the <customErrors> node in the web.config file and change mode="RemoteOnly" to mode="Off". Be sure to match the text case shown here ("off" is not equivalent to "Off").
- Save the web.config file.
- Reproduce the error by accessing the site.
The underlying error message should now be shown when the error is reproduced. When you have reproduced the error, you may want to restore mode=RemoteOnly in the web.config file.
When Zimbra Social denies you permission to do something, you might see a yellow exception message (unhandled error) screen with a red title indicating which method failed and then a stack trace of code instead of the expected friendly error message. This might occur for some users, but not for others.
Seeing the actual exception message exposed is traceable to how the customErrors flag in web.config is set. If the out-of-the-box customErrors setting (such as RemoteOnly) is changed, an exception would show as in the previous example.
Zimbra Social ships with customErrors set as RemoteOnly in order to show the friendly error message instead of raw exception errors. Leaving this setting intact means that you'll see the friendly message on all browsers except for browsers running locally on the Web server hosting Zimbra Social. (The users local on that server will see a stack trace.)
It's considered an ASP.NET best Web site practice to set customErrors in live sites as RemoteOnly. (Microsoft addresses customErrors in an article here.)