@michaeloswell Unfortunately did not work for me. Only thing that has worked so far has been to remove the jamf framework and then enroll the device.

I had this issue show up today and the only resolution I found was mentioned here before, removing the Jamf Framework and then re-enrolling the machine :)

Check out the contents of /Library/LaunchDaemons/com.jamf.management.daemon.plist

MachServices should look like this:

    MachServices =     {
        "com.jamf.management.daemon.aad" = 1;
        "com.jamf.management.daemon.binary" = 1;
        "com.jamf.management.daemon.selfservice" = 1;
        "com.jamf.management.daemon.service" = 1;
    };

If it doesn't, unload the launchdaemon, (sudo launchctl unload /Library/LaunchDaemons/com.jamf.management.daemon.plist) and modify it so it looks like that (likely issue is that com.jamf.management.daemon.binary is missing and com.jamf.management.daemon.agent is in its place). Next load the LaunchDaemon again (sudo launchctl load /Library/LaunchDaemons/com.jamf.management.daemon.plist) and Self Service should work.

@colonelpanic I took a look at the affected Mac and here's what MachServices in com.jamf.management.daemon.plist looks like

    <key>MachServices</key>
        <dict>
                <key>com.jamf.management.daemon.aad</key>
                <true/>
                <key>com.jamf.management.daemon.selfsevice</key>
                <true/>
                <key>com.jamf.management.daemon.agent</key>
                <true/>
                <key>com.jamf.management.daemon.binary</key>
                <true/>

I changed "agent" to "service" since that's what's different, but it has the same results.

Jamf 10.11.1 with a MacOS 10.14.6 that is experiencing the error when trying anything in Self Service:

Binary Request: triggerPolicy [2019-08-15 09:43:45] Error triggering policy id:437 error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.jamf.management.daemon.selfservice was invalidated from this process.}

Here is part of the com.jamf.management.daemon.plist from a Mac has a working Self Service:

<key>MachServices</key>
    <dict>
        <key>com.jamf.management.daemon.aad</key>
        <true/>
        <key>com.jamf.management.daemon.selfservice</key>
        <true/>
        <key>com.jamf.management.daemon.agent</key>
        <true/>
        <key>com.jamf.management.daemon.binary</key>
        <true/>
        <key>com.jamf.management.daemon.service</key>
        <true/>
    </dict>

Here is part of the plist from a non-working Self service

<key>MachServices</key>
    <dict>
        <key>com.jamf.management.daemon.aad</key>
        <true/>
        <key>com.jamf.management.daemon.selfservice</key>
        <true/>
        <key>com.jamf.management.daemon.agent</key>
        <true/>
        <key>com.jamf.management.daemon.binary</key>
        <true/>
    </dict>

Seems odd that it is missing the key for the .service? It only has four out of the five keys that appear on a device that has properly functioning Self Service app.

On the problem device, I re-enrolled it and now it has all five keys in the .plist. Self Service functions now. (I should have simply tried to add that missing key for the .service daemon.)

I recall that if you delete some select .plist related to Jamf and then run the

sudo jamf manage

command, it will download fresh copies of some of the .plist. Next time I witness this issue, I might test that as a method

For what it's worth, our Anti-Virus was blocking the jamfaudit process after an upgrade to Jamf Pro 10.15.0:

/Library/Application Support/JAMF/Jamf.app/Contents/Frameworks/JamfAudit.framework/Versions/A/JamfAudit

Whitelisting this process fixed the problem, policies are now executing correctly via Self Service.

I ran into this issue today with our self service printers. We really have nothing in these policies except for a printer mapping, and a Complete Message set in User Interaction. I noticed that the printer was successfully installing, but just not reporting back or finishing the policy in the Jamf.log. When I disable the User interaction message in the policy, the stuck executing problem is gone entirely, and printers install in seconds. When I add some text back to it, I'm stuck back in executing. I don't mind removing the User Interaction messages from all my policies, but I'd rather not if possible. Clients are on 10.14.6 and JSS is 10.13.

I discovered that the problem manifested itself right after upgrading to 10.13.0... I am glad to report that upgrading to 10.16.0 fixed it for affected Macs.

We seem to be running into this issue campus wide again since our Jamf Cloud was upgraded to 10.16.1. We are going to whitelist these paths and see if that resolves it.

/Library/Application Support/JAMF

/usr/local/jamf

/Library/Application Support/JAMF/Jamf.app/Contents/Frameworks/JamfAudit.framework/Versions/A/JamfAudit
^We already has this one whitelisted.

Thanks for for feedback, @jared_f . I am in the midst of upgrading my TEST and DEV environments with 10.16.1, but havent really seen the issue (at least as much) in 10.15.1... Can others out there confirm whether they are seeing it in 10.16.1 as well along with @jared_f ? I'd dread to bring that issue back up in our Production environment...

I was having this issue on one today and was able to resolve it with the following:
Unload the plist via (sudo launchctl unload /Library/LaunchDaemons/com.jamf.management.daemon.plist)
Move the plist to the trash
Run (sudo jamf manage) to reinstall the plist

I didn't notice any difference in the plists. They were both missing the service key.

Edit: We are on 10.13.1 running 10.14.5-6

We ran into this campus wide. One of our anti-viruses (Cylance) was picking up Jamf Audit as a threat and quarantined it which broke anything Self Service related. Once our security person whitelisted it, all Self Service policies were able to execute.

For my case, following the note; sudo jamf -removeFramework > restart machine > enroll machine. I was then able to successfully run policies from self service that had previously been hung up at the execution stage.

Thanks Truex,

removing framework, restarting, and re-enrolling instantly fixed the issue of self-service policies hanging on the execution stage on a Mac I just setup.

What worked for me was deleting the plist from @jhalvorson comment and running 'sudo jamf manage'. It redownloaded the plist and Self Service started working.

This was a terrific thread, and I wanted to contribute a solution to my specific problem. It seems that somehow i ran a sudo launchctl unload -w /Library/LaunchDaemons/com.jamf.management.daemon.plist in that past. That set the system in a state where the plist would not be loaded. Even when removing that plist and running sudo jamf manage, the plist would be restored but the service disable state would be maintained. Also same if jamf framework would be removed and then reinstalled. The fix was simply sudo launchctl load -w /Library/LaunchDaemons/com.jamf.management.daemon.plist. Now all is well.