1 ACCEPTED SOLUTION
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
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!
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
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!
