Our Windows server 2008 R2 domain controller does not appear to be logging anything into the windows firewall log: c:\windows\system32\logfiles\firewall\pfirewall.log. The file is always blank. Every 2003 server and 2008 R2 non-dc work fine. I'm a little stumped. The firewalls are configured via GPO's and appear to be applied ok. I compared the 2003 and 2008 configuration and did notice one discrepancy: The 2003 windows firewall service runs as the local system account. It's effective permissions to the pfirewall.log file is "full control" However, the 2008 firewall service runs as "LOCAL SERVICE". This account has read-only permissions to the pfirewall.log file. I haven't changed anything as this is a production server. I was hoping for some guidance before I start changing default settings. Any ideas why the pfirewall.log file is always blank? Thanks!

LocalService account: The LocalService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has minimum privileges on the local computer and presents anonymous credentials on the network. This account can be specified in a call to the CreateService function. Note that this account does not have a password, so any password information that you provide in this call is ignored. While the security subsystem localizes this account name, the SCM does not support localized names. Therefore, you will receive a localized name for this account from the LookupAccountSid function, but the name of the account must be NT AUTHORITY\LocalService when you call CreateService , regardless of the locale, or unexpected results can occur. SYSTEM account: The system account is used by the operating system and by services that run under Windows. There are many services and processes within Windows that need the capability to log on internally (for example during a Windows installation). The system account was designed for that purpose; it is an internal account, does not show up in User Manager, cannot be added to any groups, and cannot have user rights assigned to it. On the other hand, the system account does show up on an NTFS volume in File Manager in the Permissions portion of the Security menu. By default, the system account is granted full control to all files on an NTFS volume. Here the system account has the same functional privileges as the administrator account. NOTE: Granting either account Administrators group file permissions does not implicitly give permission to the system account. The system account's permissions can be removed from a file but it is not recommended. Please try to give the LocalService account full control on the file and check if this solve the problem or not. There will not be a negative affect on the server if you will proceed like that so don't worry. This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

Hi, Generally, C:\Windows\System32\LogFiles\Firewall\firewall.log has the following permission settings: NT SERVICE\MpsSvc:(F) NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) BUILTIN\Network Configuration Operators:(F) Please make sure MPSSvc (Windows Firewall service) has Full Control on this file. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

a) we had similar problem - 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? b) 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. ondrej.