locked
Changing Database Server Name RRS feed

All replies

  • Hi Ben,

    Here are the steps below

    https://support.microsoft.com/en-us/help/4456879/change-the-database-server-in-a-sharepoint-farm


    Please remember to click Mark as Answer on the answer if it helps you

    Monday, April 15, 2019 6:10 PM
  • Leave it to MS to make it this excessive.

    Follow up, since I only touch SP when there's a problem, and I'm not a DBA, just a clarification on where the steps are performed.

    Step 1: Create a new SQL alias on all SharePoint servers in the farm
    (on SP server)

    Step 2: Point the SharePoint databases to the new SQL alias
    (on SP server)

    Step 3: Point the default database instance for the web applications to the new SQL Server instance
    (on SP server)

    Step 4: Change the Distributed Cache cluster configuration
    (on SQL server)

    Step 5: Reprovision the Distributed Cache service on all Distributed Cache servers
    (?? SP server?)

    Step 6: Remove reference to the old server
    To do this, run the following PowerShell cmdlet in an elevated SharePoint Management Shell window:
    (SP server)

    Step 7: Verify the change
    (SP server)

    Ben Rollman

    Tuesday, April 16, 2019 4:54 PM
  • Hi Ben,

    You should consider below two things:

    1. Have you set up the SQL Alias and used that to connect SQL?

    2. Or if you use the DNS alias or simply server name?

    If you use alias then its very simple to rename.I would shut down the SharePoint, rename the server and update the SQL alias on the servers and start the SharePoint, everything will be work.

    If no Alias then you have to rebuild the farm because their is no supported way to update the config db connection string. But still you have your Content DB and Serivces db their so once you rebuild the farm then you can attach old DBs to new farm.

    You can refer to below article:

    https://docs.microsoft.com/en-US/SharePoint/administration/move-all-databases

    Best regards,

    Allen Bai


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

    SharePoint Server 2019 has been released, you can click here to download it.
    Click here to learn new features. Visit the dedicated forum to share, explore and talk to experts about SharePoint Server 2019.

    Wednesday, April 17, 2019 7:34 AM
  • So, we had an outside vendor set our environment up initially.  I'm sure I took notes, but it was years ago.  Then we migrated to 2013, again, years ago, and I have very little memory of how it's set up.  So I can't tell you for sure if it's set up as a SQL or Domain alias.

    Before I start on either of these steps, can I find out which we're using?  I can see in CA that we're connected to a SQL server and the DB name.


    Ben Rollman

    Wednesday, April 17, 2019 1:26 PM
  • you may check current connection string for Sharepoint config database - it is stored in system registry (check e.g. SharePoint Server config database connection string). In this connection string pay attention on server name.

    After that use cliconfg tool to check whether you use SQL server alias or not: How to check in MS Sql Server to what db instance alias belongs to. My suggestion is to always use aliases as they greatly simplify such tasks as moving databases to the new server.


    Blog - http://sadomovalex.blogspot.com
    Dynamic CAML queries via C# - https://github.com/sadomovalex/camlex

    Wednesday, April 17, 2019 2:46 PM
  • I'll go ahead and say I'm not familiar with that tool.  But when I found it, there was nothing in it.  Just named pipes and TCP in the Disabled Protocals.  Nothing on the Alias tab.

    Ben Rollman

    Also, the registry shows DNS and the server name followed by the content DB name, so I'm guessing it's not a SQL alias.
    • Edited by brollman Wednesday, April 17, 2019 3:01 PM
    Wednesday, April 17, 2019 3:00 PM
  • There wouldn't be an alias (well, unless they set things up correctly in the first place if you're not dealing with an AOAG SQL implementation).

    What you need to do is find out the database server\instance name (if applicable) you're connecting to today. So perhaps the SQL Server name is TMASQL01. You can find this information in Central Adminstration -> Servers in Farm. From there, you'll look for the server running the Database service.

    Let's say you are moving to TMASQL02, so this is where you'll repoint your databases. First thing, make sure all of your Windows SharePoint services (services.msc), including AppFabric, are off and IIS is shutdown (iisreset /stop).

    What you'll do at that point is, on every SharePoint server, run cliconfg. On the Alias tab, you'll select TCP and the alias name will be "TMASQL01" (yes, your old SQL Server). In the Server name box, you'd enter TMASQL02. Move all of your SharePoint databases to TMASQL02 using the backup/restore method via SSMS or your SQL backup tool management of choice.

    Finally, start all SharePoint services/AppFabric and resume IIS (iisreset /start). Give it a minute or so and then check to make sure SharePoint still works.


    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, April 17, 2019 3:11 PM
  • Neat, a third method! :D

    Okay, so CA shows Config db version, db server, db name.  Got all that.

    We're not moving anything, we're renaming the existing server, but from what everyone has said, it's the same as moving it.

    So from what this sounds like, all I need to do is stop all the SP services, and IIS.  Set up an alias, and then restart them all.  Since we're not moving any DBs, the config db name should be the same.


    Ben Rollman

    Wednesday, April 17, 2019 3:32 PM
  • Yes, that's all you need to do. And note that my comment was an abridged form of the official MSFT docs :)

    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, April 17, 2019 3:34 PM