Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Need help creating a package that uses a network share because of its size (2.7 GB)

We need to upgraded MatLab on 50 some computers and the install process typically takes 30 to 60 minutes to complete. Therefore I volunteered to try to create a package in Patch Manger to upgrade these installs. The install package for MatLab has numerous subfolders and is 2.7 GB in size. I have placed in on network share (i.e. \\Server\Share). If the install files didn’t have folders then I would have consider placing all 2.7 GB into a package in Patch Manager (from what I have experience when importing files with Patch Manager, it removes all folders and places all files at the same top level – if there is a different way to import need files with subdirectories then please let me know). I have created a .cmd file that will use this network share and preform a silent install as needed (and I have confirmed that it does preform a silent install as we need). This cmd file contains the following code (MatLab_R2013a_Win_Install.cmd):

@ECHO OFF

pushd \\Server\Share

start /wait setup.exe -inputFile \\Server\Share\installer_input.txt

This is the XML in Package Boot to perform the install:

<program failureaction="stop"enabled="true"name="cmd.exe"type="exe"typeaction="runandwait"pathtype="simplepath"path="%WinDir%\system32"successcode="0">start /wait /c %MODULEPATH%\MatLab_R2013a_Win_Install.cmd</program>

When this package runs on computer needing the package it completes in a few seconds and Windows Update states it was successful and then the package it ready to installed again by Windows Update (because MatLab wasn’t installed). Watching Task Manager shows that setup.exe (from the network share) runs for a couple seconds and then quiets and there is nothing in the Windows Event Logs to indicate what is occurring.

My priority is get a package working to prevent our Help Desk from spend a large number of hours manually preform these upgrades. Any suggestions would be greatly appreciated.

Find more posts tagged with

solarwinds_patch_manager

custom_package

Accepted answers

All comments

jbaits

I'm not sure why your package isn't running from your network share but I can tell you that if you use the "Add Directory Content" button when you try to add additional files it will keep the directory structure of the folder you select. It will list all the files individually but you can see the path they will be placed in. Alternatively, for some packages I've built that needed a large amount of additional files, I've compressed them with 7-zip, included 7za.exe in the package, and run an extract command within packageboot. Hopefully this helps you somewhat.

LGarvin

By default, because the WUAgent runs in the context of the SYSTEM account, it's unable to read directly from a network share, so the quick execution and the lack of installation suggests that the installation failed -- there was nothing for the cmd.exe /start to do since the network resource was unavailable.

In order to facilitate a connection to the network share, one of two things must happen:

1. The network share must be accessible to the DOMAIN\MACHINE$ account(s), and both the client(s) and file server must be in the same domain (or have a domain trust).

2. The network share has READ-ONLY access to Everyone (thus no authentication is required), and the NTFS ACL grants Read/Execute permissions to "Authenticated Users" (which will include MACHINE$ accounts), or "Everyone" in a non-domain environment.

Also, you need to look at the return codes coming from your script, because the WUAgent interpreted those results as a "success" but they obviously were not. Actually, lacking any logic in the script to trap a failure, the script will always return a success code of '0' and the WUAgent will consider every execution "successful". The script, ideally, should validate the availability of the network share and return a fail code if the network share is inaccessible.

In addition, when using network resources in a package execution, there's an Advanced option that needs to be checked: On the Advanced page of the Package Wizard, be sure to enable the option "Install can require network connectivity". While it won't protect the WUAgent or client system from a missing or inaccessible share, the WUAgent does have sufficient intelligence to know if the system has a working *LAN* connection, and if it does not (e.g. a notebook with no active wireless connection), the WUAgent can defer the attempt to install an update that requires network resources when there is no network availability.

LGarvin

One other thing you might want to consider...

Rather than accessing the INSTALLER_INPUT.TXT file from the network share, there may be value in including that file in the package itself, so that it's a local resource called from the script. This really revolves around what the contents of that file actually are, and whether they reference the rest of the installation library as relative/local resources, or as absolute/network resource also in \\Server\Share.

The script line would then be:

start /wait setup.exe -inputFile installer_input.txt

scottk

Thanks for the suggestions LGarin. I am unable to add <Domain_Name>\MACHINE$. Are you referring to each computer name, like computer1$ and computer2$? There is a single domain and I did add Everyone and Domain Computers with Read and Change share permission and Read & Execute for the NTFS permissions. I also did include the option "Install can require network connectivity."

Unfortunately the manufacture requires the full path to the installer_input.txt after the –inputFile. I have tried varies ways before creating the package in Patch Manger and I verified that it must have the full path to installer_input.txt (either local or network) otherwise it fails.

I am also exploring jaits suggestion of adding all 2.7 GB of files to a package. With your suggestion I was able to figure out how to add files with subdirectories. Unfortunately I am getting some errors I haven’t seen before on this package and work with support to understand them.

LGarvin

If you've added "Everyone" and "Domain Computers" that should address the need. (I'd forgotten about the "Domain Computers" security group.)

Bummer about the fully qualified path requirement; that surely puts a dent in simplicity.

Regarding adding all 2.7GB to the package.... we have had customers that have deployed a full 1GB Office 2007 installation package previously, so it's not impossible, but there are two critical considerations:

1. How long will it take to copy those 2.7GB to the client over a BITS-throttled connection.

2. There is a WSUS configuration attribute that must be changed to support a package of that size. By default, a locally published package has a maxSize limit of 384MB. We have a command-line utility that can be used to change that value. Support can get you the download link to that file if you decide to go this route, but a 2.7GB CAB for =50= systems could turn out to be a very "expensive" proposition. Using the network share is definitely the "right solution" for this scenario.

It may be that you just need to code some diagnostics into the script to find out exactly where it's failing.

Another suggestion is to check the security log on the file server (which may require enabling logon auditing) to see if there are any logon failures (or successes) from the client computer account.

Since you did enable advanced permissions on the share and NTFS ACL, you might also put some sort of 'write' test into the script .. determine if you can create a folder or file on the share prior to attempting to read from it.

Or maybe just do some sort of COPY from the share to the local drive.

The advantage of all of those is that they'll provide a result code that you can trap inside the script and/or passthru to the WUAgent to allow it to process a return code other than the default '0'.

scottk

I think the problem is with UAC. After have this package (using the network share) downloaded to a client that needs it, I edited the MatLab_R2013a_Win_Install.cmd file and dropped @ECHO OFF. I then opened up a command prompt to the location of the files (C:\Windows\SoftwareDistribution\Download\Install) and then ran MatLab_R2013a_Win_Install.cmd. I got the attached UAC prompt. Once I click Allow, then the install proceeded. I thought packages via Windows Update weren’t affected by UAC. AM I missing something?

LGarvin

UAC prompts give us a number of possibilities...

First, I note from the UAC prompt that the publisher is unknown, which means the binary is not signed. Keep that factoid in the back of your mind.

Second, the presentation of the UAC prompt could mean a number of things.

1. At its simplest it just means you launched the installer from an unprivileged session and needed a privilege elevation.

2. However, if you launch the installer from the local Administrator account itself (which is disabled, by default, on Win7 systems), and you still get the prompt, it could simply be poor installer design. (Ideally, installers launched from privileged sessions should not further prompt -- unless you have UAC configured to always prompt.)

3. A third thing to consider here, not necessarily related to the prompt, but definitely relevant -- if you Allow the installer, does it present other UI dialogs during the installation? If so, then the question becomes whether the installer supports an unattended/silent installation and what the appropriate command line prompts should be. If it doesn't support unattended/silent installation, then you'll also need to enable the "Can request user input" option on the Advanced options dialog *and* you'll need to have a logged-in user launch the installer. (And, if that's going to happen, it then begs the question of whether you ought just send an email with a UNC link to the installer on the network share.)

Of course, there's another point to be made.... by removing the @ECHO OFF statement, you actually MADE that script become user-interactable, because now the start command needs to be echoed to the Command Prompt window. I'm also questioning the value of the pushd command in this instance. You may find it just as functional to merely call CMD.EXE directly from PackageBoot, and rather than use this string for the Command Line parameters:

start /wait /c %MODULEPATH%\MatLab_R2013a_Win_Install.cmd

simply use this string:

start /wait /c %MODULEPATH%\setup.exe -inputFile %MODULEPATH%\installer_input.txt

and then you can include the installer_input.txt with Additional Files in the package, and you still have a fully-qualified pathname for the setup.exe parameter.

It also allows you do to away with the CMD script completely, which could be part of the UAC issue, as well as a 'user interaction' complication.

scottk

The Setup.exe is signed by the manufacture and I can’t figure out why with installing from a network share it has so many problems (but not with local installs). For network installs under Windows 7/Vista there is an UAC prompt when dropping @ECHO OFF line and Windows XP just fails without any errors.

Adding all the files to a package in Patch Manger is working much better, but stilling have an issue. The Windows Update runs the install for a few minutes and then says in completed successfully, but setup.exe is still running for about 30 minutes. Once setup.exe completes, the application is installed and functional. Below is the Package Boot XML that I am using.

-<packageboot version="2.0.0.0"id="dd53b76e-babc-410f-8901-426d0989f5f1">

-<instructions>

-<execution>

-<programs>

<program failureaction="continue"enabled="true"name="setup.exe"type="exe"typeaction="runandwait"successcode="0">-inputFile %Windir%\SoftwareDistribution\Download\Install\installer_input.txt</program>

</programs>

</execution>

-<postexecution>

-<programs>

<program failureaction="continue"enabled="true"name="wscript.exe"type="exe"typeaction="runandwait"pathtype="regprependpath"regpath="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer"regvalue="InstallerLocation"usewin32registry="true"successcode="0">%MODULEPATH%\Uninstall_MatLab_Older_R2013a.vbs</program>

</programs>

</postexecution>

</instructions>

</packageboot>

The post execution section references a simple vbs file that uninstalls old version of this application and it runs correctly. Any idea why Windows Update thinks the install completes while setup.exe still runs for about 30 minutes more.

LGarvin

If the setup.exe were spawning another installer, and then terminating, I'd think that setup.exe was simply returning a success code to the WUAgent based on spawning the secondary installer, but if the setup.exe continues to exist in the process table, then there's no reason that I'm aware of for the WUAgent not to wait for that process to terminate and return a result code.

Either way, you may want to monitor the process table, maybe even run an instance of Process Monitor to capture the process trace over a period of time, to see what else is being launched during the installation.

Another way you might approach this is to enable debug logging on the Windows Update Agent, and see if it provides any additional feedback as to why it's responding to the setup.exe the way it is. For more info on configuring logging for the WUAgent see KB902093, which provides this guidance:

To turn on [WUAgent] verbose logging, add the following registry key with two values:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace
Value name: Flags
Value type: REG_DWORD
Value data: 00000007

Value name: Level
Value type: REG_DWORD
Value data: 00000004

This registry key turns on an extended tracing to the %systemroot%\Windowsupdate.log file. Additionally, this registry key turns on an extended tracing to any attached debuggers.