In each log source switch the event log protocol from MSEVEN6 to MSEVEN. The error you are getting looks like your user doesn't have access to the event log. Try switching this first and see if that helps. If not let me know.

On top of Jamie's comment.

Question 1: Is this log source configured using the FQDN (thlrational.rtp.raleigh.ibm.com versus the hostname thlrational)?
Make sure your log source is using the hostname (or IP) and not an FQDN. This is a good test to make sure the hostname resolved, but we've seen issues where the FQDN in the Log Source Identifier field causes issues like the error you are reporting. DNS configuration changes can cause these types of issues.

Question 2: If you are using a hostname, does it resolve or can you ping it? Another option is to use the IP as a test in the log source?

If the tests pass and you are still having issues when using a direct IP address, I would look at permissions. A good test is to attempt to remotely open the Event Viewer on the remote Windows host that the agent is trying to poll. You can use the "Connect to Another Computer" option and if you can connect, it helps rule out Windows changes. It could also be caused by a service being stopped.

I wrote a technical note on this topic here that might help, but my guess is that something isn't resolving properly or there are permission changes: WinCollect error code: 0x0005 Access denied

Take a look at what Jamie and I posted and let us know if either of these solutions helped.

Thanks Jamie and Jonathan for your input. Jamie's solution of switching the log protocol from MSEVEN6 to MSEVEN has resolved this issue. This appears to me to be a defect introduced in this WinCollect upgrade. This test deployment has existed for years and we've upgraded WinCollect several times since it was first installed. We went from 7.2.5 to 7.2.7 WinCollect skipping 7.2.6 so maybe this would have happened with a 7.2.6 upgrade. Is there an explanation of this these two log protocols somewhere. I didn't see them mention in the WinCollect users guide I have. I checked the servers and there had been no Windows update applied in the time frame the event logs stopped, so nothing on the OS changed. I'd like to understand these protocols and why one works different from the other. Jonanthan - We switched from the hostname log source identifier to the FQDN because we had conflicts using the hostname where several Agents were associated with a single Log Source on QRadar. Also I did read you technote prior to posting this in the forum.

In 7.2.6 we introduced MSEVEN6 as the default protocol for collecting standard event logs. In 7.2.5 MSEVEN was the standard protocol. MSEVEN is an old protocol and Microsoft replaced it with MSEVEN6. One of the big difference between the two is that MSEVEN does not support xpath queries. In 7.2.5 we used MSEVEN for standard event logs queries and MSEVEN6 for xpath queries. In 7.2.6 we moved to MSEVEN6 for all standard queries. MSEVEN6 does a better job of getting the event log data (i.e. message rendering) whereas MSEVEN we need to perform extra steps to get the message which doesn't always give us the information we need. To figure out why it didn't work in your environment we would need to see the logs. We have been running both protocols in our test lab on all supported OS's with no issue.

Jamie - What logs do you need to see? We have a production deployment waiting to roll WinCollect 7.2.7 out to with ~400 WinCollect agents included. With this issue we won't be doing that until the cause for this issue is known. Manually updating those Log Sources for then log protocol log protocol change isn't viable and there's no guarantee that will work for all of them.