I came across this issue while running SQL Server Reporting Services 2014 (SSRS) in SharePoint integrated mode in SharePoint 2013. As part of the SSRS integrated mode installation, you get a feature that enables a library template called “Report Document Library”. If you use this template, you are unable to create folders using the web interface. Using the “New Folder” option in the web interface results in the following error:
The aspx_debug attribute on the page directive is not allowed in this page.
The “Report Document Library” feature has been deprecated and should not be used. This library template comes from these feature files:
\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\ReportsAndDataListTemplates\ReportDocumentLibrary
The SharePoint group removed this from the product in SharePoint 2013, but it gets added back in when you install SSRS integrated mode.
So, when creating libraries, stay away from both of these:
This recommendation is confirmed through Microsoft support.
Use the standard “Document Library” template to create your libraries for SSRS reports. Once you have the document library, simply add the needed SSRS content types to the library to enable all of the same functionality.
- Browse to the library settings page
- Click on Advanced Settings. Then enable Allow management of content types
- Back to the library settings page, then add the SSRS content types as needed
- The SSRS content types are in the group called “SQL Server Reporting Services Content Types”
If you already have report document libraries setup, the best way (without a 3rd party migration tool) to move these into a regular document library is to:
- Rename the path of the existing library using SharePoint Designer 2013 (e.g. LibraryName_OLD)
- Create the new library using the “Document Library” template using the original name so that user’s links don’t break, then enable the SSRS content types as shown above
- Move the existing content into the new library using the Content and Structure feature (Gear -> Site Settings -> Content and Structure). NOTE: If you do this, you will need to reconfigure any shared data connections settings on the reports!!
Alternatively, if you have a library already setup and you can’t migrate to a standard document library, you can create new folders using Windows Explorer:
- Browse to the library
- On the library tab, click Open with Explorer
- Create folder as needed in Windows Explorer
I ran into an issue where in one of my site collections, I was no longer able to change the composed look or “Change the Look” in SharePoint 2013. After selecting a composed look, the following error would be presented:
Cannot complete this action. Please try again.
The ULS logs did not contain much useful information either:
08/14/2015 08:09:13.47 w3wp.exe (0x15E8) 0x3118 SharePoint Foundation General 8kh7 High Cannot complete this action. Please try again. 0ee8239d-e4c1-9060-8a21-d1416cc5bdef
08/14/2015 08:09:13.47 w3wp.exe (0x15E8) 0x3118 SharePoint Foundation General ai1wu Medium System.Runtime.InteropServices.COMException: Cannot complete this action. Please try again., StackTrace: at Microsoft.SharePoint.SPWeb.InitWebPublic() at Microsoft.SharePoint.SPWeb.get_AlternateUILcids() at …
Because I has some strange issues trying to restore a web from the recycle bin earlier in the day, I decided to check to see if there were any orphan items in the content database. Sure enough, there was an orphaned web and that was causing the “Change the Look” issue throughout the site collection.
The first step is to check to see if this applies in your environment.
- Get the content database name
Get-SPSite <SiteCollectionURL> | FL *Database*
- Check for orphaned items
$ContentDB = Get-SPContentDatabase <ContentDBNameFromStepAbove>
The above method will output XML that contains each of the orphaned items in the content database.
If you do have orphaned items, take a full backup of your SQL database. Then proceed with the following:
- Run the Repair method against the content database
- Confirm there are no longer any orphaned items by reviewing the XML output from the prior step
- Try to apply the composed look to one of the webs in the site collection
Here is the MSDN page that outlines the repair method.
I created a simple SharePoint Designer 2013 workflow. The workflow only has a couple activities – sending and email and copying the document to another library. When the workflow reached the copy document step, it would constantly pause and you would see and error such as the following on the workflow status page:
Activity in progress
Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP BadRequest to https://myserver.fqdn/sites/teamsite/_vti_bin/client.svc/web/getfilebyserverrelativeurl(‘/sites/teamsite/FormLibraryName/FormInstanceName_2015_06_01_12_00_00.xml’)/CopyTo(strNewUrl=’/sites/teamsite/SecondLibraryName/FormInstanceName_2015_06_01_12_00_00.xml’,%20bOverWrite=’false’) Correlation Id: 62600f9d-24c3-9060-8a21-d4689f426f96 Instance Id: 11915cf9-2e82-49ae-ae04-3e93dcef731c
The reason that this happens is that the URL that is being requested to get data via the client API (client.csv) is longer than the default IIS setting of 260 characters. The part that is in bold above is the request that the workflow is making, which in this case is 281 characters. Microsoft should update the default settings in IIS for the ISAPI virtual directory, but lucky for us, they don’t.
Update the web.config file in the ISAPI virtual directory on each of your SharePoint servers:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\web.config
<httpRuntime maxUrlLength=”4096″ />
Here is what it should look like:
By putting this in the ISAPI virtual directory’s web.config, the change will apply to all SharePoint web applications. You could put this in the web application’s web.config, but that is a lot of extra work. It would also then make the max URL length change for all pages in the web app, not just the ISAPI services.
When new Excel files are added or updated in a PowerPivot Gallery library in SharePoint 2013, a process called GallerySnapshot.exe is supposed to kick off and generate some pretty thumbnail images for the Silverlight gallery view of the library. I ran into a scenario where the process was not running and no thumbnails were generating. No hourglass was showing (should happen while process is running.) No red X was showing (happens when errors during the process occur.)
This is an example of what I was seeing:
This is what it should look like when the process is running (not happening in my environment):
The full path to the executable is: “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN\GallerySnapshot.exe”
I determine the GallerySnapshot.exe process was not even being called by:
- Add a sample excel file
- Start up ProcMon and set a filter on the process name contain ‘GallerySnapshot’
- Modify the properties of the Excel file (this should trigger the process)
In my case, the GallerySnapshot process was not even being called.
Turns out to be a pretty easy fix. All you need to do is deactivate the site collection feature called “PowerPivot Feature Integration for Site Collections”. Once the feature is deactivated, re-activate it. Then update the Excel workbook and you should see the process start to kick off. Thumbnails should show up in a minute or two.
Here is a simple way to get to the web part page maintenance screen. This can be helpful if a web part customization is causing the page to error out.
All you need to do is append:
to the page URL. For example, if your page URL is http://sharepoint/Pages/Home.aspx, you can enter http://sharepoint/Pages/home.aspx?contents=1
From the maintenance page, you can delete problematic web parts:
After upgrading my SharePoint 2010 databases to SharePoint, I noticed that incoming email was not processing. The timer job was running every minute as it should, but it would throw and error for each message in the drop folder:
Message: Error occurred processing 1 message(s).
In my case, my 2013 farm was running the December 2014 CU, which is version 15.0.4675.1000.
There is a bug that was likely introduced in the December 2014 CU that incorrectly checks the Sandbox Solution Code Limit on the site’s quota. The key here is that the quota template needs to have values specified in the Sandbox Solutions with Code Limit section.
This won’t work
This will work:
Update the site’s quota template to include both storage and sandbox solution code limits.
A bug report has already been filed with Microsoft on this issue.
UPDATE 4/15/15: A fix for this issue is included in the April 2015 CU for SharePoint 2013