Thats's just only an idea but why don't you try to make your scripts download the zipped file from ePO instead of making ePO push them to your computers? (in fact that's not possible)
For example, DAT files downloaded from ePO usually are stored under c:\Program Files\McAfee\ePolicy Orchestrator\DB\Software\Current\VSCANDAT1000\DAT\0000 and you will find the avvdat-xxxx.zip
You can make your uvscan computers download the file from this share (I suppose it may be a samba share for Solaris/AIX)
How many machines are we talking about?
@JoeBidgood, If we get the DAT file pushed/pulled/synced to 1 machine, then all the others can grab it from that machine with our current scripts. So just 1.
Why not just create an ePO distributed repository (FTP or UNC via Samba)?
Then set the repo to just replicate the DATs to the one machine. You would get all the files like the .GEMs, .INIs and junk but the avvdat will be there for you to pick up.
As long as your scripts are flexible to recognize the changes in the DAT version ie avvdat-6610.zip, avvdat-6611.zip etc then it should work.
@Tristan: Thank you for your response and I love your icon. While that is a way to solve this problem, unfortunately it won't assist our situation as Samba is filled with security vulnerabilities and is thus disabled on our systems. But I did check with our other engineer and our scripts are flexible enough to recognize the changes in DAT version.
The reason behind our desire for ePO to be able to perform a custom job that just blindly pushes DAT-updates to a managed client is because in our network, the ePO server is the only trusted node "outside" our network.
Also, we have verified that DAT files for VSE for Linux are perfectly interswappable with uvscan, which is why we are pursuing this greatly, (so that every step of the DAT update process is automated).
Is there a way to configure the DAT files/directories on a node with UVSCAN installed such that ePO 4.5 can do a "Product Update" task to successfully update the DAT files? Is there a way to trick ePO into thinking a DAT package is a deployable package and then can be pushed to a node via a "Product Deployment" task?
I'm going to pursue creative options with the distributed repositories for now, but hopefully there is another way.
Here you go, how about this for some out of the box thinking.
I fired up Wireshark and watched a DAT update in progress and then I released an ePO pushes all files out via http.
So a simple command like wget will be able to pull the DAT file from your ePO server in your scripts
(Obviously in this example we changed the port our ePO server serves file on)
The URL path matches that of the install directory of ePO in c:\Program Files\McAfee\ePolicy Orchestrator\DB\Software
No need for ftp, Samba or repositories the clients can pull what ever files they like that are on the ePO server.
Thinking a bit further on this..
Potentially you wouldn't know what the current DAT version is and therefore the scripts wouldn't be able to pull the correct file.
This is solved by first pulling avvdat.ini or gdelta.ini from the same location if your other engineer can parse this file with a simple grep command you should then be able construct the URL for the wget command
This flat-out can't be done through ePO directly to a uvscan end-node.
uvscan isn't even network-aware, let alone ePO-aware.
You can (as suggested) copy dat files from an ePO-managed repository though.
You would need the avvdat-xxxx.zip, as uvscan is not aware of incremental dat files either.
Then it's a matter of unzipping and replacing current dat locally.