locked
UAC Sporadic Logon Script issues RRS feed

  • Question

  • This question seems to be posted a number of times with no clear solution.  So here we go again. 

    I have been having some issues with logon script batch files running successfully on Server 2008 R2/Windows 7 PC's.  I have found where the problem lies -- is User Account Control somewhere.  When I expirience the issue, I go into User Account Control set to slider up one and select OK.  I then go back in and set the slider all the way at the bottom to disable user account control, and it prompts me to restart to apply changes.  Once I restart it maps all of the drives as it should.  After a period of restarts/logins the same issue happens again.  I have the following set in Active Directory Group Policy. 

    Policy Setting
    User Account Control: Admin Approval Mode for the Built-in Administrator Disabled
    User Account Control: Allow UIAccess applications to prompt for elevation Enabled
    User Account Control: Behavior of the elevation prompt for administrators in Elevate without prompting
    User Account Control: Detect application installations and prompt for Disabled
    User Account Control: Only elevate executables that are signed and Disabled
    User Account Control: Only elevate UIAccess applications that are installed Disabled
    User Account Control: Run all administrators in Admin Approval Mode Disabled
    User Account Control: Switch to the secure desktop when prompting for Disabled

    Also, another weird issue is that a reboot isn't necessarily required for the drive mappings to stop working.  We have a XenApp server with the desktop shared, and after a certain number of logins, the drive mappings begin failing and I have to go through the above process to turn the UAC on and off and restart the Server/Windows 7 PC's. 

    The weird thing is when I try to manually run the logon.bat after logged in, it works without an issue. 

    Friday, March 2, 2012 8:08 PM

Answers

  • Hi,

    You can see the same sort of behaviour with JavaScript (.js) and VBScript (.vbs) files too if just the script filename is entered as the executable, rather than the full script host and script filename combination.

    For example, just entering "logon.bat" (or "logon.js" as an example of another language) may well trip the UAC, as that actual script (and it's location) is being assessed.

    If you were to prefix the script with the actual shell, such as "cmd /c \\domain.com\netlogon\logon.bat" (or "cscript \\domain.com\netlogon\logon.js" to again keep in line with another example) then the script host itself is being assessed (which under normal circumstances will succeed) and the script will run without UAC intevention - assuming no other settings have been put in effecting something to the contrary.

    Have you tried prefixing the script with the appropriate shell?

    Cheers,
    Lain

    • Marked as answer by Lawrence, Friday, March 9, 2012 1:14 AM
    Saturday, March 3, 2012 12:45 PM
  • This issue will only affect users that are members of the local Administrators group on the local machine (it won't affect standard users). Group Policy runs the logon script with highest elevation, thus the drives are mapped with the users administrative token. Windows Explorer, which does not have the highest token, can't then see the drives.

    The reason the drive mappings work when you run the script manually is that the script is run with the same elevation level as Explorer.

    The best solution would be to remove the users from the local Administrators group. A different solution that does not require disabling UAC is outlined in this knowledgebase article: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or in Windows 7 



    Twitter: @stealthpuppy | Blog: stealthpuppy.com

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    • Proposed as answer by Aaron.Parker Sunday, March 4, 2012 10:19 PM
    • Marked as answer by Lawrence, Friday, March 9, 2012 1:14 AM
    Sunday, March 4, 2012 11:06 AM

All replies

  • Hi,

    You can see the same sort of behaviour with JavaScript (.js) and VBScript (.vbs) files too if just the script filename is entered as the executable, rather than the full script host and script filename combination.

    For example, just entering "logon.bat" (or "logon.js" as an example of another language) may well trip the UAC, as that actual script (and it's location) is being assessed.

    If you were to prefix the script with the actual shell, such as "cmd /c \\domain.com\netlogon\logon.bat" (or "cscript \\domain.com\netlogon\logon.js" to again keep in line with another example) then the script host itself is being assessed (which under normal circumstances will succeed) and the script will run without UAC intevention - assuming no other settings have been put in effecting something to the contrary.

    Have you tried prefixing the script with the appropriate shell?

    Cheers,
    Lain

    • Marked as answer by Lawrence, Friday, March 9, 2012 1:14 AM
    Saturday, March 3, 2012 12:45 PM
  • This issue will only affect users that are members of the local Administrators group on the local machine (it won't affect standard users). Group Policy runs the logon script with highest elevation, thus the drives are mapped with the users administrative token. Windows Explorer, which does not have the highest token, can't then see the drives.

    The reason the drive mappings work when you run the script manually is that the script is run with the same elevation level as Explorer.

    The best solution would be to remove the users from the local Administrators group. A different solution that does not require disabling UAC is outlined in this knowledgebase article: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or in Windows 7 



    Twitter: @stealthpuppy | Blog: stealthpuppy.com

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    • Proposed as answer by Aaron.Parker Sunday, March 4, 2012 10:19 PM
    • Marked as answer by Lawrence, Friday, March 9, 2012 1:14 AM
    Sunday, March 4, 2012 11:06 AM