DFS and USB Stick Mystery

[Uncle Gord]

Discovered one of the weirdest problems I've ever come across today, and wondered if anyone had seen anything vaguely similar.

Client is piloting a DFS migration, had been fine for 2 weeks but this week reported some oddities that started last weekend. One of their network drives, mapped by a login script, was reverting back to the old f&p UNC server path; this didn't seem possible given the logic in the scripts, however I think it may be a simpe case of contention and the script perhaps getting ahead of itself, so I think I've cracked that bit..

The oddity is that an E: drive has also appeared few times showing as a disconnected network drive mapping, but none of the scripts ever map anything to an E: drive; first appeared last weekend when the client was working offline (they use offline files, a lot!)..

Checked through the registry and the only evidence of an E: drive appears to have been from a locally mounted device (HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\DosDevices\E: ), probably a USB device, that's either been attached by the client or the person who made the build at some point.

So I told them this in a mail yesterday... and this morning (wasn't there unfortunately) his phantom E: drive appeared again. Someone else was with the client when he noticed and they suggested plugging in his USB stick to see what happened. Rather than mount it with a different drive label, namely F:, XP mounted it to the E: drive and when they browsed into it they found they weren't looking at the contents of the USB drive; it turns out what they were looking at, and happily browsing through, was the contents of the DFS root directory....... disconnected the stick and the E: drive vanished with it.

What the hell??? Normally if someone non-technical tells me something like this I take it with a pinch of salt, but the other guy who saw it and suggested trying the USB stick has a fairly good techie background.

Unsurprisingly I can't find anything on t'interweb about this, so I thought I'd ask you guys ..

 

[slylittlefox]

Sorry I can't be of more help That's seriously strange. Consider Ghostbusters, or the cast of Round the Twist.

 

[Uncle Gord]

 

[Yamahahahahaha]

So they plugged the USB stick in which obviously made the drive connected.
Then double clicking on it, started browsing DFS root?

I have a feeling it's something to do with the script not mapping the drives properly, either through a conflict with a GPO or another script.

 

[Uncle Gord]

So they plugged the USB stick in which obviously made the drive connected. Then double clicking on it

Yep, exactly..

I have a feeling it's something to do with the script not mapping the drives properly, either through a conflict with a GPO or another script.

They only have one drive mapped by way of a script and that's the one that keeps reverting back to the old f&p UNC mapping, which is still happening after I thought I'd cracked it yesterday. The new script performs the DFS migration tasks when it's first run (updating offline files paths, forcing a full sync) and then continues to act like a fairly noddy drive mapping script; deletes the existing drive if it's present, pauses for 5 seconds then remaps the drive with the DFS path.

There's not a lot else going on, so I think you're right that there's some conflict or contention between the 2 which is what I've been trying to establish today; the scripts are not configured to run synchronously in this environment so it's possible they're partly running at the same time once the user session starts.

Still don't get this E: drive issue though, which the client is certain first occured when working offline at home, so no scripts; only appeared twice and I can't reproduce it. None of the scripts specifically map to the E: drive, though it is the next available drive letter.