Monthly Archives: August 2013

Applying March 2013 PU – BdcServiceDatabase is not upgraded

After applying the March 2013 PU for SharePoint 2013 you may notice that the BdcServiceDatabase has the following status “Database is in compatibility range and upgrade is recommended.” This can be seen by going to Central Admin | Upgrade & Migration | Review database status. You may also see the following Health Analyzer Problem:

 healthanalyzerbdc

This can be fixed easily by running the following PowerShell command:

SSRS 2012 Add-In for SharePoint 2010 Performance Testing

After reading my last post you were probably like “well that’d pretty cool, but why would I want to do that?” Well after finding a few sources on the internet indicating that this may speed up report page load times, I figured I had to see it myself. It definitely increased all page load times and the most notable performance increases was the largest report. In this testing I hit the page 5 times and took the average page load time.

Other Sources:

  1. http://spandps.com/2012/04/30/ssrs-web-part-performance-2008-r2-vs-2012-initial-results-sharepoint-sp2010-in/
  2. http://blogs.msdn.com/b/mariae/archive/2012/04/23/improving-performance-of-reports-for-reporting-services-2008-amp-2008-r2-integrated-with-sharepoint-2010-by-using-the-sql-server-2012-add-in.aspx

Again, the SSRS 2012 Add-In is available for free download on the Microsoft website (http://www.microsoft.com/en-us/download/details.aspx?id=29068). One important thing to note is that any SSRS web parts will need to be recreated in the environment as the 2012 Add-In updates the web part (Microsoft.ReportingServices.SharePoint.UI.WebParts.ReportViewerWebPart) from version 10.0.0.0 to 11.0.0.0.

Normal Report Page:

Row Count (From dbo.executionlog) 2008 R2 SSRS Add-In Page Load (In Seconds) 2012 SSRS Add-In Page Load (In Seconds) % Speed Increase
70066 5.3090059 3.8353092 38.424457
21320 1.4462438 1.3420621 7.7628104
16318 0.656880567 0.587642967 11.782256
6210 1.1072249 1.097880133 0.8511646

 

Web Part Page With SSRS Web Part (Same Reports):

Row Count (From dbo.executionlog) 2008 R2 SSRS Add-In Page Load (In Seconds) 2012 SSRS Add-In Page Load (In Seconds) % Speed Increase
70066 5.292353533 3.862166 37.030711
21320 1.4832806 1.4392445 3.0596678
16318 0.677473233 0.5520499 22.719565
6210 1.175019933 1.0670111 10.122559

*Note: Page load times were recorded using Fiddler2. When total times (Time Data Retrieval + Time Processing + Time Rendering) were recorded from database (dbo.ExecutionLog) the 2012 add-in sometimes took longer and sometimes took shorter. This is not a great indicator of report speed anyway as the numbers recorded were very inconsistent.

Also, I have successfully tested a rollback of the add-in from the 2012 version back to the 2008 R2 version and remember the web parts will need to be recreated and you will need to reconfigure Reporting Services Integration in Central Admin.

Upgrading the SSRS 2008 R2 Add-in to SSRS 2012 Add-In For SharePoint 2010

Download the Add-In from http://www.microsoft.com/en-us/download/details.aspx?id=29068

Note: For SharePoint 2010, you can use either the SQL Server 2012 or the SQL Server 2008 R2 versions of the Reporting Services add-in for SharePoint 2010 products. However, if you use the SQL Server 2012 SP1 version of the add-in, then you must also use a SQL Server 2012 SP1 report server.

The SSRS/SharePoint/Add-In Supported combinations:

Report server Add-in SharePoint version
SQL Server 2012 SP1 SQL Server 2012 SP1 SharePoint 2013
SQL Server 2012 SP1 SQL Server 2012 SP1 SharePoint 2010
SQL Server 2012 SQL Server 2012 SharePoint 2010
SQL Server 2008 R2 SQL Server 2012 SharePoint 2010
SQL Server 2008 SQL Server 2012 SharePoint 2010
SQL Server 2008 R2 SQL Server 2008 R2 SharePoint 2010
SQL Server 2008 SP2 SQL Server 2008 R2 SharePoint 2010

 

  1. Run rsSharePoint.msi on the SharePoint Integrated SSRS Server
  2. Click Yes to Upgrade the 2008 R2 Add-In (Installed with SP10 Prerequisites) to the 2012 Add-In
  3. image
  4. Click Next
  5. image
  6. Accept the license agreement. Click Next
  7. Click Install (If UAC pops up click Yes)
    1. My install took a little while (specifically on the “removing backup files” step)
  8. Click Finish when the install is complete
  9. image

Now try to run a report. You will get the following error:

An error has occurred during report processing. (rsProcessingAborted)

               Cannot impersonate user for data source ‘DataSource1’. (rsErrorImpersonatingUser)

This data source is configured to use Windows integrated security. Windows integrated security is either disabled for this report server or your report server is using Trusted Account mode. (rsWindowsIntegratedSecurityDisabled)

The error “Windows integrated security is either disabled..” tells you that you need to go back in Central Admin and reconfigure Reporting Services Integration.

  1. Go to Central Admin > General Application Settings > Reporting Services Integration and configure Windows Authentication. Click OK
  2. image
  3. After this is done the Report should run successfully
  4. Now, view a part page that contains the SQL Server Reporting Services Web Part.
  5. You will get the following error:

A Web Part or Web Form Control on this Page cannot be displayed or imported. The type Microsoft.ReportingServices.SharePoint.UI.WebParts.ReportViewerWebPart, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 could not be found or registered as safe.

The SSRS Add-In updates the web part from version 10.0.0.0 to 11.0.0.0 so you will have to delete and re-add the web part for it to display without this error.

Note: This Add-In is free to download and does NOT contain SSRS 2012. After installing this add-in you do have the following PowerShell commands available. DO NOT USE THEM!

These commands require both the add-in and SSRS 2012 to be installed before it will work correctly. Also, it appears that the install using the free download link versus running the install from a SQL 2012 CD create different folder/files/registry keys. The same still applies though..Using SSRS 2008 R2 with the 2012 Add-In (Installed using SQL 2012 installation media) I was actually able to create a SSRS Service Application, but it did not function.

The SSRS Add-In install from the free download link does not create any registry keys under SQL Server for “110” and it does not create anything more than a KeyFile folder in the C:\Program Files\Microsoft SQL Server\110 location. Using the SQL 2012 media to install the SharePoint Add-In it will create the registry keys and will create folders called KeyFile, License Terms, Setup Bootstrap, and Shared.

SharePoint 2013 – Requesting Apps using the App Catalog

After a SharePoint 2013 environment has been configured for Apps, by default the SharePoint Store is open for all farm administrators and anyone with Site Owner/Full Control access to a SharePoint site. If you are using non-default permission levels you need the “create subsites” and “manage web site” permissions to add an app for SharePoint. There is no way of keeping site owners from of browsing the SharePoint Store, but we can configure the environment so that they must request an app from the store and only specified administrators can approve these requests.

To suit this requirement Microsoft created the App Catalog. There can only be one app catalog site collection (Yes, it is its own site collection) per web application. The setting to keep site owners from downloading apps directly is set in Central Admin > Apps > Configure Store Settings. If there is no App Catalog setup you will receive the following error: “Sorry you need to create an app catalog site…” Hit back and go to Manage App Catalog. During the creation of the new App Catalog (With the familiar site collection creation screen) you will be asked to add a Primary Site Collection Admin and End Users. The Primary Site Collection Admin is your “App Gatekeeper” and the End Users are the site owners that you want to be able to see apps from the app catalog.

Once the App Catalog is all setup you can go back to the Configure Store Settings page and you should see the following options (The default for the first option is Yes, but I moved it to no so site owners cannot acquire apps directly):

clip_image002

Now, if a site owner goes to add an app for the SharePoint site they will be able to search the SharePoint Store, but when they click the App they will be presented with a Request It option instead of a Add It option (If the checkbox was marked as yes from the previous screenshot)

clip_image003 Vs. clip_image005

Once the site owner clicks Request It, they will need to specify licensing options (How many user licenses or is it for everyone) and an optional “request justification” field. Once the site owner submits the request, it will show up in the App Catalog’s “App Requests” List:

clip_image007

From here the App Catalog Admin(s) can approve or decline app requests. Once the status has been changed to Approved the App Catalog Admin will need to go to the SharePoint Store and acquire the app. This is done by clicking the link next to View App Details on the App Request entry:

clip_image009

Once this is done the site owner can check the “Your Requests” list and notice the status of their request. After the App has been acquired and approved the App will show up in the “Apps You Can Add” list.

clip_image011

SharePoint 2013 Claims Authentication – AD Group changes not reflected

One of the most noticeable differences between SharePoint 2010 and SharePoint 2013 is the default authentication method  is claims authentication, not classic. This is all fine and dandy until you go to add an AD group to a SharePoint site with a user in it. This user no longer needs access to the site so you go ahead and remove the user. You have the user test after lunch and they are still able to access the site. Your gut tells you to run a full User Profile Sync and then a Search Crawl and everything will be alright. After doing all that the user can still access the site…What the F David Blaine!?

When a domain user logs on to SharePoint, the server creates a token that contains information about that user  and any domain groups they are a member of. By default, SharePoint 2010 and SharePoint 2013 will cache this data for 24 hours, at which point the token will expire, and the next user logon will force a fresh token to be created. This is explained here: http://msdn.microsoft.com/en-us/library/aa543158(office.14).aspx

You can check the current values of the server’s token timeout with this command:

You should get the following back: <property value=”1440″ exist=”Yes”>

Now if you want to go and change this value here is a sample script to change the value to one hour (60 min):

This will fix the server-side and make SharePoint aware of a user being granted access through membership in AD, but if the user already obtained their claim earlier in the day they may still get access denied. These properties are WindowsTokenLifetime (Default is 10 hours) and LogonTokenCache (Default is 10 minutes).

Here is a PowerShell script to change the Token Lifetime to 2 minutes and Expiration to 1 minute. Only use forms if you are using FBA (DO NOT SET THE LIFETIME SHORTER THAN THE EXPIRATION WINDOW):

SharePoint 2013 Web Applications not creating successfully. Not deploying all files to the virtual directory

As I was working on a 2013 environment which had some migrated 2010 sites I noticed something interesting. The request to create a new web application would just time out. After a while (after staring at working on it… for a while) it would just say page cannot be displayed and when I tried to browse the new web application after creating a root site collection it would just give me page cannot be displayed. I tried browsing to _layouts/settings.aspx and got the error: “SharePoint Could not load file or assembly ‘Microsoft.SharePoint.ApplicationPages”

This got me thinking that something wasn’t deployed to the bin folder correctly so I checked the Virtual Folder and noticed that there was no bin folder (and many of the other folders were missing). I did some research and came across this: http://social.msdn.microsoft.com/Forums/sharepoint/en-US/2ff83934-d7d1-4419-9374-3cf7a0c34d7a/new-web-application-not-creating-correctly

This seems to be an issue with some environments that have been migrated from 2010 to 2013 and to fix the issue I had 2 options:

  1. Set the Central Admin App Pool Shutdown Limit to 400 temporarily
  2. Copy all contents from a working SharePoint site into this folder.

I chose to update the App Pool because the folders did not get permissions provisioned properly either (Everyone was not granted read access to the virtual directory). After making this change everything provisioned properly