problem with login policy

I'm still having issues with this.

I've even flushed the policy -- and at some point every computer did re-run the login script/policy. However, they do not run at EVERY login, like they used to.

any ideas?

@Krytos I'm experiencing very similar issues. I need to login a second or third time for the policies to finally run.

Have you found a fix for this? What OS? What JSS version are you running?

Thanks,
Ronnie

By any chance are you using filevault?

I was about to come here to post that it appears that my filevault encrypted computers will not run login policies from a cold boot, but will only run them if you login/logout/login.

If it isn't filevault, then why are the login policies getting skipped on cold boot?

OSX 10.10.5, JSS 9.82

@Krytos Are there any errors in your jamf.log?

I'm working with support for something that sounds similar. In my case I have errors in the jamf.log (web certificate not trusted) and a corresponding error in the system.log.

@Brad_G

Thats the exact same problem I had. This really seems like a problem with the way login scripts are processed in casper. In any event, we were never able to get the login scripts to work properly again.

What I ended up having to do was create a launch daemon that pointed to my login script.
heres a link to what i ended up using hope this helps: https://jamfnation.jamfsoftware.com/discussion.html?id=19325

@Brad_G @Krytos

I have spoken to JAMF support and they refered to defect PI-002269 which has been causing me issues. When I look at the jamf log I see that the loginhook runs then the login policy call to the jamf binary fails with the message "The jamf binary could not connect to the JSS because the web certificate is not trusted".

JAMF suggest that the login policies are running too early before the keychain can unlock and the web certificate can be read. It is being worked on but it isn't mentioned in the release notes as a defect. We really should be able to see all the defects somewhere because this affected a number of machines and because I wasn't monitoring for it, it slipped under the radar for a few months. It doesn't affect all machines apparently but 75% of my inventory has had the error at once time or another.

I created an extension attribute to quickly look for the error in the jamf log files and see how many had been affected.

#!/bin/sh

grep "The jamf binary could not connect to the JSS because the web certificate is not trusted" /var/log/jamf.log

if [ $? = 0 ]; then
    echo "<result>Found</result>"
else
    echo "<result>Clean</result>"
fi

Any update on this from Jamf?!?! We have been getting many reports lately from students/staff and we are thinking about turning off all of our policies that rely on Login/Logout hooks because of it's lack of reliability. We currently do our drive mapping via login scripts for our domain users. Our temporary solution has been creating a Self Service policy to allow users to map the drives if the login script failed to run. On a campus of around 150 machines, this has been happening multiple times every day. We'd hate to convert everything to launch daemons just to have the issue fixed in an upcoming JSS upgrade.

Thanks!

Do you have multiple login policies at play? If one stalls it will prevent the others running.
We have multiple drive mount scripts and I break them away to a seperate process each and it seems to work.
Something like this.

#!/bin/bash
(
SCRIPT CONTENTS
) &

The only downside is you don't get logging back to JSS for everything between the brackets.
Also specifically for drive mounts, if you using a script I found that the mount was attempting too early and I had to wait for the Finder to load before attempting (but then I am making an Applescript call to the Finder so that makes sense).