Group Policy Management Console incompatibility with Windows XP Service Pack 2

I may have missed the boat on Windows XP Service Pack 2 (SP2) reports (had a lot of other stuff going on to create this post), but I hope this helps someone having the same problem I was. I have been using Group Policy Management Console (GPMC) SP1 to configure policies that are deployed via Active Directory to our Windows XP and Windows Server 2003 machines. The settings are largely based on the Windows XP Security Guide and the Windows Server 2003 Security Guide When configuring settings for System Services (i.e. NT Services) in GPMC SP1, an incompatibility is created for a few (that I have found) specific services in SP2. This incompatibility stops, at least, Automatic Updates and the Windows Firewall services from starting even when set to automatically start. With XP SP2, the Automatic Updates service is required for access to Windows Update. Tracking this fact down alone took some time, because I hadn't seen it mentioned publicly anywhere. When you configure a Service in GPMC, it prompts you to define an Access Control List (ACL). An ACL you ask, Services don't have ACLs! I had no idea on this either until this incident, but yes Services have ACLs. Of course you can't look at the ACL on a service (e.g. by looking at the Properties on a Service and viewing the Security tab like on every other OS object with an ACL), you can only see the ACL in a binary value in the Registry. Here is the ACL for the Automatic Updates service in XP SP2: HKLM\SYSTEM\CurrentControlSet\Services\wuauserv\Security\Security How do you see these binary value ACLs in human readable format? I can't find anything to do this, and the only tool that allows you to set the ACL is GPMC. This MS Knowledge Base article has the details on this and the steps needed to configure your machine: How To Configure Group Policies to Set Security for System Services The article has one critical flaw though. It says the default ACL GPMC creates for your services contains the permission of Everyone - Full Control. Under XP SP2, this is not true. The default ACL looks like this: Administrator - Full Control Interactive - Read System - Full Control For Automatic Updates pre-SP2, this setting does not present a problem. Under SP2, it would appear that both the Automatic Updates and Windows Firewall services are configured to run as Local System, but in fact launch threads running as Network Service. What clue do I that this in fact happening? I happen to have failure audits on through Group Policy, and the Network Service account on the Object Name wuauserv was generating a failure that it didn't have Accesses: READ_CONTROL... As soon as you add Network Service - Read to the ACL for Automatic Updates, everything operates flawlessly. Windows Firewall would seem to operate the same way. If I hadn't turned on failure audits, Windows just silently fails the Automatic Updates service since it actually starts, then kills the process once the thread logging the failure can't read to service configuration. My main machine is in a Windows domain of course, so the Security Center would not normally be enabled to notify users that the Windows Firewall is disabled, but I enables this XP SP2 feature to look the screens. This took close to an entire day to debug. It halted my companies XP SP2 rollout until I figured out what was causing the problem with Windows Update. I just happened to stumble on the Windows Firewall having the same problem because we wanted to set that to Automatically start like Automatic Updates, and it started failing on my test machine in the domain. This is one of those gnarly problems that is just not obvious while testing on a single machine, you need all the pieces together to expose the issue. Nasty.