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.
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.
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
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.
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'.
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?
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.
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.
<program failureaction="continue"enabled="true"name="setup.exe"type="exe"typeaction="runandwait"successcode="0">-inputFile %Windir%\SoftwareDistribution\Download\Install\installer_input.txt</program>
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.
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:
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.
The setup.exe does call multiple installers and some of them are called setup.exe. It’s possible while I watch Task Manager that the original setup.exe completes and another one starts with the same name. Do you have any suggestions for an installer like this?
The only thing I can think of is to use a simple program called sleep.exe that I can tell to run for so many seconds and then exit (i.e. sleep.exe 1800 /quite – runs for 30 minutes). I would prefer something better but not extremely complex.
If the original setup.exe is spawning another process, then terminating and returning a result code, there's not much you can do to manage that scenario. Even if you did use something sleep.exe, you'd still be guesstimating what the delay time should be, and there's always a possibility that it comes up too short and wreaks havoc on the installation. Plus you have the VBS script
Another option ... possibly ... is to break those several subordinate installers out into their own individual packages, document any dependencies by defining prerequisite rules in the package definition, and then have the packages install sequentially. This is just as complex as other solutions though, and has it's own risks and pitfalls.
A third way it might work, if you can break the subordinate installers out (and they have a way to not automatically spawn the next installer), is to tag them all as postinstallation Run Program events in PackageBoot that are tied to the previous via return codes and continue-on-success constraints, with some benign or 'administrative' task defined as the primary package executable.
And, in the end, sometimes it's just the case that a product is not well-suited for installation using the Windows Update Agent. :-)