SSRS SharePoint Integrated Reports stop working unexpectedly and prompt user to open and save instead of running in the web part

As if there are not enough oddities and issues with a typical SSRS implementation, I ran into an interesting issue the other day where a customers SSRS reports just stopped working one morning when they came in. So the day before all reports were working properly with no issues and had been for some time.

When the user would go to run any of their reports they would get the following message

I began to dig into the issue a bit and everything is the environment looked good. There were no strange errors, services stopped, etc. From the surface everything looked to be running correctly.

The other strange thing I noticed was that all the report specific items were gone from the drop down menu in the library

After looking at some other areas I began isolating my testing to a single WFE server at a time since there was a load balancer in play in the environment. After doing this I quickly found that one of the WFE servers still worked normally, while the other WFE server exhibited the faulty behavior.

In the end, this problem was being caused because the SSRS SharePoint Add In had not been installed on one of the WFE servers.  After installing the Add In all the reports ran normally again as they had been from either one of the servers.

SSRS 2012 Report Server Add-In
http://technet.microsoft.com/en-us/library/gg426282.aspx

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

How To install the Workflow Foundation Farm in an Offline Environment

While working on a clients SharePoint 2013 implementation I ran into a number of different issues due to the clients servers having very limited access to the internet. I ran into issues with some different installations such as SharePoint prerequisites, .Net framework, etc. 

In order to get this to work I had to go through a number of hoops that you wont have to deal with if you have access to the internet. The following MS article provides details on these steps, but I found that there ended up being some details missing

http://technet.microsoft.com/en-us/library/jj193448.aspx

This error will be received when running the platform installer if you don’t have internet access

Offline Installation

•  Navigate to http://technet.microsoft.com/en-us/library/jj906604.aspx
  
•  Click on the link in step 1 under “To Download the files”
  
•  This will take you to another page that provides the link for the installer -
• WebPI v4 x64: http://download.microsoft.com/download/7/0/4/704CEB4C-9F42-4962-A2B0-5C84B0682C7A/WebPlatformInstaller_amd64_en-US.msi
  
•  Click on the link to download the file
  
•  Open an elevated command prompt and navigate to the download location of the file
  
•  Run the following to extract the content of the MSI file, below is example       
              Msiexec /a D:\temp\WebplatformInstaller_amd64_en-US.msi /qb TARGETDIR=D:\temp\web
  
• This will extract the contents of the MSI into the specified folder, you will want to drill down into the sub folders of the folder you extracted the files to in order to get to WebpiCmd.exe , this should be located in “\Microsoft\Web Platform Installer\WebpiCmd.exe”
  
• Change directories to this folder location in your command prompt and then run the following
            webpicmd /offline /Products:WorkflowManager /Path:D:\WorkflowManagerFiles
  
• This command will run for 5-10 min mattering on connection speed and display a number of products as it is running.

• Once complete it will return to the command prompt

• Zip up all the contents and upload to dropbox or another site that can be accessed from the client site
  
• Download and then extract the zip file on the server that will run workflow manager in the farm
  
• Once the files are downloaded and copied to the target server, launch an elevated command prompt and navigate to the bin folder contained within the Workflow Manager files folder used. This location will contain the Web Platform Installer executable that can be run in offline mode.
  
• Run the following command
   WebpiCmd.exe /Install       /Products:WorkflowManager /XML:C:/WorkflowManagerFiles/feeds/latest/webproductlist.xml
  
• This will start the installation of the required components, once it is complete you will see the screen below and the workflow manager configuration will launch

• Select the first option to use default settings

• Enter in the SQL alias being used in the farm and click test connection to verify

• Enter in Configuration information and then Click the next arrow and it will validate your configuration

Setting	Value
User ID	Enter in “Run-As” service account being used in the farm
Password	Password for service account
Allow workflow Mgmt over HTTP	Yes if HTTP will be allowed, No if not
Certificate Generation Key	Set key that is used to join other servers to the farm

• Configuration validation will occur

• After this completes you will see a list of the configuration that you have chosen, Click the check box to apply the configuration

                          ** You can click on “Get PowerShell Commands” to get the configuration you selected in a PS script **

• The configuration will run and provide a status after all has completed, Close this window once this has been completed

                                       ** Review the log below the status and look for any errors or failures **

• If there are multiple servers in the farm then you will need to install the workflow client on all other SharePoint server in the farm. The installation file is WorkflowManagerClient_x64.msi
  
• Double click on the file and it will perform the installation, you will not be prompted for anything once complete, it only takes a few seconds to complete
  
• All files and folders are required for this process or you will run into errors when trying to run the offline file installation.
  
• If you try and run the offline installer without all files being present that are downloaded you will receive the error below

Once this has completed you are ready to complete wiring up the workflow farm to your SharePoint farm.

SSRS SharePoint Integrated Reports stop working unexpectedly and prompt user to open and save instead of running in the web part

As if there are not enough oddities and issues with a typical SSRS implementation, I ran into an interesting issue the other day where a customers SSRS reports just stopped working one morning when they came in. So the day before all reports were working properly with no issues and had been for some time.

When the user would go to run any of their reports they would get the following message

I began to dig into the issue a bit and everything is the environment looked good. There were no strange errors, services stopped, etc. From the surface everything looked to be running correctly.

The other strange thing I noticed was that all the report specific items were gone from the drop down menu in the library

After looking at some other areas I began isolating my testing to a single WFE server at a time since there was a load balancer in play in the environment. After doing this I quickly found that one of the WFE servers still worked normally, while the other WFE server exhibited the faulty behavior.

In the end, this problem was being caused because the SSRS SharePoint Add In had not been installed on one of the WFE servers.  After installing the Add In all the reports ran normally again as they had been from either one of the servers.

SSRS 2012 Report Server Add-In
http://technet.microsoft.com/en-us/library/gg426282.aspx

My Site tasks not updating from multiple site collections and show old updated date

While working through some SharePoint 2013 farm configuration for an upcoming demo I ran across an issue where the tasks link in your mysite would not load up corretly and would throw the following error

Sorry, we are having trouble refreshing your tasks
or
Last updated at 1/1/1901 12:00AM

I ran across the following article that described the issue and provided a fix. It seems that the UPA security setup in SharePoint 2013 has changed from SharePoint 2010 as adding additional accounts to the UPA was not required in 2010.

For me the issue ended up being that the account I used for the work management service application had not been added to the UPA. After doing this and running an incremental crawl the tasks were showing up from other site collections for the user.

Thanks to Hong Gyem for publishing the information on the issue and the fix
http://honggyem.blogspot.com/2013/05/my-tasks-not-updating-seen-following.html

Learn How to Survive SharePoint and STIG Compliance

For those of you having your first experience with DISA STIGS and SharePoint I am sure you are finding that it is a bit convoluted, confusing, and there is little to no guidance published from Microsoft on this topic. I have been involved with a large SharePoint 2010/2013 implementation and migration project with one of our customers who happens to be in the Health Care industry and has to maintain compliance to these STIGS and other security measures on their systems. 

It has been very interesting and frustrating since SharePoint is such a complex product and relies so heavily on other systems and applications. Unfortunately I cannot cover all the pitfalls and issues that were encountered through this deployment, but I can hopefully at least provide some of my experiences and what to watch out for.

The interesting thing about STIG compliance and SharePoint is that it is not just SharePoint that is involved in this lock down process. The other systems/applications that SharePoint interacts with and depends upon are also subject to STIG lock downs which causes some interesting issues as your are building and configuring your farm.

SharePoint and these other applications all have their own set of compliance configuration that must be performed. This makes it even more challenging as the configuration performed in these other systems does not take into account the requirements of SharePoint. So there were areas that when locked down would break OOTB SharePoint functionality.

The main systems we have had to deal with have been:

• SQL Server 2008 R2 / SQL Server 2012
• SQL Reporting Services 2008 R2 / 2012
• IIS 7.0
• Windows Server 2008
• SharePoint 2010 / 2013

Out of all the systems mentioned above the one that has caused us more issue and pain by far is the SQL server. The configuration that gets done on the SQL servers for the security lock down essentially renders SQL unusable to SharePoint. The problems begin as soon as you try to create a configuration database to build the farm and don't stop there. As you progress through the build process you find problem after problem that requires custom roles being created in SQL to remedy the issues encountered. In our case it would come down to watching ULS logs and running SQL traces as we were performing the various configuration tasks that are required to build out and fully configure a farm.

Once I was able to get through the installation items I thought I was in good shape and that the rest of the deployment should smooth out and become more standard. How wrong I was about that. After the farm had been built we then started testing the various functionality the client was using. I quickly found that there was still a good bit of work ahead of me. In this particular environment SQL Reporting Services reports were used very heavily and I found out quickly that there were a number of issues with these and the SQL lock down.

I was able to work with the DBA team to get all the required roles and permissions configured so that all required functionality was working as expected.

Below are some of the resources I found useful when wading through the convoluted waters of compliance 

STIG Viewer - Useful site that allows you to quickly find information on the various STIG's
http://www.stigviewer.com/

National Vulnerability Database
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=411

IASE STIG Information
http://iase.disa.mil/stigs/

SharePoint and compliance can be a very confusing, difficult, and extremely time consuming to get implemented if you are unfamiliar with what all is required and how all of this impacts your SharePoint deployment.

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