NOTE: UPDATED 1/8/2011
I wanted to follow-up on the previous post about migrating authentiation types in SharePoint 2010 that was done here: http://blogs.technet.com/b/speschka/archive/2010/06/12/migrating-a-web-application-from-windows-classic-to-windows-claims-in-sharepoint-2010.aspx. I still recommend taking a look at that posting if you haven't already because it includes some good background information about the migration process. Recently we've been tweaking with the set ot steps to migrate authentication types and having more success than previously so I wanted to share those steps. These may or may not become the final steps, but it's a pretty good start.
UPDATED INFO: Folks, one of the things we discovered is that at least one of the issues we were seeing post-migration can be solved if the account that is running the PowerShell commands described below is a) a local administrator on the server where the commands are being run and b) is added to a Full Control web app policy on the web application that is being migrated. The script below already created a Full Control web app policy so I've just updated it to indicate that the user running the script should be used.
So here are the steps:
$WebAppName = "http://yourWebAppUrl"
#THIS SHOULD BE THE ACCOUNT THAT IS RUNNING THIS SCRIPT, WHO SHOULD ALSO BE A LOCAL ADMIN$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName
Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default# this will prompt about migration, CLICK YES and continue
#This step will set the admin for the site $wa = get-SPWebApplication $WebAppName$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
#Once the user is added as admin, we need to set the policy so it can have the right access$zp = $wa.ZonePolicies("Default")$p = $zp.Add($account,"PSPolicy")$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")$p.PolicyRoleBindings.Add($fc)$wa.Update()
#Final step is to trigger the user migration process$wa = get-SPWebApplication $WebAppName$wa.MigrateUsers($true)
There are a couple of things that may still be a problem for you after doing this that you'll want to take care of or be aware of:
If you follow these steps and use these troubleshooting tips you should be good to go in most cases.
I'm having the issue you described in the item number 1. But I don't understand what you mean by "portalsuperuseraccount and portalsuperreaderaccount "
Same problem here - users can not log in, although they have permissions.
Could you please clarify, what you mean by configuring the "portalsuperuseraccount" and "portalsuperreaderaccount"?
Thanks in advance!
Souhil and Stephan:
By default there are two separate accounts (portalsuperuseraccount and portalsuperreaderaccount) that are used for caching and by default portalsuperuseraccount account is System Account and for the portalsuperreaderaccount it is NT Authority\Local Servicethese accounts will work for web application in classic mode but will not work for claims and might result in acess denied errors so thats what Steve meant i.e. to change it. Use the following command to change it (there is powershell equivalent also)
stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue accountname -url http://fqdn
stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue accountname -url http://fqdn
i have followed ur stsadm cmds , after applying this cmds and iis reset.
when i tried to login with windows authentication, i am UNABLE TO DO SO.i am not getting any prompt for entering AD CREDENTIALS.
and WHEN I SELECT THE FORMS AUTH. DROPDODOWN ITEM I was navigated to the defaiult Signin page and when i give the SUPERUSERREADERACOUNT name , i am getting the below error:
The user does not exist or is not unique.
Troubleshoot issues with Microsoft SharePoint Foundation.
Correlation ID: 75e66a48-6c32-4106-b990-733dbdb2e445
Date and Time: 11/25/2010 12:14:27 AM
Go back to site
pls help why i am unable to login to both windows and forms after migration from cassic mode to claims mode.
i have used custom mebmship provider and role provider and entered the entries in the auth provider s section in the CA -->FBA section.
I tried these commands but get access is denied when I run this command
Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
I made sure that I was an administrator on the server as well as dbo on the SQL tables.
Any ideas why It won't let me run the script?
When I try to execute the above:
# this will prompt about migration, CLICK YES and continue
Set-SPWebApplication : Operation is not valid due to the current state of the o
At line:1 char:21
+ Set-SPwebApplication <<<< $wa -AuthenticationProvider (New-SPAuthenticationP
rovider) -Zone Default
+ CategoryInfo : InvalidData: (Microsoft.Share...tWebApplication:
SPCmdletSetWebApplication) [Set-SPWebApplication], InvalidOperationExcepti
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletSetWebAp
How do I move beyond this error?
Were able to resolve the issue?
I am also facing same issue.
I was asked to investigate Claims implementation in our SharePoint 2010 environment. From above, seems like many issues, is this still the case?
Does anyone know if this is true? "Authentication enhancements in SharePoint 2013 make the use of claims-based authentication easier"
Hi. I was doing SP2013 upgrade so, I did the above commands for my SP2010 classic mode application to claims. It converted successfully but, when i do test-contentdatabse for migrating to SP2013, It says my existing application is still in classic. can you help me
I am also gertting access denied after migration toi Claim. I tried both stsadm command but no luck. Is anyone got success? Please share. Thanks!