Tag Archives: Migration

We were working for a client, they had many groups and we had to build a collaboration portal for all the groups. Key thing was few sites of some groups were already present in SharePoint 2010 in different standalone servers. Migration was a key thing here as the existing sites has huge data, and huge user base.

The Requirement was to build a portal /web application which will have migrated sites and new set of sites as per agreed site structure. According to the agreed architecture and design we created a new web application and started building the site hierarchy.

As part of this we followed the regular approach database detach –attach method and migrated the existing SharePoint 2010 site .Migration was successful and we were able to access the site with the system account. Later we tried with couple of site admin accounts, to our surprise we were getting “ACCESS DENIED” with any other user id.

Background:

By default when we create a web application in SharePoint 2013, it gets created with Claims authentication. When we migrate the content DB to 2013, it recognizes the user account only in this format i:0#.w|domainusername . Though it’s an AD account it no more recognizes the DomainUserName format.

SharePoint assumes all users to be claim users and renders them so. Therefore, a normal windows user – “DomainUserName” appears as “i:0#.w|DomainUserName”. Moreover, it uses the username in this same format to check for its permissions but does not find a matching entry for the user as the database has windows users – “DomainUserName”. So, the site will give you an access denied.

Note that the System Account will work since its “DomainUserName” is never used and System Account is a keyword used by SharePoint for the application pool identity. Therefore, it remains unaffected.

Solution:

In brief the share point 2010 site which needs to be migrated should be converted to claims format and then migrate it to 2013. But a word of caution , do not directly change the SP 2010 site to claims format in a production environment as it will not allow existing windows accounts to login and existing SharePoint 2010 site will be no more operational.

Below power shell script converts classic mode site to claims mode:

This script converts user accounts to claims format:

On executing the first script (to enable claims authentication) the SharePoint Content Database is made ready for claims based authentication but the already existing site users were windows users, are not “migrated” to be understood by claims authentication.

We use the second script to “migrate” the users. MigrateUser($true) will convert all user accounts to claims format. After running this script user accounts are converted in the database to claims format, therefore, user names are read correctly by SharePoint therefore, permissions for users are associated correctly by SharePoint hence the site permissions work correctly.

Note:

By any chance if you execute these scripts directly in productions, by executing$webapp.MigrateUsers($false) will not convert user accounts to windows mode, rather it will throw an exception. Make sure you have a temporary environment built where you execute the above scripts. Also note that these scripts are running on Web Applications so they will affect all site collections in that web application

This is a step by step guide on how you migrate your SharePoint’s (I used 2010 version in this instance) SQL Server to an new SQL Server host. In this exercise I tried migrating it in a new version of SQL server which is 2012 from 2008 R2, also had tried it in the same […]

This is a step by step guide on how you migrate your SharePoint’s (I used 2010 version in this instance) SQL Server to an new SQL Server host. In this exercise I tried migrating it in a new version of SQL server which is 2012 from 2008 R2, also had tried it in the same version. There are only 9 steps to perform this task but it takes into consideration you already have a new SQL Server provisioned.

Place it in the data folder of the SQL Server instance of the new host.

database files

5.Set up same user permissions on the new SQL server

best way to do this is when you use AD accounts is by scripting the users on the old server and running that script on the new server. If you are not using AD accounts then you will have issues with passwords so best way to do that is to follow this -> http://support.microsoft.com/kb/918992

6.Attach your databases to the new SQL Server

attach database

attach database

7. Verify what ports your New SQL is using

If it’s using a dynamic port change it to static. To do this go to SQL Server Configuration Manager and into theSQL Server Network Configuration Section choose the instance you will be using. Go to the TCP/IP section and if TCP Dynamic Ports are set to 0 (zero) then remove that and assign a static port into the TCP Port Section on all IP’s. For this sample we will be using 14330 <- notice I just added 0 at the end from the default port. Note that as we will need that on the next section also if you changed the port number from dynamic to static you will need to restart your SQL Server before it can take effect.

port allocation

8. Go to your SharePoint server and create your SQL Server Alias

If SQL Configuration Manager is installed just head over to the SQL Native Client 10.0 configuration then intoAliases. Create a new alias that points to your new SQL Server by right clicking on the Alias. You need to do this on both 32 and 64 bit instances.

alias configuration

On the Alias name put your old SQL Server IP or Name

On the Port the port you indicated on step 7, in this case 14330

Protocol should be TCP/IP

And on Server the new SQL Server IP or Name together with its instance name if there is any. In our case it’s SQL2012

alias configuration

If you don’t have SQL Configuration Manager in your SharePoint Server then run the CLICONFIG again on both 32 and 64 bit instances. For 32 bit go to run command and execute this “%SystemRoot%/SysWow64/CliConfg.exe” and for 64 just this “CLICONFG” all without quotes of course. Add the same info as above.

alias configuration

9.Start all your SharePoint services, now you have successfully migrated your database.

While working on SharePoint 2010 to SharePoint 2013 migration, a site collection with Business Intelligence on it had quite a lot of bugs after being upgraded to 2013.. One of the bugs I found is that in a PowerPivot Gallery, whenever you want to create a new PowerPivot Gallery Document, you get this instead:

powerpivot add new document

$Resources:PowerPivotFeatures,ReportGalleryDocumentDisplayName;

$Resources:PowerPivotFeatures,ReportGalleryDocumentDescription;

After investigating, I found out that you get the same message when you look at the PowerPivot Gallery Document content type.

Site Content Type Information

With the info we got in those screenshots it’s pretty clear that the problem is a resource file, but why? The problem is that Microsoft, decided to rename the resource file names between SharePoint 2010 and SharePoint 2013. If you go on SharePoint 2010 in “C:Program FilesCommon FilesMicrosoft sharedWeb Server Extensions14Resources ” You will see that all the PowerPivot resource files are named “PowerPivotFeatures.resx” + language. You can view this in the image below.

powerpivot resources file location

However, in SharePoint 2013, when we navigate to the resource folder “C:Program FilesCommon FilesMicrosoft sharedWeb Server Extensions15Resources” , we realize that Microsoft decided to change the name of the resource file to “PowerPivot_Features.resx” As you can see an underscore is now added to the name of the file as you can see in the picture below:

powerpivot features

Since we got our Site Collection from SharePoint 2010 to SharePoint 2013, everything still references the old resource file, which does not exist since you migrated. Unfortunately, Microsoft did not automatically fix this when you attach the Database, or when you run the “upgrade-spsite” command.

I fixed the problem by simply copying all the “PowerPivotFeatures.resx” files from SharePoint 2010 to SharePoint 2013. Since the filenames are different, you won’t have to override any SharePoint 2013 ones. So when you copy them all, your folder will look something like the screenshot below. Notice the SharePoint 2013 resource files in blue and the 2010 ones in Orange.

powerpivot features file-location

I would do this during off hours as you may need an IISReset in order for SharePoint to pick up the new resource files.