Login triggered policies

sinergi
New Contributor III

ello,

I'm looking for more information regarding the login trigger of a policy, basically I have created four global policies to run at login, once per user.

After testing this, it appears that only one policy will have run rather than all four... If I was to logout and then log back in it fires off another single login policy. As you can imagine I don't particularly want the user having to login and logout multiple times to make sure the computer is setup correctly. Can you tell me if this is expected behaviour?

Is there another way/best practise way of setting up users configurations? For example, I have a policies that creates an Application folder in the users homes, enables certain system preferences padlocks, configures dockutil and disables AD timeout.

Thanks

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

That's basically it.
Just one thing I'll mention is that hopefully you're working with http enabled Casper sharepoint(s) since I believe there is an issue if you try to run multiple policies from a script with AFP/SMB share point(s) Specifically, since the share is mounted to run the script, when it attempts to run the actual policies being called in the script, it will have trouble since it'll try to mount the share again and will fail.
The problem shouldn't happen when using http/s on the distribution point.

The other thing is, you can make this script kind of modular in that instead of hard coding the manual triggers or policy IDs, you can pass them to the script as parameters, so $4, $5, $6 etc can be entered as the policy IDs/triggers that get passed to it. That way you can use the same script for different login policies if need be, Make sense?

View solution in original post

7 REPLIES 7

mm2270
Legendary Contributor III

That doesn't sound normal to me personally. Although I'm not a good candidate to confirm or deny the behavior since a) we don't use any login policies here and b) we are still on version 8.73 in production.
That said, I think the login hook scripts that the jamf framework installs should be seeing whatever policies are triggered by "login" and running them, all. It doesn't make any logical sense that it would only run one each per login. The only thing I can think of is that the behavior when using a once per user setting is a little weird. See this feature request for what I mean.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=45

But I'd say this is likely a bug or not expected behavior. You might want to check in with your account manager to get their thoughts, or file a bug if this isn't the way it should be working.

As for a workaround, you could do something like craft a simple script that would call each policy one by one by their policy IDs or a manual trigger. Then in your login policy just run that script instead. That should then cycle through all the policies that the script is calling.

sinergi
New Contributor III

Thanks @mm2270

I plan to try the workaround you mentioned, can I just clarify that I am doing this correctly?
- Create a script with multiple (jamf policy -trigger customTriggers), upload this script to casper admin and attach it to a policy to run at (login) execution frequency (per user)
- Once this script runs, it should essentially trigger the customTriggers container with the script?

Thanks a lot.

mm2270
Legendary Contributor III

That's basically it.
Just one thing I'll mention is that hopefully you're working with http enabled Casper sharepoint(s) since I believe there is an issue if you try to run multiple policies from a script with AFP/SMB share point(s) Specifically, since the share is mounted to run the script, when it attempts to run the actual policies being called in the script, it will have trouble since it'll try to mount the share again and will fail.
The problem shouldn't happen when using http/s on the distribution point.

The other thing is, you can make this script kind of modular in that instead of hard coding the manual triggers or policy IDs, you can pass them to the script as parameters, so $4, $5, $6 etc can be entered as the policy IDs/triggers that get passed to it. That way you can use the same script for different login policies if need be, Make sense?

sinergi
New Contributor III

It does and makes perfect sense, Ill need to play around with the scripts again as they work if I run them on the client manually but not quite working the above way.

You mentioned HTTP File share, we do have one setup as well as an internal SMB File share. However, I noticed that you cannot specify which File share the script runs from like you can do with packages. If you have HTTP enabled, does it automatically pull it down?

Thanks again.

alexjdale
Valued Contributor III

Just a note, we have file share distribution points and have no issues running a new trigger policy while the share is already mounted by another policy, so having a policy script invoke additional policies should not be an issue.

It's true that this did not work in 8, though.

sinergi
New Contributor III

@mm2270 sorry to trouble you with another off topic question but I'm trying your above method by using an attached script to run a policy which is then triggering the below script, however it's creating the Applications folder in the root's directory rather than the current logged in user. Any ideas how I can improve this so that I can reuse in future?

For example, I am try to create a folder in the users Application folder;

#Find current user
U=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
echo $U" is the current user"
#Create directory
mkdir /Users/$U/Applications

Thanks in advance

sinergi
New Contributor III

Scrap that crappy script above!

mkdir /Users/$3/Applications

Did that trick