Tuesday, 27 May 2014

Backing up & restoring SharePoint

Last week we had the unenviable task of restoring a production SharePoint due to the corruption of a number of libraries.  We didn’t want to restore the entire site as the restore point was 17 hours from the previous backup.  The decision was made to restore to an alternate location, compare the files and manually copy the required files across.

The first point to note is that this is much easier if you have a full application level backup of SharePoint – possible through backup utilities like Microsoft DPM (Data Protection Manager) or Dell’s AppAssure and herein lies the real moral of the story.  However, we only had a backup of a full server image and a backup of the SharePoint database.

Restoring the site from this point, back in to the same SharePoint Farm for comparison, had its challenges and we found no reliable, single point of reference on the web to give us guidance.  We’ve documented the process for reference and we will certainly be backing up the SharePoint application from now on.

Restore SharePoint content into the same SharePoint Farm

The only way to do this is to use export import using one of the following SharePoint commands:

Backup-SPSite -Identity SiteCollectionURLHere -Path BackupFilePathHere [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]
Restore-SPSite -Identity SiteCollectionURLHere -Path BackupFilePathHere [-DatabaseServer DatabaseServerNameHere] [-DatabaseName ContentDatabaseNameHere] [-HostHeader HostHeaderHere] [-Force] [-GradualDelete] [-Verbose]


stsadm -o backup "webappurl" -filename "yoursitecolleciton.bak"
stsadm -o backup "restore" -filename "yoursitecolleciton.bak"

The above commands are native SharePoint command for backup and restore. They will work well provided the original site content that you want to backup is still good (so you can take the SharePoint backup from this site and restore it to the other site in the same farms).

If the original SharePoint content has broken and you need to restore content from backup without deleting the old content then it is going to be a challenge as you can’t restore SharePoint content into the same farm. This is because one site only can have one application GUID, so when you import the database it will always shows that you have 0 sites.

There is a work around to this:

Step I

Create New Web App:

1. Go to SharePoint Central Administration -> Application Management -> Manage Web Application -> Click the ‘New’ icon in the top left.

2. Fill out all the required details, make sure it is running port 80, specify the new database name, it will create the new one (e.g.: WSS_Content_Restore)

Step 2

Attach the new database, the database must be attached in the same instance where the SharePoint is installed

1. In the SQL server management studio, right click databases and choose attach

2. Click add and point it to the restored database (.MDF) and log (.LDF) files

3. Make sure that we change attach as the new name  (e.g.: WSS_Content_Restore_1)

Step 3

Attach the database to the SharePoint:

1. Open SharePoint 2010 Management Shell as administrator

2. Execute this command: Mount-SPContentDatabase “WSS_Content_name” –WebApplication restoreurl -AssignNewDatabaseID
e.g: Mount-SPContentDatabase "WSS_Content_MynetRestore" -WebApplication http://mynetrestore.myriad-it.com/ -Assignnewdatabaseid

(Note that the CurrentSiteCount is 0 although we have 5 sites in that database) – Database attach from the web interface will not work because one SharePoint farm can only have one database ID so we need to assign the new database ID to the imported database.

3. Go to Central Administration- > Application Management -> Select the correct Web Application -> Manage Content Database and remove all the original database, make it the restore database as the only database.

a. Change the Database status to Offline

b. Tick remove content database

c. Click OK

4. Make sure only one database listed

Notice that it only has 0 number of site collection

Step 4

Create the new site in the new WebApp, the site name must be the same with the original SharePoint.

1. Go to SharePoint Central Administration -> Application Management -> Create Site Collection -> Change the web application that we created on the step 1

 2. Title and Description can be anything, url for the new sites must be the same with the original site, if the original site is /sites/clients then we also have to create /sites/clients

3. Template must match the original template, for this case is Team site.

4. Put yourself as primary site collection Administrator

Step 5

Match the application GUID with the original site.

When you create the new site it will create the new application ID, you need to change this to match the original site application ID. This is the tricky part.

1. Go to the database server and open SQL Management Studio

2. Execute the following query:

use WSS_Content_MynetRestore_AV

select ID, TimeCreated from dbo.Sites

3. Take note of the new site ID, when we look at the date, it should be the recent time and date as we just created it:

4. Execute the following query to see the ID of the old site

use sp2010_Config

select ID, Path from dbo.SiteMap where path = '/sites/clients'

5. Take note of the original site application ID:

(if there is two ID like above, need to find the correct clients ID which one is belong to the original ID), in this example the correct site ID is: 6E76FF13-6C70-4BFE-A112-74D29C553EC9

6. Go to Sharepoint_Config, expand and go to -> Tables -> dbo.SiteMap, right click and choose Edit Top 200 Rows

7. Find the original site ID and replace the most end character with any character, and copy the original application ID to the new site. The reason we do this because one sharepoint farm only can have one application ID.

8. Do the IISreset

9. After iisreset, the original site will be down showing 400 Bad Request, to make the original site up need to put back the correct value to the original site

10. Change the last character of ID on the new site’s application ID to anything, but must remember the original value.

11. Go to the new site URL,  if the restore is successful, it should represent the same layout with the original site

There was some error showing on the page, that because of publictokenkey that we need to save it on the web.config of the sharepoint file, should ignore the error if just need to get the file, if need to get the site running must put this line in the web.config located in IIS virtual directory, e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\80:

<SafeControl Assembly=”DateTimeWebPart, Version=, Culture=neutral, PublicKeyToken=2bfd9e5fd3b67b15″ Namespace=”DateTimeWebPart.DateTimeWebPart” TypeName=”*” Safe=”True” />

12. Then map either map or explore the sharepoint site using explorer, we should be able to see all the files:

Note: There is a grace period between wrong ApplicationID that being mapped to the sharepoint site, on the next database refresh one of the site will fail so need to re-do step 10 and 11 to make sure both sites are working.

Key takeaway:

There are a number of challenges in restoring SharePoint that the above steps can help address. The most important thing to remember is that this would have been much easier with a full application level backup of SharePoint – possible through backup utilities like Microsoft DPM (Data Protection Manager) or Dell’s AppAssure.

- Nicolas Prasetyo, Systems Engineer

Thursday, 1 May 2014

End of Windows 2003 support – opportunity or threat?

April 8 2014 was a well published milestone with Microsoft no longer supporting Windows XP.  The next big date is July 14 2015 when Windows 2003 support will reach end of life and I think this is a much more daunting proposition. 

At a recent vendor conference, someone threw out a number 10-12 million servers worldwide still running production applications on Windows 2003. It’s unclear if this estimate is accurate but I imagine there are a lot of Windows 2003 servers out there still running production applications. 

Whilst the number of servers out there is much smaller than the number of PCs, the task of migrating is much more complicated and the risks greater.  Most Windows 2003 servers shipped between 2002 and 2007 and given normal server lifecycles and corporate asset replacement cycles many will already have been retired.  However, I still see Windows 2003 servers at sites and usually this is due to the legacy applications that are not supported on newer versions of Windows.

We all know if it was easy to replace an application or the ROI to do so is compelling it probably would have been done already.  Establishing business cases, finding suitable replacement applications and testing new versions all take time and I sense that, even though the date is over 14 months away, the urgency is building. 

It doesn’t need to be all doom and gloom though.  This presents a great opportunity to look for modern applications delivered in alternative ways.  Not only is it an opportunity to move applications into the cloud but also to consume them differently. 

The subscription models now available also change the financial impetus as the monthly expense is smaller and more immediate.  Paying for applications as they are consumed removes the requirement for developing business cases for capital expenditure, saving time and effort.

Instead of thinking about the task of replacing a server and an application I think this is a great opportunity to deploy modern applications, without any infrastructure requirement, and to move away from traditional “shift and lift” upgrades permanently.