What is "Updates for Win Apps Extended"?

Usage and Config Patch
1

If you haven’t noticed, there is a new patch site available for Lifecycle and Compliance customers called “Updates for Windows Applications Extended” and it currently has over 100 titles covered. I wanted to explain a bit about the site in general and cover some frequently asked questions.

How do I get the site?

If you are a Lifecycle or Compliance customer, as a Master Operator, look to enable the site Updates for Windows Applications Extended in the License Overview dashboard in the Windows Console. This only needs to be done once. You will then have to set which computers are subscribed to the site once the first gather has completed.

This YouTube video shows the process, but be aware, the site will now show up as the full name, not like it does in the video at the time: https://www.youtube.com/watch?v=LtS_pWlBeao

What is the target platform?

Windows 10 64bit or later is the platform specifically targeted, but that also includes Windows Server of similar version. That said, most of the content COULD work on Windows XP 64bit or later in many cases, and SHOULD work on Windows 7 64bit or later in basically all cases.

If you have trouble with an update NOT working on something older than Windows 10, let us know, but the fix is very likely to be that we add relevance to exclude older operating systems unless there is a simple fix that could be made to the actionscript.

What about Windows 32bit?

We do not intend to create 32bit software updates when there is a 64bit version available from the vendor. That said, if there is only a 32bit version available, then that update is written to work on both 32bit and 64bit versions of Windows, but it is only tested on Windows 64bit.

If you have a lot of 32bit Windows out there and can make a compelling case for it, then I’m interested to hear about it, but this is not a current priority.

Will you make a 32bit update fixlet for software where a 64bit version is available?

In most cases, no.

There are exceptions, particularly things like JRE/JDKs where you need both a 32bit and 64bit version depending on what kind of software is using it.

For most other software, the 64bit update should be relevant on systems that have the 32bit version installed and it should upgrade from the 32bit installed version to the 64bit installed version. That said, this has not been tested in all cases and may fail or may result in both versions being installed. We may need to publish content in the future to help handle this case and transition from the 32bit version to the 64bit version.

If you have very specific use cases where you absolutely need the 32bit version of a certain software update, I’d be curious to hear about it, but it will be a case by case basis.

What software will you consider including in the future?

Any software that has a publicly available download (no login required) and can be silently installed per machine for all users. Software that can only be installed per user might be done as a rare exception, but not the typical case. Software that requires a login to download might be possible to address in the future, but it will require a download plugin to be configured for each vendor on the root server or top level relays, which is not ideal.

Ideally the software has a version specific download URL available so that when a new version is released, the older version is still available for download. There are those that do not appear to have a version specific download but they in fact do, so it isn’t always obvious. That said, we will make exceptions to this depending on the software, but just be aware, if the vendor updates their software before you have actioned one of them and before we have updated it, then the prefetch will have a hash mismatch and will not work until we update. We are looking at options to help with this situation in the future, but our current solution is just updating more often. If you were to deploy a WebUI Patch Policy that auto refreshes content from this site to test machines, then you should be less likely to run into this problem as long as your root server has a large enough cache configured. I would generally recommend at least a 100GB root server cache, especially as the size of this site grows over time. See more info on the setting _BESGather_Download_CacheLimitMB.

How often will you update content in the site?

We intend to update at least once a week, but we will generally update more often than that and are working on making it more frequent over time. Generally not more often than once a day.

How many versions of each title are available to update?

We only keep around the newest version of each software. That could include multiple long term servicing branches of some software in the cases where each branch is getting actively maintained in parallel, in which case there will be fixlets for each. Software that is end of life or has not received and update in over 2 years is not generally going to be considered, though there could be exceptions.

You can make custom copies of the fixlets if you want to maintain specific versions.

What if a vendor stops providing the download?

Then the fixlet for the vendor will stop being updated, marked as deprecated, and then removed after a time.

How do I request new software be added?

NOTE: Federal customers should contact Devaughn Rackham instead of using the Ideas Portal.

Please submit an Idea to the section currently labeled “Content” in the HCL BigFix Ideas Portal with the name of the software, the webpage you download the software from, and an example link to the actual downloaded file. MSI installers preferred when available.

This section may be renamed from “Content” in the future.

Also, please vote on existing ones that you would like to see.

What about CVE Metadata in the update fixlets?

We don’t currently provide CVE Metadata. We are looking into options for providing it in the future, but may come in the form of metadata outside of the update fixlets themselves.

The content DOES include CPE metadata tags. In some cases those tags might not match the corresponding CPE tag in NVD, but we are working to correct that over time. These tags can be used to correlate with data in NVD.

What is the value to the site? What is the overall goal?

The goal of the site is to provide update fixlets for as many software titles as possible. The ideal main value of the site is the quantity of software titles covered. The content will not have as thorough descriptions with version specific information. It will not have metadata that cannot be figured out automatically. We will put info in the descriptions where needed in general where a particular content is different than other examples in the site, but it is not the main focus.

Look for the amount of titles covered to grow in the near future.

Related:

7 Likes
2

We’re starting to use this and excited it is now available.
I’ve used the Wireshark, 7Zip, and a couple other ones with success.

I do have feedback & caution anyone using the vmWare Tools fixlet. It will not work as is. Reasons:

  1. There is not an "action requires restart " in the fixlet. A reboot is required.
  2. When the vmware tools EXE is extracted and it runs, it installs C++ runtime first. If the Windows OS needs C++ then it will install, and exit with exit code 3010 (reboot requierd) Then the vmware EXE will never install the vmware tools MSI. Requiring the fixlet to be applied a second time after a reboot, then reboot again to apply tools.

My team is working on completely reengineering this fixlet as we speak.

1 Like
3

If you or others have working fixes for it or any other one, then please let us know and we can update the actionscript or relevance as needed, at which point those fixes will carry over as new versions are released automatically.

It sounds like it should have relevance to only be applicable if the required VC++ redist is already installed.

That said, the reason it doesn’t have this is because this is a fixlet only for Upgrades, not for new installs, so we figured the VC++ redist would already be installed from the previous install.

This could be added. It isn’t always clear when a reboot is truly required or not.

2 Likes
4

Thanks for this, really useful and was looking for something like this from the begining!

For us specifically is WinZip. We have some legacy automation pipelines that rely on x32 version of WinZip. While we have officially migrated to x64 on most machines as a standard we do maintain x32 version on others as an exception of sort and unfortunately we will be stuck with them for at least a while. It would be extremely helpful if x32 version of WinZip is also considered.

Is there no consideration to offer some kind of configurable way to retain multiple versions automatically? For example, custom configuration where you can enable up-to let’s say 3 versions of the apps to be retained. The reasoning/use case is specifically about rollout plans and impacts. We run servers-only environment where it is closely controlled which app versions are deployed and each deployment plan requires first to deploy to DEV, then to UAT/DR/etc and only as last to PROD. Depending on the application complexity and any ill-effects it is not unheard of that certain app deployment to take months and by the time you get midway through, you may need to start it all over because a new version came out all of a sudden with no warning…

Copies is just not viable option - creating copies means you need to manually keep those copies but what happen if there is defect discovered in a few and it is re-released? There is just no easy way to keep track of the versions even of the same app version and its source code and the more apps that will be added (seems to be the general direction it is going) the harder it will become to manage all of this! I can easily see it being an operational nightmare in the not very far future…

It would be great if at some stage it is in the fixlets cause this will automatically rule the entire site from the CVE Search functionality as well as IVR which seems to be gathering momentum and met with significant interest…

One last question, that the above doesn’t clear - what criteria is used to identify what is “server software” and “desktop software”? It seems that general direction is to support “desktop software” and not every “server software” is being accepted to be supported but a lot of software is exactly the same whether it is for desktop or server and it is used for both. I will give you an example - one of the titles we asked for and is high on our agenda is SQL Server Management Studio and the answer we got is that it is not currently supported because it’s “server software”, well, I do have SSMS installed on my desktop too and use it. It is also same software type as MongoDB Compass (just different database type obviously), yet one is supported and considered “desktop software” and the other “server software”…

1 Like
5

To be honest, this is a really really specific need. I’m not against including it because you need it, but you might be the only one. We have heard this request and are considering it, and we might do it just because you need it, and this extra justification of why you are stuck needing it is helpful. Until hearing exactly why you need it, my inclination was to not do it.

This is what baselines do. If you add a component to a baseline, it will stay at the version it was at the moment you added until you “sync” changes in for that component. You add all the stuff you want on the versions you want to roll out to the baseline, then roll it out to Test/QA/Dev/Prod in whatever order and roll out schedule you want. You can even create a new baseline and starting adding new stuff to roll out to Test while you are still rolling out the previous baseline to Prod.

Also, because we are only keeping a single version around, you can take your existing baseline you created to roll out through your process the previous month, make a copy of that baseline, and then sync all the changes to the baseline and it would have all the new components from the site.

You can also use WebUI Patch Policies and just set the refresh interval to be long enough to get fully through all of the different stages including Prod, and then have schedules that are shifted in time, so the schedule for test goes first and prod goes last. The only problem with this is you can’t be deploying new patches to test while still rolling out existing ones to Prod unless the Prod action has already been generated.

Also, I think basically every time you take an action, you are in a way making a copy of the fixlet at the time you created the action, assuming you didn’t make any changes to the relevance or actionscript during action creation. (which is not a given) This would be super annoying, but you could technically reconstruct a previous fixlet version from an action.

That can happen, but is pretty rare. In general for most of these products that move quickly, the defect will end up being fixed in the newer version, but not the previous version of the fixlet. It is a stream that is just constantly moving forward. The only take there would be a fix is if the currently released version has a breaking defect and we need to fix it but there isn’t a new version for long enough.

We should probably have a way to call out this possibility specifically… basically that we are changing relevance or actionscript but NOT changing the version or the prefetch hashes, and thus you might want to sync your baseline component to get the new change.

It is not ideal for sure, but baselines are an interesting middleground.

This is a high priority for us because we also use it internally a bunch. This was actually one of the first apps we started doing with this process, we just haven’t released it yet, but it is coming in the near future. Anything we use a lot internally or use to help setup, configure, or manage BigFix itself is automatically a priority for us.

There isn’t a clear distinction between server software and desktop software, and we aren’t limiting the content to only “desktop” software. There is some server software that is not as easily downloaded and installed without a license or other configuration applied.

Another category we are not currently able to do, but might in the distant future is plugins for other things, like office plugins, browser plugins, server plugins, etc… The relevance is much more complicated for something like that. If you notice, the majority of the relevance for the majority of the things in the site are the same, with only the name and version being different.

Visual Studio (not code, the full one) is kind of hard to download and install and update because there are like 500 different possible combinations of things and it could range from like 1GB to 50GB depending on what you select. We are experimenting with it, but not sure it is viable honestly, just because we aren’t even sure what would make sense for the most people.

This is the real distinction, things that are not really easily installed or updated without making very specific choices, or even having a full offline installer is just too big to really be reasonable.

Also, we have considered making the client setting _BESClient_Download_FastHashVerify mandatory for the content in this site and provide a fixlet to enable it. We may have to if we deliver fixlets that have downloads over a certain size for those specific fixlets.

We have found that there are generally 0 CVEs for the newest update for fast moving software updates, even though that particular update would close CVEs in much older versions of the same software, but sometimes many years or 20+ versions back. We are looking into methods to address this in the future, but putting a CVE in a fixlet to say that fixlet closes the CVE, but that CVE isn’t in the exactly previously released version, then it causes false positives for CVEs and other problems.

If we can find a way to automate CVEs in a way that works, we will, but we are focused on adding more software titles for now instead. We will investigate this further in the future, but we already have an idea of how to make it work.

1 Like
6

Thanks, @jgstew, really useful info.

Again, they are linked to legacy pipelines which do whatever processing work and application publishing/compiling and use x32 winzip which used to be our standard from back in the day when we still had 32bit OS (not that we have gotten rid of all of them today, unfortunately). It will just take ages to rewrite all those pipelines before we can fully get rid of the x32 winzip…

I did think about baselines but again that makes sense if you are doing bulk deployment - if they are doing application per application then creating a baseline with 1 single fixlet just so we have it “frozen”/“safeguarded against overwriting” is a bit tedious.

Looking forward it for sure then!

I will ask around our Vulnerability Management team to see if they have any sources of information. I know our vulnerability scanning (Qualys) would certainly be capturing stuff but not sure if they would share where they are getting their CVEs from for each of the products…

7

From what we can tell it comes from NVD. We are able to get the same CVE info from NVD APIs and have done so, but we have found that it isn’t obvious where to put it.

8

Yes, the complication here is that the vulnerability scanners and NVD itself generally track “software version X has CVE-1, CVE-2, CVE-3”; while what we track on the BigFix side is “fixlet X resolves CVE-1, CVE-2”.

Where that gets complicated is what CVEs should we say the latest version of WinZip fixlet resolves? Should it be every CVE that has ever existed in any earlier version of WinZip? That would give the false impression that when the system is relevant to the latest version, that the system is vulnerable to every CVE that ever existed, even if you are only one dot-release behind the latest version and maybe only actually vulnerable to one of those CVEs.

We’re still deciding the best way to represent a case like that, but it’s not desirable to have separate fixlets in the Console for every version of WinZip that has ever existed, to track which versions corrected which CVE. That’s where we might want to leverage something like Compliance or Inventory instead, to keep track with the external CVE-to-Version mappings, reporting on “what versions are installed” versus “what fixlets are relevant”.

3 Likes
9

I have another consequence of the baseline approach discussed above that I wanted to check if I am missing something. We have a bunch of custom session-relevance-based web reports to track compliance %s (what’s the % of installed of the total), what is still outstanding, etc. All those reports are based on the user supplying a list of devices (paste the list in a text box, run the report and it spits out the data only for the machines in question). The general structure of the session relevance is the following:

(name of it, concatenation "||" of (((if (exist source id of it) then (name of it & " (" & source id of it & ")") else (name of it)) of fixlets of it) of (results from (source fixlets of components whose (include in relevance flag of it) of component groups of bes fixlets whose (baseline flag of it = true and (name of it is "Baseline1"))) whose (relevant flag of it = true) of it)), last report time of it) of bes computers whose ((",machine1,machine2,machine3,") contains (","& name of it &","))

I yanked a bunch of custom properties we display cause they are just not pertinent for the question but there are 5-10 custom properties in each of the reports. Now for all other patching fixlets because of the nature they work (rarely change the code and if it does, it is some kind of bug-fix) those reports work. With the Extended patches it doesn’t anymore as soon as the actual fixlet is updated with a new version cause “source fixlet of component” essentially is the latest version of the fixlet, not the one in the baseline, so respectively shows machines as relevant even though they are not to the version cached in the baseline.

I looked at the properties available for bes baseline component and there just isn’t anything but the source fixlet (i.e. ideally there should be “cached fixlet” where it gives you back the version that is in the baseline). I did see the “applicable computer set” property but that will just not help me since my report is per-computer, not per-fixlet. Am I missing anything? Any ideas how to adjust the report to show me the compliance/relevance for what is in the baseline?

1 Like
10

Our finings thus far on vmware tools.

  1. The vmware tools EXE has two primary components:
    1.1. Microsoft Visual C++ 2017 (2 EXEs, 32 & 64bit)
    1.2 VMware Tools MSI
  2. When the EXE runs it extracts all 3 components and has it’s own logic to determine what is needed. If it upgrades C++ or installs it, often it will require a reboot to complete. When a reboot is needed, the VMware Tools MSI will just NOT run and exit out.
    2.1 Logs can be found verifying this fact at: C:\Windows\Temp\vminst.log
    2.2. VMware documentation states this specifically and offers no solutions, other then to re-run the install again after reboot. See step #6 at the bottom.
    2.3 Install or Upgrade to VMware Tools 10.3.0
    2.4 VMware Knowledge Base

Our Solution ideas:

  1. Create a baseline. Break out the C++ runtimes to it’s own fixlets.
    1.1 Check for pending reboot and reboot.
    1.2 Install the C++ Runtimes
    1.3 Check for pending reboot and reboot.
    1.4 Run the HCL Fixlet for vmware tools, but modified with "action requires restart “647e6b799359549b4407983ae23f838cc63f81d8” at the bottom of the fixlet.
    1.5 Check for reboot and reboot.

  2. Create a baseline using HCL Fixlets.
    2.1 Check for pending reboot and reboot.
    2.2 Run the HCL Fixlet for vmware tools, but modified with "action requires restart “647e6b799359549b4407983ae23f838cc63f81d8” at the bottom of the fixlet.
    2.3 Check for reboot and reboot.
    2.4 Run the HCL Fixlet for vmware tools, but modified with "action requires restart “647e6b799359549b4407983ae23f838cc63f81d8” at the bottom of the fixlet.
    2.5 Check for reboot and reboot.

We are currently going with option #2 as it effectively does what option #1 does, but requires less work as we can just use the HCL Fixlet, just by adding “action requires restart”.
So far working well, we’ll be deploying to ~2k Windows servers this coming weekend.

image
image676×866 43.4 KB

1 Like
11

I haven’t been able to test this at scale yet, but it might be worth trying. Basically it’s a check to see whether this BES Computer is contained by the applicable computer set of the baseline component. If you validate that it works at the kind of scale you need it’s not difficult to add your other filters and report properties back in.

(name of item 1 of it, name of item 0 of it) of (components whose (include in relevance flag of it) of component groups of bes fixlets whose (baseline flag of it and name of it starts with "TcpTuning"), BES Computers whose (name of it as lowercase = "bes-root")) whose (applicable computer set of item 0 of it contains item 1 of it)
12

Hm, this is pretty complex to be sure.
What I think might be useful, is to use Action Settings when taking the action. Since this is a Fixlet, it has the default Success Criteria where it will appear as Failed if it’s still relevant after execution. Set the 'On failure, retry 1 times" and “Wait until computer has rebooted”, and set the post-action Restart options however you need them.

The first time it executes, it should extract & install the Visual C++ Runtime prerequisite, without installing VMWare Tools itself. The Fixlet has a ‘restart required’ so the Action Status should move to ‘Pending Restart’.
After rebooting, the Fixlet is still relevant, so it should be marked as Failed; the Retry logic will then have it execute again, and this time it should successfully install. It’ll be marked as ‘Pending Restart’ a second time, but it’s pretty likely that installing VMWare Tools really does need the second restart to take effect since it includes some boot device drivers.

image
image697×507 31 KB

1 Like
13

Good thinking around the “On Failure” and “Reapply” options.
I am not close enough to the testing on this to know if it’s throwing a failure code, but I think it’s just more of a generic pending reboot type code.

I bet “Reapply Action” would help as well, to retry after a reboot.

I just threw this baseline at 12 servers, and the “Show Action Info” on two different servers shows one that needed C++ and one that did not. Happy so far with the results.

Did not require C++
image

Required C++
image

1 Like
14

Hi Jason, the baseline was updated during our monthly patching cycle and the updated fixlet removed from it, so I lost the ability to test it but if I am not mistaken “include in relevance flag of it” is essentially the “Baseline will be relevant on applicable computers where this component is relevant” checkbox, i.e. will just tell you if the component relevance is impacting baseline relevance or not but won’t give you the “relevant” components back…

image
image1865×419 31 KB

15

Yes that’s how I understand it.

1 Like
16

That is interesting. I can see how this is annoying.

I guess you could see if the current computer you are viewing is within that set?

17

Yes, I am hoping that “applicable computer set” is actually based on the cached version and not on the source version but yea, will need to wait a month or so to capture it again and test if it is the case or not. If it is, what Jason provided should be a viable solution; if it is not, back to square one…

1 Like
18

It doesn’t seem to be working at all. Ran it through WR’s QnA. So back to no solution… It is better than “source fixlets of components” in the sense that it is not misreporting in the scale of thousands but it still reset the value to “0” and treats the value as “unknown” just like the console treats it (and that is wrong as well)…

Q: (name of source fixlet of it, number of elements of applicable computer set of it) of components whose (include in relevance flag of it) of component groups of bes fixlets whose (baseline flag of it and name of it starts with “baseline”)
A: Enable hardening changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) - KB5004442, 0
A: Update: VMware Tools v12.0.6.20104755 - Windows (x64), 0

image
image1870×851 106 KB

image
image914×158 10.9 KB

19

Long term it is a goal to provide content for VC++ runtimes.

1 Like
20

If this item is the only item in the baseline, and that item is set to make the baseline relevant, and the baseline has no other relevance, then all computers relevant to that baseline should be missing that version, even if it is out of sync with the source.

This is kind of what I mean by making a copy into a baseline at a specific version. Then that baseline represents that fixlet at that locked state.

As soon as you add anything else to the baseline and set the flag for it to make the baseline relevant, then that relationship no longer holds. Same is true if you add any applicability other than TRUE to the baseline.

The only reason to do this is so you can sync that baseline up to current periodically. Otherwise you should just make a copy of the original fixlet at the time.