Documentation

Other

Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Facilitate uploads to cloud distribution point via API or other non-manual method

Version 9 of the Casper Suite/Jamf Pro Suite allowed tools like JSSImporter to upload packages directly to a cloud distribution point. This has stopped working in Jamf Pro 10. If cloud is the way of the future, cloud needs to be scalable, and also needs to have some way to automate package uploads and replication. Please provide and document a way to upload packages programmatically, via some kind of API or fileupload endpoint or whatever, so that we can continue to leverage cloud distribution points with Jamf Pro 10 and not have to manually upload packages via the webapp or Jamf Admin.

I would imagine that once some kind of upload methodology is established (via API or otherwise) that it could be used in conjunction with ODST as well.

Or better still, as Shea Craig stated in the Slack #jss-importer channel:

That would be the ideal situation: one endpoint that handles all configured distribution points, of any type, would be amazing. It puts the engineering muscle of JAMF behind it rather than one person trying to keep up with all of the changes.

100% agree with this! I'm working with a customer on Jamf's cloud instance, using a cloud DP and a local DP shared off a Mac. The replication piece has been a nightmare. Not only the need to manually upload, then manually do replication, but the fact that the replication process basically doesn't work, at least not since they were auto upgraded to Jamf Pro 10. The replication looks like it's working, but the pkgs that get pulled over from cloud to local are basically broken. When trying to use them with imaging or policies they don't install because they are busted. This has caused us to need to manually copy the pkgs into the Mac share. Then they can be used from that share without issue. But what a PITA! This needs to be easier. It's long overdue that Jamf provides a better/easier way to use cloud and local distribution points that can all stay in sync. Or just easier ways to get the files up into the cloud DPs as mentioned above.

I will up-vote because I want APIs exposed for all of this, including Patch. I would prefer the ability to use whatever tools we deem the best fit for our work and then integrate those tools into the Jamf Pro Server (I almost typed JSS!) and integrate and automate them with code. This FR sounds like it would be the start of this.

I would like to manage the applications though. Somewhat a catalog style where I can create objects that house meta data for packages, and then move those objects in and out of scope to devices. Maintain multiple versions, have an easy way to roll back a package if a critical issue is found, and be able to control 100% of it through code. I would prefer to not ever log into a UI if I don't have to.

Would love to see the ability to do this regardless of cloud VS. local. We have several automated workflows we use for building software from source that end with a scripted file copy to a DP. Pretty ridiculous for a company that is "API first"... package upload is a major function of the product.

It's been said that Brandon Gil, who committed to change this to "Planned", has left Jamf. I'm sure we would all like some reassurance that an API endpoint for uploading packages is still planned. We personally would never migrate to the cloud without it, as automation is essential. I would go as far to say as we would probably use Munki instead, if this commitment was abandoned.

If this is still in the works will it only apply to the JCDS or to any Cloud Distribution Point? Those of use who either use JamfCloud but can't stand the speed/reliability of the JCDS or who run on-prem wouldn't be able to take advantage of this functionality if it's limited to the JCDS.

Can't vote this up enough! Not sure when it is "planned" for tho? The need here is great as JSS-Importer is not able to function without some real api. Seems like there have been serval releases since Aug 2018 but still no movement on this "planned" feature...

FWIW, the method mentioned in this thread (the one marked as the answer) works for me. In fact, using the method discussed, I have put a script around it that can use parameters for the API credentials and even adjust the pkg category afterwards to a label you pass to a parameter. I'm also converting it to an interactive script you can run in Terminal.

I've already tested this against our JCDS distribution point several times, and it has worked for me each time. I'm not sure if there are any limitations to it, such as file sizes, beyond what might already exist for a JCDS dist point, but so far I haven't run into any.

Still, the method outlined in that thread is more complex than just using a simple resource URI like so many of the other items, so it would be nice if Jamf came up with something more "official".

@mm2270 I also saw that thread with a way to upload via the API. I was looking at creating our own utility possibly with Pashua to create an upload wizard of sorts for our support engineers to use when promoting new packages where it would upload the selected file to both the cloud and on-prem distribution points at the same time. That's when I thought I would check the feature requests to see if it was already planned or implemented. I too would love something more "official". :)

@FritzsCorner Yes, I hear you. In fact, I'm glad this is bubbling up to the top again. @Jamf, @brandon.gil, any updates on this? I don't know exactly when this moved to Planned, but it had to be at least around the end of January of this year based on @emily's post from 1/30/19, but in reality was probably earlier than that.We're now about at the end of March, and haven't seen anything yet. Per Jamf's previous guides on this, usually when something is moved to the Planned stage, a release is imminent that includes the change/feature, so I'm wondering myself where this actually stands.