Archive Page 2


unable to cast object of type microsoft.sharepoint.webcontrols.splinkbutton

Been a long time since the last post…at least it feels like it.

Just finished troubleshooting an issue where a default page wouldn’t load.  The correlation ID pointed to an Unexpected error in the SharePoint ULS logs stating:

unable to cast object of type microsoft.sharepoint.webcontrols.splinkbutton

The site settings page would load (modifying the URL manually) as would View All Site Content.  However, clicking on any of the lists or libraries would throw the error.  We initially thought this was an issue with the default.aspx page getting corrupted, as we could create a new blank web part page in SPD, place it in the root of the web, and it would load up okay. 

What fixed this:  IISRESET!

Again, the same lesson learned, all over again.

SharePoint troubleshooting steps:

  2. Everything else

Web.config File Updating Automatically Every Night at 12:00 Midnight SharePoint 2013

We have a situation where we created a couple of SharePoint farms, QA and Production, that had some customized FBA implementations and implemented reversible encryption for the passwords.  Since the passwords are coming from a legacy system, we had to come up with a way to encrypt them and make them “decryptable” within SharePoint.  We were successful in doing this, but ended up having a couple of issues in production that would not allow users to log in.  Basically, their passwords were not being decrypted correctly.

This all begins in the <machineKey> section of the web.config.  The decryptionKey is used during the decryption process and, since this had to be supported across multiple machines, we made these sections the same across multiple machines and farms.  In fact, we had to use this on our legacy system so we could successfully encrypt and transfer the passwords from the AS400 (yes, mainframe).  This is what a <machineKey> section looks like.

<machineKey validationKey="8C3B5469A19FA84540F9B9E353679822934EF13EA0C26887B2AD4A6CA139BBBB" decryptionKey="634A6FD0D98D0A254D5E54F9D35287244C9DEB23A029BCAEA1C4FE21874C63AF" validation="HMACSHA256" />

When SharePoint is installed, it records some of the portions of the web.config file in the SharePoint configuration database.  These are located in the Objects table.


Allen Wang had a good blog post on the issue:  Here he identifies how to find the keys in the Objects table.  Here is a select statement with a part of the offending decryption key in the WHERE clause. 


This returns exactly one record.  Copy and paste it in something like Notepad++ so you can see it more easily.


Apply some XML formatting to more easily wade through the XML.  Here you’ll find m_ViewStateValidationKey and m_ViewStateDecryptionKey that correspond to the validationKey and decryptionKey in the <machine.config>


These were initially set when SharePoint was installed and, to my knowledge, there is not a “supported” way to change them in the config database.  Of course, any of us could change these in the database, but if you do make a good backup in case you need to put it back!

I can reason through why they do this.  Since the view state data is being encrypted/decrypted and there could be multiple WFEs, you certainly don’t want these values to be different across WFEs, lest your requests bounce across WFEs, as different values would yield different results, i.e. reading the view state would break.  That would be a mess.  So, they created a Health Analyzer rule to insure these values remain the same across WFEs.  Health Analyzer rules are viewed within the Monitoring section of SCA.


Here is the rule in the Health Analyzer.  Web.config files are not identical on all machines in the farm.  You can see I have already disabled this rule. 


I actually disabled this rule using the PowerShell command.  Here the rule name is ViewStateKeysAreOutOfSync. 

Add-PSSnapin microsoft.sharepoint.powershell
Get-SPHealthAnalysisRule ViewStateKeysAreOutOfSync | Disable-SPHealthAnalysisRule

Here you can see the relationship between the Name of the rule and the Summary of the rule from the PowerShell command, Get-SPHealthAnalysisRule ViewStateKeysAreOutOfSync.


Now, most of the solutions to this issue I’ve read employ PowerShell to disable this Health Analyzer rule, as shown previously.  However, you can also manage rules in the web interface.  The rules are in a SharePoint list, so simply click on the rule and edit it.


Here you can see there is another setting, Repair Automatically.  This is likely the culprit that is changing the web.config.  A Health Analyzer rule can be set to report the issue and/or attempt to repair the issue.  So, instead of disabling the rule completely, you can simply stop it from attempting to repair the issue.





An error has Occurred with the Data Fetch. Please refresh the page and retry.

An error has occurred with the data fetch.  Please refresh the page and retry.

I’ve seen this error multiple times with SharePoint 2013.  Seems like one time in the past it was related to some updates that needed to be installed on the server to fix the problem.  Most recently, I was working on one of our 2012 servers and this popped up again while attempting to access the site settings icon (you know, the "gear" icon).




I did some more searching and came upon a fix that worked for me.

In Sharepoint 2013 integrated SSRS 2012, on clicking on action in IE 10 some users were getting error:
an error has occurred with the data fetch. please refresh the page and retry.

On doing F12 we saw:
SCRIPT3: The system cannot find the path specified.
core.js, line 1 character 6957

On unchecking Tools => Internet options => Advanced => “Enable DOM storage” settings, it starts working.

  • Proposed as answer by SaurabhMathur Monday, August 31, 2015 4:05 AM

Monday, August 31, 2015 4:04 AM

So I gave it a try.  Go into Internet Options, select the Advanced tab and scroll down under Security and you’ll find "Enable DOM Storage."  Uncheck it.


And voila’!  It works for me!


Funny thing is, my Windows 7 machine has "Enable DOM Storage" checked, and it works fine.  So it must be something about the Windows Server and some update that is or is not installed.  I’ll update our server and see what happens next.


PowerShell to Add FBA User to SharePoint Group and EnsureUser

function global:Add-FBAMember([parameter(mandatory=$true)][string]$siteCollUrl, [parameter(mandatory=$true)][string]$fbaUser, [parameter(mandatory=$true)][string]$spGroup)


# Created by Russell Wright 2015-12-21

# Updated by Russell Wright 2015-12-31 Added AllowUnsafeUpdates

# Must have machine.config <membership>, <roleManager> and <connectionStrings> sections

Add-PSSnapin microsoft.sharepoint.powershell

$web = Get-SPWeb -identity $siteCollUrl

# Save the value of AllowUnsafeUpdates

$allowUnsafeUpdates = $web.AllowUnsafeUpdates

$web.AllowUnsafeUpdates = $true

# EnsureUser initializes the user in SharePoint

$user = $web.EnsureUser($fbaUser)

$getuser = Get-SPUser -Identity $user -Web $siteCollUrl

# Set-SPUser adds the user to the SharePoint group

Set-SPUser -Identity $user -Web $siteCollUrl -Group $spGroup


$retMsg = "Added user: " + $fbaUser + " to group " + $spGroup + " in " + $siteCollUrl



We needed a PowerShell Function to call from Winshuttle Workflow that would ensure the user was in SharePoint after a SQL load to the aspnetdb.  The trick appears to be using "AllowUnsafeUpdates," similar to what many others have posted with their C# code.  There were also some items noted in the config files where the machine.config required the FBA connection string in order for the PowerShell to work.


Winshuttle SharePoint Permissions

There are a fair amount of Winshuttle items that require SharePoint security of some sort, so I thought I’d start documenting them in tabular form as I run across them.

Winshuttle Function

SharePoint Security


View Winshuttle History

Override List Behaviors

11/27/15 – Error attempting to view Winshuttle history with only Read access, but form can be displayed.
4/23/18 – To view history or item in process list select Override List Behaviors and allow the three other associated permission levels to be selected.

View Winshuttle History

Process Originator

View Winshuttle History

Assignee of an assignment

Access all workflow items in a site

Users with Manage Lists permission level, given directly or via a group.

A user with Manage Lists permission level has access to all items in the list, regardless of who created them.

Access individual items in form workflow list

Item level security

The default settings for a Form Workflow list are for End Users to have access (read and edit) only to the items they create. The exception is a user who has the Manage Lists permission.  This is controlled by the SharePoint list Item-Level Permissions advanced setting.

Winshuttle Form Library web part

Site Collection Administrators or Site Owners can see all the items.

The Form Library shows all of the forms that you have created, including Running, Completed, Rejected, and Saved. Only forms you have created will be visible to you.

Winshuttle Form Library Task List web part

The Task List shows all of the tasks that are assigned to you and ready for you to complete.

Winshuttle Form Process List web part

The Process List shows all processes that you have created and are Running.

Bulk Reassignments

SP2013 – Group must have permission level that contains Override List Behaviors permission.  SP2010 – Group must have permission level that contains Manage Lists permission.

Configuration key BulkReassignmentPermissionSets must be set to contain the permission level(s) that have the appropriate permission.  For example, Full Control has this permission by default.

Delete Scripts in Central Site Collection Administrator Ref. Winshuttle documentation.
Last update 2018-06-18


Reference to the List Permissions permission levels



403 Forbidden Error on Custom FBA Login Page

We wrote a custom FBA login page and had it working in our QA system and were in the process of setting it up in our production system when we encountered a "403 Forbidden" error.  The page was written as a modification to the FBA pack on CodePlex and thus was located in the /15/template/layouts/FBA/OurCustomFolder directory.  After struggling with this for quite some time we finally realized we had set anonymous access on the site permissions in QA to "lists and libraries" (for another reason) and had not made that same change to production.


Making this change fixed our "forbidden" error. 

Interestingly, when using the out-of-the-box FBA login page, there was no issue.


RSViewerPage.aspx Controls not Rendering

Are you seeing something like this while attempting to render a report in SSRS in SharePoint 2013…or perhaps any version of SharePoint with integrated SSRS?


Try this.

Edit the web.config for the SharePoint site in which SSRS is installed.  C:\inetpub\wwwroot\wss\VirtualDirectories\Portal-80, for example.

In the web.config, find the <handlers> section within the <system.webServer> section and add the following:

<add name=”ReportViewerWebPart” verb=”*” path=”Reserved.ReportViewerWebPart.axd” type=”Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91″ />


Reload the page and voila’!  You’ll at least get some errors you can deal with.


Now, on to the next problem…

Asif Rehmani’s SharePoint Videos


Click to access a wealth of SharePoint videos

SharePoint Rx

SharePoint Rx Home


Posts by Date

June 2020
Support Wikipedia