If an existing domain policy is already managing logon auditing, this may cause the Log All Logon and Logoff policy to fail.  There are two types of observable failures.  The first is where all the remotes in the environment fail the monitor, then they flip to success and auto-close, only to reopen about 90 minutes later.  The other behavior is when they all fail and stay failed.   

For either condition, here's what is occurring: when a Third Wall monitor finds a failure state, it throws a ticket and runs an auto-fix on the remote.  The next time the monitor runs, it sees the settings set properly and closes the ticket.

An issue occurs when the existing domain policy changes those values set by Third Wall.  The results you see are determined by the domain's group policy refresh interval.  When set to 90 minutes, you'll see the first type of observable failure where tickets come in, auto-close then reappear 90 minutes later.  The refresh time for local policies is much faster and will cause the second type of observable failure - where your remotes all fail the monitor and the monitor stays failed.  To fix either condition, you'll need to find and remove the conflicting domain or local policy.

Here are the Group Policy paths to the policies that may conflict with your Third Wall settings.  Please ensure all polices here are set to 'Not Configured':

Computer Config -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies 

Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff

Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Management

Once the domain is no longer altering your Third Wall settings, you should see any open tickets for this policy auto-close within the next five minutes.

If you are unsure this failure is a result of a conflicting domain or local policy, the following test will answer that question.

From an Administrative DOS shell, run these commands:

auditpol /get /subcategory:"logon"

It will likely tell you there’s no auditing.  Let’s change that with this command:

auditpol /set /subcategory:"logon" /success:enable /failure:enable

For certainty, run the /get command again to make sure a change happened:

auditpol /get /subcategory:"logon"

Now, do a Group Policy refresh:

Gpupdate /force

…then quickly check the current state again:

auditpol /get /subcategory:"logon"

If a change is observed after running gpupdate then you've confirmed a policy conflict is at work here.

Here are all the commands used by Third Wall on the monitor run:

Auditpol /get /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}"

Auditpol /get /subcategory:"{0CCE9216-69AE-11D9-BED3-505054503030}"

Auditpol /get /subcategory:"{0CCE921C-69AE-11D9-BED3-505054503030}"

And the resolution script is here:

auditpol /set /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

auditpol /set /subcategory:"{0CCE9216-69AE-11D9-BED3-505054503030}" /success:enable /failure:disable

auditpol /set /subcategory:"{0CCE921C-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

Note:  The instructions here will work in most environments but there are some which will need additional steps.  These two links will help you to move forward if you're sure the audit policies are disabled on the Domain yet are continuing to be changed on the endpoints:

https://windowsexplored.com/2014/01/31/why-arent-my-windows-audit-policies-working/ 

https://thirdwallhelp.freshdesk.com/a/solutions/articles/43000586085