Before you post: Your responses to these questions will help the community help you. Please complete this template if you’re asking a support question. Don’t forget to select tags to help index your topic!
Hi, I’m the creator of the referenced post above, just to confirm that I am still having the issue with Windows 10 22H1, I have not traced the root of the issue very thoroughly but hope someone will have an idea, thank you.
I just double checked against my windows machine and I am not seeing this problem. One thing I did not note on the other thread but very likely could be the culprit - I am running winlogbeat 7.15.1 in this windows machine. (I know we are not supposed to go beyond 7.10 on Elastic)
Try swapping out the winlogbeat.exe on a test machine to at least 7.15.1 to see if it solves the problem.
I would note that in some instances, winlogbeat versions newer than 7.10 may change default field names so keep an eye on that!
You mentioned you’re not running into this issue, are you also on the same build of Win 11 - 22H2?
I have machines that run both Windows 10 22H2 and Windows 11 22H2 , and the issue manifests ONLY in windows 11 build.
HI -
I am seeing the same issue with Workstations that are running Windows 11 22H2 OS build 22621.819. I currently have two workstations that are having this issue both on the same OS build version. Windows 11 21H2 Build 22000.1219 seem to be fine.
That’s what I get when I do a quick read - I do not currently have Win11 in my environment so I can’t test yet. Looking to change that.
There is a post (yours maybe) on the Elastic side where this issue resides - It is also placed in Graylog’s gitub - hopefully it will gain some traction!
Yes, at this point - this is pretty much over to folks at Elastic to come up with a version fix for Winlogbeat.
I reckon this will become quite widespread with the increased adoption of this build of Win11, as well as there are a lot many other SIEM solutions besides Graylog that use Winlogbeat to forward Event logs.
Hi everyone, I wish I had a better answer than this, but unfortunately, this is a known bug that exists within winlogbeat when collecting logs from Windows 11. A member of my team put in an issue with the Beats team for this specific issue, but we have not heard back around prioritization or timing of a fix. The only workaround we have found at this point is a painful one, switching to nxlog for windows event collection. I know this is an untenable solution, and we are working as hard as we can to get the Beats teams to tackle this issue ASAP. Also, if you are utilizing the Graylog Illuminate content for your Windows log processing, the swap of the agent would not require any further work on your part as Illuminate is built to work with both winlogbeat and nxlog.
Thanks @joe.gross , appreciate the update, and thanks for raising this with the beats team.
I’ll try switching to nxlog in the interim.
I have an Input Pipeline processor as well to rename the winlogbeatxxxxx fields, I guess I’ll have to build another pipeline processor for this. But that’s alright - will perhaps learn something new.