Thursday, October 8, 2015

How to restore site collection from higher Sharepoint version

How to restore site collection from higher Sharepoint version


Sometimes you may face with situation that bug is only reproducibly on production, but not e.g. on QA or on your local development environment. Such problems are much harder to troubleshoot. Often they are caused by the content which exist only on production.

And if troubleshooting directly on production is problematic (e.g. if you don’t have remote desktop access to it), you should get backup of site collection or whole content database, restore it on local dev env and try to reproduce bug here.

But what to do if you have lower Sharepoint version on you local environment, than on production? Of course it is better to have the same versions, but world is not ideal and sometimes we may face with such situation. In this post I will show the trick of how to restore site collection from the higher Sharepoint version.

Before to start I need to warn that this is actually a hack and you should not rely on it. There is no guarantee that it will work in your particular case, because new Sharepoint version may have different schema, incompatible with previous one (that’s why standard way is not allowed).

Ok, suppose that we have site collection backup, which is created with Backup-SPSite cmdlet:
Backup-SPSite http://example1.com -Path C:\Backup\example1.bak

We copied it on local environment and want to restore it with Restore-SPSite:
Restore-SPSite http://example2.com -Path C:\Backup\example1.bak –Confirm:$false

(Here I intentionally used different urls for source and target sites in order to show that it is possible to restore site collection to the different url). If we have lower Sharepoint version on the local environment we will get unclear nativehr exception, which won’t say anything. But if we will make our logging verbose and check Sharepoint logs, we will find the following error:

Could not deserialize site from C:\Backup\example1.bak. Microsoft.SharePoint.SPException: Schema version of backup 15.0.4505.1005 does not match current schema version 15.0.4420.1017.
(Exact version number is not important. For this post it is only important that source version 15.0.4505.1005 is higher than target version 15.0.4420.1017).

What to do in this case? Mount-SPContentDatabase also won’t work because of the same reason, i.e. content database backup also won’t work. In this case we can either update our environment (and you should consider this option as basic) or go by non-standard way.

For non-standard way we will need hex editor. At first I thought that site collection backup is regular .cab file, so it will be possible to uncompress it, edit text files inside it and compress back (I described this trick in this post:Retain object identity during export and import of subsites in Sharepoint into different site collection hierarchy location), 

but this is not the case with site collection backups made with mentioned cmdlets. They look like regular binary files. So we will need some hex editor for modifying it. I used HxD hexeditor, but you can use any other as well.

If we will open backup file in it and will try to find the version, which we got from error message from the log, we will find that it is located in the beginning of the file:

Please check below link for screenshot:



The good thing is that version is stored only once. So we will change source version to the target in the hex editor now:

Please check below link for screenshot:



Now save it and run Restore-SPSite again. This time restore should work. Hope that this trick will help someone. But remember that it is hack and use it carefully.


How to resolve a slow People Picker in SharePoint Foundation 2010

People Picker slowed down from instant results to around 20-30 seconds. This made searching for users a nuisance, especially during live meetings. 

In our case, I believe that the issue was due to an old domain being turned down and SharePoint still attempting to resolve it.

The steps below were performed using the STSADM.exe console which was stored on the SharePoint server hosting the web application. It can be located at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe

 Run the following command:
STSADM.exe -o setapppassword -password key

And then the command:
STSADM.exe -o setproperty -propertyname peoplepicker-searchadforests -propertyvalue "Domain:yourdomain.com" -url https://yourwebapplication.com

This should result in "Operation completed successfully" and if you test, search results should be instant again. If you have multiple domains, you can add them to the previous command using commas. Example:
 STSADM.exe -o setproperty -propertyname peoplepicker-searchadforests -propertyvalue "Domain:yourdomain.com,Domain:yourseconddomain.com" -url https://yourwebapplication.com

Hopefully this helps you!

Google+ Followers