Author Topic: Force USB Drives to use Drive Letter X (Read 47,039 times)

Stoic Joker · « **on:** May 20, 2011, 07:13 PM »

Okay - 5 minute job...that's been going on for a few weeks now.

The tape drive died (they do that), and it was cheaper to buy 5 500GB USB drives than it would be to replace the tape drive. So... I got these 5 USB drives...And I need them to all be drive Z: when they're plugged in (one at a time of course) so that the backup software can find them consistantly...Without needing constant fiddling with.

Now here's the funny part. I've done this before. So I know it will work. I just can't remember how the

I did it.

The obvious answer of using the disk management console, doesn't work. When the drives are swapped, the drive letter assignment goes missing. Now. IIRC...(Ha!)...There was a registry hack - may have been cmd or vbs scripted - that resulted in all drives happily using the same drive letter (when~attached~one~at~a~time...). I just can't bloody find the friggin thing (again), and apparently I forgot to save it back when.

All I can find now is a constant stream of TS drones regurgitating the (wrong) use DMC answer.

Ring any bells anybody?

cranioscopical · « **Reply #1 on:** May 20, 2011, 09:12 PM »

As a stop-gap measure, USB Safely Remove or Zentimo.

TucknDar · « **Reply #2 on:** May 20, 2011, 09:51 PM »

My favourite tool for this is USB Drive Letter Manager - http://www.uwe-sieber.de/usbdlm_e.html

Quote

What it is
USBDLM is a Windows service that gives control over Window's drive letter assignment for USB drives. Running as service makes it independent of the logged on user's privileges, so there is no need to give the users the privilege to change drive letters.
It automatically solves conflicts between USB drives and network or subst drives of the currently logged on user.
Furthermore you can define new default letters for USB drives and much more.

USBDLM is Freeware for private and educational (schools, colleges, universities) use only.

Stoic Joker · « **Reply #3 on:** May 20, 2011, 10:04 PM »

Okay, let me clarify... This is for a Headless production Domain Controller ... Shenanigan software is not an acceptable solution.

"Safe Removal" is irrelevant as caching is disabled on these drives (e.g. Hot-Plugging is O-Tay)
.
There is a correct way of doing this, which involves a registry edit...Which I've used before...I just can't remember the damn thing. And was hoping somebody here did.

Shades · « **Reply #4 on:** May 20, 2011, 11:00 PM »

This link has a lot of tips and code that is supposed to accomplish the task you have in mind.

The link above also mentions the use of the SUBST command, which might be a solution for you as well.

Found one link more regarding: 'Reassigning drive letters automatically'.

Hope it helps.

***EDIT***
This link discusses a useful trick making use of standard Windows functionality.

Stoic Joker · « **Reply #5 on:** May 21, 2011, 12:01 AM »

Not quite ... But I like the way you're thinking.

Here's the thing:
The built-in Server 2008 backup software is absolutely brilliantly simple to setup and use ...(I fell in love with it imediatly)... Unfortunately (budget constraints) we're using a 2003 server because of the x64 hardware requirements for the new(er) versions of Exchange.

The primary PITA is Symantec's Backup Exec which is to stupid to pole for which mounted (to a folder) device is active within a specific backup media set. They're "working on it". This makes the only option to target a specific drive letter for all backups, and then swap the targets. Hence the requirement to have a set of 5 drives all claim to be Target X.

[rant]Symantec charges a friggin kings ransom for Backup Exec which is pathetic considering the flat-out broken half implemented features like this silly shit. How god damn hard is it to check the size of a freaking folder for christ sake?!? Ooh Size=0, next! Found a live one, start the backup. It really is just that fucking simple...but this randy bunch of greedy jack-offs can't quite seem to pull it off.

Count to 5 to get the active target for the nightly backup - Nope, can't do it - It is just too damn hard. But they can sure as hell count to $20,000 in a flash when they ring up you license fees for that busted ass piece of shit.[/rant]

(Hay Renegade, It works ... I feel much better now

)

While subst would work - kind of... - It would require that there be 5 different daily scripts to drop and reassign the drive letter to that day's target (folder mounted) drive. And (here's the bad part), would also assume that the correct drive for that day is/was connected at the time the script ran. Eek!

Edvard · « **Reply #6 on:** May 21, 2011, 06:31 AM »

Can drive letter assignment be scripted, and can you therefore put an autorun script in the root of the drives?
That way, they would auto-assign themselves as they were plugged in.

All internet searches keep pointing to USBDLM as THE solution, so I'm grabbing at straws...

Wait, this may be something: http://forums.techarena.in/windows-server-help/690830.htm
or this: http://www.2brightsparks.com/help/index.php?action=kb&article=12

Stoic Joker · « **Reply #7 on:** May 21, 2011, 02:20 PM »

Quote from: Edvard on May 21, 2011, 06:31 AM

Can drive letter assignment be scripted, and can you therefore put an autorun script in the root of the drives?
That way, they would auto-assign themselves as they were plugged in.

Autorun is disabled and requires a user to be logged in, which is not really guarantee-able on a headless server.

Quote from: Edvard on May 21, 2011, 06:31 AM

All internet searches keep pointing to USBDLM as THE solution, so I'm grabbing at straws...

That's what I keep running into also. I have access to the archive server I set this up on originally, and I've been trying to revers engineer what I did to it...But I'll be damned if I can find it.

There are no scheduled tasks, so it isn't firing a script repeatedly.
USBDLM is not installed or running.
There is no autorun scripts in the root of the drive.
The backup drive shows it's natively drive Z: in the DMC, so it hasn't been subst'es (confirmed by running subst to see nothing listed)

Quote from: Edvard on May 21, 2011, 06:31 AM

Wait, this may be something: http://forums.techarena.in/windows-server-help/690830.htm
or this: http://www.2brightsparks.com/help/index.php?action=kb&article=12

The first one is interesting, but is a reactive run it a loop and look for X script. I'm looking for a proactive do it once done solution. The 2nd one is for the DMC which (doesn't work for this) I'm already intimately familiar with.

While the USBDLM thing is tempting just to get out from under this project ... Using it would mean that if anyone inserted and/or left a ThumbDrive in the server it would be a coin toss as to which one the backup software would toast. e.g. Either the backup would fail (target not found) or it would "succeed" in destroying the contents of the ThumbDrive as the backup was sent to it. (Oh yeah) or both.

...I really don't want to go there...I much prefer my catastrophes one at a time.

Only other Quick-N-Dirty option is/would be to move the CD-ROM out of the way so the external USB backup drives could just grab the then freed up D: Which is not my favorite solution as it's just a variation on the above boo-boo in waiting. Not to mention that drive F: is the network wide DFS root share drive for everything (One of the joys I inherited from my predecessor). So if the backup tried to run to that...We get a snake eating its tail kind of effect. (Not. A. Pretty. Picture.)

Edvard · « **Reply #8 on:** May 21, 2011, 04:57 PM »

I realize my next suggestion is not ideal either, but...

Are there better backup solutions than Symantec's?
I know your company paid good money for it and the support, but this if this is as critical as "one slip and it's bye-bye data" then maybe something else needs to be done.

I know, more straws to grasp at...

Stoic Joker · « **Reply #9 on:** May 21, 2011, 05:42 PM »

Quote from: Edvard on May 21, 2011, 04:57 PM

I realize my next suggestion is not ideal either, but...

Are there better backup solutions than Symantec's?
I know your company paid good money for it and the support, but this if this is as critical as "one slip and it's bye-bye data" then maybe something else needs to be done.

I know, more straws to grasp at...

(Much as I hate to throw the baby out with the bath water...At this point I'm half tempted to set the "baby" on fire, shoot it in the head, and then throw it under a train.)

Let's say it's crossed my mind (more than once). The question is what else will handle the Exchange logs commit operation? And it has to be able to play nice with AD & MSSQL also.

scrolllock · « **Reply #10 on:** May 21, 2011, 05:46 PM »

Quote from: Stoic Joker on May 21, 2011, 02:20 PM

While the USBDLM thing is tempting just to get out from under this project ... Using it would mean that if anyone inserted and/or left a ThumbDrive in the server it would be a coin toss as to which one the backup software would toast. e.g. Either the backup would fail (target not found) or it would "succeed" in destroying the contents of the ThumbDrive as the backup was sent to it. (Oh yeah) or both.

USBDLM can be configured to assign specific letters to specific drives by means of many criteria. Most simple one: The drive type.

; USB hard disks on X..Z
[DriveLetters10]
DriveType=FIXED
Letters=X-Z

; other USB drives on O..W
[DriveLetters90]
Letters=O-W

If you are still concerned someone forgets a USB hard drive, you can specify the right one volume label as criteria.

; "Big Backup" drive on X
[DriveLetters10]
VolumeLabel=Big Backup
Letters=X

Stoic Joker · « **Reply #11 on:** May 21, 2011, 07:06 PM »

Quote from: scrolllock on May 21, 2011, 05:46 PM

If you are still concerned someone forgets a USB hard drive, you can specify the right one volume label as criteria.

; "Big Backup" drive on X
[DriveLetters10]
VolumeLabel=Big Backup
Letters=X

Hm... Okay, I'm weakening...But I gotta mull this over a bit. I'm still hoping I can figure out what I did last time.

Thanks

steeladept · « **Reply #12 on:** May 21, 2011, 08:52 PM »

If you still have the archive server to go back to, can't you Dif the registry? Alternatively, can you make a copy and transfer it to the new server to make it work? I get the feeling I missed something and these have already been done, but I just have to ask.

Stoic Joker · « **Reply #13 on:** May 22, 2011, 02:09 AM »

Quote from: steeladept on May 21, 2011, 08:52 PM

If you still have the archive server to go back to, can't you Dif the registry? Alternatively, can you make a copy and transfer it to the new server to make it work? I get the feeling I missed something and these have already been done, but I just have to ask.

By archive server I mean long term storage of old files. As it's really just a file server...At a client location. Much unlike the domain controller at our office. So comparing/merging the registries is not an option.

elvisbrown · « **Reply #14 on:** June 13, 2011, 11:44 AM »

I've used USBDLM for a few years and it is foolproof. Config is not for the novice but once you have it it always works. Experience, it can save you hours! Peace

40hz · « **Reply #15 on:** June 13, 2011, 12:29 PM »

I had a similar problem. But I didn't have a brilliant solution at the time so I used this workaround.

Instead of insisting on a specific drive letter, take advantage of the fact drive letters get assigned in next available letter sequence when a USB drive gets plugged in.

I just looked at the last fixed harddrive letter (in this case CDEFG were all being used), plugged in a USB key and assigned it one more than the next available letter which in this case is the letter is I. (I set the key to hold a backup of the system state data since I didn't want it to just sit there doing nothing BTW.)

We then set set the backup software to look for the H drive. Because with drive I now 'permanently' occupied by the USB key, it leaves a gap in the sequence, with the next available letter being H. If you remove and then immediately add (as in swap) an external drive, it will always assign it the same letter (H) since it's the next available in sequence (i.e. CDEFG_I).

So why create a gap in the letter sequence? Here's why: Anything that gets plugged in after that will get letter J or higher.

So as long as you're swapping H properly using the remove USB applet - and you immediately replace it with another drive - the drive letter shouldn't change. The backup drive will always get the letter that falls into the gap. And any additional USB drives will grab letter J or higher so it won't affect your designated backup drive letter assignment. No more having the backup drive's letter jumping around.

superboyac · « **Reply #16 on:** June 13, 2011, 04:45 PM »

Quote from: cranioscopical on May 20, 2011, 09:12 PM

As a stop-gap measure, USB Safely Remove or Zentimo.

This is what I use. I know you guys want a free solution. i did too, I tried really hard to make all the suggestions listed here work, but none of them were as nice and easy as USBSR/Zentimo. Totally worth it to me. Good program also.

Stoic Joker · « **Reply #17 on:** June 13, 2011, 04:46 PM »

Quote from: 40hz on June 13, 2011, 12:29 PM

I just looked at the last fixed harddrive letter (in this case CDEFG were all being used), plugged in a USB key and assigned it one more than the next available letter which in this case is the letter is I. (I set the key to hold a backup of the system state data since I didn't want it to just sit there doing nothing BTW.)

We then set set the backup software to look for the H drive. Because with drive I now 'permanently' occupied by the USB key, it leaves a gap in the sequence, with the next available letter being H. If you remove and then immediately add (as in swap) an external drive, it will always assign it the same letter (H) since it's the next available in sequence (i.e. CDEFG_I).

So why create a gap in the letter sequence? Here's why: Anything that gets plugged in after that will get letter J or higher.

Hm... Either there's a hole in your theory, or the server didn't read the same manuals that you did... $:-\$ The used letters on that machine were:
C: - Physical
D: - CD-ROM
F: - Mapped Drive
S: - Physical

So from what you're saying it should pick T: next, yes? It didn't/doesn't *Shrug* I got tired of fiddling with it and Moved the CD-ROM to M: (because I was Mad) so the backups could use D: without tripping over the mapped F: Drive (always a good time).

Don't ya just love it when what's supposed to happen and what does happen aren't even close...

Quote from: 40hz on June 13, 2011, 12:29 PM

So as long as you're swapping H properly using the remove USB applet - and you immediately replace it with another drive - the drive letter shouldn't change. The backup drive will always get the letter that falls into the gap. And any additional USB drives will grab letter J or higher so it won't affect your designated backup drive letter assignment. No more having the backup drive's letter jumping around.

Server headless - Caching disabled ... I'm thinking about filling the other USB parts with Silly Putty ... That'll keep the riff raff out.

40hz · « **Reply #18 on:** June 13, 2011, 05:56 PM »

Quote from: Stoic Joker on June 13, 2011, 04:46 PM

So from what you're saying it should pick T: next, yes?

Nope. It should have picked E: The next available drive letter - not the next letter available after the last drive letter you assigned.

Just checked it on our test server duplicating your setup above to be sure I didn't have my head someplace it shouldn't be.

C: - Physical
D: - CD-ROM
E: - Available (not assigned)
F: - Mapped Drive
G: - Available (not assigned)
S: - Physical

It assigns the external HD I plugged in the letter E. Installed a USB key and allowed it to be assigned a letter. The server chose G which is the next available letter since F has already been assigned as a mapped drive. Removed the drive in E, waited a minute and plugged it back in. It got assigned E again.

C: - Physical
D: - CD-ROM
E: - USB External Drive for backup
F: - Mapped Drive
G: - Flash key (used to test since mapped F has already provided the gap between D and F)
S: - Physical

The reason why you want to have a gap is to have a predictable drive letter for auto assignment. If you have an available letter down low in the alphabet, that will be what gets picked first whenever you plug/unplug your backup drive. Stuff that gets installed afterwards will land above that. Which is no problem because you usually don't need to worry too much about what drive letter gets assigned. Or if you do, you assign it yourself (I always do BTW) in disk manager. As long as the device stays connected, an assigned letter won't change. And t it should be persistent after a reboot.

About the only time it might be a problem is if you have a bunch of USB storage devices that have been auto assigned a letter by a server which gets rebooted unexpectedly. In that case there is a definite chance those drive letters may get switched around if something goes awry with the USB discovery polling. But you should always check your system after a reboot anyway so...

P.S. Moving the CD over to M (funny, I always use R

) makes the next available letter D - which will always get assigned to your backup drive as long as no other USB drive else gets plugged in first. Works the same as my suggestion.

Stoic Joker · « **Reply #19 on:** June 13, 2011, 08:51 PM »

Quote from: 40hz on June 13, 2011, 05:56 PM

Quote from: Stoic Joker on June 13, 2011, 04:46 PM
So from what you're saying it should pick T: next, yes?

Nope. It should have picked E: The next available drive letter - not the next letter available after the last drive letter you assigned.

Okay, that's along the lines of the behavior I am used to/was expecting/experienced. Ya had me thinking I was missing something there for a bit.

USB and Servers are two things I generally like to keep away from each-other. But Tape is just too freaking expensive these days... *Sigh*

Ath · « **Reply #20 on:** June 14, 2011, 06:35 AM »

Uhm, would mounting the USB drive into a subdirectory, as you can do using Disk management, be feasible? I use it to have all my USB sticks (several brands in several capacities) in 1 subdirectory (0-USBdrives) of my harddisk, and it never connects wrong. The 0 is in the name to have it on top of the directorylist for easy discovery when using Explorer.

Stoic Joker · « **Reply #21 on:** June 14, 2011, 12:00 PM »

Quote from: Ath on June 14, 2011, 06:35 AM

Uhm, would mounting the USB drive into a subdirectory, as you can do using Disk management, be feasible? I use it to have all my USB sticks (several brands in several capacities) in 1 subdirectory (0-USBdrives) of my harddisk, and it never connects wrong. The 0 is in the name to have it on top of the directorylist for easy discovery when using Explorer.

That was one of the first things I tried. However you can only mount one drive at a time to any given directory. Which means you'll end up with 5 targets. So...

Unfortunately no, thanks to Symantec's refusal to pole the media pool for the active target/device before running the backup. Which is after all the whole point of having a pool of media to select from. If you restart all the Backup Exec services it will do exactly that (pole the pool), and nail the correct device every time. But that's insanely impractical to do before every backup.

narf41 · « **Reply #22 on:** November 28, 2017, 09:57 PM »

I know this is necro'ing a super old thread, but I couldn't find an answer anywhere online and so once figuring it out I wanted anyone else who stumbled across this to get a solution.

You can clonezilla one of the drives onto another drive. There's also likely a fancy way of doing it by cloning the volume guid but clonezilla worked for my purposes so I didn't look into it.

What I can verify for you is that it does not come from the disk id so modifying this via diskpart is not helpful, and that you can get volume guid's using powershell: GWMI -namespace root\cimv2 -class win32_volume Hopefully somebody smarter than me can figure out how to change or specify volume guid and test it out or at least determine if this is indeed where the reg value comes from so we can dynamically do this without cloning entire drives.

How it works: When you assign a drive letter to a drive windows stores this in the registry under the key hklm\system\mounteddevices. You can observe that when you assign a new drive the X letter (for example) the data portion for the reg_binary (\dosdevices\x: in this case) is overwritten with the new drive and you can't have multiple entries with different values, so the next time you plug in that old drive it won't be X anymore.