JamfHelper seems to sometimes block policy running?

CCNapier
Contributor

Hi folks.
I have an imaging configuration profile where I
1. Bring down the OS
2. Install a small PKG (contains just a background)
3. Start a script.

The PKG is there so that the adobeinstall account logs on after imaging (by the way, can we not do this without a dummy pkg??).
The script basically does a jamf policy -event customevent which will fire off a load of policies for install.

I have a machine that was doing nothing. The jamHelper screen was up and nothing happening for a very long time. My script logs showed the event was to be triggered, but the jamf.log show no event being triggered. No activity in particular was happening on the machine.

I SSH and kill jamfHelper and.... suddenly the policies are triggered, and the processes lurch into life. All now works well.

I don't get this behavior on some other machines that I image.
Any ideas as to why jamfHelper is... well, essentially blocking the progress here?

Thanks

1 ACCEPTED SOLUTION

CCNapier
Contributor

The problem was to do with the policy itself.
It had a "Start Message" set which must be presented using the jamfHelper (which I wasn't aware of). This must have been hidden behind the real Casper Imaging "splash screen" and was what I was really killing with a SSH kill command.

It was obviously waiting for user interaction before starting the policy install action.

Thanks for your input on this :)

View solution in original post

5 REPLIES 5

sepiemoini
Contributor III
Contributor III

It sounds like you may need to throw an "&" operator at the end of the jamfHelper line to ensure that the policy that is called has an opportunity to run. Otherwise it seems that it's just "stuck" on displaying the jamfHelper command. The "&" will allow your script to run a follow up command in tandem.

CCNapier
Contributor

Hmmm, I forgot that I tried to make the package run a custom jamfHelper "over the top" of the of the generic jamfHelper screen... but the postflight script in the PKG does already have the & at the end:

/Library/Application Support/JAMF/bin/jamfhelper.app/Contents/MacOS/jamfHelper -windowType fs -title "Post Imaging" -heading 'Please Wait' -description "Installing extra components. This may take some time." -icon /Library/ENU/enuback.jpg -lockHud &

(note the icon is installed with the package).

CCNapier
Contributor

So I removed the package completely and I am not calling jamfHelper at all.
the "in-built" imaging process that calls jamfHelper is now the only way jamfHelper is getting called. And it still sticks.

jamf.log says:
"Checking for policies triggered by "...." for user "adobeinstall"...
But doesn't actually start processing until I've killed the jamfHelper.

russeller
Contributor III

@CCNapier Is your policy set to "Ongoing" or "Once per computer"? It sound like if you ran the jamf policy -event name_here it would work consistently?

CCNapier
Contributor

The problem was to do with the policy itself.
It had a "Start Message" set which must be presented using the jamfHelper (which I wasn't aware of). This must have been hidden behind the real Casper Imaging "splash screen" and was what I was really killing with a SSH kill command.

It was obviously waiting for user interaction before starting the policy install action.

Thanks for your input on this :)