SharePoint: Users cannot create new subsites

July 13, 2015 - 17:02, by Steven Van de Craen - 0 Comments


First day after my vacation and I got presented with a nice situation at one of our clients. Most users trying to create new subsites would get “Sorry, this site hasn’t been shared with you” and the site would NOT get created. Troubleshooting this showed that during site provisioning the “SiteFeed” Feature would throw an exception which would roll back the site creation. The relevant lines in the ULS logs pointed towards the “Following” (Social) of the newly created site:

FollowedContent.FollowItem:Exception:Microsoft.Office.Server.UserProfiles.FollowedContentException: ItemDoesNotExist : Item does not exist.     at Microsoft.Office.Server.UserProfiles.SPS2SAppUtility.GetPersonalUrl(UserProfile& profile)     at Microsoft.Office.Server.UserProfiles.SPS2SAppExecutionContext.InitializeForProfile()     at Microsoft.Office.Server.UserProfiles.SPS2SAppExecutionContext.EnsureInitialized()     at Microsoft.Office.Server.UserProfiles.FollowedContent.FollowItem(FollowedItem item, Boolean isInternal)

Could not follow the url https://sharepoint/newsub

Leaving Monitored Scope (Event Receiver (Microsoft.Office.Server.UserProfiles, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c, Microsoft.Office.Server.UserProfiles.ContentFollowingWebEventReceiver)).


The newly created site could not be added to the user’s Social list on his MySite due to an Access Denied on adding the item to the list.


The MySites were recently migrated from SharePoint 2010 (classic mode) to SharePoint 2013 (claims mode). MySites work by setting the ‘owner’ as Primary Site Collection Administrator, but the conversion to claims had erased all the classic-mode Site Collection Administrators from the migrated site collections. Querying for the Site Collection Administrators would just return empty which is of course not good.

(Blank) Site Collection Administrators


I whipped up a PowerShell script that would loop all MySites and report any sites with missing or non-matching Site Collection Administrator. Toggling the ‘report only’ flag in the script will correct the situation.

asnp Microsoft.SharePoint.PowerShell -ea 0 | Out-Null cls $reportOnly = $false Write-Host "ReportOnly:" $reportOnly $mySites = Get-SPSite -Limit ALL | ? { $_.RootWeb.WebTemplate -eq "SPSPERS" } Write-Host "Found" ($mySites.Count) "MySites" $mySites | % { $s = $_ $w = $s.RootWeb $owner = $w.EnsureUser($w.Title) $primaryAdmin = $w.SiteAdministrators | Select -First 1 if ($primaryAdmin -eq $null) { Write-Host -ForegroundColor Red ($s.ServerRelativeUrl) ": no primary SC admin. Owner should be" $owner if ($reportOnly -eq $false) { $owner.IsSiteAdmin = $true $owner.Update() } } elseif ($owner.IsSiteAdmin -eq $false) { Write-Host -ForegroundColor Yellow ($s.ServerRelativeUrl) ": primary SC admin (" $primaryAdmin ") does NOT match owner (" $owner ")" if ($reportOnly -eq $false) { $owner.IsSiteAdmin = $true $owner.Update() } } else { Write-Host -ForegroundColor Green ($s.ServerRelativeUrl) ": primary SC admin (" $primaryAdmin ") matches owner (" $owner ")" } $s.Close() }

After correcting all sites should turn up green.

 All MySites corrected


Calling web services in Nintex Workflow and different authentication mechanisms

September 12, 2014 - 20:40, by Steven Van de Craen - 9 Comments

With the rise of claims based authentication in SharePoint we’ve faced new challenges in how to interact with web services hosted on those environments. Claims based authentication allows many different scenario’s with a mixture of Windows, Forms and SAML Authentication.


When you’re working with Nintex Workflow you’re faced with authentication in Actions such as “Call Web Service” or “Web Request”.

If you’re just using Windows Authentication (NTLM, Kerberos, Basic) on your site then Nintex will handle that authentication just fine for you and use the credentials you specified (manually entered or stored credentials).


However you might have to deal with different or multiple authentication mechanisms such as Forms Based Authentication, ADFS or a combination. In such cases you’ll get a 403 FORBIDDEN regardless of the credentials you enter.


Overcoming this hurdle can be challenging.

  1. Use a different URL zone (with windows authentication) to make the call
  2. Pass an authentication cookie along with the request

Use a different URL zone (with windows authentication) to make the call

Nintex Actions execute on the server, not on your -already authenticated- client. The connection information you’ve entered (URL, username, password) is used to construct a connection and execute the operation. Since the Action executes locally on the server it can make use of a different URL to do the call. It is a best practice/requirement to have the Default Zone of your Web Application configured with -just- Windows Authentication in order to get things like Search to work properly. Why not make use of this and use that URL in your Actions?


Define a set of credentials that can be used in “Call web service” or “Web Request” Actions and have it execute against the URL that has Windows Authentication. If this option is available to you it probably is the preferred way of working.

Pass an authentication cookie along with the request

If the above is no option for you things get trickier and “specific”, meaning it is specific to a certain scenario but might not be possible for yours.

In MY case I have a SharePoint 2013 on-prem environment with “mixed” authentication (Windows and Forms Based). SharePoint issues a FedAuth cookie when the user successfully authenticates. If you send this cookie along with the web request it will work just fine. Note that the “Call web service” action does NOT allow you to specify additional headers so the “Web Request” Action becomes your new best friend here.

Using the “Web Request” Actions allows for much more flexibility, but you’ll have to build the request message yourself. I our case that means the SOAP message.


Once you have all of that in place the “Web Request” will happily call out to the web service. See it here working with the FedAuth cookie I “borrowed”.


Getting the FedAuth cookie

The base premise is that you need to ‘replay’ the authentication mechanism in code to get the FedAuth cookie. Once you have this you can send it along with future requests from Nintex Workflow. Again this is really specific to my case and may not be possible for you because of additional security or complex authentication schemes.

For my SharePoint 2013 on-prem environment with “mixed” authentication (Windows and Forms Based) I force the call to do Windows Authentication:

public static class AuthHelper
    public static Cookie GetFedAuthCookie(Uri uri, ICredentials credentials)
        Cookie result = null;

        // Emulate the authentication via a request to the /_windows/default.aspx page using the provided credentials
        HttpWebRequest request = WebRequest.Create(uri.GetLeftPart(UriPartial.Authority) + "/_windows/default.aspx?ReturnUrl=%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252FDefault%252Easpx&Source=%2FDefault.aspx") as HttpWebRequest;
        request.Credentials = credentials ?? CredentialCache.DefaultNetworkCredentials;
        request.Method = "GET";
        request.CookieContainer = new CookieContainer();
        request.AllowAutoRedirect = false;

        // Execute the HTTP request 
        HttpWebResponse response = request.GetResponse() as HttpWebResponse;
        if (null != response)
            result = response.Cookies["FedAuth"];

        return result;

I actually made this available as a Web Service so that it can be called from with a Nintex Workflow.

public class AuthService : IAuthService
    public string GetFedAuthCookie(string requestUrl, string userName, string password)
        string result = null;

            NetworkCredential credential = !String.IsNullOrEmpty(userName) ? new NetworkCredential(userName, password) : null;
            Cookie cookie = AuthHelper.GetFedAuthCookie(new Uri(requestUrl), credential);

            if (cookie != null)
                result = cookie.Value;
        catch (Exception ex)
            result = null;

        return result;

And now I can call my Authentication service prior to the other services.


Door #3

It feels like it must be possible to use access tokens that can be passed along similar to the FedAuth cookie. Considering this is how the App model works in SharePoint 2013, there has to be a way to leverage this for what we’re trying to accomplish. But that’s for another post.

SharePoint 2013: CreatePersonalSite fail when user license mapping incorrectly configured

May 5, 2014 - 13:49, by Steven Van de Craen - 0 Comments

Last week I was troubleshooting a farm with ADFS where MySite creation failed. The ULS logs indicated that the user was not licensed to have a MySite.

04/29/2014 17:34:10.15 w3wp.exe (WS12-WFE1:0x031C) 0x1790 SharePoint Portal Server Personal Site Instantiation af1lc High Skipping creation of personal site from MySitePersonalSiteUpgradeOnNavigationWebPart::CreatePersonalSite() because one or more of the creation criteria has not been met. [SPWeb Url=|adfs|]|adfs|]Self-Service Site Creation == True Can Create Personal Site == False Is user licensed == False Storage&Social UPA Permission == True Site or Page or Web Part is in design mode == False c0048c9c-234d-700b-502b-52356264cbda

As it turns out, this message was correct, since User License Management had been enabled recently by a colleague of mine, while preparing to roll out Office Web Apps to a subset of users.

It seems that if you enable the licensing functionality in SharePoint 2013, you need to have a license mapping for the “Standard” license in order to have MySite functionality.


I quickly came up with the following script that would add “all authenticated users” to the “Standard” license.

$claimString = "c:0(.s|True"
$cpm = [Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager]::Local
$claim = $cpm.DecodeClaim($claimString)
$lmap = New-SPUserLicenseMapping -Claim $claim -License Standard 
$lmap | Add-SPUserLicenseMapping

This adds a mapping as can be seen in the following screen (number #3 is the one relating to the above script)


A big note on this: make sure to have the correct casing! At first I used “c:0(.s|true” but since its value type is String this fails to match.

Claim Spy

If you want to get a quick overview of claims for a user you can drop a page in the layouts-folder called claimspy.aspx (body: see below) and have a user navigate to /_layouts/claimspy.aspx. It just outputs all known claims for the current token. Feel free to improve the page and do proper deployment through solution packages and such Winking smile

<%@ Page Language="C#" %>
<%@ Assembly Name="Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" %>
<%@ Import Namespace="Microsoft.IdentityModel.Claims" %>

<script type="text/C#" runat="server">
    protected override void OnLoad(EventArgs e)
            IClaimsIdentity identity = (IClaimsIdentity)Context.User.Identity;

            if (null != identity)
                repeater1.DataSource = identity.Claims;
        catch (Exception ex)

                <asp:Repeater ID="repeater1" runat="server">
                            <td><nobr><%# Eval("Issuer") %></nobr></td>
                            <td><nobr><%# Eval("OriginalIssuer") %></nobr></td>
                            <td><nobr><%# Eval("ClaimType") %></nobr></td>
                            <td><nobr><%# Eval("Subject") %></nobr></td>
                            <td><nobr><%# Eval("Value") %></nobr></td>
                            <td><nobr><%# Eval("ValueType") %></nobr></td>


Win Auto SignIn

May 13, 2013 - 13:32, by Steven Van de Craen - 0 Comments

Claims based authentication in SharePoint 2010 and SharePoint 2013 works with a FedAuth token that can be kept on the local machine for a configurable amount of time. This leads to an effective Single Sign On even between client reboots, as long as the cookie and the token aren't expired yet. The SSO experience also works for Microsoft Office and Explorer View, so the user can transparently open and edit documents and workbooks from the SharePoint environment.

When configuring the Web Application with only Windows Authentication, the FedAuth cookie isn't written and the Windows handshake will need to redone when the browser is closed or when opening documents from Office applications. If the client cannot automatically authenticate the Windows user, it will present a credential prompt which may be undesired.

The Win Auto SignIn component is a sign in page for a Claims Authentication Web Application that automatically redirects all requests to do Windows (NTLM, Kerberos, BASIC) sign in for SharePoint 2010 and SharePoint 2013. It has the benefit that it will generate a FedAuth cookie for the Windows user as well.

Once you have the dual authentication (Windows and FBA) and custom sign in page configured, your users will automatically be redirected to use Windows authentication for the SharePoint Web Application, but with the benefit of having a FedAuth cookie.


SharePoint Saturday Belgium 2013 - Claims for developers

May 4, 2013 - 08:02, by Steven Van de Craen - 0 Comments


Last Saturday I delivered a session on “Claims for developers” at the 3rd Belgian SharePoint Saturday edition, focusing on Claims Based Authentication. It was great to see that there was a lot of interest in this topic, since it’s something that allows you to do some very cool things.

It was a really fun event and I am really proud to have been part of it! Kudos to the BIWUG people for doing all the hard work organizing this.



I promised to share my slides and the code I demoed, so here it is.


Claims for devs - SPSBE - Steven Van de Craen


Here’s the code package with the following:

  • Role Claims Provider – copies incoming “role” claims that aren’t mapped (augmentation), resolves a list of known claims (received from a web request) to the Entity Picker
  • FBA Login Page – additional functionality such as Reset Password (with Captcha)
  • Windows Login Page – when configuring dual auth on a Zone, use this page to force users to Windows Authentication
  • SAML Login Page – custom redirection to the STS so we can use a generic realm for our STS registration in SharePoint
  • SAML Logged In Page – Debug overview of claims for current user, can be used for updating SPUser
  • STS – Security Token Service with username/password, Facebook and Twitter login. Normalizes the user and provides custom claims. Contains custom redirection logic for SharePoint (generic realm)
  • SampleApp – Sample application configured for authentication delegation to the STS. Displays all claims in the token.

I can’t share the code for the Profile Manager (DB UI) due to copyright.

The package also contains some basic deployment steps.

Disclaimer: all code can be freely used and modified as desired, but I don’t take any responsability for bad things that might occur should you do so Winking smile

SharePoint and Claims: Map Network Drive issue

February 6, 2013 - 13:42, by Steven Van de Craen - 2 Comments


If a SharePoint Web Application is configured with Claims Authentication, you might run into an issue when trying to map SharePoint as a network drive.

Map Network Drive

If you only have Windows Authentication configured on the Zone…


…you’ll be either automatically signed in or get a credential prompt and you’ll see the SharePoint content just fine.

SharePoint content

But if you’re offering multiple authentication types on a single zone…


Sign In

…you might get a nasty error.

Access Denied

The mapped network drive could not be created because the following error has occurred:

Access Denied. Before opening files in this location, you must first add the web site to your trusted sites list, browse to the web site, and select the option to login automatically.


If this is the case, it probably is because you’re not getting logged in automatically using the Windows Authentication option.

You can test this fairly easy by going to the URL you’re trying to map in Internet Explorer. If you get there without having to choose the authentication type, you’ll be fine for your Network Mapping.

Now if you close that browser and redo this and you have to select the authentication type *again*, it probably means your SharePoint environment is configured to use session cookies rather than persistent cookies.

PS C:\> $sts = Get-SPSecurityTokenServiceConfig
PS C:\> $sts.UseSessionCookies

Once you change this to use persistent cookies, you can close the browser and it will remember you as long as the cookie is valid.

PS C:\> $sts = Get-SPSecurityTokenServiceConfig
PS C:\> $sts.UseSessionCookies = $false
PS C:\> $sts.Update()
PS C:\> iisreset

Back to the issue

Once you have persistent cookies in place, you must first create it using the browser. This is required because the Network Mapping dialog doesn’t allow you to pick the authentication type. So go ahead and log in to your SharePoint site using your browser.

Now you can go create a Network Mapping and it will work as long as the cookie is present and valid.

If the cookie is removed and you reboot, you’ll get an error again.

Restoring Network Connections

An error occurred while reconnecting Z: to http://intranet.******.com/Shared Documents
Web Client Network: Access Denied. Before opening files in this location, you must first add the web site to your trusted sites list, browse to the web site, and select the option to login automatically.

This connection has not been restored.

To get it working again you just have to log in into the site with your browser to create the cookie. This will make the network mapping work again.

Hope this helps!

External User Management

September 30, 2011 - 16:31, by Steven Van de Craen - 2 Comments

This project is further maintained at the Ventigrate Codeplex Repository (
Please go there to get the latest news or for any questions regarding this topic.
Page was cross-posted to this blog on 09/30/2011.

External User Management

The External User Management solution allows for easy management of users and groups for a SharePoint 2010 environment configured for Forms Based Authentication (FBA), handled by Claims Based Authentication (CBA). It contains management pages for Site Collection Administrators to:

User Management tasks

  • Add users
  • Edit a user (edit details, password or role membership)
  • Unlock a user
  • Delete a user

Role Management tasks

  • Add a role
  • Delete a role


Log4Net is a highly flexible and configurable logging mechanism and is used by this solution. It is included in the Deployment Package and can be installed as a SharePoint Solution Package (.wsp) using STSADM or PowerShell:

STSADM -o addsolution -filename Log4Net.v1.2.10.wsp
STSADM -o deploysolution -name Log4Net.v1.2.10.wsp -allowgacdeployment -immediate



Add and deploy the SharePoint Solution Package (.wsp) using STSADM or PowerShell:

STSADM -o addsolution -filename Ventigrate.Shared.ExternalMembership.wsp
STSADM -o deploysolution -name Ventigrate.Shared.ExternalMembership.wsp -allowgacdeployment -immediate

Add an internal Alternate Access Mapping "http://extranet" for the Zone on the WebApplication that has the Membership and Role Provider (Claims) configured in it's web.config. This is the key to getting the administration pages to connect to the correct provider.

Activate the Site Collection Feature to make a link to the management pages appear in Site Collection Administration.


Q. Will this solution work on SharePoint 2007 ?
A. No, there are certain features that make it work only in SharePoint 2010. But there are similar projects for doing FBA User Management in SharePoint 2007 on CodePlex (CKS

Q. I don't use a Role Provider or my Membership Provider doesn't allow certain tasks such as Password Change. Can I use this ?
A. It will probably throw some issues since this code wasn't really designed to capture any possible Membership or Role Provider configuration. Feel free to provide improvements through the Discussion Boards

Q. Will the Advanced Computed Field still work if I migrate from SharePoint 2007 to SharePoint 2010 ?
A. Definitely, but you'll need to upgrade the SharePoint 2007 solution package to the SharePoint 2010 version. Either retract and delete the SharePoint 2007 package prior to deploying the SharePoint 2010 package, or do an upgrade to the new solution. Make sure to IISRESET afterwards !

Q. Other questions ?
A. No problem. Ask them in the Discussion Boards

SharePoint Policy For Web Application: Account operates as System

February 12, 2011 - 10:58, by Steven Van de Craen - 4 Comments

Both in SharePoint 2007 and SharePoint 2010 policies can be defined where you grant or deny permissions to specific users on Web Application level. This overrules any permissions the user may or may not have on a Site Collection, Site, List or Item level.

User Policy

For example: the Search Crawl Account (Content Access Account) will be given Full Read on all Web Applications to ensure all content is indexed.

In this section you have the option to check “Account operates as System”. This effectively hides the real user name and masks it as “System Account”.

Created by System Account

Only for Windows Accounts

During experiments with Forms Based Authentication (in SharePoint 2010 through Claims Based Authentication), I found that while it is possible to give policy permissions to a non-Windows User, it is not possible to make it “operate as System”.

The SharePoint Logs confirmed that the underlying mechanism is really looking at Windows User Account Management to perform the lookup:

System.ComponentModel.Win32Exception: i:0#.f|fbamembershipprovider|demouser1    at Microsoft.SharePoint.Win32.SPAdvApi32.LookupAccountName(String strAccountName, String& strDomainName, SID_NAME_USE& sidUse)     at Microsoft.SharePoint.Administration.SPPolicy.set_IsSystemUser(Boolean value)