LDAP scoped policy won't start via Self Service or jamf policy -event customtrigger. Only starts by using jamf policy -id #####

[bradtchapman]

I have a problem with Self Service policies scoped to all computers, but limited to certain LDAP groups / users, with no other triggers except the Custom trigger. Self Service is enabled for these policies.

When I initiate a policy via Self Service, the little window displays "Gathering Information..." for a few seconds, then the progress bar rapidly fills up and the message disappears. The policy says it "Succeeded," but nothing actually happened. In /var/log/jamf.log, it says "Checking for policy ID 12345..." and nothing else.

So I start debugging on the command line:

If I run jamf policy -event awesomeapp then it says "No policies were found for the "awesomeapp" trigger." (Update: thank you @PeterClarke for the correction. This is my mistake.)

If I run jamf policy -trigger awesomeapp then the policy runs and completes as expected.

If I run jamf policy -id 12345 then the policy runs and completes as expected.

wtf...?

Configuration Summary:
- JSS 9.81
- One computer has 10.10.5, the other has 10.11.3
- Both Macs are bound to AD
- Both Macs have AD users logged in
- Self Service is set to "No Login."
- Policies scoped to LDAP user / group appear as expected in Self Service.
- Self Service displays the username set in "User & Location" in the JSS Computer record.
- Actual logged in Mac user makes no difference; Self Service still displays the "assigned" username.

So far I have tried / verified:
- removing the JAMF Framework and re-enrolling the machines;
- Unbinding and rebinding the Macs with AD;
- Rebooting the Macs;
- Resetting the policy scope to computer-based (it works);
- The casper service account in AD is valid and not locked;
- The local management account is valid and has the right password;

What could I be missing? Any other suggestions of things to try?

[PeterClarke]

Yes, jamf policy -event awesomeapp

awesomeapp is NOT an event..

an event is something like: login, logout, startup, network change..

What you want is: jam policy -trigger awesomeapp

You CAN specify it as a "custom trigger"
but it's not a "custom event"..

An event is where "something" in the system happens..

A trigger is where you cause something to happen

Sometimes the two can be very similar, such as with 'login', where its both a trigger and an event
- but that's not always the case.
- Least that's my current understanding.

By specifying: jamf policy -id 12345 you were specifying a specific trigger
( the index value of the trigger, in your DB, rather then the name of the trigger)

Generally it's more transparent to use the name of the trigger, rather then it's index value.

So just change 'event' to 'trigger'

[bradtchapman]

@PeterClarke, thank you for clarifying the incorrect syntax. I tested that and it works now.

However, I think the bigger point was missed: the policy does not run when kicked off in Self Service.

[cvgs]

According to "jamf help policy", "trigger" is a historical synonym for "event"; so that should make no difference.

But does your Self Service policy do anything? It sounds like you want to trigger a policy from within Self Service; for that to work, you would need two policies:

1. Policy with custom event "awesomeapp" and execution frequency "Ongoing" (or "Once per computer"), scoped to e.g. "All Managed Clients", and installing the software you would like to have installed
2. Self Service Policy scoped to the desired user group with execution frequency "Ongoing". This policy just uses "Execute Command" "jamf policy -event awesomeapp" in the "Configure Files & Processes" section.

Just guesswork, of course.

Cheers
Christoph

[bradtchapman]

@cvgs, it would appear that -event and -trigger are no longer historically synonymous.

When I run jamf policy -event awesomeapp, nothing happens.

When I run jamf policy -trigger awesomeapp, it works.

When I run jamf policy -id 12345, it works.

See attached screenshot. It is intentional that this policy only has a script.

Why would I need to have a second policy?

[cvgs]

Hi Brad,

i didn't realize the trigger was just used for debugging - i thought you tried to execute policies chained together by triggers. In your case there is indeed no need for more than one policy.

Something strange seems to happen here - you could have a look at ~/Library/Logs/JAMF/JAMFApplications.log to see if there is some hint at what's going on.

Cheers
Christoph

[bradtchapman]

Could you take a look at my latest comment in this thread? Please tell me if I'm missing something, or if this is normal behavior for Self Service in our current configuration.

https://jamfnation.jamfsoftware.com/discussion.html?id=12516#responseChild113154

[PeterClarke]

Hi, sorry I missed the bit about SelfService..

When I've seen this before:

SelfService, progress bar runs through, says succeeded - but 'nothing has happened'

It's been because the SelfService Policy DID download a package - but then did nothing..
In Casper 8, you could say download cached, then install cached.

Your running Casper 9.81.. You can still download cached..
But then you need ANOTHER policy to 'install cached'

Alternately, your SelfService policy, can instead do an 'install' - which will download and install.
My first guess would be that your SelfService policy is simply doing 'cache'

If not that - then something else is going on / going wrong..
- such as a faulty installer

[bradtchapman]

The policies never get to the stage "Mounting Distribution Point..." so they don't talk to a DP, don't download any packages, etc...

This will happen with any policy, regardless of its contents. For example, I have a policy that has just one script, and it doesn't work when scoped to LDAP groups/users.

[James_tolley]

Did you find a solution to this? 

I found that the issue only occurred when the user wasn't prompted to sign into Self Service. When they did, it passed through the LDAP group membership and worked.