Need to create a task to run a PS script to install an application from a network location. Running the PS script manually pulls the installer from the network location and installs/configures as expected.
Next step is to create a bigfix task that will either 1) push the script to the client and run it, or 2) run it directly from the bigfix repository. Being new to bigfix, I’m not sure of the easiest way to accomplish this. I found the following post which details manually creating an Action script, but I was hoping to let the tool create it and I would just feed in the PS script.
You just copy and paste the contents of your existing powershell script in between the createfile until END_OF_FILE and END_OF_FILE lines, replacing what is in between them already.
This is not generally how I would recommend doing this. You should instead use a prefetch statement to download the files using BigFix, then run the part of the powershell script that does the installation and configuration with the locally downloaded copy.
A BigFix prefetch will have a greater chance of working across network boundaries than trying to download directly from some network location. Also, you won’t be able to actually download from the network location if it requires authentication, unless you have credentials within the powershell script, in which case that is a bad idea.
Thanks jgstew, yes, it is Powershell I’m working in. I was able to get the script to work with the exception of a curly brace issue (line shown below). With the help of some more experience on the team, we added a ‘{’. Not sure why, but the action is failing on this line. Through trial and error, we found adding a curly brace fixed the issue.
I’ll have to read up on the prefetch block. You mentioned downloading from a network location will have a higher failure rate. As far as the prefetch goes, will that store the package in the bigfix repository? Just want to make sure I’m understanding.
curly braces need to be escaped in actionscript because that is how actionscript does “relevance substitution”. It is a bit annoying to have to do this, but that is the reason.
There are a few different methods for prefetches / prefetch blocks. The 2nd & 3rd option is generally what I would recommend:
One is that you upload the file to the bigfix server using either the REST API, a wizard, or some other method. This will store the file on the bigfix server and then the prefetch command will pull it from there. The main drawback of this method is that you would have to manually delete the upload from the BigFix server when it is no longer in use, or use an automated method to try to detect and do cleanup on a schedule. This is how most people do it, but not the method I would recommend for large files.
If the file that is being downloaded to the clients for installation is available on the public internet, then you could use the URL for the actual download file in the prefetch. This is safe from man in the middle attacks because the BigFix system validates the SIZE, SHA1, and other attributes of the file to ensure it is the same one. This only works for some cases, but usually the majority if you do it right. These types of downloads do not get permanently stored on the BigFix root server, but instead go into a cache that rolls over automatically when things are not used anymore. This is the method I primarily use.
The other option is that you have an internal software repository that you place software on and have available to the BigFix root server to download over HTTP/HTTPS. It could be available to other systems in your organization as well, but it is only required to be available to the BigFix root server. You then use URLs pointing to this software repository in your prefetch statements or prefetch blocks. I think regardless of what method you use, PowerShell, Prefetch, or anything else, this is a good idea and should generally be done anyway. This method causes BigFix to cache the content from the software repository in its cache that rolls over automatically, so you don’t have to manage storage on the BigFix root server as much.
The reason to use Prefetch Statements or Prefetch Blocks is that then the downloads pass through the BigFix root server and relay infrastructure, which provides very good load balancing, failover, and reliable downloading. If the client can communicate with BigFix, then it will be able to do downloads generally. This also has the benefit of optimizing the downloads over slower links. If you have a BigFix relay behind a WAN link, then generally all clients will be downloading the content from there instead of from a central source. This will greatly improve the speed of distribution while reducing the single point of failure.