You include smart group crtieria that look for the specific application version. In some cases, that can result in an installation error which may become apparent to the end users.Ī way to avoid this is to scope your policies dynamically based on what is already installed on clients. However, that means the policy will run even if the same version has already been installed by some other means. jctl can also be used to flush the policy. Some people create policies that run once-per-computer, and flush them when they are ready to stage the next version to production.
This includes a tool called pkgctl which you can use to swap out packages in existing policies. Once we have tested version 102.0, how do we then stage this particular package to a policy that is scoped to all production computers? We can’t just run the same AutoPkg recipe again with a different policy template, because by then version 102.0.1 could have been released, and we would inadvertently push it straight to production without it having been tested.Īpart from the obvious but tedious method of logging into the Jamf Pro admin console to manually make changes, one option is to use a different tool that works with the Jamf APIs, such as the University of Utah Marriott Library’s jctl. For example, when we import Firefox-102.0.pkg into Jamf Pro, we can write our Firefox.jamf recipe so that it creates a policy with that package attached to it, which is scoped to a smart or static computer group called Firefox testing.
jamf recipe to create a policy that is scoped only to a group of testing computers. Therefore, a common practice is for the AutoPkg. For many, the package that has been imported should be tested before it is staged to production. AutoPkg, in conjunction with the JamfUploader processors, provides an automated way to import packages into Jamf Pro.
0 kommentar(er)
