Turning On Detailed Logging in a Self-Hosted Environment

Note: the instructions in this article apply only to self-hosted XpressDox environments — that is, where XpressDox Server is installed on your own server rather than being hosted by XpressDox. If you access XpressDox through a web address supplied by us and you don’t have your own server, this article doesn’t apply to you.

Why you might need this

XpressDox Server keeps a log — a running record of what it does. By default it records only the essentials. When something goes wrong and the cause isn’t obvious, our support team may ask you to switch on detailed logging. This tells the server to record far more about each step it takes, which usually reveals where the problem is occurring.

Turning it on involves editing one file on your server. You don’t need to be a developer, but you will need administrator access to the server, and you should be comfortable editing a text file. If you have an IT person who looks after your servers, this is a good task to hand to them.

Before you start: make a backup

You’ll be editing a file called web.config. This file controls how XpressDox Server runs, and a small typo in it can stop the site from loading. Before changing anything, make a copy of the file and keep it somewhere safe. If something goes wrong, you can simply put the original back.

You’ll find web.config in your XpressDox installation folder, typically:

C:\inetpub\wwwroot\XpressDox\web.config

Open it with Notepad++. Right-click Notepad++ and choose Run as administrator before opening the file, otherwise Windows may not let you save your changes.

Step 1: Add the logging key

Inside web.config, look for the section that begins with <appSettings> and ends with </appSettings>. This section holds a list of settings, each on its own line.

Add the following line anywhere inside that section — the last line before </appSettings> is a good place:

<add key="DetailedFfsRestApiLogging" value="true"/>

The screenshot below shows the new line in place, highlighted in orange. Note that it sits above the closing </appSettings> tag:

Step 2: Set the logging level to ALL

Adding the key above tells XpressDox to produce detailed information. This second step tells the logging system to actually write all of it down.

Still in the same web.config file, scroll down to the section that begins with <log4net>. Within it, find the part marked <root>. You’ll see a line setting a level value. Change that value to ALL:

<level value="ALL" />

The comment line just above shows the available options: ALL, INFO, DEBUG, WARN and ERROR. These run from most detailed to least. ERROR records only things that actually failed, while ALL records everything — which is exactly what’s wanted when diagnosing a problem.

Save the file once both changes are made.

Step 3: Reproduce the problem

Saving web.config causes XpressDox Server to restart automatically, so the new settings take effect within a few moments. Anyone using the system at that instant may notice a brief pause, so you may prefer to make these changes outside of busy periods.

Once it’s running again, repeat whatever action was causing the problem. This is important — the log can only capture the fault if the fault happens while detailed logging is switched on. Make a note of roughly what time you did this, as it helps our support team find the relevant part of the log.

Step 4: Find and send the log files

Log files are saved in a logs folder inside your XpressDox installation path, typically:

C:\inetpub\wwwroot\XpressDox\logs

The main log file is named XpressDoxServer.log. Log files are created daily, with older entries stored in files named according to their date. If the problem occurred a while ago, you may need to look at more than one file.

Send the relevant file or files to our support team, along with the approximate time the problem occurred.

Step 5: Turn detailed logging off again

This step matters. Detailed logging records a great deal of information, and the log files grow quickly — on a busy system they can consume a significant amount of disk space in a short time. Detailed logging is meant to be switched on temporarily while a problem is being investigated, not left running permanently.

Once support has what they need, reverse both changes:

• Set the DetailedFfsRestApiLogging value back to false, or delete the line entirely
• Change the log4net level value back to what it was before, commonly ERROR or INFO

Save the file again, and the server will restart with normal logging restored. This is another reason the backup copy from the beginning is useful — you can check it to confirm what the original setting was.