Caching packages

[casper_admin]

I am deploying Office 365 and few Adobe CC packages through Self service and the download becomes very very slow once multiple computers start downloading the packages.

Here is how am doing it:

A policy is caching the packages to all computers, then another policy installs the cached packages scoped to a smart group of computers that have those packages and make them available in self service.

Its taking a very long time for the packages to show up in self service, so I was wondering if theres a better way to deploy. The packages were being downloaded through http, but I was getting most of them were timing out, so i turned off http, and now they are going through afp which seem to work lil better but still very slow downloading.

I have about 700 computers, 1 JSS and 1 Distribution point both hosted on 2 different mac mini.

Will things get faster if I were to add a second, and third Distribution point?

Please advise

Thanks

[sdagley]

@casper.admin Those are pretty large packages, what does the network between your DP and those machines look like?

Are all the computers on the same subnet? You can define a Network Segment to specify which DP to use if you added DPs. Or if you can divide the computers into different Smart Groups, you could create multiple Policies to cache the installer and use the setting in the Package payload to specify what DP to use.

As for the delay in the package showing up in Self Service, does you Policy to cache also include a Maintenance payload to update inventory so your Smart Group to report computers with cached installers updates as soon as the caching is complete?

[khey]

Hi,

I would recommend using a script to trigger the cache policy and then run the installer policy once cached. This way you dont have to wait for your computer to update the inventory.

something like this

#!/bin/sh
   caffeinate -dis &
   jamf policy -trigger cache-office365-installer
   jamf policy -trigger run-office365-installer
   #Restart
   shutdown -r now
   exit 0

Regarding your slow download, could be either your network traffic is heavy or your mac minis are getting smashed. Check the Activity Monitor on your mac minis during deployment.

Staging the deployment would be better than deploying to all machines at once.

[sdagley]

@khey I'm also a fan of using a policy trigger to force an install after caching completes (although that's less of an issue now that package installs from SMB/AFP DPs work better with JSS 9.100.0), but if you're intending to use that script in a policy note that shutdown -r now will force the machine to shutdown before the policy returns the results to the JSS.

[casper_admin]

@khey khey how to stag the deployment? And would the script be an addition to the cache and install cache policies?

Right now i have a cache policy trigged at recurring check in which is set to every 15 minutes, then an install cache available in self service.

[casper_admin]

@sdagley the computers are on different subnets. What if i create more DPs and then use the failover option in the JSS and turn on randomising. I think thats was an option after adding a second DP

And yes all the computers are in smart groups

[sdagley]

@casper.admin I missed the arrival of the randomizing option for additional DPs, that definitely would help. I'd also recommend the additional DPs not be connected to the same switch as your primary unless that switch has a 10GB connection to your network.

[casper_admin]

@sdagley will try adding 2 more DP . Will also look into adding an update inventory at the once the cache police runs so the install cache policy will pick up right away. I believe that is part of my issue as the install cache policy have to wait jntil inventory update to come in before it runs.

The other issue i need to figure out is how to send out the policies 1 at a time. Right now all the policy are enabled and all trigger at recurring check in.

[khey]

@khey khey how to stag the deployment? And would the script be an addition to the cache and install cache policies? Right now i have a cache policy trigged at recurring check in which is set to every 15 minutes, then an install cache available in self service.

Hi @casper.admin , in total you would have 3 policies.
1. Policy to Cache with Custom Event - set to Ongoing
2. Policy to Install the Cache with Custom Event - set to Ongoing
3. Policy that trigger the two policies above one after another as my post above. You can also include sudo jamf recon after the install is done. - Set to your Smart Group that exclude machines that already have Office365 or Adobe installed.

This way, you dont need to wait for computer to do recon to run the installer.

What i meant by staging is to create either smart or static groups just to deploy to limited number of machines at a particular time.

[khey]

do you actually want users to install Office 365 via Self Service at their convenience?

From my experience, most of users wont be bothered to do that.

[casper_admin]

@khey I am not gettting the custom event and why setting the Ongoing execution. What could the custom event be?
I wanted the package to get removed out self service once its has been installed by the user, so my trigger is set to Recurring check in and Once per computer.

when using a script policy to trigger the 2 policies, what would the Trigger be set to? and the frequency?

[sdagley]

@casper.admin Just as an FYI, you can download installers for the individual Mac Office 2016 apps from macadmins.software if you want to be more granular with your Office installation.

Here's a somewhat simpler approach to using multiple policies to install a package as soon as it's cached:
- Create an ongoing policy with a Trigger of Custom scoped to all managed devices that has a Package payload with an Action of Install Cached for the package you want installed
- Create a 2nd policy scoped and triggered however you want it that has a Package payload with an Action of Cache for the package you want installed. Add a Files and Processes payload to this policy, and in the Execute Command field put sudo jamf policy -event <TriggerForInstallCachedPolicy>. Replace <TriggerForInstallCachedPolicy> with whatever you specified as the trigger for your Cache policy. The sudo shouldn't be necessary, but it's habit.

This approach avoids having to use a policy with a script to call separate Cache and Install Cached policies, although you do still need more than one policy to get the job done.

[casper_admin]

@sdagley

Wait! Here is what I have set up

I have 2 policies:

1. Cache policy with Adobe pkg, Triggered to Recurring checkin ( every 15 minutes), Execution is Once per Computer, Scoped to All computers

2. Install cache with Adobe pkg, No trigger, Execution is Once per Computer, Scoped to a Smart Group of Computer that has Adobe pkg.

Now wouldn't be the same if I were to just add an Update Inventory Maintenance payload to my Cache policy, that way my Smart Group of computers that has the Cached packed will update then the package will show up in Self Service ?

This way I wont need to use triggers. Wouldn't the result be the same?

I am making all my package available in self service for the user to install. Nothing is being installed automatically, they chose what to get.

[sdagley]

@casper.admin The approach of a Custom triggered Install Cached Policy being called from a Policy that first does a Cache isn't really applicable for you as it would install as soon as the installer had been cached.

I would make the following changes to what you describe as your current setup if you want to keep the approach of packages will be cached, and it's up to the user to initiate the install from Self Service:

For the Cache policy I'd change the Execution to Ongoing, and add Exclusions to the policy Scope that excludes machines that either have the software installed, or have the installer cached. This way if the Cache policy fails you don't have to manually purge the failure in your JSS before the policy will be applied again (Once per Computer doesn't mean the policy was successful, just that it was run).

For your Install cached policy I'd consider using Ongoing for the Execution setting. If you do an Inventory after the package is installed the computer will fall out of the Smart Group for package is cached so you shouldn't need to worry about limiting how many times the policy can be run. And that way if the install fails they could re-try without you having to purge the failed install from that policy in your JSS

[sdagley]

@casper.admin I should note that I originally adopted the Cache then Install Cached from a policy trigger when installing large packages like OS updates to work around a bug with an Install payload that doubled the amount of data transferred across the network if you were using AFP or SMB Distribution Points. The problem was that the Install policy would first verify the package on the server (requiring all of the data in the package be read across the network), then copy the package to the client machine. With a Cache/Install Cached approach the package is copied without verification by the Cache policy, then the Install Cached policy verifies the package copy on the user's machine. Jamf finally fixed that bug in 9.99.0, so these days there's not really a disadvantage to using a straight Install policy if you're looking to install things without user action.

[khey]

@khey I am not gettting the custom event and why setting the Ongoing execution. What could the custom event be? I wanted the package to get removed out self service once its has been installed by the user, so my trigger is set to Recurring check in and Once per computer. when using a script policy to trigger the 2 policies, what would the Trigger be set to? and the frequency?

Hi @sdagley ,

The cache and install policies can be both Ongoing and available to All Users or Computers (only Custom Events). This is fine because the trigger would be from the script of the 3rd policy that calls the other two policies. You scope the Script Policy only to your smart group and you can set it to Ongoing and Recurring Check in. Why? because you want to make sure that all computers are getting the installs.

You would need a proper Smart Group to exclude the computers that already have the Apps installed, you can do this by using EA or the built in search criteria. This way it doesnt matter if you set it to Ongoing and Recurring Check In.

As previously posted, you would have the script below in your third policy

#!/bin/sh
   caffeinate -dis & #prevent computer from going to sleep to download the package
#Both commands below will execute line by line
   jamf policy -trigger cache-office365-installer #this is the Cache policy 
   jamf policy -trigger run-office365-installer #this is the Install Policy
   sudo jamf recon #to remove the computer from your smart group
   #Restart (put # if you do not want to restart)
   #shutdown -r now
   exit 0

in a nutshell:

1st policy - Cache Package, Ongoing, Scope to All Computers & Users, Custom Event cache-office365-installer
2nd policy - Installed Cached Package, Ongoing, Scope to All Computers & Users, Custom Event run-office365-installer
3rd policy - Script that calls the first policy and then the 2nd policy, Ongoing , Recurring Check In, Scope to Smart Group

Hope it makes sense.

[sdagley]

@khey I think you meant that for @casper.admin

As for the approach of using 2 or more policies to Cache then Install Cached for packages, did you come up with your approach to avoid the problem of doubled network traffic from AFP/SMB DPs on a straight Install policy, or was there another reason? If the former, note that Jamf Pro 9.99.0 fixed that bug.

[casper_admin]

@sdagley Got it. I am Caching 6 Adobe packages, So for the exclusion part I will need to create a Smart Group for each package to check if a computer has a particular package?

[sdagley]

@casper.admin Correct. Don't forget the Smart Group for computers that have the software installed as you don't want to re-cache the installer package to them.

[casper_admin]

@sdagley yes I create 2 Smart Group for each package, one has the cached package and the other one has the cached or the application.

Issue: The system will not let me set it the execution to Ongoing with a Trigger of Recurring check in Scoped to All computer, because of the update inventory payload.

here is the error message: "Policies that update inventory on all computers cannot be set to ongoing frequency at recurring check-in."

[sdagley]

@casper.admin Do not scope the Policy to do the Cache to all computers, do it to a Smart Group of computers that don't have the software installed and exclude the computers that have the package cached already.

For the policy that does the Install Cached, the only trigger should be the Custom event, and you don't need an Inventory payload on that policy since the one from the Cache policy will execute after the Install Cached policy is called.

[casper_admin]

@sdagley Too many Smart Groups now. So the Install cache policy wont run if I dont chose a Trigger? If I check Custom for the Trigger do I need something on the Custom event? or can i leave it blank?

[sdagley]

@casper.admin Something has to trigger a policy (unless it will only be used for Self Service), and for the Install Cached policy you will check Custom under Trigger, and enter what you want the Custom Event to be. For the policy you show above, I'd use something like InstallCachedPremierProCC2017. In the policy that has the Action of Cache for the package you would use an Execute Command of sudo jamf policy -event InstallCachedPremierProCC2017 in a Files and Processes payload.

[casper_admin]

@sdagley .. Thats right, I just left it with no trigger cause its available in self service.

Everything is set up and running, but am getting a Failed Status on the Install Cache because the policy tries to run again 3 times after the initial install, then fails because the cached packages is not there anymore after installation complete. So I get 1 Comptete and 3 failed status.

See picture:

I have update inventory in both Cache and Install Cache policy.

[sdagley]

@casper.admin As I noted in my first post on 2017-07-29, you would not use the approach of a Cache policy triggering an Install Cached policy via a custom trigger if you're still intending to have the user initiate the install from Self Service. The whole purpose of that approach is to initiate the install as soon as the package has been cached. That post also describes how I'd recommend setting things up for user initiated installation via Self Service.

[casper_admin]

@sdagley Am not using triggers. In my cache Install policy, I think I will need to exclude a Smart Group of computers

[sdagley]

@casper.admin If you want to install on every computer you have managed, in your Policy that caches the installer use a Scope Target of All Managed Clients (that's a selection under Computer Groups when Target Computers is set to Specific Computers - as you discovered you can not have an Ongoing policy set to All Computers but you can this way). You need 2 Smart Groups you can reference under Scope->Exclusions for this policy - a group for machines that have the package cached, and a group for machines that have the software installed. This policy should have only 2 payloads besides General - a Packages payload that Caches the installer, and a Maintenance payload set to Update Inventory.

[casper_admin]

thanks all for the replies. All seem to be going but seeing few computer failing to copy from the DPs. maybe the load is too much as I am caching 8 Adobe CC packages, SmartNotebook and Office 365.

The packages do exist on all 3 of my Distribution points but I am still seeing this error message on some computers, not all computer though. Some do execute and complete with no problem.

[sdagley]

@casper.admin Do those machines eventually manage to cache the installers, or do they perpetually fail with the no such file or directory error? If the former, I'd suggest taking a look at the error logs on your DPs to see if they were dropping connections due to load.

[casper_admin]

@sdagley Which logs should I look at? It seems like it failling when I have multiple computers trying to cache at the same time, however I have 3 DPs in place.

[sdagley]

@casper.admin Look at the logs for the SMB or AFP processes on your DPs for the times corresponding to the failed copy to the client machines and see if you can figure out why the server didn't respond.