using SCCM 2012 in a LAB - Part 5. Enable the Endpoint Protection Role and configure Endpoint Protection settings

[gordonf]

When you run a RSOP on that machine, does it still say something about the update location?

Also what update location is show in the windowsupdate.log?

Resultant set of policy? Isn't this tool included in Group Policy Management (Group Policy Results)? I usually use GPO modelling because the Group Policy Results wizard usually fails due to my client firewall settings. But fair enough; thanks for the reminders of where to look. I'll update this post once I've rebuilt my System Center (4th time) and tried again.

 

In the container I put my client PCs in, I blocked inheritence and added only minimal GPOs (like default domain policy) to ensure I wasn't inheriting my production WSUS settings. The modelling didn't turn up any WSUS settings. WU would (and did) fail at that point because the client PCs and users in my test don't have internet access. Is the System Center client supposed to replace (or enhance) the WSUS client then?

 

More to come after I finish this rebuild, so no need to reply until I do.

[Peter van der Woude]

Is the System Center client supposed to replace (or enhance) the WSUS client then?

Nope, but it does tell it where and when to look for updates. For telling it where to look it uses local policies and that's why it's so important that their ain't any GPO's as they will overwrite local policies..

[gordonf]

When you run a RSOP on that machine, does it still say something about the update location?

Also what update location is show in the windowsupdate.log?

I'll delete the last post and replace it with this one.

 

RSoP shows me a WSUS source of my System Center server, and no other Windows Update settings. When I compare this with the GPO Modelling output, the WSUS source is the only setting difference, and if I recall properly, this doesn't take any effect unless "Configure Automatic Updates" is also enabled. So it seems the SC client is changing the WU source server but not enabling it.

 

I've attached an attempt at checking for definition updates from windowsupdate.log. It does not reference my System Center server at all, except at the very beginning when it refers to policy changes. I did set "Configure Automatic Updates" by hand in this instance, to see what would happen. It appears WU (and the Forefront client by extension) is ignoring the WU setting and trying to go straight to Microsoft for its updates.

 

I suppose I could approve these updates through WSUS instead of System Center, set up an auto-approve schedule in WSUS, and use System Center to manage the clients only. That runs contrary to how this instruction set is supposed to work though.

 

(Update) The log shows it can't get a certain .cab file from Microsoft. This WU / SC client does not (nor should it) have internet access. I thought this was what WU self-update was for.

wulog.txt

[gordonf]

Now I'm confused. For a while I noted that the FEP client wasn't obtaining updates and it seemed to be trying to fetch them from Microsoft Update and the MS malware center when I tried a manual update. This would fail because I have internet access blocked on desktops by default. But if I left the clients alone for a while, they'd come up as updated and running.

 

Is there no manual process to update FEP then, if the only update source selected is the System Center server?

[anyweb]

This would fail because I have internet access blocked on desktops by default. But if I left the clients alone for a while, they'd come up as updated and running.

 

sounds like they are working just fine then !

[gordonf]

I'm going to have to keep an eye (that is read logs) on my test PCs overnight. My web filter log shows they're still trying to access Windows Update on the internet (and are failing due to filter rules) when left on their own. If I open up access to windowsupdate.com and update.microsoft.com they can auto-update or hand-update. This happens even though I only have the one checkbox (obtain updates from SCCM) turned on. The client does say it's using my custom malware policy and not going to the default malware policy (help / about shows me the applied policy).

 

If you get a chance, would you or someone else see if this problem is reproducible? My test environment has a SCCM server that can access the internet but has clients that cannot, or at least cannot unless an authorized domain user is logged on. I happen to use a Barracuda web filter that authenticates against Active Directory, but you need only isolate your client PCs from the internet to reproduce this problem, say on a subnet or VLAN that can't route out to the internet but can still see the SCCM server. The environment is otherwise identical to this lab.

 

I'm going to go out on a limb and suggest that the lab environment in these examples permits internet access from the servers and from client PCs by default. Our environment happens to restrict internet access per-user, but other environments could just as easily block internet access from desktops completely, while still permitting it from servers. In our production environment, WSUS manages updates for PCs that don't have internet access, and I suppose I could configure WSUS in parallel with SCCM to deliver definition updates in my case.

 

[12 DEC] My test PCs were left on overnight and the windowsupdate.log clearly shows repeated (and failed) attempts to auto-update via windowsupdate.com and update.microsoft.com. I just created an auto-approval rule in WSUS instead of SCCM for Forefront 2010 updates and changed the malware policy to update from WSUS alone. This seems to have taken effect as the update checks (and windowsupdate.log) show me successful updates coming from WSUS without my input. Hand-update seems to work, too.

 

[12 DEC] Reproducing this might be as simple as removing the IP Default Gateway setting from your SCCM client PCs, if the SCCM server, domain controllers (DNS) and client PCs share the same subnet. You also need not leave the clients turned off for an extended period; a FEP client might be up to date but still fail to retrieve new updates and you'll see the errors in windowsupdate.log.

[anyweb]

well i guess i can try and repro, by keeping my clients powered off for a day or so, then sync the sccm box via internet, then power down my NAT, then power up the client.... i'll see what i can do

[P.A.]

Hi together,

i got problems with the automatic deployment rule. i get the error code 0X87D20417 with the following information: automatic deployment rule download failed. when i start the download of a forefront update manualy i works great and places the update in the selected folder.

Can anyone give my a little bit help.

in the ruleengine.log i got the following error: Failed to download the update from internet. Error = 5 and in the next line Failed to download contentID 16791605 for UpdateID 16792808. Error code = 5.

Brgds, Jan

 

Hi...

First contribution here... I hope will help!

I faced the same problem and temporary solved by granting Full Control permission to Everyone on the sources share.

Of course it's not acceptable in production environment but perhaps will help finding a better solution.

Regards,

Pierre-André

[vitalstatistix]

Hi Anyweb,

Would you happen to know the query statement for all FEP client workstations? I am trying to make a collection based on this.

 

Many Thanks

[gordonf]

I faced the same problem and temporary solved by granting Full Control permission to Everyone on the sources share.

Of course it's not acceptable in production environment but perhaps will help finding a better solution.

 

Way back in the earlier days of NT Server, I was taught to use permissions on the file system instead of on the share so I had more granular control over the permissions. Granting Everyone (or Authenticated Users) Full Control over the share should be OK, as long as the NTFS permissions are not like that. In my case I set this permissions scheme up:

 

SYSTEM and BUILTIN\Administrators: Full Control

BUILTIN\Users and [domain]\Domain Computers: Read and Execute (Also likely replacing with Authenticated Users: Read and Execute would also work)

 

This allowed automatic download to work. I don't believe this had a bearing on my other problem (client auto-updates only working via WSUS) as my windowsupdate.log keps telling me it was trying to update from the internet instead of from System Center. Though I suppose it's possible System Center-based updates use a different API than the Windows Update API; I was told to check windowsupdate.log.

 

(About that last bit: I had even enabled auditing on the share to determine if I had a permissions problem, and of course I had failure auditing turned on for object access. I didn't see any failure audits unless I deliberately tried to cause one.)