Right but the idea is to make these part of patching and add to bulk deployments. If we have to create a custom copy of every single fixlet or respectively add every single fixlet into a separate baseline it becomes a management nightmare… I just think that the design needs to be looked at long-term and
either something new kept in database/retrieved as session relevance inspector that would allow us to keep track the real applicability of baseline components at all times, irrespective of their “sync” state
alternatively look into a site-level configuration where you can configure how many fixlets rotation of each kind are kept (let’s say you configure “3”, so it automatically imports the last 3 version of each of those applications’ fixlets, and respectively fixlets are NOT overwritten). You can still instil the same level as current design with default value = 1 (i.e. unless you configure otherwise, it only imports the last fixlet for each application and keeps the numbers to a minimum). If you really want it to be fancy, you can do some more complex too - tweak that number to be per fixletID as well (VMware tools last 3 versions; SQL Management Studio last 2 versions; everything else 1 version).
Obviously, the same exact problem would exist with the new Middleware apps which are strictly server-only with slower deployment cycles, so there needs to be a solution for the version controls that doesn’t break the reporting capabilities.
Since our site content is digitally signed, we can’t really publish different versions with different Fixlet counts based on individual preferences. I think the most we could do is to publish several versions of the Fixlets and give you some tool to hide/unhide the Fixlets based on your preference.
That said, we don’t currently have any plans to keep earlier-versions of the Fixlets, as we auto-generate them and adding a version control piece to it is a pretty heavy lift right now where we’re focusing on adding more software titles as the priority.
I’d like to reproduce your issue with the baseline component relevance reporting though and I need to check my assumptions. Where your console is displaying “316 Unknown” - are the computers subscribed to the source site “Updates for Windows Applications Extended”, or are they only subscribed to the custom site that contains the baseline?
I just made two suggestions but yea, wide open if there are others. There just needs to be a level of control offered for - maintaining the version that you want to deploy that doesn’t add very heavy management overhead and at the same time offers the required compliance reporting.
You can replicate it quite easy. Here are the steps:
Create a custom fixlet with very broad relevance - let’s say: windows of operating system
Create a baseline and add the custom fixlet in it where you enable the relevant checkbox (you can leave the baseline relevance to “true”, it really makes no difference).
At this stage, what you would expect certain Relevant/Applicability count (let’s say you have 10 windows machines)
Go to the custom fixlet and narrow the relevance’s scope - let’s say: (windows of it and version of it = “10.0”) of operating system (i.e. instead of the 10 Windows machines, you only have 6 Windows 10 and the remaining 4 are Windows 11)
At that time, if you go to the “Component Applicability” tab you would be seeing something like: 0/0 (6 Unknown), in other words it knows that there are 6 relevant to the baseline now BUT it has no idea what the applicability of those 6 machines are against the actual components of the baseline. Respectively, at that time the session relevance that you suggested just returns “0”…
So, just to answer your question - YES, the machines are subscribed to the external and the custom sites, and they have been all along (no change to subscriptions whatsoever), just the change of the fixlet that no longer in sync with the component is losing the ability to track the individual component applicability…
Yes, you’re right, I’ve reproduced…I don’t see any way around it though. From my client logs I can see the source fixlet become relevant
At 14:21:39 -0500 - CustomSite_Check_This_Out (http://BES-Dev-Root:52311/cgi-bin/bfgather.exe/CustomSite_Check_This_Out)
Relevant - test baseline component relevance (fixlet:7722)
And I can see the Baseline containing the component become relevant:
At 14:22:38 -0500 - CustomSite_Check_This_Out (http://BES-Dev-Root:52311/cgi-bin/bfgather.exe/CustomSite_Check_This_Out)
Relevant - Test Baseline Component Relevance (fixlet:7723)
However it doesn’t look like there’s any point at which the client reports which components of the Baseline are relevant. That has to be calculated at the server/console based only on the source fixlets, so when the source fixlet changes it can’t tell anymore (and on mine it goes to 0 immediately upon un-syncing the component, same as you observe).
Adding a data point on VMware Tools – we just used the Update: VMware Tools fixlet for the first time, and had to run it twice with reboots each time before it successfully updated VMware Tools. I suspect that it may have updated C++ first and then completed the VMware Tools update second, as suggested up-thread. We’re grateful to have the VMware fixlet available! However, it would sure be nice if it handled the whole process in one shot somehow.
Yes, this is a case where we’re a bit at the mercy of the installers provided by the vendor. It should be possible to install the updated C++ runtimes separately before installing VMWare tools itself, and possibly that might remove the need for a second reboot, but trying to anticipate that condition and work around it would probably delay our ability to publish updated fixlet versions.
You can do that yourself though, can’t you? VC++ requirements for VMware tools are well documented (link), so you can easily create yourself an analysis/property to check the version of VC++ you are after and know ahead of time which machines will require a single reboot, and which two. From there when you are scheduling deployment on machines that do NOT have it, then schedule it twice. We have been using the fixlet ever since first release of it and has deployed a few different versions company-wide, and haven’t seen any instance of it (VC++ is just there) but if you have an environment that is not the case then you should make plans for it. As you can imagine, it will be nearly impossible for HCL to have a fixlet for all those apps that will just account for all pre-reqs in all customers’ environments and account for any issues…
There are a number of other things you can do as well - you can create a baseline and stick the fixlet in there twice (you can even make one of them a custom copy and stick relevance only if VC++ is not present); as Jason suggested, you can have a fixlet that does fresh install of VC++ as first fixlet in the baseline; etc…
Certainly, we could create a baseline each time a new fixlet comes out, and we could also spend time running down the VC++ relevance.
But, we just went through our whole environment updating VMware Tools on all VMs (Server 2012 through Server 2022) by applying the fixlet twice with a reboot after each. That process was 100% successful regardless of the existing config on the VM. There’s not really a downside; if it’s applied twice when it’s not needed it still succeeds – it installs just fine over itself. Also, it doesn’t take long to install. So, the easy button is just to install it twice and forget it. As a result, I would say that an Action 2 doing just that would completely solve the problem.
I presume that it would not be hard for HCL to add that action to whatever script they use to generate the fixlets.
We do try to avoid using action presets unless they’re absolutely necessary. In the first case, an action preset may be unexpected if the operator isn’t paying close attention and expects their own default action behaviors to apply (certainly having a separate “Actions” can help indicate that the action is outside of the norm). There’s also a considerations hat action presets won’t apply in a Baseline or Patch Policy configuration.