Would there be an easy way to delay the execution of a self service policy, if a software installation or script is being run in the background? I have an ongoing issue where a user attempts to execute a self service policy, but the policy fails because it 'could not mount a distribution point' due to the fact that another software package or script (running in the background) has already mounted the DP. Appreciate any help!
Solved
Self Service vs. Background Installations - How to manage conflicts?
+6Best answer by mm2270
The proper solution to this issue is to set up http(s) share points. It gets around this problem since it doesn't need to mount any DP as with AFP/SMB.
Besides that, there is a thread here that discusses this issue at length, with some possible workarounds posted that don't involve setting up HTTP distribution points. I'll see if I can locate it and post back with that.
+24The proper solution to this issue is to set up http(s) share points. It gets around this problem since it doesn't need to mount any DP as with AFP/SMB.
Besides that, there is a thread here that discusses this issue at length, with some possible workarounds posted that don't involve setting up HTTP distribution points. I'll see if I can locate it and post back with that.
+24OK, found it. Its not on a thread that you'd expect to find it. Take a look at /url">@clifhirtle][/url's post on this thread. See if his solution to the same issue helps you out.
[https://jamfnation.jamfsoftware.com/discussion.html?id=5404#responseChild38686
As I said though, enabling http/s on your share point(s) will resolve this without needing any complicated workarounds. So I'd encourage you to do that if at all possible. You also get resumable downloads with http, so added bonus.
+11Thanks Mike. Though I suspect the only reason my workaround of calling main policy A's manual trigger from policy B's run command "/usr/sbin/jamf policy -trigger PolicyAManualTrigger" is that Policy B's command never actually needs to mount that DP in the first place (since it is just forwarding a simple shell command)? As a SMBsharer I definitely still see those cannot mount DP errors, but more in the context of machines that have a bunch of pending policies and (for some reason) never fully dismount the DP between runs (though admittedly I have not dug into these one-offs too deep).
+6Thanks @mm2270 and @clifhirtle for the information. I have a pending request with my storage team to create/assign an HTTP compatible distribution point.... hopefully in 2014 :)
Thanks again.
+24@josaxo][/url - glad to hear that. I know getting http shares set up isn't always possible for everyone, but once you do I think overall you'll be happier. HTTP shares come with their own set of issues you may run into, but this one isn't one of them.
Truthfully, it would be nice if JAMF could find a way to make the jamf binary and other components a bit more intelligent. If the share point is already mounted, I don't get why it tries to mount it again. It should be checking to see if the share is there already with the proper read permissions and if so, use it. THAT I think would be the correct solution to this issue if you ask me. I get the feeling the whole procedure is pretty hard coded in though- 1- mount share point, 2 - copy down files, etc, with no logic to work around step 1 if its not able to mount the share because its there already.
+18...Truthfully, it would be nice if JAMF could find a way to make the jamf binary and other components a bit more intelligent. If the share point is already mounted, I don't get why it tries to mount it again...
No truer words have ever been spoken. This is killing me. I suppose I could/should turn off email notifications and I just won't know it's happening :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.