am trying to create a task that will copy and execute an msi installer from a network share. after playing around with the action script in the Fixlet Debugger i am able to get a copy of the file from my network share to the Download folder in the Fixlet Debugger site location on my local drive (C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__FixletDebugger\__Download). here is the script i am using to do that:
when i add this as a Task in the IEM Console and run the action on a few subscribed PCs, the action fails. but i would assume that if it works to copy the file to the Fixlet Debugger site it should do the same and copy to the current site’s __Download folder if run through the client, right? i am wondering, why does this work in the Fixlet Debugger and not from the Client on my test PCs? the only idea i have is that there is possibly a permissions issue but i am not sure how to debug that. i tried accounting for it per the first reply in this thread where the response mentioned assigning permissions on a network share to the computer accounts instead of user accounts: https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014751302
all of this is because, long story short, i have temporarily lost access to the Software Distribution Wizard within the Console and need a way to drop a copy of a customized installation file onto each machine in a location where IEM can then go ahead and execute the file. is there a way to upload a file to the BigFix server Uploads folder besides using the Software Distribution Wizard?? that would really make this all moot if so and i could proceed happily without trying to make this awkward Task work. in case it is relevant, with my current access to IEM i can only create and run tasks from my Operator Site since this is the only location my company has allowed me to create content
(i have no access to the server itself).
The BES Client is running in LocalSystem context, and as such generally will not have access to network shares.
It’s possible to make it work, but exceedingly difficult. You will need all of the BES Client computers to have access to the share. This means the computers need to be in a group that have “Access this computer from the Network” right assigned (via Group Policy or Local Security Policy on the server hosting the share), as well as Share Permissions and NTFS rights to the file and path. The client will also need direct access to the network share through routing & firewall rules, as the downloads will not be distributed through the BES Server/Relay model.
A better option would be to host the file on a path accessible via HTTP/HTTPS, which can be one of your own internal servers (possibly the same server where the files are hosted now). Anonymous HTTP/HTTPS access would be needed, but you could restrict access to the IP address of the BES Server.
Perhaps you could use the Archive and Upload Manager tasks to get files hosted on the BES Server itself, but it sounds like your admin is trying pretty hard to prevent that.
thank you for the detailed reply @JasonWalker. the requirements for making it work as you describe are mostly in place, i am server admin on the machine hosting the share and had already setup (a) read & execute security permissions for an AD group that contains the computer accounts for the machines and (b) share permissions for the same group to read the folder. i just added the AD group to the allowed groups under the local server policy you mentioned and will give it another try with this change.
if it fails again after this i may be at a loss until my full access to the Console features and the Wizards is restored. i could enable IIS on the server and host the file this way but i know the BES server would be unable to reach the file server as there is no routing in place between the two server subnets and the file server is not DNS registered either. basically lack of routing is the same reason that i have lost use of the Console on my local machine. i only have access to a console on a vm (hosted on the same side of the network as BES) but am not admin on the vm so cannot enable Flash to use the Wizards. would you happen to know any way around this?
Unfortunately, no, you’ll have to have a working Flash (Internet Explorer variety) to use most of the console dashboards.
As for actually uploading the file…I dug into this a bit, and it looks to me like the Software Distribution Wizard includes a standalone uploadmanager.exe file you might be able to leverage. I found it at %USERPROFILE%\AppData\Local\BigFix\Enterprise Console<servername><operatorname>\Sites\Software Distribution\uploadmanager.exe
uploadmanager.exe /?
BigFix Package Uploader Usage
SWITCHES
-besusername <x>(optional for -wizardpackage or -uploadfileslist)
-bespassword <x>(optional for -wizardpackage or -uploadfileslist)
-hostname <x>
-inputdir <x>
-inputdirslist <some_file> (not available for wizard mode)
-dsn <x>(an alternate dsn over the default: bes_EnterpriseServer
-help (displays this)
-chunksize <x>(x = number of bytes each PostFile upload chunk will be, default = 256 * 1024)
-wizardpackage <some_file>
-sharedpackage (import as Shared packages)
-excludefolders <folder1;folder2..>
-compresslevel <x>(x = level of directory to begin compression, 0 = all levels)
-port <x>(x = alternate bes server port, default = 52311)
-fpprefix <x>(x = prefix for datastore name of file pointers, if this is not supplied default = SWD)
-dashboardid <x>(x = dashboard Id associated with datastore variables, if this is not supplied default = SoftwareDistribution.ojo)
-uploadsuffix <x>(x = suffix of files in server upload folder, if this is not supplied default will blank)
-uploadfileslist <inputfilelist.txt>(CAUTION: THIS COMMAND WILL BE DEPRECATED AFTER BES SERVER V9.1. this is for a standalone upload mode, requires a hostname. input file is a simple list of <full fil
e path + name, sha1>)
-tempdir <tempdirectory> (this is an alternate temp folder compared to using the folder this executable is located for writing out compressed temp archives)
-tempfilename <tempfilename> (whatever temp file you want for compressed file temp file)
-httpgetfilecheck (does an http get header on files, after upload if the last chunk errors server 8.0.584 only)
-utf8 (allow use of UTF-8 filenames in archive)
-vendor <x>(specify the vendor name of the upload package, not available in wizard mode)
-product <x>(specify the product name of the upload package, not available in wizard mode)
-version <x>(specify the version of the upload package, not available in wizard mode)
-log <some_file>(specify where the output log save to)
return code = 1024
That’s just my guess though, I don’t use the Wizard myself.
…and, I think I’ve found it to be much easier to just use the REST API from curl.exe or from python. I’ve tried out the curl flavor and it’s working fine for me.
When you POST the file, the output will give you the path to which it was uploaded, along with its size, sha1, and sha256 values.
Here, this executes curl with the options specified in the developer.bigfix.com example, along with “-k” to ignore checking the BES Server certificate (better to add the server certificate to ca-bundle.crt in the curl.exe directory, but this should let you start testing)
C:\Temp>curl -X POST -F "file=@c:\temp\hi.txt" --user myusername https://myserver.mydomain:52311/api/upload -k
Enter host password for user 'myusername':
<?xml version="1.0" encoding="UTF-8"?>
<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BESAPI.xsd">
<FileUpload Resource="https://myserver.mydomain:52311/api/upload/8cf2f469b3323c76735159ca3331a17f2cc59ba4/hi.txt">
<Name>/8cf2f469b3323c76735159ca3331a17f2cc59ba4/hi.txt</Name>
<URL>http://myserver.mydomain:52311/Uploads/8cf2f469b3323c76735159ca3331a17f2cc59ba4/hi.txt</URL>
<Size>5</Size>
<SHA1>8cf2f469b3323c76735159ca3331a17f2cc59ba4</SHA1>
<SHA256>004f1d2a97d7ac09d758198810e275185e51f95d9bc01143e9d70ab40fffa5b8</SHA256>
<Available>1</Available>
<ReferenceID>852806</ReferenceID>
</FileUpload>
</BESAPI>
The return values give you the URL, Size, SHA1, and SHA256 of the file you’ve uploaded. You can use that with plain-old fixlet authoring and http download urls, I don’t think there’s a need to use SWDProtocol. The following should work to download that file:
begin prefetch block
add prefetch item name=hi.txt sha1=8cf2f469b3323c76735159ca3331a17f2cc59ba4 size=5 url=http://127.0.0.1:52311/Uploads/8cf2f469b3323c76735159ca3331a17f2cc59ba4/hi.txt sha256=004f1d2a97d7ac09d758198810e275185e51f95d9bc01143e9d70ab40fffa5b8
collect prefetch items
end prefetch block
sorry i am just getting the chance to update on my status with this problem.
@JasonWalker thank you SO MUCH!! i was able to use your guide to do exactly what was needed using curl.exe and it worked like a dream it was so simple that i think i might even use it for every upload i need to make to BES server since it is even easier then using the SWD Wizard in the console. i have zero experience using REST API and would have never been able to craft a solution such as this with my knowledge set so i very much appreciate your help.
Is this an air gapped network? Does the BigFix server get downloads from the internet either directly or through a proxy or only with manual caching?
I put software installers in a dropbox public folder or on other places I can host files over HTTP / HTTPS and then use that location in the prefetch command, but that only applies for the software I can’t already download directly from the vendor, because in those cases I just use their download link.
it was so simple that i think i might even use it for every upload i need to make to BES server since it is even easier then using the SWD Wizard in the console. i have zero experience using REST API and would have never been able to craft a solution such as this with my knowledge set so i very much appreciate your help.