I have recently created a new policy that is intended to run with the frequency of "once per user per computer". This is my first time i have used this type of policy in production.
This policy acts as a simple 'on-boarding' policy for new users (it displays a 'welcome to your new Mac' message, sets the user's wallpaper to our company logo, and puts specific apps in the user's Dock, etc).
However, this policy's frequency appears to be very inconsistent, and I am seeing it run more than one time per user when it should not be doing this. Sometimes it runs weeks or even months after the policy has already executed the first time.
Are "Once per user per computer" policies not reliable? Have you experienced this issue before?
I've never personally changed the default value on this since policy logs are typically lightweight and necessary. Apparently at my current environment we have it set to 3 months.
The other way around this is to simply unscope the machines after they run that policy. If are scoping with smart groups, you could use logic in those groups to change membership automatically.
@sdamiano Currently, the policy is scoped to All Macs and triggered only at login. Set to run once per user per computer.
I have considered getting 'creative' with a policy scope, but it may be tricky. Some of our Macs are communal and thus a new user may log into it at any time. So, if I unscope the Mac after a certain event or date, any subsequent users will not get their home environment set up as intended (wallpaper, Dock, etc).
Also, we have a lot of interns and students who may use a dept Mac for a few months and then another user will use it for a while. And we have rotational students that move around from dept-to-dept at times (and our Macs do not always get wiped and re-deployed "clean" after a user moves on. IT may not even KNOW that a new user is the new temp owner).
I'm trying to brainstorm a way to keep this policy running without accidentally running again when the policy log is flushed. The only thing I can think of is to simply not flush policy logs at all - which may come with its own implications.
I may open a support case and confirm the consequences to the JSS database if I never flush policy logs.