The processing of audits is a multi-step process and fairly complex. Here are the details of how Policy Auditor results are handled from the creation of the audit to the ability to display the results on the ePO console. Before you start using Policy Auditor you have to use ePO to deploy the McAfee Agent (MA) and then deploy the Policy Auditor agent that will run under control of MA. The following assumes that you have MA and the PA plug-in installed on the systems that you want to audit.
Here are the Policy Auditor processing steps:
Note that after step 5 the displayed results in the audits panel will change from “No Result” or whatever the previous status was to a pass, fail or some other status and after step 6 the finding will be visible in the results displays and queries also.
So, it could take 2 hours and 10 minutes to see all the audit results and findings to show up in the ePO PA tables and the PA console views in the worst case. There is also a case where it could take 3 hours and 10 minute. The 3 hours wait can occur if you deploy the PA agent right after an ASCI has expired. In this case, the expiration of the next ASCI will update the ePO device properties and one of the items updated will be the fact that the device has PA on it. The PA policies are only sent to devices that have the PA plug-in on them, the first ASCI will set this fact, and the second ASCI will send the audit related ePO policies and the third ASCI would return the audit results event.
If you want to speed this up you can do that by using an ePO waking up on the devices after step 1 (creating or modifying the audit). This will cause the device to contact the ePO server and get the audit content or changes in the ePO policies and the device will run the audit. Note, if this is a newly install PA plug-in you need to wake the device up twice. During step two, the audit scan is running and can take seconds to hours depending on the device and the benchmarks. Also each audit, regardless of how many benchmarks are used, creates one audit event. If 2 audits are assigned to the same device, then when the first audit is complete, an audit event is queued to MA and could be sent if an ASCI expired while the second audit scan continued on. The second audit results in this case would need the ASCI to expire or another wake-up call.
After step 2 is complete, audit scan completed and event data queued to MA, you could issue another MA wake-up to cause MA to send the queued audit events (and any other point product events) to the ePO server.
After step 3, audit event has been sent to ePO, you can force the 5 minute wait in the Process Audit Results task to expire by running the “PA: Process Audit Results” system task. Whenever this task is started it will cause the waiting subtasks to end and will start a new set of subtasks and those subtasks will immediately look for unprocessed results.
After step 4, process unprocessed audit results, you can force its 5 minute wait in the Process Findings task to expire by running the “PA: Process Findings” system task. Whenever this task is started it will cause all the waiting subtask to end and will start a new set of subtask and those subtask will immediately look for unprocessed findings.
Assuming you waited long enough for the audit scans to complete before issuing the agent wake-ups, this is the fastest way to get PA audit results and findings from devices into the ePO database. Any other behavior you see would be something to be concerned about.
All of these processing steps add to the scalability of the ePO/Policy Auditor system but can be confusing in the instant gratification world that we live in and that most demos are done in. There are good reasons for each one of these processes and associated delays but when looking at the entire end to end process it can be confusing and hard to explain what you are seeing.
Here is a further complication, what happens when Policy Auditor SCAP content is updated? When will new or updated content that is checked into the ePO / PA server be used at the devices that have the older version of the content?
Any content associated with a NEWLY CREATED PA audits will be sent to the assigned devices at the next MA ASCI. This will include any OVAL checks that have been updated but only those checks that are referenced by the newly created or newly added assignment for the devices.
The updated content for existing audits is sent to devices two ways. If a benchmark has been updated AND that updated benchmark is activated so it will be used, then all content associated with that benchmark is sent to all devices that have that benchmark assigned to them on the next MA ASCI after the benchmark is activated.
If the benchmarks being used are NOT changed (and therefore there is no need or way to activate the benchmark since it is already activated), then the updated content (the OVAL checks) will be sent to the device on the next MA ASCI AFTER the “PA: Benchmarks and Checks Synchronization” system task has run. The default for this task is to run every 7 days. So it may take 7 days before the devices fetch the updated content.
An example may describe this better. Create an audit that includes the “MS Windows Bulletin 2011” and “MS Windows Bulletin 2010” with frequency of 7 days and no blackout periods on one device. The audit for this will run soon after it is saved, let’s says it runs on December 1st.
On 12/2 the “PA: Benchmarks and Checks Synchronization” system task has runs and since no updated content has been receive since the PA audit policies were created, nothing is changed.
On 12/3 updated content is received and this includes an updated “MS Windows Bulletin 2011” with an updated MS11-001 patch check and a new patch check for MS11-002. Furthermore it also includes an update to a patch check MS10-005 that is referenced by the existing “MS Windows Bulletin 2010” benchmark but that benchmark has not changed.
On or about 12/8 the PA agent will run the audit the second time, but since the “MS Windows Bulletin 2011” was not activated and the “PA: Benchmarks and Checks Synchronization” system task has not run the audit that is run will use exactly the same OVAL checks that were fetched by the agent on 12/1.
On 12/9 the “PA: Benchmarks and Checks Synchronization” system task will run and it will update the PA audit related policy to include the updated MS11-001 and MS10-005 patch checks for the audit definitions in use. The next MA ASCI after this task runs will fetch the updated content for this two patch checks.
Then, on or about 12/15 the PA agent will run the audit the third time and will use the two updated checks.
At any point if the updated “MS Windows Bulletin 2011” is activated, that process will cause the update MS11-001 patch check and the new MS11-002 patch check to be included in the ePO / PA audit related policies. But the activation of the updated “MS Windows Bulletin 2011” will have no effect on the updated MS10-005 patch check. Running the “PA: Benchmarks and Checks Synchronization” system task would affect the updated MS10-005 patch check as well as the updated MS11-001 patch check.
This is a bit complicated but is consistent with the store and forward architecture of ePO that allows for the scalability needed to handle 10’s of thousands of devices from one ePO server.
We also get questions about how to determine what state an audit is in, similar to: “Can you track the status of an audit (started, in-progress, complete) on the client workstation?”. The short answer is no, not really. The only status or state that really matters for the audit of a system is are the benchmark results current or expired on the ePO server.
How the benchmark results transitions from “no result” or expired result to current result is a very complicated process. You can read the detailed steps involved in a Policy Auditor audit defined earlier in this document and better understand why. A bit longer answer is that there are a lot of states that a given audit can be in for a given system (some of them at the same time because there is an ePO state and a state on the audited system). Here are the states that I can think of during normal day to day processing, if various system task or ePO services have been stopped or crashed, other states can exist:
It seems like it should be simple but it is not because state or status is related to your viewpoint. Are you looking at the results for a system as then exist in the ePO database for an Audit that already has results and the audit definition has not change, or for a newly defined audit or for an changed audit definition. The processing is this complex so that auditing processing can be highly scalable and self-managed.
Another common question is: “Is there any way to kick off an audit on a client workstation (other than “Run Audits” from ePO console) ?”.
Yes, there are a couple of ways to cause audits to run sooner than the normal processing. Through the ePO console here are the steps:
At this point you will be able to see the results for the system that just completed its audit.
If you have console access to the system, you could also use the PA Agent debug console and the run the audit manually and then use the McAfee Agent Monitor to force the system to send the audit results then go to step 4 above. The PA Agent debug console can be run from the install directory of the PA agent using enginemain –u (windows) or enginemain –n for UNIX. Use this interface to list the audit, select it and run it.