Hello all,
in our LAB environment we create baselines per our company standards and after they are distributed to several different PROD environments. We use currently version 9.5.13.130
Issue: Since “patching.bes” contain hardcoded info from LAB:
SourceSiteURL=
SourceID=
which is different to every other PROD, uppon import to PROD baselines they can be used for patching, but they show fixlets/components as “source unavailable”, example:
MS20-MAR: Servicing Stack Update for Windows Server 2016 - Windows Server 2016 - KB4540723 (x64)
source unavailable
Windows Conditional Restart Task
source unavailable
MS20-MAR: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB4540670 (x64)
source unavailable
Windows Unconditional Restart Task
source unavailable
etc …
and patch result check via WebRepots is therefore reporting 100% no matter the patching succeeded or failed. Customers therefore have no way to determine result and how successful was their patching.
My question to you all is, what is the fix for this? Or best/better practice to export and import baselines across several environments to not have corrupted “source unavailable” component list.
Does BigFixPatch have some script or job that would fix baselines on each PROD environment and fill component with correct source info/data?
Thanks and regards.
We don’t have any built-in script to do that, as far as I know. The .BES file is simply XML text though, so it should be possible to open it and do a find/replace to swap the source and Target deployment names.
Some customers who run multiple deployments use the REST API to generate their Baselines on each deployment , and their orchestrator carries the logic for which components should be “in” the baseline, so they don’t copy baseline from one deployment to another. Others forgo Baselines entirely, and just use the API to send individual actions instead.
Most of us who have multiple deployments don’t use them in quite the way you are describing (though I understand the reasoning). We use our pre-production BES service for testing BES itself - updates to BigFix versions, API orchestration and custom reporting, for example. When it comes to testing patch deployments across the platform though, that’s usually just a custom site and computer groups assigned in the operational BigFix deployment.
The idea of a find/replace in the XML should work for external sites like “Patches for Windows”, but it won’t work for any custom site source components - because the same fixlet may have different fixlet IDs in each deployment. There it would require some more complex handling, like tracking source fixlet IDs and Names and mapping those to new fixlet IDs on the Target deployment.
Thanks for answer. Maybe you or someone else can help me understand other possible ways to solve situation. My next question would be:
Is it possible to import custom fixlet to the environment and force SourceID which will be assigned to it? So we can import not only baselines, but also custom fixlets. (Custom fixlets are copies from the original “Patches for Windows” - this is done to avoid issues with patches that were superseeded at some point, which report as remediated/installed and in reality they were not installed at all)
Idea would be to import fixlets from LAB to PROD the way it will preserve SourceID and custom baselines from LAB will match.
For sure I know that original “Patches for Windows” have same SourceID on all environments (LAB and PROD):
454072304 MS20-MAR: Servicing Stack Update for Windows Server 2016 - Windows Server 2016 - KB4540723 (x64)
Official/original fixlets are therefore imported with same SourceID (therefore forced).
My question is how to force SourceID for custom fixlet via API 
I don’t think there is a way in the API to assign the ID for a new fixlet. There was at one time, but it was removed several years ago (I don’t know the issue or reasoning behind removing it).
I haven’t tried this approach before, but you might consider -
When you export/import the fixlets, create a new MIME field or two to track the original site and original fixlet ID, and use those to look up the new site & fixlet ID to when creating the new baseline.
When you export/import the fixlet, they should come over with MIME fields intact.
Instead of importing the baseline, you could create a new one. Loop through each component of the original baseline XML, and use a REST query to find the new site name and ID. Something like
(name of site of it, id of it) of Bes fixlets whose (exists mime field whose (name of it = "Origin_Site" and value of it = [original baseline source site]) of it and exists mime field whose (name of it = "Origin_Fixlet_ID" and value of it = [original baseline fixlet source id]) of it)
What is the best way of using REST query?
Should we use The Client API Tester https://developer.bigfix.com/tools/cc_tester.html?
Sorry for many questions, I`m curious and learning on the go
That one is for the Client Compliance API which is not the one you need for server REST API calls. You could use the iem command line, more at: https://developer.bigfix.com/rest-api/iem_cli/ or tools like Postman.
Got it, no need to apologise, love the enthusiasm.
The ‘best’ way to use REST depends (a LOT) upon what you’re trying to accomplish, and the toolsets with which you are comfortable.
The iem.exe command line is fine for the odd query, status check, or stopping an action once in a while. It has some pretty severe limitations though when you throw it at your use case - it doesn’t have anything built-in for manipulating XML content, for example.
If there are any high-level scripting languages with which you are comfortable, it can probably handle REST and XML.
Personally I prefer Python, which I’ve been teaching myself for the last few months; but I’ve also seen some very concise and useful integrations using PowerShell or Perl.
Any of these make it possible to retrieve a Baseline in XML form, and replace individual fixlet nodes in the XML before re-POSTing it as an updated baseline.