none
Cant unmap a Shared Drive with my script

    Question

  • Awhile back I moved the location of a Shared Drive which all my users map to. I have a simple logon script that maps the new location, I also have one that is "Supposed" to unmap the old Shared Drive however it is not working for some reason.

    @echo off
    net use S: \\ServerName\SharedDriveName     ***If I manually disconnect the "OLD" Shared Drive first, this works for mapping"

    @echo off
    net use S: /delete   

    This is the one that is supposed to delete the old S: Share but is not working. I have tried running as a logon/logoff script. From what I've found online this works for everyone but me it seems. I Have the script order doing this script first then the mapping of the new Shared Drive. I also tried a couple vbs scripts but have not had any success implementing ANY vbs scripts for some reason.

    Any thoughts, ideas or suggestions would be much appreciated. Thank you!

    -Moss

    Thursday, June 28, 2012 8:51 PM

Answers

  • I still have yet to resolve this issue...

    @JRV regarding one of my last posts about it working...All I was saying was that everything in the script works (Unmapping and Mapping) ONLY when run manually from the desktop...Either way...I've just about given up on getting this to work correctly.

    Remove all scripts that map or unmap drives.  Logointo the account a couiple of times.  Is the drive still mapped?  If it is manually umap the drive then logoff an on a cpouple of times.  Is the drive still unmapped?

    Do you have the users home drive pointed at the letter that you are trying to unmap?

    If all of that works or doesn't find your issue I will try one or two more things that are likely to cause this.  This si not a scripting issue.  It is a configuration and management issue with somae adminitrative trouble shooting problems.  It my next two suggestion still fail to find you r answer you will haev to either camm MIcrosoft Support or seek a consultant who can take a close look at you network and determine what is misconfigured or not working.  This can be time consuming and cannot be done through a forum.


    ¯\_(ツ)_/¯

    Wednesday, July 18, 2012 10:55 PM

All replies

  • Too vague.

    How do you know it is not working?

    How is the drive being mapped in the first place? 

    Is Group Policy remapping the drive immediately after you unmap it?


    ¯\_(ツ)_/¯

    Thursday, June 28, 2012 8:56 PM
  • You need to give yourself a pair of eyes so that you can see what's going on:

    @echo off
    if not exist c:\Logs md c:\Logs
    echo %date% %time% >> c:\Logs\log.txt
    net use 1>>c:\Logs\log.txt   2>>&1
    net use S: /delete  1>>c:\Logs\log.txt   2>>&1

    Thursday, June 28, 2012 9:02 PM
  • Ok...

    I map a shared location to the drive letter (S:) (A location different then the one I want to actually map)

    THEN

    I push the GPO...logoff...

    THEN

    login...

    AND...it doesnt work...thats how I "know" it doesnt work...because it should UNMAP the (S:) Share

    If I disconnect that (S:) Share, then remove the script from my GPO that is supposed to unmap the drive and re push the GPO...Logoff then login...the drive maps correctly using the logon script for mapping the drive...

    When I have BOTH scripts in the GPO for unmapping the (S:) drive...it is not unmapped...therfore not remapped to the correct location...

    Thursday, June 28, 2012 9:04 PM
  • @Oberwald -

    I am by no definition..."A Scripting Guy"

    Hence the simplicity of the ones I have provided...

    So I have no clue what you gave me is...other than it probably writes to a log.

    Thursday, June 28, 2012 9:10 PM
  • Ok...

    I map a shared location to the drive letter (S:) (A location different then the one I want to actually map)

    THEN

    I push the GPO...logoff...

    THEN

    login...

    AND...it doesnt work...thats how I "know" it doesnt work...because it should UNMAP the (S:) Share

    If I disconnect that (S:) Share, then remove the script from my GPO that is supposed to unmap the drive and re push the GPO...Logoff then login...the drive maps correctly using the logon script for mapping the drive...

    When I have BOTH scripts in the GPO for unmapping the (S:) drive...it is not unmapped...therfore not remapped to the correct location...

    Wow wowo wait a second.  What is this "both" scripts about.

    Yuo cannot relible unmap in one script and map in another.  You cannot comtrol the order or execution rate of logon scripts.

    What do yuo mean by "push' GP.  You cannot push Group Polciy.  You can only run GPupdate.

    With user policy you do not need to run GPUpdate.  User policy is always refreshed during logon.

    If you haev multiple DCs then yor policy may never get propagated if you keep editing teh policy or teh script.  Any cahnges to GP cause a re-versioning of the policy and a restaging of the poicy. This can take a long time in a large domain.  Keep editing anf teh policy never actaully gets updated.

    Run RSOP to be sure what policies and what scripts are being used by the user. Runit agains the user account and teh computer you are testing.  RUn it usiong any DC you fell will serve your logon.

    Slow down and let policy propagate.

    PLace a line (as per Obey) that will write a versionnumber to a local file so you can see whih version of your logon script is executing.  Be sure to cahnge the number when you cahnge the script.

    I have seen this many times.  Either polcy is broken or you are making too amy edits or there is another policy overwriting you.

    Slow down and crack one nut at a time.  You will find the answer.


    ¯\_(ツ)_/¯

    Thursday, June 28, 2012 9:23 PM
  • @Oberwald -

    I am by no definition..."A Scripting Guy"

    Hence the simplicity of the ones I have provided...

    So I have no clue what you gave me is...other than it probably writes to a log.

    Correct, it writes a log. Do whatever you do when the script is supposed to run, then use notepad.exe to examine the log file. What does it say?

    Note also that if you want to be successful in using logon/logoff script then you have to acquire some basic expertise in scripting.

    Thursday, June 28, 2012 9:28 PM
  • Yes by "push" I mean do a GPUPDATE...I push it via Altiris to the workstation...I dont think it takes long to propagate because soon as I put the script in the GPO to map the drive it works right away.

    I tried putting the unmapping portion in the same script but that didnt work.

    I give up...lol

    Thursday, June 28, 2012 9:33 PM
  • @Oberwald -

    I am by no definition..."A Scripting Guy"

    Hence the simplicity of the ones I have provided...

    So I have no clue what you gave me is...other than it probably writes to a log.

    Correct, it writes a log. Do whatever you do when the script is supposed to run, then use notepad.exe to examine the log file. What does it say?

    Note also that if you want to be successful in using logon/logoff script then you have to acquire some basic expertise in scripting.

    While I dont disagree...I wouldnt be here if I had "expertise in scripting"

    I will "TRY" what you've provided and re post soon...hopefully

    Thursday, June 28, 2012 9:35 PM
  • Hi,

    Check that your script is not on S: while trying to unmap the S: drive, that will definitely fail.

    Add the following sentence to change disk C: before running NET USE S: /DELETE

    C:


    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu

    Friday, June 29, 2012 12:13 PM
  • Hi,

    Check that your script is not on S: while trying to unmap the S: drive, that will definitely fail.

    Add the following sentence to change disk C: before running NET USE S: /DELETE

    C:


    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu

    Sebastion - think about it.  A logon script cannot be on a mapped drive ever.  The logon scripts are on the SYSVOL share for the domain at \\domain.com\sysvol\domain.com

    They can be either here:

    \\domain.local\SYSVOL\domain.local\scripts

    Or in any one of the policy object folders denoted by GUID.

    \\domain.local\SysVol\domain.com\Policies\{GUID}\User\Scripts\Logon\

    A logon script can NEVER ever be executed from a mapped drive during logon.  The system will not and cannot do this.  When the scritps are executed there are no known mapped drives.  Any logon script can delete a mapped drive s long as the drive does not hav eopen files.  If any other script is accessing the drive then the delete will fail. Tis is why I stress that all operations on a drive letter must be in the same file.  There is no maybe about that.  If the drive still cannot be mapped then look for other issues.  One issue that is problematic is that another script has mapped the drive.  Also a AV scanner can be scanning the newly found drive and it will then block any attempt delete the mapping until the scanner is done scanning.

    A virus or trojan can also cause this behavior because it will likely be looking to infect and will be insppecting files on teh mapped drive.  Netowrk drives are a priority with viruses becuse that always lead to other systems.  Sharing is inherently unsafe.


    ¯\_(ツ)_/¯

    Friday, June 29, 2012 12:29 PM
  • Hi,

    I'm not saying that script is stored at S: or launched from S:

    But, maybe, at some point of its execution it's standing at S: and then tries to unmap it.


    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu

    Friday, June 29, 2012 12:35 PM
  • Hi,

    I'm not saying that script is stored at S: or launched from S:

    But, maybe, at some point of its execution it's standing at S: and then tries to unmap it.


    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu

    Well maybe.  If the OP has made S the current drive then that is a dumb move and would cuse an issue,

    This is supposed to be what teh file looks like:

    @echo off
    net use S: /delete

    If it is other than that then we have been tricked.


    ¯\_(ツ)_/¯

    Friday, June 29, 2012 1:09 PM
  • All of my scripts are at \\DomainName\NETLOGON FYI

    So I've established (ON A TEST ACCOUNT and a TEST MACHINE) that the script I placed in the GPO for mapping a drive works correctly (As long as there is no drive currently mapped using S:).

    AND

    The "net use S: /delete" script does NOT work (When placed in the GPO)

    HOWEVER

    If I place the "UNMAPPING" script in the test accounts profile in Active Directory it unmaps the drive.

    This is however not a good solution because then I would need to place it into everyones account...AND eventually take it out the that the Script in the GPO can map the new one correctly...

    I have tried taking out the script from the GPO that MAPS a drive and only placing the script to UNMAP the drive in the GPO and it doesnt work...If I run the script from the desktop of the machine and dont rely on the logon script to unmap it...it works fine...Any thoughts?

    ALSO

    If I do the following all in the same script and run it from the desktop...it works. If I run it from the GPO as a logon script...It does nothing. 

    @echo off

    net use S: /delete

    net use S: \\SERVERNAME\Shared_Drive

    • Edited by Maurice Moss Tuesday, July 03, 2012 3:05 PM Update
    Tuesday, July 03, 2012 3:01 PM
  • Why would you put logon/logoff script at NETLOGON.  They need to be in the Group Policy object.  Each GPO has a set of folders for logon/logoff and startup scripts.  That is wher ist looks for them.  If you are puting them somewher else then that is why you are having issues.

    In GPMC the policy editor places you at the script folder by default. You need to drag and drop your scripts into this folder and then attach them to the policy object.  The use of the global NETLOGON share will not do what you want.

    The NETLOGON share is a leftover from NT4.  As of W2K and AD it was deprecated.  It can still be used for some things but it will not cooperate with Group Policy.  The NETLOGON scripts are executed t teh wrong times and are not executed by the GP engine but are executed by local system I believe.  If I reemember correctly the use of NETLOGON for scripts was designed for use before Group Policy was created. 


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, July 03, 2012 3:39 PM
    Tuesday, July 03, 2012 3:22 PM
  • The script that maps the drive and another script are both logon scripts and are both being run from NETLOGON and they work fine...

    Its when I try to use the script that unmaps the drive that gives me issues.

    When I go into the GPMC...I ONLY type the name of the batch file I am trying to run...and with the script ONLY being at NETLOGON...How does that make sense....and isnt NETLOGON the default location it searches? Hence how I am able to run other scripts by only the file name and not the UNC.

    I AM trying what you said however to see if it helps


    • Edited by Maurice Moss Tuesday, July 03, 2012 3:40 PM Revised
    Tuesday, July 03, 2012 3:38 PM
  • It is also possible for the NETLOGON scripts to execute too early for the workstation to be ready for mapping or unmapping a drive.  The issues you note seem to indicate some confusion over what may be happening at any given time.  This happens to all of us after fighting with an intractable problem for a long time.

    Move your script to a Group Policy and remove it from NETLOGON.  Be sure the policy is added to the OU where the users are that you want to affect.

    The Group Policy engine is more controllable when applying the scripts stored in a GPO.  We can set that GPO to run the script synchronouly which may be necesssary in a slow domain.  We can use this GPO to narrow the scope of this GPO to only out test users.  You cannot do that with a scrip on teh NETLOGON share. It will apply everywhere by default and you cannot mange how it is used in a granular way.


    ¯\_(ツ)_/¯




    • Edited by jrv Tuesday, July 03, 2012 3:58 PM
    Tuesday, July 03, 2012 3:50 PM
  • When I choose browse when creating a startup script, this is the default folder I am presented with:

    \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup


    Grant Ward, a.k.a. Bigteddy

    Tuesday, July 03, 2012 3:53 PM
  • Can you tell me the exact path for where I should place my scripts?

    ALSO

    should I do the unmapping and mapping of the shared drive in the same script?

    I still dont understand since they work from NETLOGON...atleast some anyways...

    regardless...if you could provide the path I will definitly give that a shot...I am ready for this to be resolved.

    I am signing up for a class on scripting! Its far to complex and useful to be ignorant about...Cant rely on the google machine to give me everything

    Tuesday, July 03, 2012 3:56 PM
  • Can you tell me the exact path for where I should place my scripts?

    ALSO

    should I do the unmapping and mapping of the shared drive in the same script?

    I still dont understand since they work from NETLOGON...atleast some anyways...

    regardless...if you could provide the path I will definitly give that a shot...I am ready for this to be resolved.

    I am signing up for a class on scripting! Its far to complex and useful to be ignorant about...Cant rely on the google machine to give me everything

    As I pointed oput before each Group Polciy object gas its own script folder.

    Start by createing a new GPO on the DC.  Find the logon script section under USER and click 'Show files"  - copy (drag-drop) your scritp into this folder.  Just copy it from explorer and paste it into the folder display.  Then select 'Add" on the form and add the script to the policy.

    Be sure the GP is attached to the OU where the user accounts are located.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 4:03 PM
  • When I choose browse when creating a startup script, this is the default folder I am presented with:

    \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup


    Grant Ward, a.k.a. Bigteddy

    Ok I found it...I placed my script there...no dice.

    Tuesday, July 03, 2012 4:03 PM
  • When I choose browse when creating a startup script, this is the default folder I am presented with:

    \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup


    Grant Ward, a.k.a. Bigteddy

    Grant.  Each GP has its own scripts folder.  Browse through sysvol to see how it is alayed out.

    The GUID you are seeing IS the group policy object which is a folder on SYSVOL.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 4:04 PM
  • Grant.  Each GP has its own scripts folder.  Browse through sysvol to see how it is alayed out.

    The GUID you are seeing IS the group policy object which is a folder on SYSVOL.


    ¯\_(ツ)_/¯


    OK, got it. I didn't know that. But Maurice's problem is not solved. 

    Grant Ward, a.k.a. Bigteddy

    Tuesday, July 03, 2012 4:08 PM
  • When I choose browse when creating a startup script, this is the default folder I am presented with:

    \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup


    Grant Ward, a.k.a. Bigteddy

    Ok I found it...I placed my script there...no dice.

    WRONG - you are not creating a startup script.  Plese follow my instructiosn.  Grants folder will not work for a logon script

    Creat a NEW GPO and edit it.  Create it in teh continer where your users are or, better yet in a test ou where you have a test user.  This way only the test user will be affected and yu can get that user working correctly before linking the policy to other users.

    DO NOT try to use a startup script to do this.  It will not work.

    .


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 4:08 PM
  • Grant.  Each GP has its own scripts folder.  Browse through sysvol to see how it is alayed out.

    The GUID you are seeing IS the group policy object which is a folder on SYSVOL.


    ¯\_(ツ)_/¯


    OK, got it. I didn't know that. But Maurice's problem is not solved. 

    Grant Ward, a.k.a. Bigteddy

    What do you eman "Maurices problem is not solved"?  What makes you think it might have been solved?  He hasn't even created teh GPO yet then he needs t owait fo r replicatiopn (15 minutes) then start with a fresh user profile and test the logon and the unmapping.

    Testing and debugging on a domin that has never had GP setup or tested can be a pain becasue you have no idea what is working and what is not working.  Whenever an admn start using old NT4 instructiosn to ficx a probblem it is usually because something is broken in Grou Policy.

    One Admin I fixed had deleted all of teh domain policies while trying to make his policy work. That will create a very difficult to fix situation.  When I went on site and saw no policies except one lonely little GPO I knew it was going to be a long day.

    NEVER delete teh default policies and NEVER edit the default policies.  A least on WS2008 this has been made more difficult and a warning is generated I believe.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 4:15 PM
  • LOL...

    Its basically the same location except that last part says Logon...I didnt put it in Startup when its a logon script...im not THAT incompetent...

    I clicked browse when creating a LOGON script...and its a very similar location just ending with Logon

    I have a TEST OU, with a TEST GPO...four TEST machines and three TEST accounts are applied to this...it is the only thing I use when testing things such as this..I do not test in a live environment.


    • Edited by Maurice Moss Tuesday, July 03, 2012 4:16 PM revision
    Tuesday, July 03, 2012 4:16 PM
  • So I removed the script from NETLOGON and placed it in the GPO's logon script location...ill let you know the outcome
    Tuesday, July 03, 2012 4:40 PM
  • LOL...

    Its basically the same location except that last part says Logon...I didnt put it in Startup when its a logon script...im not THAT incompetent...

    I clicked browse when creating a LOGON script...and its a very similar location just ending with Logon

    I have a TEST OU, with a TEST GPO...four TEST machines and three TEST accounts are applied to this...it is the only thing I use when testing things such as this..I do not test in a live environment.


    Not indicatin incompetence but maybe a littel burnout as this has been going on for days.  Yuo have to be very frustrated.

    I also suspected that you had a test setup although I cannot see how you caoul isolat logon scripts on the Netlogon share as it applies to every logon and every machine.

    You should be able to now set both the delete and the net use in a file and run it.

    if exist s: Net use s: /delete
    net use s: \\server\share

    If this fails then we may need to set this GPO to process synchronously.

    You may want to run RSOP on the uer that fails and look closely at what policy has been applied.  RSOP can only be run after the user has logged on and off. It will tell you what the user profile has had done to it during the logon.

    We can also turn on detailed GP logging and see, step-by-step,  what is happening.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 4:42 PM
  • I know you werent saying I was incompetent :P

    First thing...I have NO CLUE how some scripts run from NETLOGON if it isnt supposed to...either way...it does, and its isolated to only the GPO I apply the script(s) to.

    Second...I placed the script in the logon scripts area for the test GPO and it does not work. I just did another GPUPDATE /Force /Boot -- Going to see if it works after this try... :S

    I just want to note...that the script executes perfectly from the desktop of the test machine using the test account...AND when placed under the profile tab in Active Directory...This is all screwy..that aside...just ignore my rambling.

    Tuesday, July 03, 2012 4:52 PM
  • Ok...I placed it in the location you said...still doesnt work...
    Tuesday, July 03, 2012 4:54 PM
  • Ok...I placed it in the location you said...still doesnt work...

    Maurice, slow down. You are way ahead of the game heere.

    You need to logon and logoff of the user account then run RSOP on the user account and target the computer you logged onto. We need to see if GP is actually working for that computer and user.

    I suspect that you may have issues with your GP infrastructure.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 5:01 PM
  • OK...How do I do that....
    Tuesday, July 03, 2012 5:04 PM
  • I know you werent saying I was incompetent :P

    First thing...I have NO CLUE how some scripts run from NETLOGON if it isnt supposed to...either way...it does, and its isolated to only the GPO I apply the script(s) to.

    Second...I placed the script in the logon scripts area for the test GPO and it does not work. I just did another GPUPDATE /Force /Boot -- Going to see if it works after this try... :S

    I just want to note...that the script executes perfectly from the desktop of the test machine using the test account...AND when placed under the profile tab in Active Directory...This is all screwy..that aside...just ignore my rambling.

    GPUPDATE has no affect onlogon script application.  It only forces a reapplication of computer and user settings but only for teh currently logged on user and it still does not cause logon scripts to be run.  GP specifies the script but eh local system does the actualy execution during the logon process.  Userinit.exe is the guy who does this job.  There are a hundred things that can fail.  We need to take this one step at a time to narrow down what is failing.

    You say it executes perfectly but it doesn't. It cannot unmap a drive so it is not executing correctly. We now have the script in a manageble location and we can test and tune the GPO and use other diagnostics.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 5:07 PM
  • nono...I am saying that it SUCCESSFULLY unmaps AND maps the drive when ran from the locations i mentioned

    Either way...whats next... and how do I do it...lol

    Tuesday, July 03, 2012 5:11 PM
  • Unfortuantely I have to go to a site for about an hour.  I will be back.  RunRSOP and check teh output.  YOu can post a link th ethe report.

    Grant (BigTeddy) can probebly help you inspect the RSOP report.  If the report looks good then set the policy to execute sync and test again.

    Be sure RSOP does not show any other scrips or policies that conflict.  Be sure this user does not have settings for a strtup scritp in the AD account settings and remove the scripts (all of them) from the netlogon share before teh next test.

    If you have more than one DC be sure to wait at least 15 minutes between change to GP or force a replication with replmon or check the versionof the GP on the othe DCs to see if it has been replicated.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, July 03, 2012 5:12 PM
    Tuesday, July 03, 2012 5:11 PM
  • nono...I am saying that it SUCCESSFULLY unmaps AND maps the drive when ran from the locations i mentioned

    Either way...whats next... and how do I do it...lol

    I am lost.  If your scrip works then why are posting the issue.  I thought the script did not work.  I thought it only worked when run manually after ethe account was loged in.

    Now you have to clarify what it is you are asking.


    ¯\_(ツ)_/¯

    Tuesday, July 03, 2012 7:25 PM
  • I have an FAQ linked here that addresses some of the issues in this thread:

    http://www.rlmueller.net/LogonScriptFAQ.htm

    Logon scripts placed in the NetLogon share need to specified on the "Profile" tab of the user in ADUC. An alternate way to run scripts is to configure a Group Policy, which is applied to an OU (or the domain), in which case it applies to all users in the OU (or domain). The FAQ explains how to specify a script in ADUC and where to save it (the NetLogon share). The FAQ also explains how to save the script in the correct location for a GPO. As noted in this thread, the actual path is complicated, including a GUID, but in Windows Explorer you cannot tell which GUID corresponds to which Group Policy. I never navigate to the folder in Windows Explorer, but use the GPO GUI to save the file, so I know it is in the correct location. You may have saved you script in the folder for a different Group Policy. Or, you have not used the Group Policy editor to specify which script in the folder will be used as a logon script. The FAQ attempts to explain the steps.

    In general, one script to delete any mapping to S: and then map a share to S: should work. I would not expect it to work if the delete and map are in different scripts. I think the logon script should work basically the same whether it is specified on the "Profile" tab of the user in ADUC (and saved in the NetLogon share) or specified in a Group Policy. There can be timing differences, but I have never seen such a simple task fail in either type of logon script.

    I believe your problem could well be that your logon script never runs. Adding steps to the script to append date/time information to a log file can help troubleshoot this.


    Richard Mueller - MVP Directory Services

    Tuesday, July 17, 2012 10:54 PM
    Moderator
  • I have not read every post in this long thread but going back to the original post this sounds like a problem that i had a few years back.

    We needed to change the share to point to a different server.  When we tried to delete the first mapping and the set the next mapping the first one would not delete.

    This was caused in opur case by the original drive mapping being set to persisten in the net use command.  Once a drive has been mapped as persisten it can not unmapped with a net use command.  The only way to break it is for the user to disconnet the drive and then run the script again.

    Check your drives to see if the were set up to be persistent.

    Wednesday, July 18, 2012 8:28 PM
  • I have not read every post in this long thread but going back to the original post this sounds like a problem that i had a few years back.

    We needed to change the share to point to a different server.  When we tried to delete the first mapping and the set the next mapping the first one would not delete.

    This was caused in opur case by the original drive mapping being set to persisten in the net use command.  Once a drive has been mapped as persisten it can not unmapped with a net use command.  The only way to break it is for the user to disconnet the drive and then run the script again.

    Check your drives to see if the were set up to be persistent.

    Absolutely not the case.  NET USE /PERSISTENT and NET USE /DELETE have always worked to gether.

    NET USE /PERSISTENT says to add the setting to the registry so it will be remembered in subsequent logins. 

    The reason this may happen is because Group Policy is broken and is not applying.  Fix group policy and the delete will work.

    The other famous glitch is when more than one policy object references a script that does the mapping so it will just get mapped back.

    GP works well. It is used everywhere and is being accepted almost completely except by those who have not spen the time to learn how it can fail and what to do to fix it.


    ¯\_(ツ)_/¯

    Wednesday, July 18, 2012 8:40 PM
  • I still have yet to resolve this issue...

    @JRV regarding one of my last posts about it working...All I was saying was that everything in the script works (Unmapping and Mapping) ONLY when run manually from the desktop...Either way...I've just about given up on getting this to work correctly.

    Wednesday, July 18, 2012 9:54 PM
  • I still have yet to resolve this issue...

    @JRV regarding one of my last posts about it working...All I was saying was that everything in the script works (Unmapping and Mapping) ONLY when run manually from the desktop...Either way...I've just about given up on getting this to work correctly.

    Remove all scripts that map or unmap drives.  Logointo the account a couiple of times.  Is the drive still mapped?  If it is manually umap the drive then logoff an on a cpouple of times.  Is the drive still unmapped?

    Do you have the users home drive pointed at the letter that you are trying to unmap?

    If all of that works or doesn't find your issue I will try one or two more things that are likely to cause this.  This si not a scripting issue.  It is a configuration and management issue with somae adminitrative trouble shooting problems.  It my next two suggestion still fail to find you r answer you will haev to either camm MIcrosoft Support or seek a consultant who can take a close look at you network and determine what is misconfigured or not working.  This can be time consuming and cannot be done through a forum.


    ¯\_(ツ)_/¯

    Wednesday, July 18, 2012 10:55 PM
  • As there has been no activity in this thread for a few days, we assume the issue is resolved. We will mark it as "answered" to assist others in similar situations. If you disagree, please reply with further information. You can unmark the answer if you wish. If a reply helped answer your question, please mark it as the answer.

    I would only add that I don't see where it was ever established that your logon script even runs. If you still have a problem, please read the FAQ I linked earlier to make sure your script is saved in the correct location and is configured properly.


    Richard Mueller - MVP Directory Services

    Friday, July 27, 2012 4:49 PM
    Moderator