Prefetch file from custom site

(imported topic written by bill.ehardt91)

I’m looking for how to prefetch a file from a custom site so we can quickly update a file and use the same task over and over.


I currently have a task that takes a .ini file, searches for the server name, and if it finds it then update some registry settings. That works with no issues.

The only problem right now is in under to update the file we need to re-upload it to software distribution and update the prefetch date. For me this isn’t a problem, but I’m trying to make this as painless as possibly for newer members of the team.

I saw dynamic downloads and I’m trying to find if there is an easy way to say “download AM_List.ini of this site” and somehow convert that to a prefect statement? This way, users would only need to copy the newest file to the site, then run the command.


(imported comment written by bill.ehardt91)

I’m sure I can just set the file to be a client file in the site and set the relevance that way, but I’d prefer not to a we may just want to update 20 or 30 servers via this method, so no need to send it out to thousands of machines.

(imported comment written by bill.ehardt91)

I guess the easiest way to answer this is… what is the easiest way to push out a constantly changing file to a group of servers?

(imported comment written by SystemAdmin)

Not knowing where the “original” file resides, I would create a folder under wwwrootbes and share the folder with appropriate admin permissions so that only appropriate people can mess with the folder’s contents. You would then place the INI file in this folder/file share.

The task you created would then simply download the INI file from this folder using action script something like:

// Download my INI file

download as myfile.ini

// Do something with my INI file

copy __Download\myfile.ini C:\temp

. . .

Notice we are not using the prefetch command, which use SHA1 and file size values, and we are also not using ‘continue if {. . .}’. So basically we implicitly trust that the INI file has not been tampered with.

Best practices would have us verify the SHA1 and file size values, but we “replace” this best practice by ensuring the myfolder file share permissions are tight enough to secure the INI file.