How to downgrade SQL Standard Edition to SQL Express - running SharePoint
How to downgrade SQL Standard Edition to SQL Express - running SharePoint
Sometimes mistakes get made, imagine checking an SQL Express installation and finding SQL Standard Edition installed.
To make this harder to find, the SQL Standard instance was named SQLExpress in Services.
Run a SQL @@version to get the truth.
Overview
We'll use a Hyperv replica at the DR site for preparing the recipient server, a clone of production. You could also export the production server and configure as a new virtual machine.
This example SharePoint 2013 installation with SQL2008R2 Standard
Process fist run - without impacting production (takes about an hour)
- Confirm the production SQL server DNS name is locked in with a static entry. This is to prevent overwrite when starting up your recipient server.
- On the recipient new server:
- Configure the recipient server as a new virtual machine on a different subnet from production to prevent name clash.
- Start the recipient server, set an IP address skip the gateway address, confirm SQL is running, then make a note of the file locations for the database master files.
- Make a note of the running SQL version / patch level
- Stop SQL service on the recipient server and set to disabled.
- Rename the database master files folder.
- Uninstall SQL from add remove programs.
- Install SQL Express with a matching version and patch to the same level as the SQL Standard.
- Complete the installation and restart, confirm SQL is running (with no user databases).
- Stop SQL service.
- COPY back from the renamed SQL folder and overwrite the new SQL files (which will have the same folder location as the original had).
- Start SQL service.
- All going well SQL will start with the original databases running, permissions intact and accessible with the original SQL service name.
(If you accidentally deleted then copied in the SQL files you will need to add permission for the SQL service to modify the SQL files.
For migration
Now that the technique is perfected...
We implement a change freeze for production, a couple of hours should do it.
And copy out the database files to the new server.
The Hyper-v way to do this (15-minutes)
- Use a replica of the production server at the DR site
- Replication Start Test Failover, but don't bother starting the virtual machine.
- Open the test failover server properties and copy the hard disk path and filename of the drive which contains your database files.
- Open the recipient new server properties and Add a new hard disk with the path you have copied.
- In the recipient server, open disk properties and initialise the new disk.
- Stop the SQL service
- Use File Explorer now to Copy the database files from the new drive (most recent replica of production) over the top of the SQL files (our testing files from earlier).
- Start the SQL service
- Check event logs for clean startup
Into production (15-minutes or longer depending on bandwidth from DR to prod)
- Replicate our new server back to the production site.
- Shutdown the old Production server
- Failover the new server and start in production, set the IP address and gateway. Might as well reverse the replication at the same time to have DR ready to go.
- Job done
Notes
Testing SharePoint from the local host at DR will need host file entries for the urls pointing to the DR server, and a registry key to permit localhost access: Ref: https://support.microsoft.com/en-us/kb/896861
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
- Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
Comments
Post a Comment