locked
Windows server login scripts RRS feed

  • Question

  • We use login scripts to address various issues as needed, such as pushing out an updated shortcut or an updated file for an application.  There are a lot of things we can accomplish doing this, but sometimes we run into issues where users get an error that they don't have the access to do something because they're not an admin.  A good example of this is trying to push the current copy of the HOSTS file each time the user logs on.  This resides in c:\windows\system32\drivers\etc, so the typical user can't update this folder.  And yet, we've been able to have the login scripts install certain software.  Why is this?  I would think a domain-based login script should run at an administrative level and be able to do just about anything.  Does anyone have input or suggestions?  (Corporate has suggested we use group policies to accomplish these sort of things, but they control those.  We want/need the ability to change these at will.)

    Thursday, August 13, 2009 11:03 AM

Answers

  • Hi Ken

    Logon scripts run as the domain user who is logging on, not with administrative rights (unless the user logging on is an administrator). if not and they dont have NTFS permissions to modify files in the directory you are attempting to copy\write files to then your script will either generate an error or continue silently (assuming you have used the "On Error Resume Next" statement).

    Try targeting your scripts to execute at computer start up through group policy, these scripts will runs as the local system account rather than as the user. If you don't have access modify group policy in your organisation but have control of your desktops and want the ability to modify systems via scripts at your command then try using psexec.exe (sysinternals tool). You could deploy the host files to each system on a scheduled basis using psexec...but why not just update DNS? If you can provide some more information on exactly what your trying to achieve and what your security restraints are i'd be happy to offer some suggestions.

    Cheers

    Matt :)
    Thursday, August 13, 2009 11:28 AM
  • Matt is correct, login scripts run under the current logged in user's context so if your users are not administrators of their machines, your goal of pushing updates via login scripts won't work (under normal circumstances). The best bet would be to make use of a startup script which runs under the LSA context. Alternatively, you can push a scheduled task (using an account with system-level privileges) that runs when a user logs in. Or, use the software distribution capabilities of group policy. The following links may be of help if you want to explore this further:

    Group Policy Software Installation:
    http://technet.microsoft.com/en-us/l.../cc738151.aspx

    Group Policcy Software Installation Extension Technical Reference:
    http://technet.microsoft.com/en-us/l.../cc780425.aspx

    Regards,

    Salvador Manaois III
    MCITP | Enterprise & Server Administrator
    MCSE MCSA MCTS(x5) CIWA C|EH
    My Blog: Bytes and Badz 
    My Shots: View My PhotoStream

    Thursday, August 13, 2009 2:32 PM

All replies

  • how are you assigning the logon script?

    I would also suggest group policy...

    But i think the HOSTS file is kind of hard to replace, even if you are admin .. but i am not sure..

    Edit: And what OS are your clients running?

    Best Regards
    Jakob
    Trainer/Consultant - Coretech A/S - Blog - MCT - MCTS - VB.NET - C#.NET - Powershell - VBScript
    Thursday, August 13, 2009 11:25 AM
  • Hi Ken

    Logon scripts run as the domain user who is logging on, not with administrative rights (unless the user logging on is an administrator). if not and they dont have NTFS permissions to modify files in the directory you are attempting to copy\write files to then your script will either generate an error or continue silently (assuming you have used the "On Error Resume Next" statement).

    Try targeting your scripts to execute at computer start up through group policy, these scripts will runs as the local system account rather than as the user. If you don't have access modify group policy in your organisation but have control of your desktops and want the ability to modify systems via scripts at your command then try using psexec.exe (sysinternals tool). You could deploy the host files to each system on a scheduled basis using psexec...but why not just update DNS? If you can provide some more information on exactly what your trying to achieve and what your security restraints are i'd be happy to offer some suggestions.

    Cheers

    Matt :)
    Thursday, August 13, 2009 11:28 AM
  • Matt is correct, login scripts run under the current logged in user's context so if your users are not administrators of their machines, your goal of pushing updates via login scripts won't work (under normal circumstances). The best bet would be to make use of a startup script which runs under the LSA context. Alternatively, you can push a scheduled task (using an account with system-level privileges) that runs when a user logs in. Or, use the software distribution capabilities of group policy. The following links may be of help if you want to explore this further:

    Group Policy Software Installation:
    http://technet.microsoft.com/en-us/l.../cc738151.aspx

    Group Policcy Software Installation Extension Technical Reference:
    http://technet.microsoft.com/en-us/l.../cc780425.aspx

    Regards,

    Salvador Manaois III
    MCITP | Enterprise & Server Administrator
    MCSE MCSA MCTS(x5) CIWA C|EH
    My Blog: Bytes and Badz 
    My Shots: View My PhotoStream

    Thursday, August 13, 2009 2:32 PM
  • Thanks for all the input.  Very helpful.

    We have used PSEXEC for somethings in the past.  I guess we'll start using it more.
    Friday, August 21, 2009 9:31 PM