none
Move SharePoint 2013 farm to a new SQL server using a different server name without aliases

    Question

  • Folks, I'm looking for some help on moving our SharePoint 2013 test environment over to a new SQL server without having to use aliases. Here is our situation:

    We have a SharePoint 2013 Test environment that consists of three (3) Application, four (4) Web Servers and one SQL database server. All of these servers are virtual machine servers and we need to replace our existing VM SQL server with a physical SQL server. Due to our corporate policies on naming conventions, the new server has to have a new and unique name. The problem comes with our intended repurposing of the old server.

    We want to change this farm so that everything points to the new physical SQL server but once this has been completed, we want to take the old server and re-use it as a database server for business connectivity and custom application purposes.

    I've seen many links and discussions on how to move a SharePoint farm to a new SQL server but they all involve using aliases to allow each of the farm servers to point to the new server using the old server name. We cannot do this in our scenario, and we need to be able to configure SharePoint to use the new SQL server with it's new name.

    Also, we have Workflow Services installed in this farm and this will need to be changed to use the new server.

    Is any of this possible??

    Wednesday, January 3, 2018 7:27 PM

Answers

  • Unless you want to rebuild the SharePoint farm, you must use the same name or implement an alias. There is no supported method to use a new name for the SQL Server hosting the Config/Admin databases.

    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by JM Estrada Saturday, March 3, 2018 1:27 PM
    Wednesday, January 3, 2018 7:58 PM
    Moderator

All replies

  • I would really recommend rebuilding that old SQL server then.
    It is indeed best-practice to use aliases in this scenario:
    https://technet.microsoft.com/en-us/library/cc512725.aspx?f=255&MSPPError=-2147217396

    Also, you don't have to reuse the old server if you have a license available.
    If you have a license for two hosts, it doesn't matter on what host SQL is running, as long as it are two.

    In any scenario you are using aliases (also an interesting article):
    https://blogs.technet.microsoft.com/meamcs/2014/06/10/moving-sharepoint-databases-to-another-server-without-reconfiguring-sharepoint/

    However if you use "stsadm -o renameserver -oldservername -newservername", you can use an alias, rename it and after the migration you can reuse the old server.

    Wednesday, January 3, 2018 7:38 PM
  • Unless you want to rebuild the SharePoint farm, you must use the same name or implement an alias. There is no supported method to use a new name for the SQL Server hosting the Config/Admin databases.

    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by JM Estrada Saturday, March 3, 2018 1:27 PM
    Wednesday, January 3, 2018 7:58 PM
    Moderator
  • Ok... Well that is what I wanted to know. I've read the Microsoft links on it, which explain the use of aliases.

    Honestly, we would like to keep our naming conventions the same and be able to repurpose the old SQL server for custom applications and other uses, so maybe I will need to consider rebuilding the farm on a new SQL server... It is a TEST environment after all. It might be quicker to just rebuild it than deal with the ramifications of attempting to move it.

    When the test farm was built, it was not done with an aliased SQL name, which we should have done. So this might be a good time to create an aliased name for the SQL back-end database server and rebuild the farm using that.

    Wednesday, January 3, 2018 8:39 PM
  • Unless I'm using an AlwaysOn AG, I use a SQL Alias regardless. Usually just "SPSQL" pointing to the real SQL Server name. With AOAG, always use the FQDN as the database mobility problem (the reason for using an alias) doesn't exits.

    Trevor Seward

    Office Servers and Services MVP



    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, January 3, 2018 8:41 PM
    Moderator
  • We're not using AlwaysOn AG for this test environment, but we will be using an alias moving forward. I'm just going to have to rebuild the SP and Workflow farm.

    Wednesday, January 3, 2018 9:50 PM
  • Thanks.

    The reason we want to repurpose the old SQL server, is because we outsource our IT/Data Center, so when we have servers it's a huge ordeal to get them reloaded, or to order new servers. So since we have a new SQL we want to take the old one and use it for other purposes, still SharePoint related.

    If we had full control over our servers, I would just blow the old one clean with a new name. I think the farm rebuild is our best option.

    Wednesday, January 3, 2018 11:11 PM
  • Just use SQL aliases and you don't have to go through building a farm. It's a simplistic way and better solution as well. The only thing you've to do:

    1. Create SQL Alias for Old server name

    2. Move old DB files to new server file location

    3. Keep the alias name and update server name only.

    That's it on high level. For walk-through you may find resource like below useful:

    http://www.macaalay.com/2013/02/13/migrate-sharepoints-sql-server-to-another-sql-server-same-or-new-version/ 

    Wednesday, January 3, 2018 11:42 PM
  • Hi JM Estrada,

    How are things going? Have you solved your issue?

    If you think any suggestion is helpful, you could mark it as an answer. It will help others who meet the similar question in this forum.

    Best regards,

    Allen Bai


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Monday, January 8, 2018 2:20 AM
  • Sorry for the delayed response.

    Ultimately, I ended up rebuilding the farm. It was much simpler to just remove all seven servers from the farm and create a new farm on the new SQL server. I made sure to use a DNS alias this time, in case we ever need to upgrade or replace this server in the future.

    It did require a bit of work to recreate all the web applications, service applications and transfer content databases over, but everything came up and worked as expected.

    Thanks for the advice folks!

    Saturday, March 3, 2018 1:31 PM