Logging, Auditing and FAQ for Rollout Projects

Version 2

    Overview:

     

    The purpose of this document is to provide insight on the logging used to troubleshoot issues when a problem is encountered during the evaluation of a Rollout Project. An outline of the auditable actions will be listed and a Frequently Asked Question section will be for reference.

     

     

    Logging:

     

    The activity of a Rollout Project evaluation is recorded in the workflowprocessor.log and the workflowprocessor.details.log file. This log will provide data pertaining to the items configured in your overall project and is maintained on the core server under the ManagementSuite/Log directory. This logging is only applicable to the actual processing of the project. If you elect to use Task Template in your project actions, once the task is created, the standard Software Distribution or Repair task activity is in use.

     

     

    Auditing:

     

    To enable the Auditing feature please review How To: Enable Auditing for a User .

     

    The following auditing actions can be enabled:

         

     

     

     

    FAQ:

     

    Q: How Does a Rollout Project Work?

     

    A: How a Rollout Project Works

     

     

    Q: What's preventing my content from advancing from step to step?

     

    A: The items configured under the "Exit Criteria" section in your step controls when a package or patch definition is allowed to move on to the next step for evaluation. If all configured items aren't ready, the content will have to wait until the actions are evaluated again by the processor.

     

     

    Q: What is the difference between "Not vulnerable" and "Not vulnerable and Patch is Installed"?

     

    A: Not Vulnerable -  the definition was not detected as a vulnerability on the device when a security scan was performed, the device never needed the patch based on the detection logic in the definition.

     

    Not vulnerable and patch installed is similar to "Not vulnerable" but the only difference is that the vulnerability definition being scanned has been repaired through the patch process.

     

    A device reboot may be required for most patches so those devices will need to be rebooted before the system sees that patch as fully installed.

     

    Currently if a patch is not detected when a security scan is performed for the target group in that step, no repair will be done for those patches.

     

    The following definitions will NOT move to to the next target group:

     

    • Definitions in which no scan record has been found
    • Definitions that are not applicable to the platform in that target group

     

    Undetected patches will  move to the next target group. Content that is not detected as vulnerable won't play against your success rate.

     

     

    Q: Can I automate the addition of Software Distribution packages to a project?

     

    A: No, the Software Distribution component has no filtering mechanism directly associate to the Rollout Project component.