I'm attempting to install VNC across a large network and I'm running into an issue where the program gets downloaded and executed correctly but it never executes silently per the command line switches provided. Tested locally and the switches are correct. I can tell its reading the .inf file since all the selections are preselected the way I intend to install the software. I was thinking about bundling the .inf within the package but I'd need to tell the .exe where the .inf is in order to execute the silent install. Not to mention I will need to bundle the registry keys for the passwords into it eventually. So the question is, where are these additional files stored?
As a side note I'm contemplating just pushing a batch file that will pull down the file, execute it with the .inf, run the reg import, and delete the mess afterwards. But I'm looking for something a little easier.
One more question about where these files are stored, are they deleted afterwards? It'd be a huge security breach if sensitive information were to be left behind for users to discover.
On the client-side, the files are normally deleted after the update is successfully installed. The ~\SoftwareDistribution\Download folder is auto-maintained by the WUAgent and files are deleted 10 days after they are no longer needed.
Since they're stored in the %windir% folder tree, only Administrators would have access.
However, in some instances it has been observed that the contents of the Download folder and the WUAgent datastore get 'out of sync'. When this happens, you can simply delete anything found in the Download folder that is >10 days old.
All files transferred via WSUS to the Windows Update Agent are held in an update-specific installation source folder under %windir%\SoftwareDistribution\Download. The actual CAB file is copied into the ~\Download folder and extracted from there.
Generally speaking, if the installer allows for relative pathname references in the command line parameters, then you should only need to indicate that it should use the current folder. It might also be that you need to specify that with dot-backslash notations to explicitly identify the local folder as the source, e.g. .\thisFile.inf.
Finally, there is also an environment variable, %ModulePath% that can be specified that contains the fully qualified pathname of the installation source folder, if relative referencing cannot be used.
I tried changing the files per your recommendations but now I can't get my test laptop to see the update. Before it would run but now it says it's all up to date no matter how I push the update from Patch Manager.
That may be an accurate indication. What are the rules defined in the Installed Ruleset of the package? Are those rules true, or not? What are the rules defined in the Applicability Ruleset of the package? Are those rules true, or not. Whether a package is detected as NotInstalled, NotApplicable, or Installed is a completely separate discussion from the physical files contained within the package.
True and if that is the case we can move this to another thread.
My rule states that if winvnc.exe does not exist in the c:\program files\uvnc bvba\UltraVNC\ directory then it is applicable. If it does exist it is installed. I have check my test laptop and that director nor the file exists. While viewing the active task I see it hang on wmi for quite some time before giving up. I've tested with wbemtest and I can connect via wmi to that laptop. May be a support request at this juncture.
Just additional info.. eventually you'll want that Installed Rule to not just test for the presence of WINVNC.EXE, but also for the correct version of that file; else the WUAgent will be unable to distinguish between machines with the current version of WINVNC, and older versions of WINVNC.
For Applicability Rules the practice is to look for the file being present and with a version number lower than the one to be installed (e.g. there actually is a patchable application). Of course, if you're building a "Full Installation" package, then the mere absence of the executable file would be sufficient -- provided there is only one package in the WSUS server and approved for that client. (So in this case, building the first package with some forethought regarding the eventual existence of a subsequent package will save a lot of headache when that second package comes to be in existence.)
Now, there may also be some relevance to how you've implemented the "does not exist" logic, so that could be complicating things as well.
Of course, if you're having issues establishing a WMI connection to invoke the Update Deployment task, then the package is completely irrelevant. Support can definitely help you with WMI connectivity issues.
Thank you for that information. There was once an excellent youtube video on creating these rules back when this product was still eminentware. I believe you were the one who did it as well. Do you happen to have a link to this video?
No videos on YouTube, but there was a collection of videos hosted on the EminentWare.com website. Links to those videos are available here on the Thwack site in the Library and Support collection.
Package Creation Video #1 - covers fundamentals of update metadata and installation file specifications.
Package Creation Video #2 - covers rulesets and their interactions.
Also, recently I did a series of blog posts in PatchZone that covers this information on a more basic level.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.