Skip to main content

The example below installs our Flash Player package on All Managed Clients. The Smart Computer Group and Policy is created in a way that allows us to re-install Flash Player on systems that have been re-imaged (without flushing the Policy Log) and update all existing clients to a newer version of Flash Player simply by replacing the package on the JSS and updating the Plug-In Version criteria in the Smart Computer Group.



Components:



+Flash Player.pkg+      Package

+deploy_Flash Player+       Smart Computer Group

+Install_Flash Player+      Policy


Component Details:



+**deploy_Flash Player**+, Smart Computer Group



    Plug-in Title does not have +Flash Player.plugin+

AND Computer Group member of +All Managed Clients+

OR  Plug-in Title has +Flash Player.plugin+

AND Plug-in Version is not +13.0.0.206+

AND Computer Group member of +All Managed Clients+





+**Install_Flash Player**+, Policy



Trigger:            Recurring Check-In

Execution Frequency:        Ongoing

Packages:           Install +Flash Player.pkg+

Maintenance:            Update Inventory

Scope:              +deploy_Flash Player+, Smart Computer Group


That being said…



We have created a package that deploys a folder containing images that our users then set as their Screen Saver. Periodically we will update and re-deploy this package with new images at the direction of our Corporate Communications team, incrementing the package version so that the Installer will know to overwrite the existing images currently on the workstation with those contained in the package.



Unlike the example provided there is no Application or Plug-in Version criteria in which to base the membership in a Smart Computer Group. Is there a way we could deploy this package while still maintaining the same level of automation?

I would have a preinstall script that erases the images currently there (I hope they are left in a specific directory). A 'Flush All' would certainly push it out again. Another option is to create a Version.txt file in the root of the image folder, then key off of that. You'd have to create an extension attribute to read it in, of course.

I'm with @thoule.




  • Policy set to all managed clients

  • Deploy package once per machine

  • add the updated package

  • flush policy logs forcing it to run again on all the machines



You don't need to know what version is on the machines if you know that all the machines have successfully installed the most recent package.

Hopefully I'm not misunderstanding what you're looking to accomplish here, but try this-
Change the package receipt identifier for the 'folder of images' package each time you rebuild it, perhaps by adding a date component.
So say the base package receipt name is something like com.company.ssimages. Change the package receipt to be something like com.comoany.ssimages.20140522 if you rebuild it today.
In a month when you rebuild it, you can change the package receipt id to com.company.ssimages.20140622



Then for your Smart Group, you can change the criteria to use something like:



Packages Installed By Casper | does not have | com.company.ssimages.20140622


That should collect all Macs that do not have that latest installation package receipt on them. Use that for your scope for the push once you've changed the policy to include the new package.
Keep in mind with the above approach that you can keep the actual package name identical each time, so you can easily overwrite the old package up on your CasperShare. Doing this means the policy will use that package each time, but you just need to update the SG criteria to scope Macs that don't have the receipt ID on them.



Is that what you were looking for? If so, does it make sense?

While I agree it's a simple solution, flushing the policy log does not resolve the issue I am trying to address. We use DeployStudio for our imaging process:



• Partition the primary hard drive.
• Restore image to a volume.
• Assign computer name.
• Bind system to Active Directory.
• Install the CasperAgent package.



When we re-image a workstation that has already received our Screen Saver package, it retains the same computer name as it did before. Therefor when it checks back in with the JSS, the package is not re-installed as the policy log shows that it's complete.



Granted the technician doing the deployment could simply log into the JSS and flush the policy log for that particular workstation, but we are trying to avoid that as much as humanly possible by automating the process.

All you need to do is add a script to deploystudio that runs
jamf flushPolicyHistory



That will cause all policies to run for that machine again.

@waderobson This suggestion just resolved my issue (and apparently another one that I didn't realize I was experiencing yet). Thanks!

Reply


Terms & ConditionsCookie settings