script to unmap and remap network drives

Any suggestions on how I could script changing persistent drive mappings on
several hundred user profiles to change the server name they point to?
We're migrating shares from one server to another (a new DFS namespace
actually), and we have a lot of users who have manually mapped drives for
themselves (on top of the ones we map for them with their login scripts).

I need a way to parse the Windows registry and grab all the values for each
drive mapping's "RemotePath" value in HKEY_CURRENT_USER\Network, unmap
anything that points to the old server (e.g. "net use g: /d") and then remap
that same driveletter to the same sharename with a new servername.

Too much to ask?

Thanks for any tips.

Windows Server 2003 domain with a mix of XP and W2K clients.

"Phil McNeill" <> wrote in
message news:%...
> Any suggestions on how I could script changing persistent drive mappings
> on several hundred user profiles to change the server name they point to?
> We're migrating shares from one server to another (a new DFS namespace
> actually), and we have a lot of users who have manually mapped drives for
> themselves (on top of the ones we map for them with their login scripts).
>
> I need a way to parse the Windows registry and grab all the values for
> each drive mapping's "RemotePath" value in HKEY_CURRENT_USER\Network,
> unmap anything that points to the old server (e.g. "net use g: /d") and
> then remap that same driveletter to the same sharename with a new
> servername.
>
> Too much to ask?
>
> Thanks for any tips.
>
> Windows Server 2003 domain with a mix of XP and W2K clients.

Having persistent drive mappings in a domain environment is not
a good idea, as you see yourself right now. This would be a good
time to put your drive mappings into a centralised netlogon file. At
the same time you should turn off persisten connections.

"Pegasus (MVP)" <> wrote in message
news:%...
>
> "Phil McNeill" <> wrote in
> message news:%...
>> Any suggestions on how I could script changing persistent drive mappings
>> on several hundred user profiles to change the server name they point to?
>> We're migrating shares from one server to another (a new DFS namespace
>> actually), and we have a lot of users who have manually mapped drives for
>> themselves (on top of the ones we map for them with their login scripts).
>>
>> I need a way to parse the Windows registry and grab all the values for
>> each drive mapping's "RemotePath" value in HKEY_CURRENT_USER\Network,
>> unmap anything that points to the old server (e.g. "net use g: /d") and
>> then remap that same driveletter to the same sharename with a new
>> servername.
>>
>> Too much to ask?
>>
>> Thanks for any tips.
>>
>> Windows Server 2003 domain with a mix of XP and W2K clients.
>
> Having persistent drive mappings in a domain environment is not
> a good idea, as you see yourself right now. This would be a good
> time to put your drive mappings into a centralised netlogon file. At
> the same time you should turn off persisten connections.

It seems to me that he is mapping non-persistently in his logon scripts, and
that part of the change to a new server will be trivial.

The persistent drive mapping seems to be something that the users are doing
for themselves. Given that this "is not a good idea in a domain
environment", the way *I* would approach this (or the way I would *like* to)
is to say that, since the users created their non-standard mappings, they
are self-supporting, and quite capable of accommodating the change however
they see fit.

When we provide shares for some individuals that appear nowhere in the
standard mappings, I try to avoid encouraging them to map to them, but show
them how to create a shortcut. And if they keep them in a folder on their
home folder, the same shortcuts will be available everywhere they logon. I
also provide a folder full of the more widely used shortcuts on a standard
share and update them myself when things change.

/Al

"Al Dunbar" <> wrote in message
news:%23mW$...
>
> "Pegasus (MVP)" <> wrote in message
> news:%...
>>
>> "Phil McNeill" <> wrote in
>> message news:%...
>>> Any suggestions on how I could script changing persistent drive mappings
>>> on several hundred user profiles to change the server name they point
>>> to?
>>> We're migrating shares from one server to another (a new DFS namespace
>>> actually), and we have a lot of users who have manually mapped drives
>>> for
>>> themselves (on top of the ones we map for them with their login
>>> scripts).
>>>
>>> I need a way to parse the Windows registry and grab all the values for
>>> each drive mapping's "RemotePath" value in HKEY_CURRENT_USER\Network,
>>> unmap anything that points to the old server (e.g. "net use g: /d") and
>>> then remap that same driveletter to the same sharename with a new
>>> servername.
>>>
>>> Too much to ask?
>>>
>>> Thanks for any tips.
>>>
>>> Windows Server 2003 domain with a mix of XP and W2K clients.
>>
>> Having persistent drive mappings in a domain environment is not
>> a good idea, as you see yourself right now. This would be a good
>> time to put your drive mappings into a centralised netlogon file. At
>> the same time you should turn off persisten connections.
>
> It seems to me that he is mapping non-persistently in his logon scripts,
> and
> that part of the change to a new server will be trivial.
>
> The persistent drive mapping seems to be something that the users are
> doing
> for themselves. Given that this "is not a good idea in a domain
> environment", the way *I* would approach this (or the way I would *like*
> to)
> is to say that, since the users created their non-standard mappings, they
> are self-supporting, and quite capable of accommodating the change however
> they see fit.
>
> When we provide shares for some individuals that appear nowhere in the
> standard mappings, I try to avoid encouraging them to map to them, but
> show
> them how to create a shortcut. And if they keep them in a folder on their
> home folder, the same shortcuts will be available everywhere they logon. I
> also provide a folder full of the more widely used shortcuts on a standard
> share and update them myself when things change.
>
> /Al
>
>

Hi guys,

Definitely something that our users are doing themselves, and we DO
discourage it, but some of them do it nonetheless (about 150 of them out of
700 based on some info we've gathered). I do not have the option to tell
them "you brought this on yourself, so too bad for you". Wish I did.

As far as the script goes, I found something online describing the EXACT
problem I'm having (it has to do with the implementation of a DFS
consolidated root and what that does to EXISTING persistent drive mappings).
Turns out I don't need to remap to the new location at all (although that
would be a "nice to have"). After the activation of the consolidated root,
it will be good enough to unmap the persistent drive mappings, and remap
them back to exactly where they pointed to previously. The consolidated
root problem only affects drives mapped BEFORE it was implemented (more info
for anyone interested as to why:
http://www.tech-archive.net/Archive/...4-08/0711.html


The script I found to do this is as follows:

Set objNetwork = WScript.CreateObject("WScript.Network")
Set colDrives = objNetwork.EnumNetworkDrives
For i = 0 to colDrives.Count-1 Step 2
Wscript.Echo colDrives.Item(i) & colDrives.Item (i + 1)
objNetwork.RemoveNetworkDrive colDrives.Item(i)
Wscript.Echo "Check to see if " &colDrives.Item(i) &" is now unavailable"
objNetwork.MapNetworkDrive colDrives.Item(i),colDrives.Item (i + 1)
Wscript.Echo colDrives.Item(i) & " remapped to " & colDrives.Item (i+1)
Next

I've tested calling this at the bottom of our existing logon scripts, and it
works fine, except for a few things that I'm hoping you can help with.

1. I NEED it to be non-interactive/quiet. Right now it prompts the user 3
times for EACH drive mapping.

2. I NEED it to ignore the H: drive. Right now it coughs on the H: drive
(standard drive mapping for home directories), presumably because we have a
single share for home directories, and each user maps to their specific
folder WITHIN that share that only they have access to. Windows sees that
connection below the share level as an open file, and this script can't kill
that to unmap and re-map the drive, so it quits with an error.

It would still be NICE if we could remap to the new location, but if I can
take care of those two NEEDS above, that'd be sufficient to allow us to
implement the consolidated root without killing all these manually mapped
drives.

Any help greatly appreciated!

Thanks,

Phil

"Phil McNeill" <> wrote in
message news:O$...
>
> Hi guys,
>
> Definitely something that our users are doing themselves, and we DO
> discourage it, but some of them do it nonetheless (about 150 of them out
> of 700 based on some info we've gathered). I do not have the option to
> tell them "you brought this on yourself, so too bad for you". Wish I did.
>

My users never do it, simply because persistency gets turned
off on all machines by the logon script. This makes central
administration much, much easier.

<snip>

"Pegasus (MVP)" <> wrote in message
news:%...
>
> "Phil McNeill" <> wrote in
> message news:O$...
>>
>> Hi guys,
>>
>> Definitely something that our users are doing themselves, and we DO
>> discourage it, but some of them do it nonetheless (about 150 of them out
>> of 700 based on some info we've gathered). I do not have the option to
>> tell them "you brought this on yourself, so too bad for you". Wish I
>> did.
>
> My users never do it, simply because persistency gets turned
> off on all machines by the logon script. This makes central
> administration much, much easier.
>
> <snip>
>

You must have a different kind of management than I do. I can just imagine
the meeting where I tell my managers that I want to turn off that
functionality because it will make things easier to manage. My management
environment is a little closer to the type the admin in California who
locked down the entire network thought he was living in. Thankfully I don't
let it bother me as much as he obviously did. In the time I've been here
I've managed to take us from share to file level permissions for security,
and from over 100 shares down to around 15. I'm counting my blessings with
that.

Anyway, any help with the script would be appreciated.

Thanks!

"Phil McNeill" <> wrote in
message news:...
>
> "Pegasus (MVP)" <> wrote in message
> news:%...
>>
>> "Phil McNeill" <> wrote in
>> message news:O$...
>>>
>>> Hi guys,
>>>
>>> Definitely something that our users are doing themselves, and we DO
>>> discourage it, but some of them do it nonetheless (about 150 of them out
>>> of 700 based on some info we've gathered). I do not have the option to
>>> tell them "you brought this on yourself, so too bad for you". Wish I
>>> did.
>>
>> My users never do it, simply because persistency gets turned
>> off on all machines by the logon script. This makes central
>> administration much, much easier.
>>
>> <snip>
>>
>
> You must have a different kind of management than I do. I can just
> imagine the meeting where I tell my managers that I want to turn off that
> functionality because it will make things easier to manage. My management
> environment is a little closer to the type the admin in California who
> locked down the entire network thought he was living in. Thankfully I
> don't let it bother me as much as he obviously did. In the time I've
> been here I've managed to take us from share to file level permissions for
> security, and from over 100 shares down to around 15. I'm counting my
> blessings with that.
>
> Anyway, any help with the script would be appreciated.
>
> Thanks!

I had the good fortune to set up my IT environments from scratch and
educate my clients at the same time. When they want access to a
new share then they ask for it and I put it into their profile the same day.
This means that I know of every user what shares he's got mapped to
which drive letter.

You can walk around your problem with a scripting solution, keeping
in mind that it will rear its ugly head again next time when you change
servers. Here is the batch file you could call from your logon script:
01. @echo off
02. set OldName=Pegasus
03. set NewName=Nalle
04.
05. net use | find /i "%OldName%" > nul || goto :eof
06. for /F "tokens=2-3" %%a in ('net use ^| find "\\"') do call :Sub %%a %%b
%%c
07. goto :eof
08.
09. :Sub
10. set DriveLetter=%1
11. if %DriveLetter:~1,1%==: goto Letter
12.
13. :NoLetter
14. set ShareName=%1
15. call set ShareName=%%ShareName:%OldName%=%NewName%%%
16. echo net use %1 /d
17. echo net use %ShareName%
18. goto :eof
19.
20. :Letter
21. set ShareName=%2
22. set ShareName=%ShareName:Pegasus=Nalle%
23. echo net use %DriveLetter% /d
24. echo net use %DriveLetter% %ShareName%

Instructions:
- Adjust lines #02 and #03 to suit your environment.
- Test the batch file on a few machines.
- When satisfied, remove the word "echo" from line #16, 17, 23 and 24.

Please note: The batch file will not work if your share names have
embedded spaces or "poison" characters such as "%^().

"Pegasus (MVP)" <> wrote in message
news:...


> I had the good fortune to set up my IT environments from scratch and
> educate my clients at the same time. When they want access to a
> new share then they ask for it and I put it into their profile the same
> day.
> This means that I know of every user what shares he's got mapped to
> which drive letter.

I walked into an environment where they were running OS2 Lanserver (with a
different share for almost every file it seemed) and we're now at Windows
Server 2003 with a stop off at NT 4.0 along the way. More than a brand new
environment, I need brand new users. The environment is easy to change.
The users, not so much.

> You can walk around your problem with a scripting solution, keeping
> in mind that it will rear its ugly head again next time when you change
> servers.

The beauty of it is that this SHOULD be the last time we change names.
We're implementing a domain-based DFS namespace, with a consolidated DFS
root as an interim step to ease the migration. People will never map to a
server name again. They'll map to the namespace.

Here is the batch file you could call from your logon script:
> 01. @echo off
> 02. set OldName=Pegasus
> 03. set NewName=Nalle
> 04.
> 05. net use | find /i "%OldName%" > nul || goto :eof
> 06. for /F "tokens=2-3" %%a in ('net use ^| find "\\"') do call :Sub %%a
> %%b %%c
> 07. goto :eof
> 08.
> 09. :Sub
> 10. set DriveLetter=%1
> 11. if %DriveLetter:~1,1%==: goto Letter
> 12.
> 13. :NoLetter
> 14. set ShareName=%1
> 15. call set ShareName=%%ShareName:%OldName%=%NewName%%%
> 16. echo net use %1 /d
> 17. echo net use %ShareName%
> 18. goto :eof
> 19.
> 20. :Letter
> 21. set ShareName=%2
> 22. set ShareName=%ShareName:Pegasus=Nalle%
> 23. echo net use %DriveLetter% /d
> 24. echo net use %DriveLetter% %ShareName%
>
> Instructions:
> - Adjust lines #02 and #03 to suit your environment.
> - Test the batch file on a few machines.
> - When satisfied, remove the word "echo" from line #16, 17, 23 and 24.
>
> Please note: The batch file will not work if your share names have
> embedded spaces or "poison" characters such as "%^().
>

This is great! Thank you. I'll play with it. The namespace is in the
format "domainname/dfsroot" effectively making that the "NewName". Any
issue with the "/"?

Thanks for your help!

"Phil McNeill" <> wrote in
message news:...

< snip >
>
> This is great! Thank you. I'll play with it. The namespace is in the
> format "domainname/dfsroot" effectively making that the "NewName". Any
> issue with the "/"?
>
> Thanks for your help!

Forward slashes are OK but you must test the batch file.

"Pegasus (MVP)" <> wrote in message
news:...
>
> "Phil McNeill" <> wrote in
> message news:...
>
> < snip >
>>
>> This is great! Thank you. I'll play with it. The namespace is in the
>> format "domainname/dfsroot" effectively making that the "NewName". Any
>> issue with the "/"?
>>
>> Thanks for your help!
>
> Forward slashes are OK but you must test the batch file.
>

No worries, I test ad nauseum before dumping something out to 700 users. I
like having a job.

I've tried it out, and it seems to unmap and remap the drives to the same
location they were originally mapped to. This actually does solve my
critical issue, as a freshly mapped drive AFTER the consolidated root is put
in place will work, whereas one that already existed would not (even if they
point to the same place). However, if you have a chance to have a look and
can determine why it won't repath to the new servername, it would be
appreciated. The only other thing I changed in it (aside from your
instructions) was line 22, subbing in "OldName" for Pegasys and "NewName"
for Nalle.

Thanks!