Posts Tagged Migration

SharePoint 2013 Migration: User not able to access after migration from SharePoint 2010 to SharePoint 2013


We have migrated our sites from SharePoint 2010 to SharePoint 2013. After migration, users are not able to access newly migrated site. If we delete user and provide access again, user able to access site. (Fortunately, this was happening on test migration)


The missing link was warning that we overlooked. When we ran PowerShell Test-SPContentDatabase cmdlet, we missed following warning:

Category : Configuration

Error : False

UpgradeBlocking : False

Message : The [SharePoint2013] web application is configured with claims authentication mode however the content database you are trying to attach is intended to be used against a windows classic authentication mode.

Remedy : There is an inconsistency between the authentication mode of target web application and the source web application. Ensure that the authentication mode setting in upgraded web application is the same as what you had in previous SharePoint 2010 web application. Refer to the link for more information.

Locations :

In other words, SharePoint 2013 discourage classic mode authentication. If web application is created via Central Administration, claim based is the default and preferred method of authentication. If want to create web application with classic mode authentication, you need to use PowerShell cmdlets.

It goes like this:

  1. Create classic mode web application using PowerShell cmdlets
  2. Attach all content database with web application
  3. Convert classis mode web application to claim base authentication
  4. Configure Object cache

Create classic mode web application using PowerShell cmdlets

$ap = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication –DisableKerberos

New-SPWebApplication -Name “SharePoint – 2013” -ApplicationPool “SharePoint 2013 Web Apps” -ApplicationPoolAccount (Get-SPManagedAccount “domain\login”) -Port 80 -Url http://sharepoint2013 -AuthenticationMethod NTLM -AuthenticationProvider $ap -DatabaseName “WSS_Content_01”

Attach all content database with web application

Mount-SPContentDatabase “WSS_Content_2” -DatabaseServer “SQLDB2013” -WebApplication http://sharepoint2013

Convert classis mode web application to claim base authentication

Convert-SPWebApplication –Identity http://sharepoint2013 –To Claims -RetainPermissions –Force

Configure Object cache

$wa = Get-SPWebApplication -Identity http://sharepoint2013

$wa.Properties[“portalsuperuseraccount”] = “domain\login”

$wa.Properties[“portalsuperreaderaccount”] = “domain\login”


Make sure you enter user login using SharePoint 2013 claims encoding. It must be in this format “i:0#.w|contoso\chris” [For details, please visit] and don’t forget to restart IIS.

Leave a Comment

SharePoint: Workflows Implementation

In this article we have tried to explore implementation details of workflows in SharePoint 2007 and 2010. SharePoint provides us with three flavors of workflows, namely, Out Of the Box (OOTB), SharePoint Designer (SPD) and Visual Studio workflows. We will discuss implementation details of OOTB and SPD workflow w.r.t. to SharePoint 2007 (MOSS) and SharePoint 2010.

Out Of the Box Workflows: OOTB workflows are workflows which come with SharePoint server installation.

In MOSS, these workflows come in rigid form. You can’t customize them. The only option available is to create instance of OOTB workflows in different list or libraries and run them as they are. The instance details of OOTB workflows are stored in content database.

In SharePoint 2010, OOTB workflows are also termed as “Globally Reusable Workflows”. Other than “Three State workflow” which comes with SharePoint Foundations (free of cost), all other workflows comes with server or enterprise licenses. Great news is that these workflows can be customized using SPD 2010. The definition of OOTB workflows can be found using SPD 2010. Open site in SPD 2010 and select “All Files”. In the right pane, select “_catalogs” and then “wfpub”, you will be able to find OOTB workflows.

When you customize “Globally Reusable Workflow”, the definition of newly created workflow is stored in a list “workflows”.

SharePoint Designer Workflows: Workflows created using SPD are termed as SPD workflows. They are also called declarative workflows because they consist of Extensible Markup Language (XOML) rather than compile code as in the case of Visual Studio workflows.

In SPD 2007, we have only one type of workflow, namely, List workflow. In case of SPD 2010, we have three different types of workflows, namely, List, Reusable and Site workflows. When we create a new SPD workflow, a list “workflows” is created if don’t exist. Workflows list is not visible in SharePoint UI and can be accessed via SPD or SharePoint Object Model (OM). We can traverse workflows list using OM as under:

using (SPSite spSite = new SPSite(“Site_URL”))


SPWeb spWeb = spSite.OpenWeb();

SPList spList = spWeb.Lists[“workflows”];

foreach (SPListItem spListItem in spList.Items)





In case of SPD, open site in SPD and select “All Files”. In the right pane, select “workflows” and you will be able to find SPD workflows

Workflows list contains all the files related to a particular workflow. For each SPD workflow, three or four files are created depending upon the existence rules or conditions.

  • xoml – Contains all the activities included in the workflow in Extensible Application Markup Language (XAML) format
  • xoml.wfconfig.xml – Contains details of the list or site GUIDs and start configuration of the workflow
  • xsn or aspx – In MOSS, an aspx page is created for starting workflow. In SharePoint 2010, we have InfoPath form in place of aspx page
  • xoml.rules – Contains workflow rules if used

In the next post we will discuss the issues relating to migration of SPD workflows.

Comments (1)