Skip to content

Instantly share code, notes, and snippets.

@potatoqualitee
Created September 8, 2014 11:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save potatoqualitee/7fbfbd0976bace497838 to your computer and use it in GitHub Desktop.
Save potatoqualitee/7fbfbd0976bace497838 to your computer and use it in GitHub Desktop.
1. Took note at the exact version of SQL Server, down to the build number
2. Made backups of all databases, including the system databases
3. Stopped the SQL server role within the Failover Cluster Manager
4. Once the disks went offline within Windows, took a storage-level snapshot of the shared disks. I named this snap “ent version”.
5. Copied the system databases, and their logs (mdfs and ldfs) to backup directories just in case the snapshot didn’t work (one can never be too safe)
6. Used VMware to snapshot both Windows nodes (alternatively, you can shut them down and snap them at the storage level)
7. Uninstalled SQL Server from both nodes using the Remove Node from Cluster option. This will delete the system dbs, but not the user dbs.
8. Deleted templog.ldf from my system directory (it was the only one that the uninstall didn’t get rid of)
9. Reinstalled SQL Server Standard exactly as Enterprise was before on both nodes – down to the IP, service account, name, directory structure, filestream share etc.
10. Patched both nodes of SQL Server until I was back at the same build
11. Ensured the SQL role was stopped within the cluster and that disks were offline
12. Snapshotted the storage again, naming this snap “std version”
13. Restored storage back to “ent version”
14. Started SQL role within the cluster
15. Voila! The version was now SQL Standard and all of my dbs/logins/settings were just as they were.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment