none
Application will not install via GPO startup script, but works manually

    Question

  • I have  startup scripsscript t that runs these commands:

    wmic product where name="Java 7 Update 71" call uninstall

    \\server\Java\8u31\jre-8u31-windows-i586.exe /s /L \\server\Java\8u31\Install-Logs\%computername%.log

    They both work when I run them manually.

    When I assign it as a startup script, it fails.  It neither does the uninstallation or new installation.

    I know the policy is applied and I know the computer has access to the file share, because when I restart the computer it creates the log file in the specified location.  Unfortunately the log file it makes is 1K and blank.

    When I run the script manually the log file is 9k and has all the details of the installation.

    Since it does not enter any info into the log file, it is difficult to troubleshoot.

    When I look in the Windows application log, all I see is this:

    Log Name:      Application
    Source:        MsiInstaller
    Date:          1/21/2015 9:36:14 PM
    Event ID:      1042
    Task Category: None
    Level:         Information
    Keywords:      Classic
    User:          SYSTEM
    Computer:      xxxxxxxxxxxxxx
    Description:
    Ending a Windows Installer transaction: C:\windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.8.0_31\jre1.8.0_31.msi. Client Process Id: 4204.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

    When I go to C:\windows\system32\config\systemprofile\AppData\LocalLow\ there is no Sun folder.

    What could be causing these batch files to fail when deployed via Group Policy startup scripts, but run fine when run as a ussr?

    Thursday, January 22, 2015 5:58 AM

All replies

  • Hi,

    Based on the description, we can try to restart the computer twice continuously to see if the script can run, or we can try to enable the following policy setting to see if it helps:

    Computer Configuration\Administrative Templates\System\Logon\  Always wait for the network at computer startup and logon

    Best regards,

    Frank Shen

    Friday, January 23, 2015 6:20 AM
    Moderator
  • That really does not appear to the issue since I can see in the application log error and the blank log file that is part of the bat file that this script is attempting to run.

    Also, I had done multiple restarts and gpupdate /force to make sure the policy would apply and I also see the policy applied in gpresults.


    Saturday, January 24, 2015 12:21 AM
  • From your description, it seems that GP is firing the script, and the script is firing the .exe, and the .exe is creating the (blank) logfile, and extracting the MSIfile and msiexec is firing the MSIfile.

    But, what is the MSIfile doing ?

    To determine that, you may need to enable some detailed MSI logging.
    If the .exe you are using doesn't allow you to specify logging parameters, you can enable MSI logging via registry keys/values:
    http://support.microsoft.com/kb/223300

    http://support.microsoft.com/kb/2545723

    Alternately, you could use psexec to launch an interactive CMD in the LocalSystem security context on the workstation.
    Since startup scripts are launched in LocalSystem context, sometimes LocalSystem can be an issue for some software.

    download psexec from MSFT and logon to the workstation, RunasAdmin CMD, then from inside that elevated CMD console, execute psexec -s -I CMD
    This will open a second CMD running in LocalSystem context; try your script there and check logfiles etc after that.

    We use ConfigMgr to deploy lots of software installers, including Oracle JRE, and we don't have this issue you're seeing.

    You might also consider searching the Oracle JRE admin guides, also itninja.com has lots of greats tips for deploying installers.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    • Edited by DonPick Saturday, January 24, 2015 8:35 AM
    Saturday, January 24, 2015 8:34 AM
  • From your description, it seems that GP is firing the script, and the script is firing the .exe, and the .exe is creating the (blank) logfile, and extracting the MSIfile and msiexec is firing the MSIfile.

    But, what is the MSIfile doing ?

    To determine that, you may need to enable some detailed MSI logging.
    If the .exe you are using doesn't allow you to specify logging parameters, you can enable MSI logging via registry keys/values:
    http://support.microsoft.com/kb/223300

    http://support.microsoft.com/kb/2545723

    Alternately, you could use psexec to launch an interactive CMD in the LocalSystem security context on the workstation.
    Since startup scripts are launched in LocalSystem context, sometimes LocalSystem can be an issue for some software.

    download psexec from MSFT and logon to the workstation, RunasAdmin CMD, then from inside that elevated CMD console, execute psexec -s -I CMD
    This will open a second CMD running in LocalSystem context; try your script there and check logfiles etc after that.

    We use ConfigMgr to deploy lots of software installers, including Oracle JRE, and we don't have this issue you're seeing.

    You might also consider searching the Oracle JRE admin guides, also itninja.com has lots of greats tips for deploying installers.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    I see that it wants to write to the AppData\LocalLow folder during the install.

    Ending a Windows Installer transaction: C:\windows\system32\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.8.0_31\jre1.8.0_31.msi. Client Process Id: 4204.

    It is using Windows\system32 instead of a user profile since the startup script isn't running as a user.  Could this be part of the cause? 

    Saturday, January 24, 2015 5:30 PM
  • I suggest you examine the Windows Installer logfile, since the event log does not have enough detail

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Sunday, January 25, 2015 4:21 AM