Another 3rd Party package deployment question

[SMR1]

I created 6 smart groups for devices missing specific software. I then created 6 Policies and set the scrope to the smart groups. These are all updating via Installomator script. We have an office in San Diego and Fort Mill, SC. I set the client side limitation to not install from 5am-8pm and checked the days I don't want the software to install hoping the deployments would kickoff after 8pm local time. Prior to that, all of my testing with client-side worked with individual devices. Is it possible, I had too many deployments set? It was 6 updates on 21 Mac's. I just did a test with just deploying to one smart group with client side configured and it went through.

[AJPinto]

I am assuming each smart group is paired with a specific policy. Each of the pairs would be independent of each other. It should work fine. Smart group 1 sees application 1 is not installed. Policy 1 is targeting devices missing application 1. So, when Device A is added to smart group 1 for missing Application 1, Policy 1 should trigger at check in to install software 1 if your triggers are set right. However if a device is offline between 8p and 5a nothing will happen because of your time limitation, the software will never install.

Just make sure you set the client side time limitation, and not server side time limitation. Also note how many devices may be offline in your preferred window of 8pm-5am. Many MacBooks people have will be powered down in that time window, and not get the installs at all because you blocked off their online time. I typically let policies install at any time of day, and give a deferral option to the user if its something that will impact them. However, every environment has its own needs.

[SMR1]

Thanks for the reply. We're actually in the process of getting Jamf rolled out, so this all kind of new and going through testing. We have around 28 Mac's enrolled and using them as beta testing. In our environment, they prefer to have updates run at night and we typically send out communications prior letting our end users know updates are coming. Yes, each smart group is paired with a specific policy for the specific application and they're all set for the same client-side limitation time. Since we're testing, these users know to keep their devices on and plugged in. 

[AJPinto]

We originally tried to stick with overnight deployments like with our Windows environment. However, it just did not work out for Macs. If the Macs are all desktops I dont see you having any issues. If there are MacBooks in the mix I recommend reconsidering. Between PowerNap, various network states, and Users flat-out not listening you will have problems. You are also limiting your troubleshooting to overnight unless you want to change limitations for policies targeting your production environment to test or making copies.

We generally enable the policy at 5pm (with user notification) and have no time restrictions on it. If a user left their device offline overnight they will get the policy 1st thing in the morning, and can differ usually 2 days before it just forces. Most applications only take a few moments to install. We don't use Installomator, I have never found a need for it. I suppose its down to how important it is to make sure a device is complaint.

[SMR1]

That's the same here, they wanted us to mimic the windows update process. How do you set the policy to enable at 5pm? I'll try the referral route as well.

[AJPinto]

In the general screen of the policy, go to the bottom and setup the activation date/time. The policy will not start doing its thing until that date/time passes even if you have it enabled and ready to go.

For OS updates with JAMF that is all out the window. For intel Macs you can use a script that is wrapped around a policy, but with apple silicon macs you must use MDM commands or the users will get a popup box to enter admin creds to approve OS updates. MDM commands are a beast in and of themselves that in no way shape or form can be made to mirror anything like what Microsoft is doing.

One thing that is a tough pill for any org to swallow that is primarily a Microsoft shop. You cannot manage MacOS like Windows. The moment that is accepted Macs can thrive, until then it will be a horrible mess that barley functions. 

[SMR1]

I reran the updates and had more success this go around. I still used the client-side, but made a bigger window for devices that come back online in the morning. Have a lot of devices with multiple updates, but maybe 1 or 2 would install. Might have to switch to the deferral option like you mentioned, because don't want a user to get the update in the morning and have it close there application. I need to change the timezone for Jamf, because the default is UTC.

[mm2270]

---

@SMR1 wrote:

I need to change the timezone for Jamf, because the default is UTC.

---

There was just another thread on this topic here. If you're on Jamf Cloud and specifically Jamf Cloud Standard, you won't be able to change the servers timezone. They are all set to UTC. Those servers are part of a shared tenant model, meaning several customers are all hosted from the same virtual server. If you run Jamf Pro on prem OR have Jamf Cloud Premium, then it can be done. I assume since you mentioned UTC that we're talking about Jamf Cloud though.

That said, the client side limitations respect the time zone of the device, not the server, so your Macs in San Diego will get the policy kicked off at whatever timeframe you specify for their respective timezone. And same for your Macs in SC.

[SMR1 · Accepted solution]

I did read read about the premium user.  I've set it up using both methods, but some devices are are hit and miss with the updates even though the update has been active for a couple of days, the device never grabs it.