I recently discovered a problem with our Symantec Endpoint Protection software not starting it's services on our winxp and 2008 systems. I'm seeing a few errors, but event logs show a timeout waiting for response from the service. I get the following error in the event log: A timeout was reached (30000 milliseconds) while waiting for the Symantec Settings Manager service to connect. After working with symantec on this issue and digging into it on my own, I found that it seems to have started when our default domain policy was updated recently. I moved a server to an OU with inheritance blocked, and confirmed that SEP started working again. As far as I can tell, the only change made on the day the problem started was adding certificate services related policies. I'm not the one that added these, but he and I have both looked over the policies and can't see why it would be affecting SEP. Here is the portion of the policy that I believe was added the day this SEP problem began. Can anyone see something in this GPO, or think of something related to this that would cause SEP services to not start? Under Computer Configuration: Public Key Policies/Certificate Path Validation Settings/Trusted Publishers Policy Setting Trusted Publishers can be managed by: All administrators only Verify that certificate is not revoked when adding Disabled Verify that certificate has a valid time stamp when adding Disabled Public Key Policies/Trusted Root Certification Authorities Properties Policy Setting Allow users to select new root certification authorities (CAs) to trust Enabled Client computers can trust the following certificate stores Third-Party Root Certification Authorities and Enterprise Root Certification Authorities To perform certificate-based authentication of users and computers, CAs must meet the following criteria Registered in Active Directory only Edit: Removed sections of GPO reports that were unrelated to issue and/or not discussed in the thread.

It is very hard to give an exact answer to this, but I can possibly think of the setting below as a possible cause if the service uses certificate based authentication and has its own trust "To perform certificate-based authentication of users and computers, CAs must meet the following criteria" with the value "Registered in Active Directory only" /Hasain

Okay, I found the specific policy setting that seems to be causing this problem. : Trusted Publishers can be managed by: All administrators only I'm not sure exactly why this is affecting it, but when I change this setting to "Allow all administrators and users to manage user's own trusted publishers", symantec starts working again. Is there something that 2008 handles differently about this policy than 2008 R2? (Our Win7 and R2 systems were not affected by this problem, only 2008 and XP machines.)

Good, I just missed that one! The trusted publisher tells the system when and how to trust signed applications, scripts, drivers and installation packages. The reason it only affected XP and 2008 but not R2 and W7 might be related to 32/64 bit and differences in how the service/driver software is signed. /Hasain

Hmm, for XP that would definitely make sense, as they are all 32 bit systems where our W7 machines are all 64 bit, but I am certain that we have 64 bit 2008 servers in production that were affected by this issue. Still, it's probably somewhere in there.

W7 and 2008 R2 share the same requirements for driver signing in 64 bit and requires the use of Software Publishing Certificate that chains to an approved certification authority (CA) part of the Microsoft Cross-Certificates for Windows Kernel Mode Code Signing (http://go.microsoft.com/fwlink/?linkid=150525 while Windows Vista and 2008 allow components to be signed by a certificate from "any" trusted CA. /Hasain

The more restrictive requirements of R2 would lead me to expect 2008R2 and W7 machines to have problems, in this case they continued working normally, it was only the 2008 / xp systems affected.

It is actually the opposite, as the less restrictive requirement means the software can be signed by "any" trusted publisher in the local computer and the GPO prevented software from adding the vendors own certificates as trusted publisher. The special Microsoft Cross-Certificates for Windows Kernel Mode Code Signing required by R2 & W7 is not affected by the GPO setting because it is not a "normal" publisher certificate. /Hasain