Enable Failed Request Tracing in IIS to troubleshoot SharePoint web.config errors

While working on a SharePoint 2013 implementation with a client this week I ran into an issue that I had not run into before and ended up having to do some debugging that I don't do regularly.

For this I ended up using request tracing in IIS to further isolate the issue and gather more information. This ended up providing me with the additional information I needed to resolve the problem. In the end the problem was with a machine.config file.

Since this was not something I have to do very often when working with SharePoint I thought I would share this for others that may have forgotten about this useful tool or have never had to use it.

 

Enable Failed Request Tracing

• Go into IIS, drop down the list of sites, select the site you want to enable tracing on
• In the right side you will see a Configure section as below, Click on Failed Request Tracing

• On the next screen check to enable

• You can create a new rule to capture an error code range if you have an idea of the error code
• Double click on Failed Request Tracing Rules

• Click Add

• Click Next

• Enter in the desired error code range

• Click Finish

• Generate the error that you are troubleshooting
• Once the error has been generated go to the web front end server and look in the directory specified in the trace logging setting you set

• You will see an XML file in that location, open the XML file in a browser

• You will see the information on what has been captured. Take note of the frame mentioned in the error

• Click on Compact view and scroll to the bottom of the page and you will see more specific error information

SQL Reporting Services report subscription file share issue solved via SharePoint site access via UNC path

On a recent project with a client we had a situation where they were using SQL Reporting Services in SharePoint integrated mode and wanted to create report subscriptions that would output these various reports to a file share so that another application could pick them up from there.

The issue with this solution is that when you are configuring a subscription that will output to a file share you have to specify a username and password that has access to this location. The problem with having to do that is that each time the account password changes, in this case it was 180 days, the client would have to go out and manually update this password for each individual report subscription. With a large number of reports and subscriptions this is just not an efficient or sustainable solution.

There was no way to get around the requirement that you had to supply account information to output this to the file share. So I asked the client how this other application accessed the file locations that were setup in the configuration of this application and found that it used UNC paths.

Once I had this information I knew I had a workaround to the issue. I let the client know that you can access a SharePoint site or library via a UNC path with minimal configuration required and that this would solve the issue at hand.

After I had everything configured I tested accessing the sites and found that I could not. I would just receive the generic error that the network path could not be found. I checked that all required services on the client and server were started and they were. I started looking into the issue a bit further and after some searching found the bit of information that I was missing. These sites were all running SSL and I found that the path used to access an SSL site in this manner was slightly different then if the site was running HTTP. After correcting my path everything worked as I would expect it to and the subscription output issue was solved.

Since I could not find a single place that had all the required information to get things configured as well as how to access the sites on different ports I thought it would be a good time to pull all the information together in one place. Below are all the steps required to get this setup as well as the different paths that are used when accessing sites running on ports other than 80.

In order to make SharePoint sites accessible via a UNC path there are steps that need to be taken on both the client and the server. This will cover what is required in order to make this work on Windows Server 2008 and a Windows client.

Windows Server 2008 Configuration
We need to install desktop experience feature. This feature will also install Ink support. In earlier version of windows the webclient service could be installed by enabling the WebDAV component in IIS.

• Start the Windows Server Manager.
• In the tree view, highlight the Features node.
• In the details pane, click Add Features.
• In the Add Features Wizard, check the Desktop Experience box, and then click Next.
• Click Install.
• When the Add Features Wizard has finished, click Close.
• Click Yes when prompted to restart the computer. There will be two restarts that will occur during this process ad you will want to make sure you log back into the server after the last reboot as it will bring back up the installation screen and you will need to acknowledge that it has completed.

Windows Client Configuration

• On the Windows client machine you will just need to start the web client service
• Go to the run command or command prompt and type in services.msc
• When this opens find the web client service in the list
• Change the start up to automatic and then start the service

Accessing the site via a UNC path

The way in which you access a site via the UNC path will differ based on whether you are using HTTP or HTTPS.

The example below provides the format required for each of these scenarios to access a document library named reports. 

HTTP

\\intranet.contoso.com\sites\sales\reports

HTTPS

\\intranet.contoso.com@SSL\DavWWWRoot\sites\sales\reports