Distribution points with on-prem Jamf-Pro packages not associating with policies properly

[kbreed27]

I'm running an on-prem instance of Jamf Pro 11.5.1 and still testing getting packages uploaded to our File Share distribution points before jumping to the next version. When we upload packages using either Jamf Sync or Directly to the SMB share, they only install/download the package with a VERY low success rate (10 percent or so). The Policy will complete without any issue, but it won't run the package the vast majority of the time. Screenshot included showing what I am talking about.  

If we upload the package using Jamf Admin, we have 0 issues with packages associating with the policy. Is there some way to tell the jamf pro instance that the package exists, it seems like there is something that runs with jamf admin that just doesn't run with Jamf sync or when manually uploading to the smb share. 

[A_Collins]

You need share the policy to get responses. I would say first thing you can test is defining the package source. In the package payload, try specifying the distribution point. 

[kbreed27]

We have a primary node that is used for manipulating the jamf pro GUI and several children nodes behind a load balancer with the GUI disabled. I enabled the GUI and went and looked at the policy on each node and most of them showed an "Unknown" Package. 2 of the Nodes actually showed the package. Interesting, the package exists in the Settings > Packages menu.

[Gascolator]

Our on premise setup is similar. I believe the intended way to manage this moving forward, is to upload packages via Settings->Packages in the JSS GUI. If you are using multiple file share distribution points you use JAMF Sync to replicate/keep them in sync. If you do not have multiple distribution points, you don't need JAMF Sync.

We've been on premise since 2019 and not once have I uploaded anything directly to the file share distribution point, always via JAMF Admin or JSS and then replicate to our AWS distribution point with JAMF Admin. With the deprecation of JAMF Admin, the above will be our workflow. 

-Matt-

[Gascolator]

Also note that https is the preferred method of distribution for on premise file share distribution, and that is what we are using. 

-Matt-

[kbreed27]

Are you fully on-prem or hybrid? In Settings > Packages I don't have the option to upload a package. I thought this was because we are on-prem only.

In my training classes we could upload using the GUI, but  I thought that was because a Cloud DP was accessible. We don't have a cloud distribution server.

I can manually upload the package to the SMB share and specify the name of the package in Settings > Packages, but in my testing it's been just as inconsistent as using Jamf Sync to do the initial upload and DP sync. 

[Gascolator]

We are fully on premise with our JSS and file share distribution point (running on local file server) but we have an AWS bucket setup as as a cloud distribution point as well. That allows install of items from Self Service for devices off network.  The cloud distribution point is authoritative in our setup.  

The lack of a cloud distribution point is why you are missing the upload button. Your workflow is correct. I would suggest changing to HTTPS distribution instead of SMB and see if the issue clears up. 

If you want to be able to upload directly from JAMF you can spin up an AWS cloud distribution point, set it as authoritative, and then use JAMF Sync to keep them in sync. I'd sort out the local file share distribution first though. 

-Matt-

[kbreed27]

The distribution of packages to MacOS Endpoints is via HTTPS already. However it was my understanding that the Distribution points themselves sync to each other and the web nodes using SMB. 

and regarding uploading files to the On-prem DPs from my admin computer, is your suggestion not to upload to them via mounting the SMB share? IT doesn't look like there is anyway to disable SMB sharing in JP settings. Does uploading to the DP's via something like scp make a difference in how tomcat nodes process the package? It's still the same share volume right?

I doubt my org is going to go for an AWS bucket or another cloud DP, although that would be swell.  

[Gascolator]

Your understanding is correct. I did not note https in your original screenshot but now I see it. You won't need to disable SMB in the JSS settings if you have HTTPS setup and the box checked to "Use HTTPS Downloads"  under the settings for the distribution point. 

Is one of your file share distribution points selected as the principal distribution point?  If so, is that the share that you are manually uploading to? Any errors in the policy log when it fails to download?

-Matt-

[kbreed27]

1. Yes we do have a primary Distribution point that we are uploading to first. I've even tried manually uploaded to both distrbution points (without Jamf Sync) to about the same results.

2. No Errors in the Policy. It just completes and doesn't pull any package. I'm guessing it's because over half of the children nodes show an unknown package in the policy. 

[kbreed27]

Also big thank you for taking your time to chat with me and try to help me. I really appreciate it. 

[Gascolator]

I'm running out of ideas 😂. If the distribution points are working fine with JAMF Admin I think you can rule those out.  If the file was actually failing to download you'd have an error in the policy log. It's just missing the .pkg in the policy on the child nodes. Can you post a picture of your clustering settings with any private info masked?

[kbreed27]

My guess is the deprecation of Jamf Admin wasn't taken into account for instances without any Jamf Cloud services. Whatever API endpoint that was deprecated in 11.6 probably forced all of the children nodes to sync with each other... othewise... *shrug*.

I do have a jamf support ticket open, otherwise this is a pretty gnarly work around when uploading new packages. 

For what it's worth, it doesn't seem to be an issue with overwriting an existing package (upload GoogleChrome.pkg with a newer version with the same file name). 

Thanks for helping me look at this. 

[Gascolator]

Let us know what you find out with support. I'm curious what the problem is. 

-Matt-

[mschlosser]

A brief thought, like most enterprise networks, there is more then likely VLANS involved; may be a good idea to make sure the file share is accessible from all the VLANS where the client devices may live. Whether the protocol used is http or SMB. A decent way rot check this, without asking the network guy is try to connect to the share from the same network as the client devices.

At my employer; I use a cloud DP for many packages, but recently setup a local SMB share for larger packages and that works great, after getting the network guy to make the share reachable from the necessary VLANS. Hope that helps. A firewall block or incorrectly configured layer 2 or 3 switch would explain why the policy execute, but the pkg never copies

[mschlosser]

Also while jamf sync is a new tool; i'm waiting for it to get a little more mature, before trusting it completely. To get the packaging to copy to the local share. You can also cache the packages from the cloud DP and copy them to share from the local waiting room. I believe they have to go into  a <share>/Packages folder.

[TJeff]

Did you ever hear anything back from Jamf?
I'm running into the same issue on 11.5.1 in a fully on-prem clustered Jamf Pro environment. Knowing Jamf Admin would deprecated Jamf Pro 11.6, I was trying to determine a workflow for manually uploading the packages and creating an entry for the package in Settings >  Computer management > Packages before I upgraded. Like you, I found the package did not install even though the logs indicated a successful install when using this manual method. I did notice that after manually uploading the packages to the DPs, that I only had to open Jamf Admin and there would be a duplicate entry for the package in question showing up under Settings >  Computer management > Packages. I did not save anything in Jamf Admin. My guess was that the second entry was created by Jamf Admin seeing the package on the primary DP and noting it some where. I then deleted the entry I made in the Settings >  Computer management > Packages webpageSettings >  Computer management > Packages webpage and left the second entry. Now the package would install and all was well. Like you I think there is some mechanism that Jamf Admin has that notifies the primary instance of Jamf Pro. Reading the Jamf Pro documentation for version 11.5.0, it spells out this manual method of uploading a package and creating the entry. However, I must be missing something because I've not been successful yet.

[mschlosser]

this may not be possible with an on-premise setup as I have never had to deal with that, that being said for my larger packages; I've taken to uploading them to the jamf cloud once, and then using Jamf Sync to bring them down to the local lan distribution points. The policies can then be modified to use the cloud or local DPs as necessary.

[TJeff]

Thanks for your reply. Check out this part of the documentation, I could be reading this wrong.

https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-11.5.0/page/Package_Management.html#ID-00...

[mschlosser]

that was an interesting read. the only detail i noticed that may be overlooked if you were in a hurry, the packages must be in a .../Packages folder when copied to the share.

So in the form of /Volumes/<share>/Packages when mounted. Maybe double check that the packages are in a /Package subfolder.

[TJeff]

Yes, that could be confusing as the instructions say "root of the file share on the distribution point". However, that wasn't the issue in my case. They were placed in the Packages directory with all the other working packages. It started working after I opened Jamf Admin and I didn't have to move the packages anywhere. But, thanks for brainstorming. :)