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 -Path C:\Backup\example1.bak

We copied it on local environment and want to restore it with Restore-SPSite:
Restore-SPSite -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 "" -url

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 "," -url

Hopefully this helps you!

Friday, August 14, 2015

Missing Site Pages and Site Assets libraries in SharePoint 2010

Ever wonder why sometimes when you create a site in SharePoint 2010, 
the Site Pages and Site Assets libraries are not created, yet other times,
 they are?

The answer lies in a feature called Wiki Page Home Page,
 which is enabled by default for Team Sites in SharePoint 2010.
 However, other types of site templates may not activate that feature by default, 
and if that’s the case, those libraries won’t be there.

If you need them, you have a few options:

Activate the “Wiki Page Home Page” feature. The feature will create 
those libraries and will also create a wiki page and set it as the 
home (welcome) page for your site.
If you only need the libraries and don’t want your home page changed,
 you can have SharePoint Designer 2010 create the libraries for you:
Open SharePoint Designer.
In the “Site Objects” pane on the left, click “Site Pages.” SP Designer
 will load the contents of the Site Pages library and tell you it’s empty.
 However, it also creates the Site Pages library for you in the process.
Do the same thing for “Site Assets” (also in the Site Objects pane).
If you have code that depends on the existence of these libraries 
(such as a feature receiver), you can use two methods on the SPListCollection 

class to ensure the libraries are there:

Tuesday, June 2, 2015

SharePoint 2013 Online App Development using 'Napa’

SharePoint 2013 Online App Development
Table of Contents
·         Apps
·         Developer Site Settings
·         ‘Napa’ Office 365 Development Tools
·         Using Napa Office 365 Development Tools
Apps are new type of solution that helps to extend Microsoft Office 2013 product features to fulfill business demands. The new Office solution type Apps for Office are built on web technologies like HTML, CSS, JavaScript, REST, etc. The Office Apps solutions will be supported in Microsoft Excel Web App, Microsoft Outlook 2013, Microsoft Outlook Web App, Microsoft Project Professional 2013, Microsoft Word 2013, Microsoft Excel 2013, Microsoft SharePoint 2013 and Microsoft Exchange 2013.
An App for Office is essentially a webpage that is hosted inside an Office client/web application. You can use Apps to extend the functionality of a document, email message, meeting request, or appointment. Apps can run in multiple environments and clients, including Office desktop clients, Office Web Apps, mobile browsers, and also on-premises and in the cloud.
The following is the SharePoint Administration Center control for managing Apps in Microsoft Office 365 – SharePoint 2013 Online.
Apps Building Blocks
The basic components of an App for Office are XML manifest file and webpage. The manifest defines configuration, settings and points to the webpage that implements the App UI and custom business logic.
App Types and Extensibility
App is classified as four main categories and each category of app will support its corresponding Office products.
·         App for SharePoint
·         Task pane App for Office
·         Content App for Excel
·         Mail App for Office
App for SharePoint
SharePoint 2013 presents a Cloud App Model that facilitates you to create apps. Apps for SharePoint are self-contained sections of functionalities using standards-based technologies such as HTML5, JavaScript, and OAuth that extend the capabilities of a SharePoint website.
Apps have a light imprint because they don't actually install on the host server, and that means they don't overload a SharePoint site with unnecessary API calls.
Cloud App Model offers users to discover and download apps from the SharePoint Store or from their organization's private App Catalog and install them on their SharePoint sites.
‘Napa’ Office 365 Development Tools
For creating Apps for Microsoft Office 2013, as we all know now Apps contain manifest XML and webpage file. To do this, we can use any tool which can help us to save the file in text format. But to simplify the development process, Microsoft has given full support in Visual Studio 2012 by using its project templates, development environment, and debugging tools. Apart from Visual Studio 2012, this time Microsoft has come up with new web based development tool called "Napa" Office 365 Development Tools.
Here we’re going to focus on "Napa" Office 365 Development Tools in detail. We will see how to create, manage and deployments are supported in the Napa Office 365 Development Tools.
To get started with Apps development for the Office 365 – SharePoint 2013, login to the Office 365. After successful login, the next page will be Office 365 admin center; in the same page you can find the developer site navigation where you get Napa development tools.
Another option is navigate to the SharePoint 2013 administration center and under the site collection list, you can find the developer site collection URL.
The following screen capture image will help you to navigate to the SharePoint Administrator center.
Once you navigated to the SharePoint Administrator Center, you see the developer site collection. Login to the developer site collection and you can see the navigation for the Napa tool download.
The following is the navigation for the Napa tool download available in the home page of the developer site.
Then you will be navigated to the Office apps store download site of the download.
Following is the step by step process of installing the Napa development tool to your environment.
This will be added to the trusted list of service in the browser (preferably Microsoft Internet Explorer 9 or later version)
License of the office app will be managed under the login in which we have downloaded.
Image Title Name
App Part
What is an App Part? It is a type of Web Part that is represented by the ClientWebPart class. In a way by which an App for SharePoint 2013 can be appeared is through an App part. App Part, now in some of your minds will raise a question - is this replacement for WebPart? If not, what is the difference over WebPart and does it comes with any advantages.
Here it is App Part, not replacement for WebPart. An App Part is essentially a wrapper for an IFrame that would host a page of the App. In addition to acting as a Wrapper, like a WebPart, an App part can have custom properties that users can set in a tool part.
·         ClientWebPart.aspx - In a SharePoint Hosted App, this will act as your App Part Interface.
·         Default.aspx - is the start page for the App. This will provide the full page App experience, which will be the landing page after the deployment of the App.
·         App.css – This will contain the default styling and based on the requirement, we can use the same CSS file to add any custom styles.
·         App.js – In this JavaScript file, it contains the required JavaScript and has few lines of pre-generated code to start your SharePoint App development.
Using ‘Napa’ Office 365 Development Tools
Once after installing the Napa development tool in your development environment, go to the developer site and under the site content section, you find the installed apps.
We can manage permission levels and license management for Napa app as well as all apps installed in the site.
Now let’s take a look at a simple example for how to create an app to show from Office 365 – SharePoint 2013 pages. Let’s start exploring the App development using Napa and in the later part of this chapter, we will see more logical examples.
Click on the Napa and the following page will appear for selecting the name for the app.
The following is the default project generated using Napa, which is powered by Visual Studio 2012.
By default, App solution is generated with four folders and each folder contains related app files. First the content folder which contains the App.css file, Images folder contains the Appicon.png file, Pages folder contains theClientWebPart.aspx and Default.aspx and Scripts folder contains the Apps.js file.
Apart from the default files, as per the development needs, we can add new files to our App development. Right click on the folder under which you need to add file. The support files to add to our existing solution are JavaScript file, Style Sheet and SharePoint Web page.
App properties can be defined in the properties windows, where you can define the name, permission, access and remote endpoints.

Wednesday, April 8, 2015

SharePoint error-The password supplied with the username was not correct.

Few days back when I am trying to create a web application in SharePoint 2010 I got the below error. The error message is:

The password supplied with the username was not correct. Verify that it was entered correctly and try again.

Also you can check out my previous posts on:

Attach event receiver to list in SharePoint 2010

New master pages in SharePoint 2013

File Not Found error in SharePoint 2010

After getting the above errot, I remembered I have changed my password recently. So now we need to update the password also.

For this Open the command prompt. Then navigate to
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN and then type stsadm -o updatefarmcredentials -userlogin <domainusername> -password <newpassword>

Click on enter

It will give you message as "Operation completed successfully." if successfully executed as shown in the figure below.

In the next step do an IISRESET and then try creating web application, it will work fine.

Tuesday, April 7, 2015

SharePoint 2010 to SharePoint 2013 Migration Step by Step

Migrate SharePoint 2010 to 2013

SharePoint 2013 is Microsoft's new SharePoint version (at the time of this writing) and boasts some pretty cool features. In this post, we will migrate from a Windows Server 2008 with SharePoint 2010 to a Windows Server 2012 with SharePoint 2013. This migration involves 'cookie cutter' SharePoint sites: We are going to assume you have SharePoint running on SQL Express in a single server farm and that your site collection resides in the default WSS_Content database. If you have a more complex scenario, you can still use this guide as a framework, you will just need to make the necessary adjustments.
The Server 2008 with SharePoint 2010 will be referred to as the source server and the Server 2012 with SharePoint 2013 will be referred to as the target server. In summary, here are the steps we will perform:
  • Set up a Windows Server 2012 server with SharePoint 2013 farm
  • Copy the SharePoint 2010 Database to the target server
  • Attach and Upgrade the content database
  • Upgrade the Site Collection
Set up Server 2012 Server and a SharePoint 2013 Farm
Set up Server 2012 and install SharePoint 2013 on the target server and configure a SharePoint 2013 farm. When you create your Web application and site collection, make sure that you create the same type of site, the same port and the same authentication method as the source site.
Copy the SharePoint 2010 Database to the Target Server
Next, open SharePoint Central Administration on the source server and navigate to Application Management > Manage Content Databases. Locate the database pertaining to your Web application.
From a command prompt, type net stop mssqlserver to stop the SQL Server service.
Locate the database in your file system. It should be in C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
Copy both the content database as well as the log file to a removable disk. Once database and log files have been copied, open a command prompt and type net start mssql to restart the SQL Server service.
Detach the SharePoint Database from the Target Server
Since the database we are moving is named WSS_CONTENT (the Default) we will need to detach and rename the old database from the target server. Note: Make sure your target server is not a production server with a Web application utilizing the WSS_CONTENT database before detaching it. We will assume for this exercise that you have a newly installed SharePoint 2013 and have created a new Web application.
Log in to your target server's SharePoint application management and click Manage Content Databases.
Look under database name and click on the WSS_Content database link. Place a checkmark in Remove Content Database.
Acknowledge the warning after you have read it.
Click OK to remove the default content database (WSS_CONTENT). The content database should not up for the Web application.
From the target server, open SQL Management Studio 2012. If you don't have it, you can download it from here.
Open SQL Management Studio and Expand databases.
To detach the old database from SQL, right click on WSS_CONTENT and select Tasks > Detach
Place a checkmark in Drop and click OK to detach the database.
Navigate to C:\Program Files\Microsoft Office Servers\15.0\Data\MSSQL10_50.SHAREPOINT\MSSQL\DATA and rename WSS_CONTENT to WSS_CONTENT_OLD and rename WSS_CONTENT_log to WSS_CONTENT_log_OLD.
Attach and Upgrade the Content Database on to the Target Server
Copy the source database and log files to the following folder on the target server:
C:\Program Files\Microsoft Office Servers\15.0\Data\MSSQL10_50.SHAREPOINT\MSSQL\DATA
Open SQL Management Studio 2012. If you don't have it, you can download it from here.
Right click on databases and select attach.
Click on the add button, locate the database and click OK to attach it.
Note: If you are migrating from a different domain, expand the database and in Security > users grant DBOWNER privileges to a user account or administrative account in the new domain.
On the target server, open SharePoint 2013 Management Shell.
From the SharePoint 2013 management Shell, execute the following command:
Mount-SPContentDatabase -Name DatabaseName -WebApplication URL

This command will mount the database and upgrade it to SharePoint 2013.
Enter your site and verify that it's working. You may notice that it still looks like SharePoint 2012. That's because we have not yet upgraded the site collection.
Once you verify that the site is working, go to Central Administration > Application Management > Configure Alternate Access Mappings and change the default URL to the live URL of your Web site; alternatively, you can extend your Web site.
Once you make the port forwarding and/or DNS changes (if necessary), your newly migrated site will be live!
Upgrade the Site Collection
The final step is to upgrade the site collection. Before proceeding with the site collection upgrade, create a backup or a snapshot of the SharePoint 2013 server in case the fecal matter impacts the thermantidote.
From the Web site, click site actions > site settings. In the site collection administration menu, click on the site collection upgrade link.
Click on the upgrade this site collection button.
The upgrade process will begin.
When done, click on take me to the new siteWelcome to SharePoint 2013!!!

Google+ Followers