Windows 7 Professional SP1 PL, domain-joined.
Since 2014-06-12, several of our computers (but definitely not all, not yet at least) embraced a problem with printer sharing, which was quickly explained as Windows Firewall service being offline.
Attempts to start Windows Firewall service ends with failure and error no. 5 ("Access denied") returned by the service.
Windows EventLog shows that the issue began at the above date and is recurring every morning at startup - or at any manual service launch attempt.
By courtesy of Google, we quickly identified the problem has something to do with accessing subkeys of following registry key:
There are several websites that suggest the problem is caused by insufficient access to some significant subkeys of this key for
NT Service\MpsSvc. Most authoritative source seems to be the Microsoft Knowledge Base article KB943996. While this article is about Windows Vista, it provides link to a more general website with Firewall FixIt Tool.
We have tried to apply the suggestions found in the knowledge base and came up with following results:
- We were able to verify that only
\Epochsubkey was missing the advised ACL set.
- We were unable to add
NT Service\MpsSvcmanually, as Windows was not able to find such user. We did check proper search scope (local computer) and did enable all object types. We have estabilished, that this account can be properly found and used on healthy machines.
- The FixIt tool did properly assign the rights to
NT Service\MpsSvc(!), but it did not solve the problem, which was admitted even by Fixit tool itself in the post-run test.
We have verified that the above registry key is the key to our issue. We did it by assigning inheritable
Full Access rights to
Everyone - with these rights, Windows Firewall service did start properly. This however doesn't solve our problem due to obvious security issues. What we need is to fix it correctly.
During our further investigation, we've attempted to monitor the above key using Sysinternals Process Monitor. We have established, that the Windows Firewall service fails after
ACCESS DENIED upon
\Epoch2 subkey, which we did not know of.
regedit.exe with account that has Local Administrator privileges, we were unable to see that subkey. Yet that key was clearly visible:
- on healthy machines, using same privileges,
- on affected machines, running
psExec -s -i regedit.exe)
The accounts enlisted in ACL on
Epoch2 subkey are also missing
NT Service\MpsSvc entry. On affected machine, these are:
On healthy/unaffected machine the entries properly run as follows:
Since we're unable to manually assign these permissions, we're kind of lost at what we can do next.
Range and significance
The issue has been reported in few areas only, but affects circa 50% of computers in the first area we were able to verify in detail.
The issue may likely affect other areas too. Since it requires user to interact with affected Windows features (printing on printer shared by affected computer), user reports will likely be rare when compared to the possible extent of the issue.
While shared printers are not common by now, that feature is not a real issue. But the downed firewall is definitely a problem that needs to be solved.
One: we have no idea on what could have possibly caused such issue.
All computers (both affected and healthy) are run within controlled software installation environment. Users have no administrative privileges, software is automatically deployed via Wpkg. All above computers have identical software profile - which means that same software products have been installed. These computers are even identical in hardware terms, all have been acquired in a single batch and have consecutive serial numbers.
Our primary suspicion, related to common time of issue occurence, is some selective issue with one of the recent 2014-06-10 Windows Updates. We were unfortunately totally unable to reproduce this issue in our time-snapshotted virtual test machines, so that suspicion is kind of thin.
Finding source is important though, both for fixing it and avoiding it in future.
Two: we have no satisfactory idea how to fix the problem. We're thinking about:
- adding rights for
MpsSvcuser through some commandline ACL tool, though this would take a lot of time and manforce, were the problem begin to spread;
- perhaps to deploy these rights via GPO (GPO would accept any user here), but we would first have to correctly establish that the
\Epoch2rights are the only ones missing.
Before attempting anything drastic domain-wide, we'd be grateful to hear some comments. Most of all, previous experiences, ideas for solution and ideas on the possible source of the issue.
Perhaps someone else had that issue recently?