SCEP 2012 Client settings currently have "Install Endpoint Protection client on computers" set to Yes. This is deployed to quite a few machines. The client installs just fine, everything updates, and we are set. In the Endpoint Protection Agent log shows periodic checks for if SCEP needs to be installed. Which technically isn't an issue and eventually I'll flip this setting to No and leave it Manage only.

However, around the times it checks the client I notice a GP Update kicking off. Does anyone know if installing SCEP or having the client check to see if it is installed kicks off a GP Update?

• Edited by Shambler 10 hours 9 minutes ago

I think the behavior you're seeing is triggered when EP (re)applies its policy.

In the EndpointProtectionAgent.log, you'll see a line where ConfigSecurityPolicy.exe is called to (re)apply the policy xml file.

This triggers group policy client activity which puts the settings in C:\Windows\System32\GroupPolicy\Machine\Registry.pol (open Registry.pol with Notepad and you'll see the policy entries)

From there, they are transferred into the registry.

Just to clear my head: So does this just apply the SCEP Policy settings and re-apply the current GP settings? Or does it actually reach out and start a GP Update?

As far as I know, it's limited to SCEP policy and doesn't have anything to do with overall GP Update settings or schedules.

You can run

"c:\Program Files\Microsoft Security Client\ConfigSecurityPolicy.exe" C:\Windows\CCM\EPAMPolicy.xml

manually from an elevated command prompt if you want to study the behavior.

Maybe someone from Microsoft will weigh in and confirm.

Well crap. I kicked off what you listed above and it does indeed start a GP Update. At least that is what I'm seeing on my test system. Going to run this on a few more and will report back shortly.

Anyone else see this or have any info?

Thanks Kevin!

What are you seeing as evidence that a GP Update is happening?

ConfigSecurityPolicy.exe will cause activity by the Group Policy Client service, and will generate a Group Policy event in the System log, but that shouldn't mean that the equivalent of gpupdate is running.

For example, in my System log today I see two events for a regular group policy update that runs every 90 minutes (one event for user, one for computer). At a completely different time (at least 30 minutes later), I have another GP event related to the ConfigSecurityPolicy.exe activity. The two don't seem to be related.

• Edited by KevinMJohnston 8 hours 58 minutes ago

I see activity in the Group Policy Operational Log.

I'm going to do a side by side comparison between what I see when running that configsecuritypolicy.exe and running a gpupdate /force. But so far, they look extremely similar. Both making calls to the DC, checking specific gp ini files in sysvol, etc.

Interesting. I didn't think to check that specific log. I do see activity in there for other GP objects besides SCEP. Perhaps it runs the equivalent of gpupdate /target:computer

I don't think I see any user items in there.

This reminds me of an issue I ran into before. Take the scenario of a domain joined machine that is currently connecting via the Internet. You have an IBCM server set up, so Internet connected machines are able to receive policy and software. You would think that would include changes to SCEP policy too. However, if you make a change to SCEP policy and then try to update policy on the client, it won't actually apply the SCEP policy changes until it's back on the domain. I guess that's because whatever ConfigSecurityPolicy.exe is doing requires a connection to be made to a domain controller and even though the SCEP content is stored locally in an XML file, it can't finish the process of getting it into Registry.pol and then into the Registry itself until it can connect to the DC again.

Seems like it would make more sense to just import it directly into the Registry and bypass the GP client entirely. Anyway, I don't mean to hijack the thread but it would be nice to see Microsoft clarify exactly what's going on in both cases :-)

• Edited by KevinMJohnston 8 hours 21 minutes ago

After a little poking around, it looks to be processing just computer policy like you said. I'll still double check that this week.

And no need to apologize. I welcome extra details and tidbits like that. I'm not finding a whole lot of deep diving on the net regarding SCEP 2012. And TechNet/MSDN are almost worthless when it comes to finding out info like this.

I may spend a little time to see if I can find out exactly what happens via ProcMon.