Overview of rollout projects

Rollout projects are a simplified method for managing vulnerability patching or software distribution. A rollout project is a set of steps to automate deployment. For each step, you can perform actions (such as a scheduled task), set criteria for when the content should move to the next step (such as an 80% success rate), and send notification emails.

When the patches or software packages have completed the actions in a step and pass the exit criteria, they are moved to the next step in the project. A project can be completely automatic, or you can require administrator intervention to make sure content doesn't progress until you approve it. And since you can set up email notices when a step succeeds or fails, you may not need to monitor the project as closely.

Use a rollout project for a distribution task that has multiple steps that can be automated. For example, applying patches in phases, or distributing new software to a pilot group before general distribution. Rollout projects are especially useful in situations where the task is frequently repeated or requires minimal oversight.

To use a rollout project, complete the following steps:

•Create a scheduled task for the project processor. The rollout project processor applies the actions on the content in the project, evaluates if the content meets exit criteria, and moves content from step to step. For more information about how the project processor works, see How a rollout project works.

•Create the rollout project. Choose whether you want the project to be for software packages or patch definitions. For information about the options when creating a rollout project, see Creating and editing a rollout project.

•Add steps to the project. Steps contain the information about the actions that you want performed. For more information, see Adding steps to a rollout project.

•Add content to the project. Once you have the project created, add the definitions or software packages to the project. You can copy and paste the content, or automatically add definitions using a download definitions filter. For more information, see Adding content to a rollout project.

Once the project is created and has content, make sure it is in the Play state. When the scheduled task runs, the project processor applies the actions.

Example software package rollout project

To perform a staged rollout for new software, you can set up a rollout project to deliver the software to a small group first, and then after it has been installed on 80% or more of those devices, wait for a week to make sure things are working as designed. If the software fails to install on a significant percentage of devices within 2 weeks, set up the rollout project to send an email warning and don't push the software to a larger group. However, if everything works as planned, push the software to a larger group.

This example has two steps:

• Step One

• Action: A scheduled task that distributes the software package to a small group.

•Exit criteria: An 80% success rate, meaning that the package cannot move to Step Two until the success rate has been matched or exceeded.

•Email: You get an email if the package is still in Step One after 2 weeks.

•Step Two

•Action: A scheduled task that distributes the software package to a larger group.

Example patch rollout project

To create a rollout project to automate deploying Ivanti patches, set up the definition download settings to always add Ivanti patches to the rollout project. Apply the patches to your pilot group, send an email that the patches have been downloaded and applied, then wait until an administrator confirms that the patches are working successfully. Deploy the patches to a larger group, and then when the patches are installed on 85% of the devices, set the patches to Autofix and tag them with an Autofix tag to make them easy to identify.

In this example, you change the definition download settings to add content automatically to a rollout project. When you use this feature, the downloaded content is added to the project and automatically begins to move through the project steps the next time the project processor runs. Since this feature requires no administrative oversight after it is set up, you'll probably choose to do this only in situations where you trust the content or you have an approval built into the project.

This example has three steps:

•Step One

•Action: A scheduled task that applies the patch to your pilot group.

•Exit criteria: An 85% success rate, meaning that the patch must be installed on 85% of devices.

•Exit criteria: Administrator approval.

•Email: After the success rate has been met, you get an email saying that the content is waiting for approval.

•Step Two

•Action: A policy-supported push task that applies the patch to a larger group.

•Exit criteria: An 85% success rate, meaning that the patch must be installed on 85% of devices.

•Step Three

•Action: Set the patch to Autofix.

•Action: Tag the patch as Autofix.