I am in the middle of a move of all SharePoint databases from a shared SQL Server (Windows 2003, sql server 2005) to a new SP-dedicated sql server (Windows Server 2008, SQL 2008 R2, 64-bit). I followed the steps outlined in the TechNet article "Move all databases (Office SharePoint Server 2007)" located here: http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx My SharePoint server is running MOSS 2007 SP2 with all critical updates/patches etc. installed. Everything went fine until I got to the Restore of my SSP (I have only one). When I execute the stsadm restore command on my Central Administration server (which is also my web front-end - this is a 2 server farm - one sql server and one SharePoint) the restore fails with errors. The first two errors are the SQLExceptions: Timeout Expired for the WSS Content and Shared Services databases for the SSP. A third error is "NullReferenceException: Object reference not set to an instance of an object", which I assume occurs because of the previous timeout errors. I have verified that the SQL Instance and server information I am using is correct, as well as the service account & password requested by the process during the restore. I am using the "spadmin" account on the SharePoint server, which is a farm admin, server admin, and has sql permissions of dbcreator, sysadmin, securityadmin, and public on both the new sql server and the previous sql server. I have all accounts and permissions transfered to the new sql server (server roles and user mappings in sql mgmt studio). I cannot seem to find a solution or any reference material directly related. There seems to be a hotfix out with a cumulative update, however that specifically fixes a timeout issue with a restore of a large db from backup in mgmt studio on sql 2008 (http://support.microsoft.com/kb/967205). Which is similar, but not exactly what I am experiencing here. Has anyone seen this before? Anyone have any resolution options?

No worries SharePoint is a Community... Please ping back the post and let us know if you were successfull -Ivan Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.

Using the sql svc account didn't change the behavior. Rolling back for now to reduce impact on production. If I can get a fairly solid feel that we can succesfully do this, I will schedule it in later this week. Seems odd that the only error is a timeout...maybe I can find a sql guru to assist.