We migrated our production site collections to our test server like this:

prdserver/dev ---> testserver/dev (will be the new dev, the prd/dev will be deleted)
prdserver/prd ---> testserver/prd (will be used as uat)

This was done with a Backup-SPSite and Restore-SPSite methods, with powershell.

I don't really know why, but the user names on the testserver/prd site collection look like i:0#.w|domain\username The other 3 sites have no issues. After some research, I found that this is due to different authentication settings, but as far as I understood, this can only be done on application, and not on site collection level. Can someone help me what did here go wrong and how to repair it? I wanted to move my scripts from dev to uat, but all my access mgmt scripts are failing, because the domain\userid text is not recognized as valid userid. I do not want to build an extra hook in all the scripts, if it can be resolved otherwise.
Looks like that my initial finding was not correct. Both migrated sites have claims authentication, but the difference in the user names only comes visible, when a new user is added to the site. Existing users still show up in domain/username format.


as you said, it is authentication configuration issue. Looks like in one farm you have classic authentication configured and other farm you have claims based authentication.

You cannot change the authentication on site level as it is Web application level configuration. I think you have to configured your dev/Uat with the same configuration as your production.

  • How is it then possible that on the testserver/dev I see normal user names, and on testserver/prd not? They are both on the same web application. – vilmarci Jun 1 '17 at 13:31
  • what you mean bu testserver/dev & /prod? are these two site collections in single webapplication called testserver? do you have user profile service configured? – Waqas Sarwar MVP Jun 1 '17 at 13:34
  • yes, they are two site collections under a single web application. User profile service is configured. – vilmarci Jun 1 '17 at 15:11
  • 1
    try to run the full sync of the user profile service and then check it. – Waqas Sarwar MVP Jun 1 '17 at 15:24
  • Full sync complete, no improvement. The two site collections show the usernames in two different formats. – vilmarci Jun 2 '17 at 9:14

As per my understanding, the Authentication migration involves steps as follow

  1. Convert your web application from classic to claims.
  2. Convert your users to support claims authentication. In this step, the script will convert user identities from domain\loginname to i:0#w|domain\loginname in site collection user information list.

I thinking running step 2 multiple time won`t harm to the existing users. This was tested on our stage farm during migration.

But you can try this on your test farm with below steps

  1. Create a test web application with classic authentication in the test server.
  2. Convert your application to claim authentication. steps here
  3. Restore your site collection which is in claims mode.
  4. Run the users' migration script.
  5. Verify your users using rest api call siteurl/_api/web/Lists/getByTitle('User Information List')/Items. All users should be with i:0#

This is very safe before you run this on Prod server.

You can refer below post for the additional answer.

migrate users for a site collection (not web app level)

  • All users should be with i:0# : But I don't want this. I would like the normal domain\username format, without the i:0#. – vilmarci Jun 1 '17 at 15:13
  • Can you run this query siteurl/_api/web/Lists/getByTitle('User Information List')/Items on one of site collection and see how users are stored. You will see in the same format after users migration – Venkat Konjeti Jun 1 '17 at 15:42
  • I get error 404 :( – vilmarci Jun 1 '17 at 16:02
  • Did you replace siteurl with your site collection url? – Venkat Konjeti Jun 1 '17 at 16:19
  • I queried the User Information List otherwise. The list shows the usernames in the i:0#|domain\userid format. – vilmarci Jun 2 '17 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.