Login script not mapping drives for users RRS feed

  • Question

  • I am in the process of configuring a new Windows 2008 terminal server in an existing Windows 2003 domain.  The TS is installed on a member server running Windows Server 2008 SP2.  The problem is that the domain login script (set in group policy) does not seem to be working for the users.  

    I have a special TS group policy for the new terminal server and have enabled loopback processing on the default domain policy. The only setting configured in the TS policy is the location of the user's terminal server roaming profile. This seems to be working.  Other than the login script, other elements of the domain-level group policy, such as folder redirection, seem to be working. When I run the GP result tool on the terminal server, it shows all of the appropriate group policies from both the TS policy and the domain-level policy, including the login script.  This login script is vital, since it does drive mapping for a bunch of resources on the domain that users need to run certain programs.  The odd thing is that the login script runs for the Administrator account, which uses a separate group policy that has inheritance blocked.

    Any help would be appreciated!

    Thursday, November 5, 2009 4:50 PM


  • At this point, the login script seems to be working for all the newer users we have tested.  It may have been an issue of timing. We have definitely noted that it is slow to map the drives, even when the login script works. I'm not sure what might be affecting the speed, since everything is on the same physical network.

    Friday, November 6, 2009 4:03 PM

All replies

  • Have you tried mapping drives via Group Policy Preferences?

    can you post your GPOs?

    I would create an OU, just for TS. Then apply a policy enabling loopback there (instead of the default domain policy). Then apply a user policy to the TS OU, that runs the logon script (sound like you did that part).

    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, November 5, 2009 5:17 PM
  • What sort of login script is it?  Batch?  vbscript?  Kix?  You didn't lock down the environment enough so that login scripts do not run have you?  For instance, User Config/Admin Templates/System/Prevent Access to the Command Prompt and then set the disable the command prompt script processing also? to yes.
    Thursday, November 5, 2009 5:22 PM
  • I have not tried using Group Policy preferences. I will give this a try, but I find that to be clumsier on the whole than just having the same login script run both on the TS and when the users log on to the domain from their workstations.  I'd still like to get the login script working the way it should (or know why it doesn't).

    I hesitate to post my GPs, since they're pretty extensive.  Maybe it will suffice to say that the domain GP login script works fine for all users on their regular workstations. The only place I'm having any problem with it is on the new Windows 2008 terminal server. I have already created a separate GPO for the 2008 terminal server; it only has two settings in it, one for "Use the specified licensing server" pointing to the new server; and one for the roaming profile location, which is set to use a Profiles folder on the terminal server rather than the location used for the regular domain profiles.

    I'm pretty sure that I originally enabled the loopback processing on the TS group policy and it didn't seem to work.  That's why I went back to the domain policy and enabled the loopback processing there. I will try to change it to your suggestion and test it again.
    Thursday, November 5, 2009 5:49 PM
  • It's a simple batch script that maps common drives for everyone and uses group membership to map certain drives for some users and not for others.  I did not lock down the environment much at all. I haven't put anything in the user config section of the group policy that applies only to the new terminal server.  The login script is running from the default domain policy and runs fine for all users when logging on to their own workstations.
    Thursday, November 5, 2009 5:51 PM
  • Hi,

    What happens when you logon to your TS as a standard user and run the logon script manually?  If it is a .cmd then you could open up a command prompt and run it from there, examining any errors.  You may need to make sure that echo is on, and if needed you may need to insert pause commands at key places in the script to make it easier to troubleshoot.


    Thursday, November 5, 2009 7:54 PM
  • The weird thing now is that it is working for a different user. We are just now testing a few different users, and the second one we tested got the mapped drives without any problem. So, perhaps it's a problem with that particular user, or maybe an intermittent problem. I will post back if I get more information that points to something useful.
    Thursday, November 5, 2009 8:20 PM
  • Hi Deb,

    As TP suggested, please try to run the script manually using problematic users.

    If it’s intermittent problem, it may be caused by Fast Logon Feature or Slow Link. Let’s try the steps below for troubleshooting:

    1.    Disable Fast Logon.

    Open the default Domain GPO, navigate to:  [Computer Configuration/ Policies / Administrative Templates / System /Logon]

    Enable "Always wait for the network at computer startup and logon".

    2.    Enforce policy setting.

     Navigate to [Computer Configuration/ Policies / Administrative Templates / System / Group Policy]

    Based on your policy settings, please choose accordingly policy processing policy and enable:
    -"Allow processing across a slow network connection"
    -"process even if the Group Policy objects have not changed"

    Run "gpupdate /force" on DC and reboot the client. If the issue persists, on DC, open GPMC, right-click Group Policy Result, choose Group Policy Result Wizard, follow the wizard to collect a report of the Windows 7 system. When it finish, right-click in the right-panel, choose Save Report, and use Windows Live SkyDrive (http://www.skydrive.live.com/) to upload the file and then give us the download address. 

    TechNet Subscriber Support in forum
    If you have any feedback on our support, please contact tngfb@microsoft.com 

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, November 6, 2009 1:47 AM
  • Hi,

    Could you please try this step:
    When the logon batch script fails to map drives for the User, could you please have the user run the batch script manually (in the same session, after logging in) and see if its able to map the drives; doing this tells if its a problem running the script as a logon script or if it is a problem running the script for that particular user(s).

    Mauruthi. G
    Friday, November 6, 2009 12:41 PM
  • I will look at the Fast Logon setting - I believe it's already disabled, but I will check it.

    There is no DC involved in this scenario, not is there any Windows 7 system either.  The terminal server is a member server, and the workstations I am using for the test connections are Vista Business. As I have said in previous posts, I have already run the Group Policy Results tool, and it shows all of the appropriate group policies being applied to the users.
    Friday, November 6, 2009 3:35 PM
  • At this point, the login script seems to be working for all the newer users we have tested.  It may have been an issue of timing. We have definitely noted that it is slow to map the drives, even when the login script works. I'm not sure what might be affecting the speed, since everything is on the same physical network.

    Friday, November 6, 2009 4:03 PM
  • I encountered exactly the same error. After I redesigned old AD structure, moved users to new OUs, and implemented new domain policies, some users who works on terminal servers lost network drives. Logon scripts simply did not run for them, although they were able to run scripts manually from SYSVOL share. Other users in the same OUs working on the same servers did not suffer from this problem. Moreover, users in question encontered the problem on one of terninal servers, but did not encouter it on the other one.

    After long troubleshooting process I've discovered that the main cause of the problem were Windows roaming profiles. After both local profiles and roaming profile were erased and recreated anew, logon scripts work just fine. Do no ask me, why. This is an ethernal mistery for me.

    Monday, March 1, 2010 1:40 PM
  • I have the same problem on XP SP3. Drives mapped in the login script do not appear in Windows Explorer but they are listed by "net use".  I think it is a timing issue.

    I added code to the login script to wait for the userinit.exe process to disappear before the "net use" commands are run and that seems to work but I cannot explain why.

    I have read that many are suggesting to make the login script run synchronously but I don't want to add time to the logon process.

    Anyone else has found a solution or the root cause of this problem?

    Wednesday, June 2, 2010 3:03 PM
  • I'm experiencing the same issue with following config:

    • TS server farmwith 2 servers
    • Mandatory roaming profile for TS
    • Redirected folders
    • Logonscript (.vbs) via GPO

    On one of the TS servers drives are not mapped. I see from my logonscript logging that the script has ran successfuly and that the commands for mapping drives resutled in RC 0. However, the drives do not show up in explorer. When I execute the logonscript manually again (via Run) the drives show up.

    This only occurs on one of the servers and I also notice that it is related to the roaming profile: when I deactivate the roaming profile GPO (and logon with a local profile) there is no issue. When I reactivate the GPO, same issue. It is just puzzling why this only occurs on one of the servers.

    Any ideas what is causing this? Is there a way to solve this without having to recreate a profile cfr Evgeniy's reply?


    Friday, October 8, 2010 7:53 AM
  • This is solution:

    • Edited by Beens JK Thursday, May 23, 2013 10:17 AM
    Thursday, May 23, 2013 10:16 AM
  • This is solution:


    Wednesday, July 31, 2013 2:10 PM
  • MS change content this site :/ sorry. Shortly... You have to enable Linked Connections.


    It's work for me in Windows XP and 7.

    • Proposed as answer by mekohl Thursday, October 17, 2013 2:10 PM
    Thursday, September 26, 2013 8:19 AM
  • This worked great for me.  Drives would not map when using .vbs logon script.  When user ran it manually, it mapped the drives just fine.  Added this reg key and now maps the drives as intended on logon.

    We are using the vbs logon script to map the drives because when using the group policy preferences to map a drive to a non domain smb share, the drive mappings would not properly pass the credentials through.  Maybe they weren't working because of this same reg setting.  

    Thursday, October 17, 2013 2:14 PM
  • I realize this is old, but for anyone who comes here after me, here goes.  What i found, is that instead of running a vbs script to map the drives, i run a vbs script to get the parameters i need, then i run a batch file from the vbs and pass it the parameters.  For some reason, when the logon script is run as a batch file, all of the drives map, even for users who are local admins.  It seems to run in the users current context, unlike a vbs script.  Here is an example :

    ' maps a shared documents folder "S:/"  to the same folder as the OU that the user is in. 
    Set objSysInfo = CreateObject("ADSystemInfo")
    strUser = objSysInfo.UserName
    Set objUser = GetObject("LDAP://" & strUser)
    strUserName = objUser.samAccountName
    strOUPath = objUser.Parent
    arrContainers = Split(strOUPath, ",")
    arrOU = Split(arrContainers(0), "=")
    strOU = arrOU(1)
    Set objShell = CreateObject("WScript.Shell")
    objShell.Run "\\domainname\NETLOGON\Login.bat """ & strOU & """", , TRUE

    And the batch file takes the parameters like so :

    :: Initialize variables
    set parentOU=%~1
    :: Delete all known shares
    net use s: /delete
    :: Map all known shares
    net use S: "\\domainname\mainshare\%parentOU%" /persistent:yes

    Make sure to use quotes around the variable in the vbs file, or your batch file will see it as two parameters.  Then make sure to use %~1 as the variable in the batch file to remove the quotes from the parameter that is passed.

    Friday, August 1, 2014 6:55 PM
  • After working on this on-and-off for1 year, the regedit worked
    • Proposed as answer by SergeyAnuchin Tuesday, November 10, 2015 5:58 AM
    • Unproposed as answer by SergeyAnuchin Tuesday, November 10, 2015 5:58 AM
    Thursday, January 22, 2015 11:29 PM
  • I had this exact issue. Prior to me working for this company the previous IT contractor had setup drive mappings that were persistent (they weren't deleting and then re-mapping the drives on every logon). When I came on-board I setup a logon script to delete and re-map the drives on every logon to keep things standardized. However, I noticed the logon script would run on the TS, but the drives wouldn't map. After several hours of playing with GPO settings I looked over my logon script and realized I was missing deleting one drive letter. When the batch script would run it would get to that drive letter and not finish because it asks if that drive should stop being persistent. So, the solution for me was to add the missing drive letter to the script (ie. net use i: /delete) before mapping it. It sounds like this isn't your issue, but figured I should reply in case someone else has my issue.
    Wednesday, January 20, 2016 5:46 PM
  • Had same problem: BAT file for drive mapping not executing from GPO for logon script in new Windows 2012r2 domain and Windows 10 workstation.

    Needed BAT file to map to share on different domain since I had to include logon credentials and 2012r2 GPO for drive mapping no longer allows specifying credentials.

    Adding the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
    registry key fixed it for me.

    Thursday, August 31, 2017 11:27 PM
  • MS change content this site :/ sorry. Shortly... You have to enable Linked Connections.


    It's work for me in Windows XP and 7.

    The correct answer.
    Thursday, August 8, 2019 7:02 PM