Extracting SharePoint 2007 document libraries from SQL databases - no installation required

To cut a long story short a client recently ran into difficulties attempting to restore a document library. The following code was developed for a specific scenario where a document library had disappeared from a specific site and not showing in the recycle bin (Recycle bin worked fine on testing). I’m not sure as to how this document library has disappeared without being captured but it has!

I was against installing a full blown trial install on the SharePoint servers just to recover a single document and in this specific case there was only one environment available and time was of short supply. Appreciating a dev and test environment is the best way to work unfortunately this was unavailable and the data could not be removed from site (for obvious security reasons) to another farm to explore.

Before I supply the code I need to thank Neil Hodgkinson (Microsoft) and James Orton (Tesl) for their assistance in creating this script.

All my tests carried out have been run on a SQL VM ( see disclaimer below) however in theory you should be able to run this remotely from a desktop pc assuming the logged on user has the relevant rights to access SQL and firewall permits.

Download the script. You will need to edit the code to rename a few properties.

Server = "server" - enter the name and instance of the SQL server
database = "Moss_Content" - enter the name of the database you wish to recover the document library from (You can use SharePoint Central Admin to determine which content databases are assigned to which Web App)
location = "documents" – enter the name of the document library you wish to recover so for example this document library is called documents at the root of the site collection e.g. http://sharepoint /documents
outputPath = "c:\docs\" – This folder needs to be created prior to running the script otherwise it will fail!

Feel free to develop the code further but please do share and leave me a comment on this blog post if you do.

Further development suggestions:

• Add a menu to navigate options
• Output a list of all document libraries available to extract data from
• Following on from the previous suggestion list all documents in a document library
• Extract individual documents option (assuming the location and name of the document is known)

I hope this is of some use to you, although I would hope if you are reading this you a revisiting your backup strategy!

Disclaimer: The code provided in this blog is in no way supported by Microsoft or myself and should not be performed on production SharePoint SQL Databases. This operation should be carried out as a last resort and a backup and recovery strategy should be your method to restore data. Ensure this is performed on a test environment by using a copy of your data and discarding of the database after carrying out this operation.

Bypassing ISA 2006 HTTPS redirection rule with HTTP vulnerability publishing SharePoint and OWA - Fix

It was recently pointed out to me that when a user attempts to log onto a SharePoint extranet published web site through ISA they can replace HTTPS in the header with HTTP and user credentials could potentially be sent over the web unencrypted.

For example if a user connects to the site entering http://sharepoint.extranet.com and is redirected to https://sharepoint.extranet.com/cookieauth.dll?<parameters> then the user manually modifies the URL back to HTTP e.g. http://sharepoint.extranet.com/cookieauth.dll?<parameters>.

This is obviously a security vulnerability and Microsoft have published a KB article (958607) describing how to resolve this which can be seen here.

If you have Exchange or SharePoint published via ISA 2006 I would strongly suggest either applying the ISA hot fix or workaround to resolve this.

Removing IIS 5 / 6 / 7 Server Header from SharePoint Installations

*** UPDATE 03/04/2012 ***

I’ve recently had a couple of interesting comments relating to this post and felt its worth updating my blog to make you aware of the impact of changing the settings I discuss below.

Firstly it is worth mentioning that the initial reason for blogging on this was due to a clients penetration test highlighting this security vulnerability and therefore it is still a valid consideration however the impact of making this change means that you will break SharePoint search and therefore thanks to Anthony Casillas and Iain Wyatt’s comments I have highlighted this as part of the post below.

*** UPDATE END ***

Here is a guide to remove IIS server header Server: Microsoft-IIS/6.0 from IIS to stop your browser detecting the web server SharePoint is running on. This can be particularly useful if you are externally publishing SharePoint or other IIS .NET applications and want to reduce the information to your backend servers information.

Background

Without additional configuration you can identify what platform IIS is running on using a simple tool to view the http headers.

If you download and install a tool such as ieHTTPHeaders from here. From Internet Explorer enable the tool from ‘Tools->Display ieHTTPHeaders’. Load the homepage of SharePoint and you will notice that amongst the many headers and requests you will notice something similar to the below:

Server: Microsoft-IIS/6.0
MicrosoftSharePointTeamServices: 12.0.0.6318
X-Powered-By: ASP.NET

How to remove these from IIS

NOTE: Before editing any settings to allow search to function it is required that you configure the default zone with these headers untouched and modify extended (AAM) SharePoint sites.

The last two lines can simply be removed from IIS by editing the properties of the web site under the custom HTTP headers section as shown below, noting this is IIS 6 but the same applies to IIS 7.

To remove the header Server: Microsoft-IIS/6.0 from IIS this requires a little more config!

Firstly you need to download URLScan (at the time of writing this is version 3.1) from Microsoft here. This is basically an ISAPI filter that needs to be applied to the website you wish to remove the headers from, making sure that if you have extended a SharePoint web app you assign the ISAPI filter to the correct one (i.e. the one created for external access).

Install URLScan, then from the same web app select ISAPI Filters tab and select add navigating to C:\windows\system32\inetsrv\urlscan and add urlscan.dll (IIS 7 may do this for you).

Then edit the urlscan.ini line

RemoveServerHeader=1           ; If 1, remove the 'Server' header from
                                              ; response.  The default is 0.

Save the file and check the HTTP headers using ieHTTPHeaders and you should now not see the these headers when loading pages.

Feel free to leave a comment if you have any thoughts.