Posted on 04-18-2017 04:55 AM
Hello,
As we want to implement (or force, actually) our users to update to the latest macOS I thought I'd ask for some "best practice" tips if you already have a working system in place.
We still have a two users on 10.8.5 and 10.9.5 (sigh), which I will have to deal with personally. But otherwise I'd rather we have a working system using the JSS to have our users, or help the users update this. If you're already doing this, do you have any pointers you'd like to share?
Solved! Go to Solution.
Posted on 04-18-2017 05:02 AM
Step 1: Create Smart group to define those eligible for update
- Not currently running latest OS/Cached copy of latest OSX updates
- Machine is new enough
- Machine has the space
Step 2: Create a policy to cache the OSX installer on to the machines in the above group
Step 3: Create a smart group for all users with the cached installer, caching it is just for speed from clicking install to install running to keep the end users happy.
Step 4: Create a policy for Self/Service or Recurring once a day or something, have it prompt the user to run the updates. Consider a maximum deferral to force the install after X days.
Posted on 04-18-2017 05:55 AM
From painful experience, I am going to suggest the use of the deferral tab. This will NOT get them out of running the updates that you seek but to "let them feel like they have a say..." when you do the update. When you use the deferral tab, you get the option of "allowing the users to defer until....".
I would also focus on the communication with them. Nothing is worse than getting pestered to run an update on your Mac in the middle of standardized testing or an important client engagement in the business world.
That being said, I wish you good success in your patching endeavors. I like @Joeborner 's idea of cacheing the stuff locally and getting good smart groups so you know which is going to succeed or fail. As for your 10.8.x and 10.9.x clients, I feel for you there. We still had some 10.6.x folks in the district up until last summer as they were still trying to run PowerPC apps in Rosetta. We were luckily able to convince the staff that developed the app in house to spend the summer porting all of them to Intel. It sounds bad but they are homemade text book Mac applications and getting a porting effort off the ground for those staff members required getting working with the superintendent to get them compensated for such labor. They have been continuously updating those apps since the System 7 days and have undergone 3 major code revisions since I hired in 15 years ago.
Posted on 04-18-2017 11:01 AM
Get the CEO involved and tell him or her these two machines are a security compromise to the entire network.
Posted on 04-18-2017 05:02 AM
Step 1: Create Smart group to define those eligible for update
- Not currently running latest OS/Cached copy of latest OSX updates
- Machine is new enough
- Machine has the space
Step 2: Create a policy to cache the OSX installer on to the machines in the above group
Step 3: Create a smart group for all users with the cached installer, caching it is just for speed from clicking install to install running to keep the end users happy.
Step 4: Create a policy for Self/Service or Recurring once a day or something, have it prompt the user to run the updates. Consider a maximum deferral to force the install after X days.
Posted on 04-18-2017 05:55 AM
From painful experience, I am going to suggest the use of the deferral tab. This will NOT get them out of running the updates that you seek but to "let them feel like they have a say..." when you do the update. When you use the deferral tab, you get the option of "allowing the users to defer until....".
I would also focus on the communication with them. Nothing is worse than getting pestered to run an update on your Mac in the middle of standardized testing or an important client engagement in the business world.
That being said, I wish you good success in your patching endeavors. I like @Joeborner 's idea of cacheing the stuff locally and getting good smart groups so you know which is going to succeed or fail. As for your 10.8.x and 10.9.x clients, I feel for you there. We still had some 10.6.x folks in the district up until last summer as they were still trying to run PowerPC apps in Rosetta. We were luckily able to convince the staff that developed the app in house to spend the summer porting all of them to Intel. It sounds bad but they are homemade text book Mac applications and getting a porting effort off the ground for those staff members required getting working with the superintendent to get them compensated for such labor. They have been continuously updating those apps since the System 7 days and have undergone 3 major code revisions since I hired in 15 years ago.
Posted on 04-18-2017 11:01 AM
Get the CEO involved and tell him or her these two machines are a security compromise to the entire network.
Posted on 04-18-2017 11:29 AM
In our case, that's essentially what I had to do was have our CTO explain to the superintendent that 10.6 were both beyond support and a bit of a security risk. The fastest way to solve was to ascertain exactly why they are on an old OS, and in our case, I explained how the apps were developed. He agreed to pay the staff part time over the summer to port and they agreed to do the work. We were able to phase out 10.6 and 10.7. 10.8 and 10.9 are on the way out very shortly in our district this summer, mainly due to lack of time.
Posted on 04-24-2017 07:03 AM
All good answers, thank you!