3

After migrating all SharePoint databases to a new SQL Server, how can I configure SharePoint to to reference the new SQL Server without using an Alias?

The reason we need to avoid using an Alias is because we have multiple custom webparts which use different SQL servers and the Alias will cause connection issues.

Thanks

1

Here's a crazy idea: keep the alias, and for your custom SQL DBs, use the IP of the SQL Server in your web config that those web parts use. That way you bypass the alias that is borking your custom DB pointers.

3

If

you have the old db-server up and running, use the following command in PowerShell:

Get-SPSite -ContentDatabase <SourceContentDb> | Move-SPSite -DestinationDatabase <DestinationContentDb>

This command moves all site collections from the source content database to the destination content database.

Reference: Move site collections between databases (SharePoint Server 2010)

Else

depending on where in the process you are in moving, My best guess is that you have to mount the database(s) using the following PowerShell command:

Mount-SPContentDatabase -Name contentdb -DatabaseServer dbserver -WebApplication webappname

When that is done, continue with a test and solve any errors listed by the cmdlet

Test-SPContentDatabase -Identity contentdb

Reference: Managing SharePoint Content Databases with PowerShell

Edit

To move all databases without the use of SQL Server alias, I find it faster (and easier) to set up a new farm on a different servers and do a full backup and restore in the new environment using PowerShell. Don't forget to use the -overwrite flag.

  • Thanks Benny, however I am referring to all databases in Sharepoint which includes the content, configurations, logging, etc. I need an easier way to reconfigure sharepoint to point to the new SQL server while avoiding the use of an alias. – Haroun A. Nov 30 '13 at 7:06
  • @Rounn I've edited the answer based on my experience. Hopefully you have an available server to do the restore on. – Benny Skogberg Nov 30 '13 at 8:39
  • 1
    The Configuration database has hard coded references to the name of the SQL Server (or alias) it was created on. Hence the requirement of using an alias if you're moving SQL Servers. Your only other choice is to rebuild the farm. – Trevor Seward Dec 2 '13 at 19:43
1

It's not ideal, however the best way (in my experience) would be to use multiple aliases to help simplify this issue.

One possible workaround could also be to update the SharePoint servers host files to point the db server names to the new IP address(es). The hosts file overwrites DNS entries, and is located in C:\windows\system32\drivers\etc\hosts.

The format of the file is:

e.g. 192.168.0.1 mysqlserver

Be careful if you try to restore SharePoint config/service databases as you may run into issues including potential MS support issues if not done properly (or use a third part y tool). You may find it easier to migrate content to a new farm instead.

Hopefully these ideas help you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.