How do I capture data for the Compliance pages in the Web Reports?

Preparing to track:
First, consider which Compliance data types you need to capture, and ensure that your audit settings in Windows are properly configured to track this data. For a checklist of which audit settings are required for each Compliance data type in EventSentry, please see:

https://www.eventsentry.com/documentation/help/html/tracking_requirements.htm

It is highly recommended to use the advanced audit policy settings, since this means you can enable only the audit types that you need without turning on entire categories of security event creation. For example, if you need to track File Access activity, with advanced audit policies you can choose to only turn on File System success and failure auditing. If you do not use the advanced audit policy settings, you would have to turn on the entire Object Access category even though you only want to track File Access. This would forcibly audit File System, Registry, Kernel Object, SAM, Certification Services, Application Generated, Handle Manipulation, File Share, Filtering Platform Packet Drop, Filtering Platform Connection, Other Object Access Events, and Detailed File Share. That's a lot more data for your database to receive, especially if you only needed File System auditing!

To see if advanced audit policy settings are enabled, go to the following location:
Local Security Policy (secpol.msc): Local Policies > Security Options, and ensure the "Audit: force audit policy subcategory settings" is set to Enabled.

Active Directory Group Policy Management: Select the policy that you want to edit, and choose Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, and ensure the "Audit: force audit policy subcategory settings" is set to Enabled.

After configuring all of your audit settings to match the EventSentry tracking requirements, check your EventSentry settings to ensure that your Compliance Tracking package (Packages > Compliance Tracking > Complete Tracking, - you can make multiple custom packages here if you need) contains all of the tracking types that you need, and that the package is assigned to any of the machines that you need to track for these data types. If you needed to change any Compliance Tracking settings, please push the new configuration to all of your agents afterwards.

Testing the data collection
Next, you would want to generate some test data (such as failing to log on, creating/disabling/changing an account, and so forth) to verify that your tracking events are captured. If your test data does not appear in the corresponding Compliance pages of the web reports, you'd need to double-check the Windows event viewer (the Security log) of an affected machine to see if the necessary audit events are being generated.

Based on the type of compliance data that you are tracking, here are the events that you would need to see in the security log of the Windows event viewer:
Logon/Logoff tracking: 4624, 4625 (console logons) 4768, 4769, 4771, 4776 (network logons)
Process tracking: 4688, 4689
File Access tracking: 4663
Account Management: 4720, 4722, 4724, 4725, 4726, 4740, 4767
Policy Changes: 4719, 4713, 4739, 4704, 4705, 4717, 4718, 4706, 4707, 4716

Troubleshooting
It is very common to have policy conflicts that cause problems with the audit settings. For example, Policy A will have File System auditing set for Success and Failure, but Policy B will have File System auditing disabled, and both policies are applied to Server1 on your network. Depending on policy hierarchy, the File System auditing will either never work (if Policy B has "Enforced" set to Yes) or will only intermittently work (Policy A and Policy B have the same hierarchy and enforcement) as the conflicting policies re-apply their settings on top of one another every 10-30 minutes.

If you have Policy Change tracking enabled, you can see these policy conflicts in the Web Reports as event ID 4719 under Compliance > Policy Changes > Audit Policy. To look for the possible source of policy conflicts, you can run this command from an administrator-level command prompt on an affected machine:
gpresult /R /scope computer

Anything that appears in the "Applied Group Policy Objects" section is a policy that may have changed or disabled your auditing, and you'd need to examine each applied group policy object to ensure that if it manages audit settings, it is set up to meet your tracking requirements.

To see the currently-active audit settings of any machine, you can open an administrator-level command prompt on an affected machine and run:
auditpol /get /category:*