We have upgraded our on prem Jamf from 10.42.1 to 10.47.0
On testing policies all download as they should to devices but when using self service suddenly the machines cannot mount the smb distribution point.
We have also enabled HSTS as per the upgrade docs and incrementally upgraded to 10.46.1 first before 10.46.0
This was all working fine in 10.42.1 and now not working on 10.47.0
Has anyone else had this issue?
@N2KHL We're no longer on-prem, and don't use SMB for DP connectivity, so I can't confirm the behavior you describe in 10.47.0, but as a possible workaround do you have the option to enable HTTPS for your DP? You'll find that HTTPS provides a much more robust performance than SMB for a DP (e.g. faster downloads because the Mac doesn't have to mount the DP file system to initiate a download, and resumable downloads)
Not at 10.47.0 yet for another week. However, here's the way I would test.
1) Can you mount the smb share from the machine with the same credentials that jamf uses?
2) If you can't, can you mount the share with other credentials?
3) If the answer is no for both, then is there a firewall in the way? Maybe it's had a config change.
4) Can you mount the share from anywhere? If not, then maybe the share is the issue.
5) On the machine you can look at the jamf log in /var/log/jamf.log during or after the policy run. I see more info there than on the server in the policy log. I feel like I had a lot of failover to cloud DP last week but that's because of a firewall issue.
6) If there's nothing of use in Jamf Nation ... put a ticket in and tell them what you tested and what you see
Yeah we have the same issue on our on-prem server since upgrading to 10.47, installs work fine when the policy is triggered manually via the terminal, but not via the Self Service app, just flat out refuses to mount the on site DP's. Tried re-installing Self Service, giving Self Service full disk access via system settings and even attempted to re-enroll our test mac, but still no luck. Other scripts work fine though, its literally just when its attempting to mount the SMB DP's.
I just finished setting up HTTPS with the guide below. JamfSelfService worked like charm right after setting our firewall up to allow tcp443.
JamfAdmin still seems to work fine using SMB.
Good luck getting yours fixed soon!
Just a heads up everyone, just notice this is also affecting the Patch Management system, just gone to push out this weeks Outlook update and it has comeback with the same error, unable to mount DP. Manual policies via terminal and recurring check-in are working fine though.
Same problem here, updated to 10.47 from 10.46.1... also upgraded mysql from 8.0.30 to 8.0.33. So sad this wont be fixed until 10.49 !!!! Any expereince with AFP shares in conjunction with this bug?
@def (and anyone else who hasn't switched to https delivery for on-prem DPs) You really should take a look at enabling https for your DPs. It will improve the speed of installs because there is no longer a need to mount the file system of the DP to begin downloading an installer, and for larger installers the resumable download capability will help insure that installs successfully complete on the first try.
I use a share drive on our local SAN that uses SMB. This completely broke self service for me, as any on prem devices will prefer to use it instead of the Cloud Distribution point.
I would like to avoid spinning up a server for this...
Then you most definitely should enable https on your local DP because it will support resumable downloads if there's a hiccup on that 40GB package download. And what in the blazes is in that package?
Not that I have a clue why you would want to install the entire CC suite at once, but is there any possibility you could go with a more modular approach instead of a monolithic install? For CC deployments for my org we just install CC Desktop and allow users to install the tools they're licensed for as needed. (yes, I do consider myself lucky on that)
Because, these machines are used in Labs, Can't have a class of students trying to download the apps they need to use the Suite. Just doesn't make sense for that.
I do have self service packages with Adobe CCDA for our Employees and remote students, but on campus ones are more generally used.
Yeah, I got an emergency change in place, got the server created, created the HTTPS share, however the Distribution page within Jamf Pro is broken and I can't save a new distribution or edit an existing one. Anyone else have this issue?
Are you using SSO for access to your Jamf Pro console? I believe there was a post indicating problems accessing the DP configuration page when using SSO. I'm not sure if there's an "in case of emergency" mechanism to access your JSS console and bypass SSO (we're not using it) but if there is try that to access the DP configuration page.
@dcappelle Out of curiosity if you set up a policy to install Adobe CC that's triggered only by a Custom Event, and then have a Self Service policy that triggers that install policy by doing a "jamf policy -event CustomEventName" via a Files & Processes payload does that work?
If that doesn't work you could have your Self Service policy create a hidden flag file on a Mac, use an Extension Attribute to put Macs with that hidden file into a Smart Group, and then use that Smart Group as the scope of a policy to install Adobe CC on checkin. That _should_ work around the problem of Self Service installs not working although the actual install start will be deferred until the Mac does it's next checkin.
FYI this is PI111961 "Jamf Self Service fails to install packages over SMB."
Another workaround as this doesn't affect using the jamf binary to call policies is to give your policy a custom trigger then create a second policy with a one liner "Execute Command" in files and processes payload of "jamf policy -event YOURTRIGGERWORD" and that will then execute. I appreciate for large amounts of policies thats not ideal, but for jamfcloud i would suggest use cloudDP for the bulk and then just use the above workaround for the ones > 20GB
Hope this helps someone
This is a seperate issue confirmed by JAMF. We are waiting for it to be fixed.
PI111439 If single sign-on is enabled in Jamf Pro, the File share distribution points setting is incorrectly inaccessible. Workaround: Temporarily disable single sign-on to access the file share distribution points setting.
Just upgraded my dev enviroment (im glade I have been holding off) and SMB shares are broke, i went to delete it. It wouldnt let me. I did an API command to delete it. And now whenever i try to add the SMB/HTTP share, it just spins and spins and spins..
It's a little disappointing to still see issues still and it not being fixed... Is this an attempt to convert some of us over to Jamf Cloud? Com'on Jamf, lets get this solved.