Our primary SCCM admin said that a while back the child primary sites at our branch locations were de-centralized from the central site by removing the WSUS service due to bandwidth issues from downloading packages to the field sites. Now there is a push to centralize everything again to be able to get inventory, metering, and auditing services running from the central site to all field sites. However, our IT Director doesn't want WSUS services running at this time, and would like updates to continue to be pushed from the field sites. Our SCCM admin says though that he doesn't think it's possible to centralize all of our sites to perform only centralized reporting without WSUS being installed on the Central Site Server. Here is his entry from an email we are corresponding on: Well here's the thing with System Center, site settings propagate from the Central Site to the Child Primary sites. So any configuration settings in the Central Site will be enforced to Child Primary sites if the Child site points to the Central Site as "Parent". Which includes settings (such as Software metering, Reporting, etc). So we have uninstalled WSUS from the Central Site, which could disable/ uninstall WSUS on Child Sites (This will affect patching on all sites). The Central Site enforces policies from the top-down, while reporting is from the bottom-up. As far as i know there is no way to perform Centralized Reporting without WSUS being installed on the Central Site Server. We contacted Microsoft about the issue during the build-out of SCCM. This led us to this De-Centralized structure we have now with each site being able to generate their own reports at the Child Primary site level. I just want to confirm if this is true and if any advice or references can be provided regarding this issue. All help is greatly appreciated! 

Updates don't come from WSUS in ConfigMgr, they always come the DPs so I think the discussion above is pretty moot. WSUS in ConfigMgr serves simply to download the update catalog and make it available to clients for their use in scanning (it also makes EULAs available to clients). Also, reporting in no way depends upon the existance of WSUS. All ConfigMgr data is stored in the ConfigMgr database which has nothing to do with WSUS. Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

I'm not sure what he is trying to say or do here. When you say "decentralized" are you saying each remote site is stand alone and not connected to a central site? Actually client agent settings are made at the primary site level, he's incorrect saying that all settings are made at the central site. However the software update point cannot be at a child site and not at the parent site. That doesn't mean you have to use it at all of them but it has to be installed so that data can flow from the top down. "Well here's the thing with System Center, site settings propagate from the Central Site to the Child Primary sites. So any configuration settings in the Central Site will be enforced to Child Primary sites if the Child site points to the Central Site as "Parent". Which includes settings (such as Software metering, Reporting, etc). So we have uninstalled WSUS from the Central Site, which could disable/ uninstall WSUS on Child Sites (This will affect patching on all sites)." John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|

So can all the field sites become connected to the SCCM central site in a parent/child relationship so inventory and metering can be collected at each site and collaborated at the central site, but remain independent to push their own update packages at each field site? If this isn't possible in a parent/child configuration, is there any other way to do this? Right now because we're "decentralized" since it was decided to have each field site control their own SCCM push updates, we are individually doing SCCM software inventory reports when needed and manually reporting the numbers. Our HQ Director wants to see if we can centralize all our primary SCCM sites with the central site to provide a central repository of inventory collection data to the central site, however they want to continue to have the field sites control the software pushes from each primary site. I'm relatively new to administering SCCM so please excuse my naivety with all this and thanks for all your help!

Yes to your first question. Putting sites into a hierarchy just means tht client data is replicated up the hierarchy and managament type data, e.g., packages and collections are replicated down the hierarchy. It does not preclude creating packages, adverts, or collections at any level in the hierarchy.Jason | http://blog.configmgrftw.com | Twitter @JasonSandys