Moving SharePoint DataBase to another SQL Server

This is a guide I wrote to help make this procedure as easy as it can.
You can find more information about "Moving SP to another SQL server" in this site:
microsoft

It is essential to know if you are moving the SP DB to to a different database server or a server with the same name!

This guide is for moving the DB's to a different database server.

Part 1

On the server that is running the Central Administration Web site, stop the following services:
· Microsoft Single Sign-On service
· Office Document Conversions Launcher service
· Office Document Conversions Load Balancer service
· Office SharePoint Server Search service
· Windows SharePoint Services Administration service
· Windows SharePoint Services Search service
· Windows SharePoint Services Timer service
· Windows SharePoint Services Tracing service
· Windows SharePoint Services VSS Writer service

Stop the IIS – CMD - iisreset /stop.

Backup the Content databases for the following SP sites :
· SP site Content DB
· SP Mysite Content DB
· Shared Services DB
· Shared Services Search DB

Backup the top level site with STSADM command:
Stsadm –o backup –url http://spsite/ –filename %system root%:\SPsite.bak
Stsadm –o backup – url http://spmysite/ –filename %system root%:\SPmysite.bak

Part 2

Copy the DB's (LDF & MDF) to the new SQL server:
· SP site Content DB
· SP Mysite Content DB
· Shared Services DB
· Shared Services Search DB

Attach the DB's to the new SQL server – Take online

Run the STSADM command:
stsadm -o renameserver -oldservername -newservername

You can find more about "renameserver" command in this link:
STSADM

Part 3

Log in to the Central Admin.
Start up and configure the services on the farm
Create all web applications exactly as before – use temp DB when you build the DB's.
Redirect the web application to the origin DB's - Application management > content database:
Disconnect all the DB’s for the web applications
Reconnect the origin DB's.

In Central Administration – restore the SSP: Central Administration > Application Management > Manage this Farm's Shared Services - restore the SSP

It worked for me, I hope it'll work for you…

Lockdown Feature

When publishing Web portal, most of the time we to want prevent users from accessing the application pages: _layouts/…/default.aspx

The reason to activate this feature in an internet environment is to change the permissions level of the anonymous users group Limited Access privilege. Because there is no way to change these permissions through the UI, we need to use this Feature.

The Lockdown feature removes the View Application Pages permission, and the Use Remote Interfaces permission. This is helpful in preventing users from accessing application pages on a public facing/Internet web site

The Command:

stsadm -o activatefeature -url -filename ViewFormPagesLockDown\feature.xml

Note: this is the same like on all features, we can deactivate this feature (unlocked):

stsadm -o deactivatefeature -url -filename ViewFormPagesLockDown\feature.xml

Link to Microsoft LockDown syntax: LINK

Error: The database is not consistent with the expected database schema version

After upgrade from standard license to an enterprise version of SharePoint 2007, one of my customers Starts to notice a repeated error in the event log under the application section.

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Topology
Event ID: 5617

The error massage was:

The schema version (3.0.149.0) of the database SharePoint_AdminContent_xxxxxxxxxxxxxxxxxx on x64a is not consistent with the expected database schema version (3.0.150.0) on XXX. Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match

The Solution was very simple:

stsadm -o upgrade -inplace -url http://{relevant central_admin_url}

In my case that seemed to have solved the problem.