NEW San Diego SharePoint Users Group

A NEW SharePoint Users Group is forming in San Diego!

Here are the basics, go to www.sanspug.org for more details.

Join us for the first San Diego SharePoint User Group (SanSpug) meeting on June 1st! Our first meeting will include two highly appropriate opening subjects:

· SharePoint 2010 Features Overview

· Upgrading to SharePoint 2010

SanSpug meetings are held at New Horizons Learning Centers:

7480 Miramar Road
San Diego, CA
Meetings start at 6:00 PM – 1st Tuesday of each Month

Moving MOSS 2007 SQL Databases part 2

Today I am looking at the AvePoint DocAve option that I dreamed up when faced with the need to move my SharePoint sql databases to a different sql server.

DocAve is a great backup tool, and the features it provides for disaster recovery are nice.  The product, once installed and configured(1), allows your system admin or SharePoint admin manage backup and restore activities easily.  The system can even be configured to allow others (Site Collection Administrators for example) to restore their own sites, lists and libraries.  Access is controlled, making this feature a bonus to SharePoint Administrators in larger environments.

In my scenario, where I want to MOVE all of my SharePoint databases to another SQL server, there is a little weakness displayed in the DocAve armor. The ConfigDB, SPWebService, CentralAdmin WebApp, and Admin ContentDB’s can only be restored “in place”(2). That means the destination sql server must have the same name and configuration as the sql server where the backup originated.  I can’t restore those db’s to a different sql server, thus I cannot complete my task using DocAve.  To be fair, I could use DocAve backups to accomplish part of my task, just not the whole task.

This situation is not common, so AvePoint shouldn’t be dinged points for the DocAve product – my guess is that it handles at least 95% of the requirements for pretty much any SharePoint shop.  I like the product, use the product and might even recommend the product…I am just bummed that it isn’t magically making this specific task drastically easier.  I guess that is why there are migration tools out there. 😉

Continue to Part 3

Footnotes:

1. Another post may cover the install configuration process for DocAve based on my experience.  This is an area where I think AvePoint could improve.

2. Information obtained from the “Platform Backup and Restore” whitepaper from AvePoint.

Moving MOSS 2007 SQL Databases

I have a MOSS 2007 implementation that consists of a SharePoint “farm” on one server and the SharePoint databases on a shared SQL Server. The SharePoint server is running Windows Server 2008 and is 64-bit, but the SQL Server is on Windows 2003 with SQL 2005.

One of the other applications using this shared SQL server is fairly critical and the performance is starting to take a hit. This has opened an opportunity to get our SharePoint databases moved to a dedicated SQL server.

I don’t know if anyone else out there has a similar hardware situation or not, but I thought I would try to post a few thoughts as I go through this process over the next few weeks. Let me know if you have already done this or think I am taking a wrong turn as I go.

One idea I have is to take full advantage of the need to move and upgrade to a SP2010 compliant SQL system – and go to SQL 2008 while I am at it. Good idea or bad idea?

Another thought is to investigate whether or not I can make use of our recently implemented DocAve Data Protection software from AvePoint. Maybe I could ‘act’ like a disaster happened and I need to restore my SQL Server on a new box. I wonder if that would work, and if it would be any faster/easier?

Let the investigation begin.

My first stop is with this TechNet article, Move all databases (Office SharePoint Server 2007): http://technet.microsoft.com/en-us/library/cc512725.aspx – my light reading for tonight.

Continue to Part 2