script to unmap and remap network drives
Phil McNeill
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.
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
message news:%239WL59n...@TK2MSFTNGP05.phx.gbl...
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.
Al Dunbar
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
news:%23DD4Dbo...@TK2MSFTNGP03.phx.gbl...
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
Phil McNeill
"Al Dunbar" <Alan...@hotmail.com.nospaam> wrote in message
news:%23mW$lMs7IH...@TK2MSFTNGP03.phx.gbl...
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/Windows/microsoft.public.windows.server.migration/2004-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
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
>
> 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>
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
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!
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
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 "%^().
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
> 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. :)
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!
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
< 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.
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
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!
Phil McNeill
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
Sorry, I just realized re-reading your response that I told you incorrectly
that the new format is "domainname/dfsroot". It is "domainname\dfsroot"
(backslash).
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
Since the batch file worked as expected on my machine, my response
is standard in such cases: Post your version of the batch file!
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
Ha, ya, was just about to do that. For testing purposes I have mapped a
single drive (Y:) on my test machine to \\fab4\common . There is a share
named "common" on another server named "clapton". Below is a copy and paste
of the batch file I'm running (with the line numbering added of course). I
am running the file as the logon script to the user account I'm using to
test with (as opposed to appending it to an existing script).
Doesn't seem to want to remap in the new location for some reason. When I
run the same script just at the command prompt while already logged in this
is the output I get:
C:\root>driveremap2.bat
net use Y: /d
net use Y: \\fab4\common
It seems to just map back to the original location.
Here's my script:
01. @echo off
02. set OldName=fab4
03. set NewName=clapton
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:OldName=NewName%
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
Sorry, my mistake - insufficient testing! Try this version:
01. @echo off
02. set OldName=fab4
03. set NewName=clapton
04.
05. rem net use | find /i "%OldName%" > nul || goto :eof
06. for /F "tokens=2-3" %%a in ('net use ^| find "\\"') do call :Sub %%a %%b
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. call set ShareName=%%ShareName:%OldName%=%NewName%%%
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
Thanks. The output looks correct now:
C:\Documents and Settings\philm\My Documents>remapjul31.bat
net use Y: /d
net use Y: \\clapton\common
Only problem is, it doesn't work. :( The drive stays mapped to the old
location. I don't think it's being deleted and recreated at all. It's
bizarre, as if I manually enter each of the net use commands it works fine.
I created my own little two line batch file running just those two specific
commands (without the built in smarts to look at the existing drives), and
it works succesfully with the following output:
"C:\Documents and Settings\philm\My Documents>tryagain.bat
C:\Documents and Settings\philm\My Documents>net use y: /d
y: was deleted successfully.
C:\Documents and Settings\philm\My Documents>net use y: \\clapton\common
The command completed successfully."
The one difference I see is that there are two distinct lines of output.
Not sure why the one you provided doesn't actually do anything, as the
output seems to indicated that it has. :(
Thanks for your efforts!
Pegasus (MVP)
"Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
Since there is no difference between running a command from
the Command Prompt or from within a batch file (other than
some quirk relating to indexing variables), there must be a
difference in the command itself. Your challenge is to isolate
this difference. The following variant of my batch file will help
you:
01. @echo off
02. set OldName=fab4
03. set NewName=clapton
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
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 on
17. echo net use %1 /d
18. net use
19. echo net use %ShareName%
20. net use
21. @echo off
22. pause
23. goto :eof
24.
25. :Letter
26. set ShareName=%2
27. call set ShareName=%%ShareName:%OldName%=%NewName%%%
28. @echo on
29. net use %DriveLetter% /d
30. net use
31. net use %DriveLetter% %ShareName%
32. net use
33. @echo off
34. pause
Phil McNeill
"Pegasus (MVP)" <I....@fly.com.oz> wrote in message
I think it must have been a timing issue with the original file that is
corrected by this latest one with the injection of the "net use" commands to
list the current drive mappings. I'm guessing that slows things down enough
to allow the unmapping and remapping to not stomp on each other. Not sure,
but running that as you've written it works, without any adjustment. Remove
the pause from the end and it looks like I've got something I can use (after
a little more testing).
Thank you VERY much for your help. That's going to make this much easier.
:)
Pegasus (MVP)
> I think it must have been a timing issue with the original file that is
> corrected by this latest one with the injection of the "net use" commands
> to list the current drive mappings. I'm guessing that slows things down
> enough to allow the unmapping and remapping to not stomp on each other.
> Not sure, but running that as you've written it works, without any
> adjustment. Remove the pause from the end and it looks like I've got
> something I can use (after a little more testing).
>
> Thank you VERY much for your help. That's going to make this much easier.
> :)
Thanks for the feedback.
Ken Giese
I copied the script and saved the file as remapping.bat.
When I run the mapping.bat file I get the output saying the drive is remapped, but it is not.
Mapping.bat:
@echo off
set OldName=dc3
set NewName=htc4
net use | find /i "%OldName%" > nul || goto :eof
for /F "tokens=2-3" %%a in ('net use ^| find "\\"') do call :Sub %%a %%b
goto :eof
:Sub
set DriveLetter=%1
if %DriveLetter:~1,1%==: goto Letter
:NoLetter
set ShareName=%1
call set ShareName=%%ShareName:%OldName%=%NewName%%%
echo net use %1 /d
echo net use %ShareName%
goto :eof
:Letter
set ShareName=%2
call set ShareName=%%ShareName:%OldName%=%NewName%%%
echo net use %DriveLetter% /d
echo net use %DriveLetter% %ShareName%
Results:
D:\scripts\Printer Scripts>mapping.bat
net use M: /d
net use M: \\htc1\kgiese
net use \\htc1\public /d
net use \\htc1\public
net use U: /d
net use U: \\htc4\Share
net use \\htc2\Visio2007 /d
net use \\htc2\Visio2007
U: is still mapped to DC3\share
Not sure what I am doing wrong or missing.
>> On Friday, July 25, 2008 2:46 PM Pegasus \(MVP\) wrote:
>> "Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
>> message news:%239WL59n...@TK2MSFTNGP05.phx.gbl...
>>
>> 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.
>>> On Friday, July 25, 2008 9:58 PM Al Dunbar wrote:
>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>> news:%23DD4Dbo...@TK2MSFTNGP03.phx.gbl...
>>>
>>> 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
>>>> On Monday, July 28, 2008 10:16 AM Phil McNeill wrote:
>>>> "Al Dunbar" <Alan...@hotmail.com.nospaam> wrote in message
>>>> news:%23mW$lMs7IH...@TK2MSFTNGP03.phx.gbl...
>>>>
>>>> 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. :)
>>>>
>>>>> On Monday, July 28, 2008 10:35 AM Pegasus \(MVP\) wrote:
>>>>> 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>
>>>>>> On Monday, July 28, 2008 11:06 AM Phil McNeill wrote:
>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>> news:%23wRZu8L...@TK2MSFTNGP03.phx.gbl...
>>>>>>
>>>>>> 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!
>>>>>>> On Monday, July 28, 2008 12:27 PM Pegasus \(MVP\) wrote:
>>>>>>> "Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
>>>>>>> message news:OQhAdOM8...@TK2MSFTNGP05.phx.gbl...
>>>>>>>
>>>>>>> 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 "%^().
>>>>>>>> On Monday, July 28, 2008 12:52 PM Phil McNeill wrote:
>>>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>>>> news:OYbmk7M8...@TK2MSFTNGP02.phx.gbl...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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. ;)
>>>>>>>>
>>>>>>>>
>>>>>>>> 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:
>>>>>>>>
>>>>>>>> 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!
>>>>>>>>> On Monday, July 28, 2008 1:06 PM Pegasus \(MVP\) wrote:
>>>>>>>>> < snip >
>>>>>>>>>
>>>>>>>>> Forward slashes are OK but you must test the batch file.
>>>>>>>>>> On Monday, July 28, 2008 1:26 PM Phil McNeill wrote:
>>>>>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>>>>>> news:OTxZIRN8...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>>>
>>>>>>>>>> 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!
>>>>>>>>>>> On Monday, July 28, 2008 1:28 PM Phil McNeill wrote:
>>>>>>>>>>> Sorry, I just realized re-reading your response that I told you incorrectly
>>>>>>>>>>> that the new format is "domainname/dfsroot". It is "domainname\dfsroot"
>>>>>>>>>>> (backslash).
>>>>>>>>>>>> On Monday, July 28, 2008 1:49 PM Pegasus \(MVP\) wrote:
>>>>>>>>>>>> Since the batch file worked as expected on my machine, my response
>>>>>>>>>>>> is standard in such cases: Post your version of the batch file!
>>>>>>>>>>>>> On Monday, July 28, 2008 2:45 PM Phil McNeill wrote:
>>>>>>>>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>>>>>>>>> news:uTopepN8...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha, ya, was just about to do that. For testing purposes I have mapped a
>>>>>>>>>>>>> single drive (Y:) on my test machine to \\fab4\common . There is a share
>>>>>>>>>>>>> named "common" on another server named "clapton". Below is a copy and paste
>>>>>>>>>>>>> of the batch file I'm running (with the line numbering added of course). I
>>>>>>>>>>>>> am running the file as the logon script to the user account I'm using to
>>>>>>>>>>>>> test with (as opposed to appending it to an existing script).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Doesn't seem to want to remap in the new location for some reason. When I
>>>>>>>>>>>>> run the same script just at the command prompt while already logged in this
>>>>>>>>>>>>> is the output I get:
>>>>>>>>>>>>>
>>>>>>>>>>>>> C:\root>driveremap2.bat
>>>>>>>>>>>>> net use Y: /d
>>>>>>>>>>>>> net use Y: \\fab4\common
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems to just map back to the original location.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's my script:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 01. @echo off
>>>>>>>>>>>>> 02. set OldName=fab4
>>>>>>>>>>>>> 03. set NewName=clapton
>>>>>>>>>>>>> 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:OldName=NewName%
>>>>>>>>>>>>> 23. echo net use %DriveLetter% /d
>>>>>>>>>>>>> 24. echo net use %DriveLetter% %ShareName%
>>>>>>>>>>>>>> On Monday, July 28, 2008 4:03 PM Pegasus \(MVP\) wrote:
>>>>>>>>>>>>>> "Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
>>>>>>>>>>>>>> message news:OIl4yIO8...@TK2MSFTNGP03.phx.gbl...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry, my mistake - insufficient testing! Try this version:
>>>>>>>>>>>>>> 01. @echo off
>>>>>>>>>>>>>> 02. set OldName=fab4
>>>>>>>>>>>>>> 03. set NewName=clapton
>>>>>>>>>>>>>> 04.
>>>>>>>>>>>>>> 05. rem net use | find /i "%OldName%" > nul || goto :eof
>>>>>>>>>>>>>> 06. for /F "tokens=2-3" %%a in ('net use ^| find "\\"') do call :Sub %%a %%b
>>>>>>>>>>>>>> 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. call set ShareName=%%ShareName:%OldName%=%NewName%%%
>>>>>>>>>>>>>> 23. echo net use %DriveLetter% /d
>>>>>>>>>>>>>> 24. echo net use %DriveLetter% %ShareName%
>>>>>>>>>>>>>>> On Thursday, July 31, 2008 10:56 AM Phil McNeill wrote:
>>>>>>>>>>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>>>>>>>>>>> news:unlSA0O8...@TK2MSFTNGP05.phx.gbl...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks. The output looks correct now:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> C:\Documents and Settings\philm\My Documents>remapjul31.bat
>>>>>>>>>>>>>>> net use Y: /d
>>>>>>>>>>>>>>> net use Y: \\clapton\common
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only problem is, it doesn't work. :( The drive stays mapped to the old
>>>>>>>>>>>>>>> location. I don't think it's being deleted and recreated at all. It's
>>>>>>>>>>>>>>> bizarre, as if I manually enter each of the net use commands it works fine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I created my own little two line batch file running just those two specific
>>>>>>>>>>>>>>> commands (without the built in smarts to look at the existing drives), and
>>>>>>>>>>>>>>> it works succesfully with the following output:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "C:\Documents and Settings\philm\My Documents>tryagain.bat
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> C:\Documents and Settings\philm\My Documents>net use y: /d
>>>>>>>>>>>>>>> y: was deleted successfully.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> C:\Documents and Settings\philm\My Documents>net use y: \\clapton\common
>>>>>>>>>>>>>>> The command completed successfully."
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The one difference I see is that there are two distinct lines of output.
>>>>>>>>>>>>>>> Not sure why the one you provided doesn't actually do anything, as the
>>>>>>>>>>>>>>> output seems to indicated that it has. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for your efforts!
>>>>>>>>>>>>>>>> On Thursday, July 31, 2008 11:25 AM Pegasus \(MVP\) wrote:
>>>>>>>>>>>>>>>> "Phil McNeill" <philm...@REMOVETEXTINCAPShydroottawa.com> wrote in
>>>>>>>>>>>>>>>> message news:OoV3J3x8...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>>>>>>>>>> On Thursday, July 31, 2008 3:33 PM Phil McNeill wrote:
>>>>>>>>>>>>>>>>> "Pegasus (MVP)" <I....@fly.com.oz> wrote in message
>>>>>>>>>>>>>>>>> news:%23cxE8Gy...@TK2MSFTNGP05.phx.gbl...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it must have been a timing issue with the original file that is
>>>>>>>>>>>>>>>>> corrected by this latest one with the injection of the "net use" commands to
>>>>>>>>>>>>>>>>> list the current drive mappings. I'm guessing that slows things down enough
>>>>>>>>>>>>>>>>> to allow the unmapping and remapping to not stomp on each other. Not sure,
>>>>>>>>>>>>>>>>> but running that as you've written it works, without any adjustment. Remove
>>>>>>>>>>>>>>>>> the pause from the end and it looks like I've got something I can use (after
>>>>>>>>>>>>>>>>> a little more testing).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you VERY much for your help. That's going to make this much easier.
>>>>>>>>>>>>>>>>>> On Thursday, July 31, 2008 3:38 PM Pegasus \(MVP\) wrote:
>>>>>>>>>>>>>>>>>> Thanks for the feedback.