Package Priorities and Policies

[mhatch14]

Are package priorities considered when multiple policies are running at once? In other words, if policy A has a package with a priority of 10 and policy B has a package with a priority of 5, will policy B run before policy A?

Thanks.

[mm2270]

Short answer: Not to my knowledge, but it may all depend on which policy gets run first, which seems a little random actually. Policies are run I believe in a sequential order, so Policy A has no clue there even is a Policy B when its called to run.

This is an area where I'd like to see the JSS be smarter on. For example, when a trigger is invoked like "every15" or "Check in" I'd love for it to pull down all available policy information for that trigger at that moment in time, then decide intelligently how to run them, perhaps based on package priorities, or to gather all inventory collections into one master one that gets run at the end of that policy trigger, rather than each and every policy doing its own wasteful inventory collection. I feel this should be possible, but it just doesn't work that way.
I realize that some additional policies may get run after the first batch is done, based on new inventory submitted, but at least for the same trigger run, I wish it could see ahead what's going to get run and make some better choices.

[bentoms]

@mhatch14, I do not think you can run multiple policies @ the same time.

Are you seeing polices being run @ the same time?

[mhatch14]

I meant multiple policies with the same trigger. Like if I have 5 policies run at "check-in", how can I ensure that some run before others, if necessary?

[bentoms]

@mhatch14, easiest way would be by scoping them via Smart Groups.

Can you give examples of the policies?

[mm2270]

Name your policies with a numbering system as the first part of the name. I think that causes them to run in the alphanumerical order, but I'm not 100% sure.
So:
"Policy B" becomes "01-Policy B"
"Policy A" becomes "02-Policy A"

Not completely certain that will work, but I would give it a try.

[mhatch14]

Yes. When we enroll a machine after putting a clean OS image on it, we want several packages to install. Maybe Photoshop, Office and some plugin for Photoshop, for example. We would want the Photoshop plugin to install after Photoshop installs. So we would want the Photoshop policy to run before the Photoshop plugin policy. It would be nice to prioritize these.

You can set a package priority in the packages area, but it doesn't seem to have an effect on the order of packages. We could rename the policies as mm2270 is suggesting but that doesn't seem like an ideal situation. Maybe policies should have priorities, too?

[mm2270]

I agree that naming policies that way isn't the most elegant solution.

So, there are some other ways you may be able to get around this.

For example. set up a script that gets run by a master policy after enrollment, that in turn calls each policy in a specific order based on policy ID or a manual trigger for each, rather than relying on the Check in trigger, which will call them in whichever order the JSS deems.

Or, if there is really only one policy that needs to run before any others, you can script it to just run that policy first, again by ID or trigger then call the "check-in" trigger to run the rest.

Lastly, if the above holds true, you could just rename that one policy with a number in front, for example, installing Photoshop, which i think will cause it to run first, even if its called by the "check-in" trigger.

This is all speculation since I'm not running version 9.x of the JSS, so I don't have any way to verify what I'm saying will work. It may not help at all, but just some ideas.

[yan1212]

This is indeed an area where the JSS can improve a lot. In my experience the order in which policies run is mostly down to alphabetical (or numerical) order. This was definitely the case in v8 and I haven't noticed anything different in v9, although I haven't tested that extensively.

@mhatch14, I have to deal with the situation you describe where you want to run a policy only after something else has happened before and the best way seems to be smart groups. For example in your case you can have a smart group, which only picks up clients that have run a specific package installed by Casper or Installer.app (e.g. Photoshop) and then have your separate Photoshop Plugin policy scoped against that group. This way you know that only computers that have had the version of Photoshop you want installed will run this policy and with zero interaction from your part. Also, what you name the Photoshop Plugin policy will be irrelevant as it will always run after the Photoshop one.

[mhatch14]

ah, that is a good idea. I'll try it that way and see how it goes. Ultimately what we're trying to do is mimic a deploy studio workflow but with Casper and policies since it seems better to do it that way in the long run. So we have a whole workflow that needs to be installed from the get-go. 5, 10, 15+ packages/policies. Order is important with so many that have dependencies on others.

[yan1212]

Yes, the JSS will definitely give you a lot more flexibility in this case.

The order is indeed important but in my experience it is better to not approach the entire process as one big sequential workflow as it becomes too difficult to execute without fail. I would treat the actions that have dependencies as separate smaller grouped tasks that you can look at (or even debug if required) separately.

In my current environment I was initially asked to manage a several hundred Macs that were already in use by staff on 1:1 basis. I was told that reimaging was not an option as most people are lecturers and researchers that are rarely in the office and to make matters worse there was never a build as such and they were all admins....so coming up with a set of dynamic JSS policies (scoped almost exclusively against Smart Groups) and using Self Service to deploy 90% of packages software was the way to go. Users enrol themselves (or support do it for them) and then the JSS pulls down and inventory repot and runs a few policies applying our security and client hardening scripts, installing self service, printers etc. Everything happens via extension attributes and smart groups. e.g. if Sophos is out of date it gets updated or if it not installed we push it down. Likewise with Office, Flash etc. If everything is up to date and as we would want it to be then the relevant policies may not have to run at all. There is very little interaction from us other than packaging, educating users on using Self Service and maintaining the JSS / JDS / Load Balancers etc. And the users see very little radical change on their Macs, which keeps them happy. So far this works well.

[scottb]

So, if you create a policy and add three apps:
Adobe PhotoShop
Java7
Microsoft Office

It will install those in that order as they are listed alphabetically. When you add multiple packages, you can't reorder them on that page. However, if you add those one at a time, it will be in the order you add them.

So I can install:
Microsoft Office
Adobe PhotoShop
Java7

Will the policy always install those packages in the order they're listed (under Policy/Packages) or will it use other criteria? I've not monitored the install order as we don't (yet) run more than one at a time, but that might work for you.

Another issue is that if a policy is already running (user doesn't have a clue as it's under the hood) and they go into Self Service to pull a package at the same time, it will likely fail and they will not know why. The logs will show a "Can't mount a distribution point" and the install fails.
Seems that this sort of failure should not happen as often as it does. Why can't the JSS see the DP mounted and wait for the current policy to finish then run the next policy(ies)?

[mhatch14]

@yam2012: You mentioned handling this issue with a smart group. I think that's a great idea but I have a question. Would your suggestion require inventory to run? Seems like it. Our inventory runs automatically once a week. If that's required to get them into the group that is scoped for the plugin, then that might be a tough option. Unless I force an inventory update at some point?

[mhatch14]

Looks like there is a way to force inventory as a policy. Luckily it runs at the end of the policy, from what I can tell. So I'll use that for now. Unless anyone else has other thoughts?

[mm2270]

Yeah, that's the way we all do it. Check the Update Inventory box in the Advanced section of a policy. It runs after any installs or scripts and other items.

[yan1212]

Yes, checking the Update inventory box under Advanced ( or Maintenance in v.9) will force the client to submit an inventory update at the end.