If you don’t like the GUID that trails the Central Admin Content DB, you have 2 options, create the Farm with PowerShell / scripting and create the databases with names that you like OR if you already have a Farm, you can use the scripts below to change the Admin Content (Central Admin Content Database). Needless to say during this operation your Central Admin site is not accessible. These scripts also call IISRESET and hence plan for downtime.
There are 2 examples of this script, both are 100% automated. The only thing the Script expects the User to provide is the name of the New Content Database. I would love to automate it with Read-YourMind cmdlet… but let’s leave it for now J.
Method 1 – Using Move-SPSite cmd-let.
What we are doing here:
1. Getting the Central Admin URL and the New Content DB Name from the User
2. Populating the variables we need to perform the operation like the Current Admin Content DB Name, SQL Server Name and the Database ID
3. Creating a New Content Database and Attaching it to the Central Admin Web Application
4. Calling SP-MoveSite to Move 2 sites from Old Content Database to the New one
5. Lastly, we ask the user if he wants to Detach the Content DB from the web application or completely delete it from SQL
The operation can be screen in the below screenshots:
Current Content DB with 2 Site Collections
New Content DB Attached to the same Web App and Site Collections have been moved to the New Content DB
This is the Script. For convenience, you can also download the zip file attached to this post. The zip file contains 2 scripts RenameAdminContentDB_Method1.PS1 (Move-SPSite Method) and RenameAdminContentDB_Method1.PS1 (Backup – restore methos described later in the post.)
Method 2 – Using SQL Backup and Restore.
This method is primary for demonstration purposes. It shows how you can call SQL Commands and SMO (SQL Server Management Objects) directly from PowerShell along with SharePoint. I will use the same method in future posts on automating tasks for Database mirroring. Though this script can be used for any content database, I have tested this with the Central Admin Content Database only. Also, the script below you will see that when we restore the database, we are getting the LogicalName of the SQL MDF and LDF File from the backup set (your original SharePoint_AdminContent_GUID). Though it’s possible to fire a Alter Database Statement to change the names, running Alter Database statement on SharePoint Databases are not supported and you should refrain from doing that.
This script also has the following prerequisite:
To use this script you need SQL Server Client Components to be installed on the Server and you need the required permissions for backup / restore on SQL. It’s also possible to run the SQL Section of the script on the SQL Box, or put it on the SQL Box as a ps1 file and call it form the script below with –session parameter if you do not have SQL Server Client Components installed on the server.
This script is fully automated and performs the following steps:
- Loads SharePoint and SQL Snap-in
- Detects the Central Admin Site URL
- Populates the required variables like SQL Server Name, Database Name
- Loads SQL Assemblies to get SQL Server Defaults for Backup Location and MDF / LDF File Locations
- Constructs a new Backup File name with TimeStamp
- Creates the Backup Statement and stores it in a String
- Invokes SQLCmd to execute the backup statement – this first runs a full backup and then a Transaction Log backup so that we don’t lose the Tail of the Log (required for all databases with FULL Recovery Model)
- Enters Restore Operation block
- Grabs the LogicalName of the MDF and LDF File from the BackupSet through SQLSMO.Restore object
- Gets the Name of the New Content DB from the User
- Generates the Restore Statement
- Invokes SQLCmd to execute the Restore statement – First the Full backup with NORECOVERY option and then the Transaction Log File
- Comes back to SharePoint Loop – First step is to dismount the Old Content DB
- Mounts the new Content DB to the Web App
- Runs IISRESET
- Provides a remove option to the user – if user selects that option, the database is permanently deleted.