SiteCacher v1.1

During the last few user groups I’ve attended, there were discussions around download errors particularly with the ‘Updates for Windows Applications’ and ‘Updates for Windows Applications Extended’ sites which happen when the vendor makes changes to the download after we publish the task.

In an effort to circumvent this, SiteCacher is a task that will automatically download all RELEVANT downloads and cache them on the root server. By default, it will run (via Task Scheduler) every 12 hours.

How it works:
After filling out the required fields on the description tab, you target the root server. A directory will be created in the BES Client folder on the root server. The operator password will be encrypted and stored in a file in this directory as well as a PowerShell script. In addition, a scheduled task will be created on the root server.

When the scheduled tasks runs, it will look at all relevant fixlets/tasks within the site and compile a multiple action group. It will then choose a target from the subscribed endpoints.The relevance being used in the MAG will force a not relevant FALSE.

This will then download and cache the selected payloads.

Note that this will work on any site.
To properly use this task, make sure you have enough cache on the root server to accommodate all the downloads and retain them for a period of time.

Please note: This is not an HCL supported task. Please test before putting into production.

SiteCacher Status.bes (1.1 KB)

SiteCacher v1.1.bes (10.7 KB)

8 Likes

just ran this, the schd’d task gets created and it successfully creates the action on schedule (with several extended 3rd party app fixlets). However, i’m not seeing any payloads actually get cached to the sha1 folder. Anyone have any luck with this?

Hi Lou, Any way you export that action and attach it here?

sure, here you go.. Thanks!

SiteCacher_ Updates for Windows Applications Extended.bes (34.8 KB)

It’s working for me…

odd.. i don’t see that.. this is what i see

That is odd. What happens if you export then reimport that action? relevance is FALSE so targeting is safe

same thing.. i targeted my root server (it’s a lab environment)

@LouC ,

Check the Client Logs: On the endpoint, navigate to the BES Client __BESData__Global\Logs directory. Look at today's log file (e.g., 20260624.log) to see if the client ever received the action ID, or if it's throwing relay connection errors.

Verify UDP/Command Polling: If the client logs show it only picks up actions when the service is restarted, you likely have a UDP blocking issue. Enable Command Polling (e.g., every 15-60 minutes) on that endpoint as a workaround.

-Gus

it appears to be something specific to my lab environment. I deployed in PROD and it’s working as expected. Thanks for creating/sharing this @menglish66

1 Like