gordonf

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

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.

Bring up your GPO and browse to Policies, Windows Settings, Security Settings, Restricted Groups and create Administrators. Add members as appropriate, including global groups from your domain. This will overwrite the previous BUILTINAdministrators local group, so you should check the group first and make sure you have its defaults copied into your GPO. I just cheated and added ClientInstall to the Domain Admins global group for testing, but in practice I wouldn't want to do that. I haven't had to relax any settings. Turns out I had to enable the file and printer sharing exception and remote management exception using Group Policy. As XP doesn't have the advanced firewall that Vista and 7 do, the settings I had to enable were in the Administrative Templates, under Network, Windows Firewall. For Vista and 7 I was able to use the Advanced settings to enable the groups of settings for File sharing and for WMI.

For licensing reasons I have to put the database on a different server running SQL 2008 R2 Standard. Sure I could run an evaluation version on a release candidate installation but this has to go live sooner or later. In any case I have to put the database there, and for consistency I also put the WSUS database there. When I installed SCCM it added my SQL server as one of the SCCM servers, with the database, component server and site system roles. It also added a firewall exception for port 4022; the port exception for SQL itself appeared when I first installed SQL. For some reason the Hierarchy Manager continues to complain that said ports aren't "active." I can telnet to both ports from a remote computer. Are there any caveats to putting the database on a different server that I've missed? This is going to come up because not everyone has unlimited processor licenses for SQL Server, and SQL Express may only be used on secondary sites. [16 DEC] I can deploy SCCM and WSUS with an external SQL server without any serious difficulty. I avoided the firewall complaints by creating exceptions on the SCCM server as well as on the SQL server. I managed to resolve my other non-SQL-related problems through other means, as it seems the location of the database makes no difference to those.

Thanks for responding, but I had tried disabling my WSUS-related group policy objects for the container where my test PCs are and I get the same result. I did gupdate /force and checked the Policy reg key to make sure the changes took effect. I'll keep checking. Are there any logs that I've missed that are related to this? The System event log tells me about setting changes, and it reports update sources that fail (like Windows Update and MSMC) when they're enabled. This is the third time, actually, that I've gotten through to this step. Twice I've gotten this result; the third time I messed up something on SQL and broke it completely but I know what happened there. Speaking of SQL, I have a different problem but I'll raise that in Part 1.

I've only gotten automated definition updates working by selecting WSUS as a source and specifying that source in Group Policy; leaving only "Configuration Manager" enabled consistently gives me quick "you're out of date" responses when I click the Update button. I do have the automatic deployment rule set up and it did download updates to the share I specified -- following the example in Step 4 to the letter except calling the folder "Forefront" instead of "Endpoint." Am I missing a permission or some other setting here? The logs on the FEP client don't tell me anything. The FEP client had Windows Update and the MS Malware Center as sources (HKLM\Software\Policies\Microsoft\Microsoft Antimalware\Signature Updates\FallbackOrder). This changed to "InternalDefinitionUpdateServer" when I turned on both Config Manager and WSUS as sources. What's the point of having System Center download and approve the updates when WSUS can auto-approve the definition updates as well, and auto-update from System Center seems to do nothing?

I had better luck by setting the intranet zone instead of the trusted sites zone on a "hardened" IE setup. Windows Server since 2003 has this hardened mode for Internet Explorer that disables the majority of scripting and add-ons if you're foolhardy enough to go web surfing on your production server. IE8 and IE9 have stricter controls on "Trusted Sites" than previous versions; they're closer to the "Internet Zone" settings from IE6. To make Application Center work I instead added my AD domain (*.example.com) to my Intranet Zone using Group Policy, rather than use the "Add site to Trusted Sites" switch. This works for any other local web servers, even non-Microsoft ones, that require scripting, pop-ups and so on to work.