locked
GPO - Startup Script - UAC Problems RRS feed

  • Question

  • Hi all,

     

    Apologies if this has been asked a thousand times before but I've done a lot of Googling and can't quite get an answer to this.....

     

    I'm not too good with scripting, though I can usually find and butcher what I need for general administration tasks.

     

    On this occasion I am trying to deploy a peice of client software for an already installed server application. I want to do this automatically using a startup script via a GPO.

     

    The script basically copies the software from the NETLOGON directory to a locally created directory, then launches the setup with a couple of applicaiton specific switches.

     

    What I am finding is that on XP clients all works as expected, however on Windows 7 machines the software has tried to be installed but not completed. I know this as the local clients directory structure has started to be created, ie I see;

     

    c:\program files\client app\folder 1

    c:\program files\client app\folder 2

    c:\program files\client app\folder 3

    but not

     

    c:\program files\client app\folder 4

    c:\program files\client app\folder 5

    As such I'm guessing the installation is getting as far as it can before UAC kicks in then prevents it completing successfully.

     

    Can anyone enlighten me as to how I can deal with this situation? I know UAC is there for a reason and this would seem to go against its purpose but I can't believe there is not a way to deploy software via a startup script due to UAC.

     

    Thanks in advance!

     

    Adam

    Monday, January 30, 2012 11:04 AM

Answers

  • Startup scripts run with local system privileges, as demonstrated by the fact that your script works on XP. A startup script can install software, and even add members to the local Administrators group, so it runs will local administrator privileges. I also doubt that UAC is kicking in after a delay.

    I suspect an error is being raised that terminates the script. Make sure it runs when an Administrator runs it after startup and logon. I would add logging statements to the script to track progress and trap errors. When an error is raised, log the error number and description. Problems could be due to 64-bit OS instead of 32-bit, differences in the registry, differences in the file system, or differences in local permissions in the file system.

     


    Richard Mueller - MVP Directory Services
    • Proposed as answer by jrv Monday, January 30, 2012 5:42 PM
    • Marked as answer by LikeToCode Tuesday, January 31, 2012 2:58 PM
    Monday, January 30, 2012 3:36 PM

All replies

  • If the Installation is runnig silent, without showing a GUI, you can use the following recipe:

    1. Copy Filest to Workstation (%Temp%)
    2. Let your script create a Scheduled Task to run the Installation.

    The Sheduled Task should run with User: NT AUTHORITY\SYSTEM (leave password empty!!)+ Highest privileges (Principal.RunLevel = 1) and hidden (TaskSettings.Hidden = True).

    See: PowerShell Script to Schedule a Task - Task Scheduler API
    http://myitforum.com/cs2/blogs/yli628/archive/2008/08/06/powershell-script-to-schedule-a-task-task-scheduler-api.aspx
    Hey, Scripting Guy! How Can I Best Work with Task Scheduler?
    http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/01/how-can-i-best-work-with-task-scheduler.aspx

    MSDN Documentation:
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa383607%28v=vs.85%29.aspx

    Also, the PowershellPack has a TaskScheduler module that's makes task scheduling much easier:
    http://archive.msdn.microsoft.com/PowerShellPack

    Windows PowerShell V3 comes with scheduler cmdlets...

     


    Please click “Mark as Answer” if my post answers your question and click "Vote as Help" if my Post helps you. Bitte markiere hilfreiche Beiträge von mir als "Hilfreich" und Beiträge die deine Frage ganz oder teilweise beantwortet haben als "Antwort". Das wäre Nett :-)) My PowerShell Blog http://www.admin-source.info
    Monday, January 30, 2012 1:00 PM
  • Hi Peter,

     

    Firstly, thanks for taking the time to reply.

     

    Please excuse my ignorance around this but what your suggesting would appear to be for a logon script rather than a startup script? Or can startup scripts use task scheduler services?

    Thanks

    Adam

    Monday, January 30, 2012 1:25 PM
  • Some of my colleges are using Task Scheduler to install Software with the Process I describe above.
    Because The User: NT AUTHORITY\SYSTEM is preferred to install software locally.

    I guessed your script has Local-Admin rights (like most Installations routines)!
    I don’t know with which credentials are startup scripts are running!
    If startup scripts don’t have Local-Admin rights, you have to go a way with those rights!

    If it´s even the NT AUTHORITY\SYSTEM Account then my post above is completely nonsense.

    You can go even this way:

    1.    Create scheduled Task (like described above) with GPO*
    2.     scheduled Task Installs the Software
    3.    be happy …

    * Server 2008 GPO Preferences http://technet.microsoft.com/en-us/library/dd367850%28WS.10%29.aspx#BKMK_ScheduledTask

    You can even run the Installation/Script with PowerShell remoting or  PSexec from Windows Sysinternals.
    Better solution is to Deploy Software over SMS Server or a Software deployment system.

    By the way, is your Software Package a Windows Installer Package (.msi .msu ..) or a .exe?

     


    Please click “Mark as Answer” if my post answers your question and click "Vote as Help" if my Post helps you. Bitte markiere hilfreiche Beiträge von mir als "Hilfreich" und Beiträge die deine Frage ganz oder teilweise beantwortet haben als "Antwort". Das wäre Nett :-)) My PowerShell Blog http://www.admin-source.info
    Monday, January 30, 2012 3:18 PM
  • Startup scripts run with local system privileges, as demonstrated by the fact that your script works on XP. A startup script can install software, and even add members to the local Administrators group, so it runs will local administrator privileges. I also doubt that UAC is kicking in after a delay.

    I suspect an error is being raised that terminates the script. Make sure it runs when an Administrator runs it after startup and logon. I would add logging statements to the script to track progress and trap errors. When an error is raised, log the error number and description. Problems could be due to 64-bit OS instead of 32-bit, differences in the registry, differences in the file system, or differences in local permissions in the file system.

     


    Richard Mueller - MVP Directory Services
    • Proposed as answer by jrv Monday, January 30, 2012 5:42 PM
    • Marked as answer by LikeToCode Tuesday, January 31, 2012 2:58 PM
    Monday, January 30, 2012 3:36 PM
  • I marked Richards answer as the correct answer because you will need to do thi stroubleshooting all by yourself.  If you have issues with the loggtin you should start a new topic for the specific issue as you will likely get more answers.

    I also want to suggest that you run the installer under Software Distribution as this creates a full log and will also guarantee that UAC or any other issues cannot get in the way.

    Using a Startup script will likely create issues with the file copy on faster (newer usually) computers.  If you set execution of scripts to be synchronous this may be pervented however the computers will then start up more clowly.

    Installing software in Startup Scripts and logon scripts is almost never a very good idea.  That is why Group Policy supports SOftware Disrtribution via Group Policy using the Software Distribution policy node of every GPO.

     

     


    jv
    Monday, January 30, 2012 5:48 PM