Posted on 06-06-2017 02:12 AM
Hello People!
Question, at our school we have 270 iMac's.
Last summer holiday we started to use Jamf.
Really happy with it!
Now we are getting close to the summer holiday, and every year we image all our mac's to have a fresh start at the new year.
But we noticed that reimaging isn't what it used to be :)
Since off course a lot of actions are labeled "Run Once"
I read about it, some people mention: you need to flush all policy's , some people say that that does not work.
Remove all computers from the JSS before imaging doesn't seem a pretty solution.
Any thoughts about this?
And yes, all the user data is on the AD network, and all computers are also multi user.
So no worry about data destruction, but we do have a lot of rubbish on the mac's after the school year.
Posted on 06-06-2017 02:39 AM
We are going to run the "jamf flushPolicyHistory" command in a script that runs after reimaging, either by putting that in a script set to run "at reboot" or by putting it as a postinstall script in a pkg and setting that to "Install on boot drive after imaging" (had more success with the second method so far).
I have another 2 other scripts in pkgs that stop the casper task and restart it, set to priority 6 to stop it and 12 to restart it. The postinstall pkg is sandwiched between those (set at 8) so if I wanted to, I could also put the "jamf policy" command in after flushpolicyhistory so all my packages are installed while the "Software installation in progress" splash screen is displayed.
I initially did this a couple of years ago because I found that during installation of something large like Creative Cloud (if set to "Install on boot drive after reimaging) then the jamf binary would kick in before the install was complete and would start dragging down policies and installing software simultaneously which made everything take twice as long and sometimes broke stuff.
Posted on 06-06-2017 02:40 AM
Flush on 'run once' items does work well…
No need to remove computers from the JSS if you are just re-imaging them…
But you will need to re-enroll them..
(You only need to remove computers from the JSS that you want to decommission)
Posted on 06-06-2017 03:48 AM
Flush policy history also flushes VNC logs. It also requires a db value to be set properly - so if it doesn't work with you, jamf support can help with that.
Instead of using that, since we want VNC logs to stay in place, we use a quickadd package set to install on boot drive as the first thing that happens post image. This flushes all policy history while leaving VNC logs in place.
Posted on 06-06-2017 07:06 AM
sorry if I am being dense... would a "jamf flushPolicyHistory" at reboot when re-imaging a machine reset all policy logs on the JSS side for the machine?
I was going to go through my self service policies and reset them all by hand.. if this does that, so much the better because I can target just the machines that need it.
thanks
Posted on 06-06-2017 07:24 AM
I'm also really interested in this topic. Like @A_A we started using JAMF last fall and are so far very happy with it. I'm considering re-imaging all my macs to a base image that includes nothing but the updated OS and the initial admin account with a post image script to enroll the mac and clear their policy history. Then let my policies and configuration profiles take over to install all the updated applications and settings.
Thoughts? Things to be careful of?
What are others planning to prepare their hundreds of macs for the new school year with hundreds of applications and settings that need to be updated and/or reset?
Posted on 06-06-2017 11:33 AM
Good stuff @nigelg I'm going to try some of your methods on Macs that we take back into inventory and then re-deploy to new users.
Agreed @A_A that simply deleting them from JSS, while effective, doesn't seem like the most efficient method. Any other suggestions for streamlining imaging would be most appreciated. Thanks all.
Posted on 06-07-2017 06:54 AM
We set up extension attributes to look for all software and settings on devices then we have smart groups that are dependent on the existence of that software or not. We then scope policies to smart groups and have those policies set to on going. When the device receives the proper software or setting it is removed from the "does not have" smart group and will not longer call for that policy. This way all we have to do when we reimage is run a recon to tell the JSS what this device has or doesn't have and the JSS will then run a policy to put all the proper software on the machine.
Posted on 06-07-2017 07:02 AM
Hi David,
Do i understand it correct that in this way(as an example), there is a smart group : "No Adobe" , that has members that don't have adobe installed and on that group you trigger the install of adobe ?
But when you want to run scripts once, it has a group that checks if those settings are being set?
Posted on 06-07-2017 12:09 PM
@A_A ,
I have a smart group that is "Needs Adobe or update", that smart group checks if Adobe is installed or if the version number is the latest. If the device doesn't fit that criteria that device gets put in this smart group. Then the policy is an ongoing policy on the smart group. But the policy will only run once on that device because after running the device will not fit the criteria of that smart group anymore.
When the device is reimaged it then fits the "Needs Adobe or Update" group criteria and will receive the software again.
Posted on 06-07-2017 12:09 PM
@A_A ,
I have a smart group that is "Needs Adobe or update", that smart group checks if Adobe is installed or if the version number is the latest. If the device doesn't fit that criteria that device gets put in this smart group. Then the policy is an ongoing policy on the smart group. But the policy will only run once on that device because after running the device will not fit the criteria of that smart group anymore.
When the device is reimaged it then fits the "Needs Adobe or Update" group criteria and will receive the software again.
Posted on 06-15-2017 06:25 AM
Aint it something that should be in every image configuration?
maybe run once should get a second option, run once after imaging?
for now it seems that "flushPolicyHistory" seems to work.