Two machines, one user

[sinergi]

Hiya,

How do you guys tackle a scenario where you have all your machines bound to AD, you keep all the 'User & Location' fields up to date, a user has two machines (desktop & laptop) and you have a policy that runs 'Once per user'?

For example, we have a policy that runs once per user which manually triggers a list of preference scripts for when we setup a new machine. However, if this user exists in the JSS it already accepts the fact it has run on their other device when we set it up.

The same would likely apply if I changed it to 'Once per week' as it would be like tossing a coin as to what machine the policy will run on once a week.

The last option it to set it to on-going but that defeats the purpose. Any ideas on this would be great!

Ta

[mm2270 · Accepted solution]

This is a little tricky, because as you noted, once per user is truly once per user. See this FR and vote it up if you have not already
https://jamfnation.jamfsoftware.com/featureRequest.html?id=45

You may need to script something to do your deployment. For example, deploy the package or settings into a tmp location, then have an After or postinstall script that checks to see if the users on the Mac have had the specific settings or package applied, and if not, deploy into place.

In your case since the settings are being scripted anyway, just expand your script to first check to see if the user account has had the settings applied and if not, set everything up. Then you can set up the policy to run as once per computer instead and not be limited by user logins.
Not sure if that helps or not.

[sinergi]

@mm2270

Thanks mate, really great advice and either option is much more flexible than what I have at present. I shall trial both to see which I prefer but option 2 sounds the quickest!

Si

[sinergi]

@mm2270

Just to pick your strategy brain a little bit further, I had a little think on the drive home and can't see either of these working on our environment. Ideally we want the settings from the policy (scripts) to run once the user logs in.

Our environment is not quite automated to do this; we enrol a machine into the JSS, an I.T. tech logs into the JSS and adds the machine into a static group, the I.T. tech logs into the Mac with a hidden admin account and runs a script (essentially, sudo jamf policy).

In both scenarios, once the machine has been enrolled and if the I.T. tech logs into the machine then the scripts will run for the hidden admin and not again for the next logged in user.

Should I just look at applying these settings as a package set as FUT in future?

[mm2270]

Is the administrator account the tech logs in with to configure the Mac consistent? Something part of your image?
Do you have any hidden files you drop on a configured system to identify it as a Mac that has been fully setup and is ready for the user to log in? Or a specific package receipt you can look for that wouldn't be installed on the Mac until after the tech is done with it?
Also, can you elaborate on why you add the Macs into a Static Group? I'm thinking there are going to be ways to automate what you're doing for the setup a bit more than you may be doing currently.

[sinergi]

@mm2270 I'll try give you an overview and provide you with as much information but let me know if I've not made anything clear.

Our techs use DeployStudio to setup a new machine out of the box, our workflow is simple; skip user setup, set computer name, add hidden admin and enrol machine to JSS. This is consistent for all new machines.

The tech would then login to the JSS, fill in the 'User & Location' field and then add the machine to a static group named 'Enrolled - Staff' or 'Enrolled - Student'. //depending on the group depends on what settings and apps are configured.

The tech would then login and run a script that would run 'jamf policy -verbose' to start pulling down core software/plugins. We would then leave the device for collection at a helpdesk.

Once the user logs in it would do some user configuration.
---

The reason we add machines into a static group was down to us being naive when we first got Casper. We had a few IT departments across the University all running their own Mac support which eventually got merged together to standardise the process to prevent duplication.

Our plan was to get as much machine into the JSS for inventory purposes as quick as possible, we had a thousand machines scattered across the campus, some had custom configurations and others were comfortably running munki. We enrolled all machines but made the decision to only provide Self Service.app to new or re-imaged machines. This also had a cross over with moving to a new AD as all other machines were bound to a different AD and storage.

So, we enrolled as many machines as we could get our hands onto into Casper but nothing gets pushed to these machines unless they are in the 'Enrolled' group.

I hope that makes sense, nothing to technical.