Skip to main content
Solved

Policy not respecting Priority - Solution?

  • March 15, 2013
  • 4 replies
  • 29 views
T
Forum|alt.badge.img+10

Hey, guys:

I have a policy that I want to install Office 2011 14.2.3 and then apply the 14.3.2 update, but it always installs the 14.3.2 first (and fails, obviously) before installing the suite (which succeeds):

Installing EN Microsoft Office 2011 14.3.2 Update.pkg... Installation failed. The installer reported: installer: Cannot install on volume / because it is disabled.
installer: A version of the software required to install this update was not found on this volume. Installing EN Microsoft Office 2011.dmg... Closing package... [STEP 4 of 4] Running Recon...

The two are set with sensible Priorities (10 for the install, 11 for the update).

Perhaps policies don't look at the Priority setting, and Priority is only for Imaging? I'm not too fussed about it and have since acquired an installer that installs 14.3.2 to begin with, but am curious if this behaviour is normal and am wondering what a one-policy solution might be were I need to something similar in the future.

Thoughts?

Michael

Best answer by JRM

I have had some similar issues, even with post-imaging install.

Where a restart in-between installs is required:
I've made some tiny Composer packages to create empty files in '/private/var/opt' that, in this case, I called step0, step1, step2, ect...

I add these to my policies, and use smart groups to order the policies. In the smart group "Packages Installed By Casper" You can do this several steps deep without much of an issue.

Example: http://goo.gl/nAUDm
external image link

I find using these "step" packages easier than using something like MS_Update_1234, because when the new base update is MS_Update_2345, I just have to change the policy to deploy the new package. Keeps me from having to update the smart-group and the policy for each change.

If a restart isn't required:
You can create policies with the trigger set to "other..." and give it a custom trigger name. Then at the end of policy1 (your first package) you have it call policy2 (the update) from the 'Run Command:' on the advanced page.

jamf policy --trigger *$TriggerOfSecondPolicy* &

I would be sure to include the '&' so that the first policy can close while the new policy process continues.

Note:
You can of course combine these two into a fairly complex workflow that will confuse the best of us. Good Luck!

    4 replies

    J
    Forum|alt.badge.img+7
    • JRM
    • Contributor
    • Answer
    • March 15, 2013

    I have had some similar issues, even with post-imaging install.

    Where a restart in-between installs is required:
    I've made some tiny Composer packages to create empty files in '/private/var/opt' that, in this case, I called step0, step1, step2, ect...

    I add these to my policies, and use smart groups to order the policies. In the smart group "Packages Installed By Casper" You can do this several steps deep without much of an issue.

    Example: http://goo.gl/nAUDm
    external image link

    I find using these "step" packages easier than using something like MS_Update_1234, because when the new base update is MS_Update_2345, I just have to change the policy to deploy the new package. Keeps me from having to update the smart-group and the policy for each change.

    If a restart isn't required:
    You can create policies with the trigger set to "other..." and give it a custom trigger name. Then at the end of policy1 (your first package) you have it call policy2 (the update) from the 'Run Command:' on the advanced page.

    jamf policy --trigger *$TriggerOfSecondPolicy* &

    I would be sure to include the '&' so that the first policy can close while the new policy process continues.

    Note:
    You can of course combine these two into a fairly complex workflow that will confuse the best of us. Good Luck!

    T
    Forum|alt.badge.img+10
    • tuinte
    • Author
    • Valued Contributor
    • March 18, 2013

    This is good stuff. I can think of a few implementations for this. Thanks a lot. Really.

    Michael

    P
    Forum|alt.badge.img+9
    • PeterClarke
    • Contributor
    • March 18, 2013

    This sounds like a bug... ?

    I have NOT been having that problem by the way...
    ( Casper Vn 8.62 on OSX 10.6.8 server, with AFP File Share from 10.6.8 Server, for Distribution Server )
    ( Both server are virtualised, on parallels server for OS X )

    It would be informative for us to know which version of Casper you are using and which platforms it's running on…
    -- You don't state that...

    The methodology that VPS (Vancouver) are using would definitely work, but it is extra work...

    T
    Forum|alt.badge.img+10
    • tuinte
    • Author
    • Valued Contributor
    • March 18, 2013

    Caper 8.63 on a OS X 10.8.2 Server, HTTP Distribution Point from the same machine.

    In your experience, policies, then, DO typically respect the priority settings? I'd like to confirm that this is in fact supposed to be what happens.

    Terms & ConditionsCookie settingsAccessibility statement