Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from: https://blog.jermdavis.dev/posts/2014/getting-over-enthusiastic-with-sims-delete-function

Getting over-enthusiastic with SIM's Delete function...

Published 30 June 2014
Updated 25 August 2016

As I've mentioned previously, I'm finding that getting new instances of Sitecore installed on a development machine is a bit of a "horses for courses" thing. Quick instances needed to test something or do some development that's not sensitive to precise configuration can be created quickly and easily with SIM. But sometimes I need to do some work that relies on me setting up the instance in as close as possible a way to how the production instance should be. That usually involves running the Sitecore installer.

There's generally no problem with running instances created in different ways – Sitecore installs sit happily side-by-side without affecting each other. But where this sometimes goes a bit wrong is when I need to tidy up old instances.

Consider this scenario: I install a test instance using the Sitecore installer and name it "TestOne". Later on I delete it using SIM:

InstallOne

Then further on down the road I need to install another instance with the same name... But now the Sitecore installer won't let me. I will get an error:

InstallTwo

What's going on here?

Clearly the Sitecore installer is saving some data somewhere that prevents it from re-using an instance name. But how? Lets try watching what the installer does using Process Monitor. That tool can monitor all of the inputs and outputs of a process and display them to us, so we can see what it's doing.

Now by default Process Monitor captures a great deal of data, so we need to set up filters to ensure that we only see a sensible amount of data. They key filter to add is one to restrict the data to the windows process we're interested in. We can fire up an instance of the Sitecore installer and drag the "target" icon onto it to set a filter to just the installer's process:

Filter

Then when we click through to the "Add or remove" page of the wizard, a load of data will be captured:

Keys

Some of those entries look interesting – it's reading registry keys from a node called "Sitecore CMS". Lets have a look at what's there through RegEdit. Opening up the path HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sitecore CMS\:

Registry

There's a set of registry keys here with GUIDs for names, and each one contains a collection of keys, one of which is "InstanceName" – and look, here's that instance name we couldn't re-install. Let's try deleting the appropriate GUID-folder (to get rid of the data about this instance) and then try running the installer again. (Usual registry-related disclaimer applies: It's quite possible to break your computer by messing with the Registry. If you're not confident, back up first!)

Success

Success! With that registry key removed, the validation for that instance name passes, and we're free to re-use the instance name.

Footnote: The registry node Wow6432Node has a special meaning - it's part of the infrastructure that is used to enable 32bit code to run on 64bit windows. Hence, were you to look for the registry data discussed above on a 32bit system it would be found in a different location. These days it's probably pretty unlikely that you'd try installing Sitecore on a 32bit copy of Windows – but just in case, try the HKEY_LOCAL_MACHINE\SOFTWARE\Sitecore CMS\ registry node instead.

↑ Back to top