Login/logout policy not applying

[Krytos]

I've got a lab with 20 computers in it and configured login and logout script policies. They are ongoing policies triggered by login or logout respectively.

They've been working great the last month. However, as of 2 days ago, a seemingly random half of the computers stopped getting the policy. the other half work fine.

The ones that are having problems also havent checked-in in 2 days. -- I dont know why.

Are there any troubleshooting tips I can use to try and fix this issue?

[cdev · Accepted solution]

What happens when you run either of:

sudo jamf policy
sudo jamf recon

I'd be curious to see the output. Generally, I suspect a network issue, but on multiple machines simultaneously, it's a little harder to say.

[cdev · Accepted solution]

What happens when you run either of:

sudo jamf policy
sudo jamf recon

I'd be curious to see the output. Generally, I suspect a network issue, but on multiple machines simultaneously, it's a little harder to say.

[farverk · Accepted solution]

I also had this issue and I ran:

sudo jamf manage

Which "Enforces Login/Logout hooks..." The machine ran the logout script once that was done.

Could you also run these commands and post the results. This is checking what is set for the Login/Logout Hooks:

sudo defaults read com.apple.loginwindow LoginHook
sudo defaults read com.apple.loginwindow LogoutHook

[Krytos]

@cdev

That policy and recon seem to have forced the computer to check in. I'll keep monitoring it to see if that clears it up.

[Krytos]

@cdev

also, our casper admin updated the server that day as well. Why wouldnt some clients reconnect to casper? Is this typical when an update is performed?

Should i keep an eye out for this stuff in the future?

The weird thing is that both the login and logout scripts are set to cache and run even when casper is offline...but they werent till i ran your commands.

[millersc]

@Krytos what version did the JSS get updated to? There have been some reports of client failure after upgrades.

[cdev]

Post JSS upgrade, there is always the chance that some clients may not reconnect (extremely rare in my experience). Upon first reconnect, they should notice the jamf binary version mismatch with the JSS and automatically perform the upgrade to keep working. As for the two commands, policy checks for any available commands awaiting that workstation, whereas the recon does a full inventory and should check for policies as well.

[bentoms]

@Krytos was this after the 9.8 update?

[Krytos]

@bentoms

yes, 9.8

[bentoms]

@Krytos Can you try a

sudo jamf manage

on an affected client to see if it resolves?

Else, maybe this?

[Krytos]

@bentoms yes, some combination of jamf manage/policy/recon fixed the issue.

Luckily we don't have a large environment yet -- or else putting hands on every computer that wasn't checking in would have been a big, big pain.

however, as of right now, everything is working fine.

Edit -- just marked it as solved, sorry if I caused confusion by not doing it sooner.

[hinrichd]

What should be the correct results of:

sudo defaults read com.apple.loginwindow LoginHook ; or
sudo defaults read com.apple.loginwindow LogoutHook

if login/logout hooks are managed by Casper Suite?

[Krytos]

@hinrichd

it will show something about jamf/caspersuite/login.sh and logout.sh

Sorry I'm not near a computer to actually look it up, but it will be fairly obvious. If you want them, and you dont have them. There are some management settings that you turn on casper loginhooks.