Author Archive for Russell Wright



28
Feb
16

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.

image

Allen Wang had a good blog post on the issue:  http://blogs.msdn.com/b/allenwang/archive/2012/03/23/sharepoint-2010-health-analyser-timer-job-changed-custom-web-config-machine-key.aspx.  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. 

image

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

image

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>

image

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.

image

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. 

image

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.

image

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.

image

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.

image

 

References:

http://blogs.technet.com/b/sushrao/archive/2013/01/29/sharepoint-2013-machinekey-configuration-net-4-0-conflicting-with-web-config-configuration.aspx

http://blogs.msdn.com/b/mutaz/archive/2012/05/30/keep-your-own-machinekey-values-in-sharepoint-2010-web-config.aspx

https://technet.microsoft.com/en-us/library/gg982996.aspx

https://technet.microsoft.com/en-us/library/ee663484.aspx

http://thesharepointfarm.com/2014/02/what-is-the-sharepoint-configuration-cache/

Advertisements
10
Jan
16

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).

image

 

image

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

https://social.msdn.microsoft.com/Forums/sharepoint/en-US/47b874ac-abc4-47a6-b7b7-939edee8d8b2/error-on-site-actions-menu

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.

image

And voila’!  It works for me!

image

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.

31
Dec
15

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

$web.AllowUnsafeUpdates=$allowUnsafeUpdate

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

$retMsg

}

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.

27
Nov
15

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

Notes

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

image

27
Oct
15

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.

image

Making this change fixed our "forbidden" error. 

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

06
Mar
15

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?

image

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=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91″ />

image

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

image

Now, on to the next problem…

01
Mar
15

Visio Internal Error #3400 Action 2011

The dreaded “internal error!”  What to do?  What was I trying to do?  Simple.

I was attempting to connect a Visio diagram to a SharePoint list.  I’ve done it before a million times…but not in the last year or so.  Soooo….

I fire up Visio Premium 2010 and attempt to connect to a simple list in SharePoint 2013 and am met with the error:

Visio internal error: #3400 Action 2011:  Link Data to Shape

…or some such nonsense.  An then it proceeds to tell me to restart Visio or some such nonsense.  But I try it anyway, but it doesn’t help.

So I start Google-ing (or Bing-ing) and find others with the issue.  Some dribble about needing Premium vs. Professional, required data missing in SharePoint and other babble.  Nope, not even a restart of the old tried and trusted Windows 7 would change things.  So I tried my Windows 8.1 machine with Visio 2013.  Worked the first time.

I decided to “repair” my 2010 version of Visio, since I tend to have all sorts of mixes of version of stuff on my computer and repair Microsoft Office fairly regularly.  So, off to Programs and Features to find the Visio entry.  Fired up a repair and it asked me, fairly forcefully I may say, to finish by rebooting my computer.  So I did.

Long story short…I fired up Visio, made my connection to the same list I’d been using and BAM!  It worked like it was supposed to.

Now on to bigger and better things.

Keywords:

SharePoint Foundation, Visio repair, Fix found




Asif Rehmani’s SharePoint Videos

SharePoint-Videos

Click to access a wealth of SharePoint videos

SharePoint Rx

SharePoint Rx Home

Categories

Posts by Date

August 2019
M T W T F S S
« Jun    
 1234
567891011
12131415161718
19202122232425
262728293031  
Support Wikipedia
Advertisements