Getting version of a file without a version property

Content Authoring
21

What account does it run under when these permissions are NOT required? Does it run under SYSTEM? or Network Service? or other? ( What is the default service account when one is not specified )

22

A local account named “ddagentuser” that gets created during install by the MSI itself.

1 Like
23

Oh! I did not understand that was what you were showing me! I get it now.

I missed this part, I was too focused on the screenshot.

1 Like
24

I was wondering if one approach, separate to what @jgstew may be looking into, would be to use the version specific download URL then have relevance in the fixlet that check for the service and version, i.e if service version 7.50.3.0 or later doesn’t exists, the fixlet is relevant and it will deploy only the 7.50.3.0 agent. Obviously I’m not familiar with the agent or the other install parameters you need for your environment but for me, this method that downloads a static version provides you version control and you do not need to worry about the vendor updating the “latest” version thereby loosing any form of change control

Detection (sample)
(windows of operating system) and (not exists service "datadogagent" whose (version of it >= "7.50.3.0"))

Action (sample)
prefetch ddagent-cli.msi sha1:303fd982d7675693b55a96ca41ab12b1abf533a2 size:151891968 https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-7.50.3.msi sha256:afd7927271157930b2f2dcaf80b9fef6b1964f3ef0a353ee5b93d8e28b18b456
waithidden msiexec.exe /i __Download\ddagent-cli.msi /qn /norestart

1 Like
25

As there are multiple agent updates at times in a month due to vulnerabilities, we want to be able to allow our content run on a regular basis (via Patch Policy) without the manual work of checking the latest by accessing the release page, updating the fixlet relevance/actionscript and deploying…

So in summary, what we did was the ff.

Relevance:
Check only the existence of Datadog Agent service running and exclude any server that is SQL/DC

Action:

  1. Download latest MSI
  2. Check MSI version via Powershell function and output to a file (thanks to @SLB!)
  3. Run current version check VS the version in the output file
  4. If current version < MSI version, run update action
  5. Else, do nothing
  6. Delete files
  7. Exit

I know the code/approach may not be pretty, but it seems to work at least for now. :smile: While I’m still trying to learn other automation tools/scripts that can help moving forward.

1 Like
26

One issue with this approach is there will be a lot of downloading of the MSI that is not needed, plus the download of the MSI will not be validated outside of the SSL connection itself, so it could be maliciously modified in transit. (though the SSL validation does partly attempt to prevent this)

Also if you send this to too many computers at once, it could cause a massive amount of traffic all at the same time and take down networks.

This approach may work for your needs, but it has some major drawbacks that using a prefetch that distributes the MSI through the BigFix relays would not have.

This is exactly what I was working on.

This fixlet is automatically generated from the latest agent download available every time I run the automation:

The automation could be run on a regular basis in order to generate the latest fixlet and then deploy it only when needed and do so using the BigFix Relays.

4 Likes
27

Very nice.

I’ve been playing with the idea of using as much Bigfix native methods as possible to automate via a fixlet…a little weekend project to keep the old braincells exercised :laughing:. The idea being a fixlet will download the JSON, parse the latest version and if the latest version is different to current version, it will download the MSI and update a fixlet with detection relevance and actionscript then deploy it…in my testing case a computer ID. This way only the JSON is downloaded on a regular interval so is very low bandwidth use.

Try this proof-of-concept fixlet in a suitable DEV or LAB environment (I would not suggest using a PROD env and hopefully I’ve got these steps right :wink: )

  1. Create an empty fixlet is whatever custom site in your environments you want this in, in my LAB env its “My Windows Support”
  2. Download the fixlet Bigfix/DataDog - Auto Deployment of latest version.bes at main · RobG-BF/Bigfix · GitHub
  3. Edit the fixlet as follows
    a. Line 35 – Change the value of the fixlet id to match the empty one created in step 1
    b. Line 183 – Change the site from “My Windows Support” to the custom site for fixlet you created in step 1
    c. Line 188 – This will need modifying the reflect the type of targeting that is applicable to your environment, possible a relevance statement to target a group, eg &lt;CustomRelevance&gt;member of group 876 of site "CustomSite_MY-2dGroups"&lt;/CustomRelevance&gt;
    d. Line 201 – Change the site name from “My%20Windows%20Support” to the custom site for fixlet you created in step 1
    e. Optionally, and recommended, comment out line 202 so no action is created……if in a LAB or using a computer ID, the action should be low risk.
  4. Import the fixlet (it uses secret parameters for operator password so it will warn about dynamic content)
    image
  5. The fixlet will only evaluate relevant on the main sever.
  6. Review the fixlet in the console and double check changes are correct. You can make further modifications via the console is you need to.
  7. Deploy the fixlet, remembering to enter your operator password before hitting the “Take Action” button.
    image
    image933×576 21.7 KB

Once deployed to will create/update files in the /Uploads/DataDog folder so these can be reviewed and the dynamically created fixlet and action XML files syntax checked.

image
image1068×271 19.9 KB

I wont suggest this is the cleanest or most slick of methods (with more spare time it would be nice to add option to select the site and fixlet via combo boxes so the fixlet is much more dynamic and doesn’t use hard coded fixlet IDs or site names, and there may be a better way to parse the JSON) , but it is using purely platform native features hence it runs on the min server to use platform supplied IEM.exe to access the REST API rather than other scripting language methods (granted one could also use curl.exe).

Similar to @jgstew this can be deployed to re-run every day, every 7 days etc so the content is updates as the vendor releases new versions.

4 Likes
28

I have many older examples of doing this with the REST API, templates, Relevance and CURL on BigFix.Me

The idea was to have almost all of the logic in the Relevance / Session Relevance and only depend on CURL on the remote system to make everything work.

It is clever, but hard to scale and maintain for more complicated things or for doing the same for many many things.

Also, because I haven’t maintained them the curl that it downloads is out of date and no longer even technically required on certain versions of Win10+ that now ship with CURL.

One thing that I do like about this method is that because it only relies on REST API / Relevance / CURL, it can be implemented using almost anything, including a console dashboard, or adapted to Python or PowerShell using similar templates.

See Examples:

That said, I do NOT prefer this method anymore and use a different automation method now.

This example: RESTAPI: Generate uninstall tasks for all MSI applications - Windows I now do this way: generate_bes_from_template/examples/generate_uninstallers.py at master · jgstew/generate_bes_from_template · GitHub

This example: RESTAPI: Generate tasks to set client settings on target computer - Windows I now do this way: bigfix-content/dashboards/ClientSettingsManager.ojo at main · jgstew/bigfix-content · GitHub

4 Likes