I've done lots of reading and research about this but I still have some questions about how WSUS and SCCM interact.  There's lots of information out there but it's proving difficult for me to put it all together and understand all the pieces to the puzzle.  SCCM 2012 was recently implemented at my organization.  I wasn't involved in the initial setup / deployment but the person primarily responsible has taken a different position within the organization so I am digging into SCCM in order to help solve a few issues that have surfaced and understand how all of this works.  

The initial intent was to continue using WSUS for MS software / security updates, but I think an SCCM ADR for SCEP definition updates was not working due to domain group policy overriding the local group policy that is created by the SCCM client when the software updates client agent is enabled - the policy that sets the "specify intranet software updates location."  (Actually, since the existing WSUS was used as the SCCM SUP, this probably shouldn't have posed a problem except that the domain policy for specifying the intranet software updates location was not using the server's FQDN.  I'm not certain this is why the clients weren't getting their SCEP definition updates prior to the domain group policy being set to "not configured" but I suspect it may have been.)  I know that it would have been possible to deploy the SCEP definition updates via the standalone WSUS, but I think it was preferred to use SCCM.  In order to get the ADR for SCEP definition updates working, the domain group policy that specifics the intranet software updates location was set to "not configured" in all GPOs where it was configured.  The other WSUS-related group policies (varying by OU) were left in place.  These include things like whether the updates are just downloaded, whether the install is scheduled, etc. 

Problems / questions:

It seems that some computers are still getting WSUS notifications for updates that were approved on the standalone WSUS server (now the SUP) prior to the SCCM deployment but hadn't been installed yet.  Updates are no longer being approved in the WSUS console on the SUP.  Additionally, it looks like WSUS is also installed on the primary SCCM site server with all updates being set to automatically approved inside the WSUS console there.  Local group policy on the SCCM clients does have the SUP (old standalone WSUS server) configured as the specify intranet software updates location.  I tried modifying domain group policy such that "Configure Automatic Updates" was disabled.  I ran gpupdate on one of the computers to which that GPO was applicable.  I stopped wuauserv and bits, cleared the softwaredistribution folder, and restarted both services.  I then initiated a "software updates scan cycle" from the Configuration Manager applet in the control panel.  This caused the outstanding approved updates to be downloaded and a notification to appear on the computer to which I was logged on as an admin.  Should this be the case?  I am guessing that if I install all of these updates that were approved on WSUS prior to SCCM implementation and reboot the system, I will no longer get the old style WSUS notifications (which I don't want to get) but I'd like to understand how all of this works and why I am seeing the behavior that I am.  And should I set "configure automatic updates" to disabled in all GPOs where it is enabled?  I've read that if you leave it enabled, in certain circumstances a WSUS notification and SCCM notification may occur when software updates are deployed.  Plus, wouldn't leaving this enabled cause updates detection to continue occurring at the default 22-hour interval since the SCCM clients are pointed to the SUP for the "specify intranet software updates location" and potentially cause issues since the SUP is the old standalone WSUS server?

Is there any reason that the WSUS installation on the primary SCCM site server should be configured to automatically approve updates?  Since it is not the SUP, should it even be syncing with MS update and isn't the automatic approval of updates just causing them to be downloaded unnecessarily consuming considerable disk space?

With SCCM and software update groups (as opposed to WSUS), it is my understanding that aside from the ability to create software update groups and use ADRs, "sofware updates" are "pushed" out much like SCCM software deployments that do not use the SCCM software updates client agent.  Is that correct?  Does the default polling interval of 60 minutes still apply for policy changes that might include a new software updates deployment with a deadline or available time?

With regard to the software updates scan cycle...  Is that primarily for reporting which of any applicable software updates are required on a given system or is that actually checking to see whether any deployments exist and triggering them if the deadline has passed or making them available if that is applicable?  (From what I've read the software deployment evaluation cycle is the one that checks for existing deployments and ensures that systems are still in compliance whereas the software updates scan schedule seemingly just reports the state of any applicable software updates back to SCCM.  Should the default software updates scan cycle of 7 days be changed?

Lastly, the ADR for SCEP definition updates isn't filtered by product.  It is only filtered by released or revised within the last one day and any updates that have NOT been superseded.  The deployment is enabled after the rule is run, the deployment evaluation schedule is daily, the deployment schedule is "as soon as possible" and the deployment is targeted to the "All Desktops and Server Clients" collection.  I am not seeing how this would prevent other updates released within the last day from being installed since the SUP (and the WSUS instance installed on the primary site server that I don't think is being used) are configured to download updates for products other than just SCEP.  Any insights on this?

Any insights on all of these concerns and questions would be appreciated!  Like I said, I have spent lots of time reading and researching but am still struggling to put all of the pieces of the puzzle together.

• Edited by ModeratelyGeeky Sunday, November 03, 2013 3:53 AM Typo

Just noting that I think that even though I had run gpupdate, I don't think the group policy that set "configure automatic updates" to disabled had taken effect yet.  It also seems like the old style WSUS notification is gone.  As expected based on the properties of applicable existing SCCM software update deployments targeted to this computer, there are updates "available" to be installed in the Software Center.  Many of my other questions are still applicable, but I am thinking that what I need to do for starters is to set "configure automatic updates" to disabled in any GPOs where it is currently enabled in order to exclusively use SCCM's software update client agent for deploying updates.  I would welcome confirmation that this is the correct course of action.

You should probably configure your GPO to NOT CONFIGURED instead of disabled, this way the local policies will 'WIN' and SCCM takes care of your updates.

• Proposed as answer by narcoticoo 18 hours 17 minutes ago

I'd recommend keeping "configure automatic updates" disabled to ensure there is no autonomous Windows Update Agent activity.  The only reason for that setting to be on is for updating the WUAgent, which Jason Sandys has solved in a cleaver way:

http://blog.configmgrftw.com/?p=687

 

I hope that helps,

Nash