Archive Page 2


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…


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.


SharePoint Foundation, Visio repair, Fix found


Updating a SharePoint List with Login Name, Email Address, Display Name and User ID with a 2010 Workflow

Here’s the situation.  You have an email address and you want to display the login name (domain\username), display name (Russell Wright) and perhaps the user ID from the SharePoint user list.  Here are the steps to accomplish with a SharePoint Designer 2010 workflow.

We start by creating a custom list and add the following fields.


The main field is Email PP (email people-picker) that we will populate with an email address.


Using the people-picker for an email address can be problematic if you have multiple user IDs with the same email address.


However, you should be able to select the correct one you want to use.


If you pick an email address that is related to a single AD account, you shouldn’t have this issue.


You’ll notice the workflow named Set Fields executed and populated several other fields.  See the Completed link under the Set Fields column?  This link will take you to the workflow history list.  Let’s see how this is done in the workflow.

We’ll start with a simple list workflow created on our custom list.  The start options are set as shown.


Begin by creating all the variables you’ll need.  We will create string variables for each attribute we are dealing with.


Using the action Set Workflow Variable, we’ll read the Email PP field and set a variable for each variation of the field we want to set in a text field.  In this example we create the variable named LoginName and set its type to string.


We then set its value to Email PP from the Current Item.  The important thing is to return the field as Login Name.


Repeat this process for each variant of the people-picker field you want.


As a matter of good practice, log the fields to the workflow history list so you have a record of what they look like.


This action will give you an entry in the workflow history that will display the values of your variables.


Now, on to the step to set the fields in the list, using Update List Item.


Insert an Update List Item action.


Here you can set each field to your variable values.


Here is an example of setting the LoginName Text field with the LoginName variable.


And the final result should display multiple attributes of the person in the people-picker field.



“The database principal owns a schema in the database, and cannot be dropped” Error Running the SharePoint Configuration Wizard

I was applying some CUs to SharePoint 2013 and running the configuration wizard was failing.  You may or may not know this, but the configuration wizard will write a log file to the SharePoint hive as well as an error log.  This error log is the one you want to look at.




In my case, I was receiving

The database principal owns a schema in the database, and cannot be dropped.  User, group, or role ‘SPDataAccess’ already exists in the current database.

When looking at the error log, it was apparent this had something to do with the SPDataAccess principal within the SP15_UsageAndHealth database. 

01/09/2015 15:39:43.99    OWSTIMER (0x359C)    0x2838    SharePoint Foundation Upgrade    SPUpgradeSession    ajxnm    INFO    SPUsageDatabase Name=SP15_UsageAndHealth    012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:43.99    OWSTIMER (0x359C)    0x2838    SharePoint Foundation Upgrade    SPUpgradeSession    ajxnm    ERROR    Upgrade [SPUsageDatabase Name=SP15_UsageAndHealth] failed.    012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:44.01    OWSTIMER (0x359C)    0x2838    SharePoint Foundation Upgrade    SPUpgradeSession    ajxnm    INFO    SPUsageDatabase Name=SP15_UsageAndHealth    012dde9c-16ee-b0ba-8634-adb34afb8eb1
01/09/2015 15:39:44.01    OWSTIMER (0x359C)    0x2838    SharePoint Foundation Upgrade    SPUpgradeSession    ajxnm    ERROR    Exception: The database principal owns a schema in the database, and cannot be dropped.  User, group, or role ‘SPDataAccess’ already exists in the current database.    012dde9c-16ee-b0ba-8634-adb34afb8eb1

SharePointgotchas ( gave me the hint I needed and Pinal Dave ( had some more details about this issue.

If you look at SQL Server Management Studio and navigate to the offending database, you can navigate to the Schemas node and investigate who owns each of the schemas by looking at each Schama’s properties.


In my case, the schema owner was set to SPDataAccess.  I’m not sure how it got this way, but upon further inspection, this was also true for SP15Farm and SP15MyAppPool.


For each of them, I set the schema owner to be the same as the schema name.


Now, running the configuration wizard was successful!  All is well in SharePoint land again.

Asif Rehmani’s SharePoint Videos


Click to access a wealth of SharePoint videos

SharePoint Rx

SharePoint Rx Home


Posts by Date

May 2019
« Jun    
Support Wikipedia