Vista Logon script user.bat not running RRS feed

  • Question

  • We have a mixed Mode Windows 2003 Domain.

    We have the majority of users using XP SP3, we have a a few  Vista Business boxes, fully patched to Dec '09.

    We have users using login scripts setup in their profiles  that use the 'NET USE' command to map drives when they connect to the network.  This remaps the drives each time the user logs in.  We do not use the persistant setitngs on the 'NET USE'

    The system as of about Jan 4th 2010, stopped running the network login script.
    If the user remotes into a computer that is running Windows 2003 Terminal server, the script runs.
    We had just tried another user to login the Vista box and the drives are mapped.

    We had noted that there was an event in the security log for EVENT ID 5032 at time of login.  I am wondering if a rule my have been adjusted that may be causing the scripts to be blocked?

    If the user logs in and runs a local copy of his login script it runs properly and the drives get mapped. It works properly.

    Am I on the wrong track with this?  It seems that it is something with his local Vista profile that is blocking this is there a way to validate this or to see what we can do to have the scripts run normally?

    Tuesday, January 12, 2010 2:59 PM

All replies

  • Is it possilbe that the Vista Firewall is blocking the users domain logon scripts?

    If I turn the firewall Off (For domain connection) this should vallidate this correct?  If I turn off the Firewall when Connected to the Domain, would that effect the user if they were logged in via VPN or would that be under a different rule set?

    Would such a firewall rule be system wide rule or is there local firewall rules in Vista?

    Wednesday, January 20, 2010 4:57 PM
  • Have you tried this?

    We had issues with some Win7 logon scripts that worked fine before (XP) / plugged in the reg hack and all is well.


    Windows Vista Tip - EnabledLinkedConnections

    On Windows Vista when you map a drive under your admin account you will find that your mapped drive is not available after you switch to your full token via a RunAs or Consent dialog. This is by design because there are actually two tokens in play here. What happens is the LSA recognized that you are admin at logon and creates two logons. The first with a "filtered" token or non-admin which is used to render your desktop and the other containing your full token to be available after consent dialogs. 

    Because there are two separate logons there are separate logon ID's.  When network shares are mapped they are linked to the current logon session for the current process token. Meaning you don't have access to the network drive from the alternate logon. This can come into play with logon scripts and a number of other areas where you may require access to a network share from both tokens.

    If you set the following key it will change how SMB shares are mapped. They will be mapped to a token, which means that LSA will check to see if there is a linked token associated with the user session and add the network share to that location as well. Basically all of this means that after setting this drives will be accessible from both tokens no matter which they are mapped under.

    Disclaimer: This is not supported by Microsoft and was never tested. Use at your own risk.

    EnableLinkedConnections = 1 (DWord)



    Wednesday, January 26, 2011 4:32 PM