While installing the EMC SnapView software, we had a problem with our LUNs not “anchoring”.  We clone the drives, then use mountvol to mount them.  We then change the LUNs to the appropriate drives for our SQL Server instances.  The problem was that the drives would move everytime we rebooted the machine, which is not something you really want happening on a SQL Server installation (or any other type of installation I can think of at the moment).

After EMC researched the issue for several days and discovered they really had no idea what they were doing, I found out that the problem was the registry.  Under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\, there are keys for the volume name of a drive and the volume letter of a drive.  For example: 

 VolumeName:  \??\Volume{6f2f7016-57fa-11d8-af91-806e6f6e6963}
 VolumeLetter:  c:
 Key:  0x1DAD3BC2007E000000000000

The problem we were experiencing was caused by Windows changing the drive letters, but not the Key.  Because of this, they VolumeName would still be pointed to the old Key, which was for a different drive letter.  Every time you rebooted, it would resolve back to that old drive.  I fixed the problem by hacking the registry basically.  I deleted the old keys completely, and made sure the Keys matched for the VolumeName and VolumeLetter. 

We have not had the issue with drives moving since this.  Unfortunately though, since I dont' want to take the chance of this happening again when I set up new clones or change things, I need to build the logic into my script to resolve this.  Here is what I'm planning.

Before I change the drive letters I will run:

EXEC master..xp_instance_regread 'HKEY_LOCAL_MACHINE','SYSTEM\MountedDevices','\DosDevices\D:'
EXEC master..xp_instance_regread 'HKEY_LOCAL_MACHINE','SYSTEM\MountedDevices','\??\Volume{6f2f7013-57fa-11d8-af91-806e6f6e6963}'

for example to get the registry keys for both the drive and volume names of the cloned drives.  I will then change the drive letters and get the registry keys for the new drive and volume names.  If there is a mismatch, I will delete the old keys using xp_instance_regdeletekey.  I will then use xp_instance_regwrite to match the drive and volume keys to each other.

We're doing this in SQL because our entire process is already written in SQL and I don't want to introduce anything else into the environment at this stage in the game.

Does anyone have a script written that already does this so I'm not wasting my time?  :)

When I am done, I plan on posting the entire process on my website so somebody else doesn't pay EMC $50k to come in and try to figure out how to get this to work.  Since we wrote all the scripts, EMC hasn't really done anything for us.  They actually had to research how the command line tools worked when they came here, which I just foolishly assumed the experts would already know.  That's kind of like a DBA having to research how the BACKUP command works and charging $50k for it.  They could have given me a book with the examples and we would be further ahead.

Favorite words used: 2 (foolishly, assumed) --Not much of a blog from this perspective.  :)

Mean level (1-10):  2 (I've ranted enough about EMC already.)

Education level (1-10):  7 (It's been a learning experience for me anyway.  Hopefully, someone can pour some knowledge on me.)

Entertainment level (1-10): -5 (If this entertained you, ummmmm I don't really know what to say.)