Windows Firewall logging through GPO keeps resetting to "Not configured"

I am trying to set up "Windows Firewall With Advanced Security" (WFwAS) through GPO.
My goal is to have WFwAS automatically log dropped packets for all Domain Controllers.

I go to: "Computer Configuration -> Policies -> Windows Settings -> Security -> WFwAS -> WFwAS -> choose  Windows Firewall Properties -> Logging -> Customize" and untick "Not configured"
That auto fills the name for the Firewall log file as:
I also choose to log dropped packets, but to not log successful connections.

When I OK my way out, and then og back in again - the "Notconfigured" checkbox is ticked...
Even though I unticked it a few Seconds ago, it ticks itself back!
No logging takes place on the servers affected by the GPO, so the GPO is not making the DC's log.
Other settings in the same GPO do take effect on the DC's.

I see several People have asked the same questions around the Internet, but no one has gotten an answer.

Any suggestions?
Rather StayanoAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Why are you sure there are packets being dropped? Please provoque that by setting up some deny rule (take port 3389 from some test IP) and try to connect using rdp (3389) from that IP, see if it's denied and logged. Works here.
Hello ThereSystem AdministratorCommented:
Yes, it's a known issue with no stable resolution. Every single administrator solved this by different way.

Some suggestions from other discussions:
1. Generally, C:\Windows\System32\LogFiles\Firewall\firewall.log has the following permission settings:
BUILTIN\Network Configuration Operators:(F)
Please make sure MPSSvc (Windows Firewall service) has Full Control on this file. -> Adding the NT SERVICE\MPSSVC account with Full Controll permissions on the C:\Windows\System32\LogFiles\Firewall folder and restarting the server solved my problem.

2. It repaired itself after moving the log location somewhere else and back again to the original location. didn't it happen after promotign the server to DC?

3. You can also use AUDITPOL command line tool or the Advanced Audit Policy GPO/SECPOL.MSC settings to enable Object Access/Filtering Platform Connection or Filtering Platform Packet Drop and you will see the log entries in normal Security log. This is actually a very nice feature.

4. The settings should be saved under the following registry on the client:
This issue can be caused due to the registry settings remained although the GPO is removed or unlinked, please check it on your side. You can change or remove the registry keys on one client as a test, if it works, you can deploy the changes to multiple machines via group policy.

5. It appears that the events are actually put in the Windows Event Log (security) instead, and they fill it up, pronto!
You need to specify in your GPO not to log in the Windows Event Log under Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Configuration/Object Access

6. However there is another policy under Administrative Templates/Network/Network Connections/Windows Firewall/Domain Profile (or Standard Profile) which over rides the "Security Settings" object. Check that "Allow Logging" under the Administrative templates to see if there is a setting configured, because this over rides the "Security Settings" object.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Known issue? Never seen it and we do log dropped packets since years (vista/7/8.x/10/servers...). We configure the logging path (default) using GPOs.
Make Network Traffic Fast and Furious with SD-WAN

Software-defined WAN (SD-WAN) is a technology that determines the most effective way to route traffic to and from datacenter sites. Register for the webinar today to learn how your business can benefit from SD-WAN!

Rather StayanoAuthor Commented:
Seems that adding rights to the service account that runs the Firewall service did the trick.
A restart was indeed neccecary!
...and what again was the "known issue", @Hello There?
Rather StayanoAuthor Commented:
Hi there McKnife :-)
The GPO was unable to create the "pfirewall.log" file and start logging to it.
The solution was to give the "NT SERVICE\MPSSVC" full control on the "C:\Windows\System32\LogFiles\Firewall" folder and give the server a reboot.
The GPO was then able to create the pfirewall.log file and log to its hearts content :-)

Let me add that configuring WFwAS locally on the server never yielded any problems - it seems that out of the box there are enough permissions on the "Firewall" folder to configure WFwAS logging through the local console, but not through GPO.

Hope this explains the problem/solution better :-)
itavdelingen, I don't need the solution to be explained. I was wondering what "known problem" he talked about.
The folder C:\Windows\System32\LogFiles\Firewall is accessible by NT SERVICE\MpsSvc with full permissions by default, by the way - I wonder why that would not be true for you. Anyway, I still hope "hello there" could clarify what he meant - just interested :-)
Rather StayanoAuthor Commented:
Apparently the security rights were not present/working on my server (Domain Controller) - otherwise I would not have had the problem to begin with. Many others have reported the same problem, but I do not know what, if anything at all, solved it for them.
Hello ThereSystem AdministratorCommented:
For your explanation:
Known Issue - A fault or defect in a system that has been documented, but not yet fixed.

My words: "It's a known issue with no stable resolution (no approved official fix). Every single administrator solved this by different way."
While it will not be a known issue, this issue will not exist anymore. But now, it exists, many people haven't solved this yet, that's why I marked it as known issue. I said 'known' because there are lots of discussions about it - lots of people have issues with this.
Look, you seem to get me wrong, both.

I am a security administrator. If there is a known issue with the windows firewall (whatever type of issue it may be), I like to know about it.
If you, "hello there" know about a known issue, be so kind to tell me about it.
If this known issue is about access permissions to that logfile/logfile folder, then tell me.

I have not seen any systems yet that have wrong access permissions on that very file / folder, but I am interested to learn about the conditions when this happened to you or, if it did not happen to yourself, even links to threads that you have if you don't mind to share them in one or two lines - that is all.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.