WSUS vs SCCM SUP - What is the point of changing? Pros and Cons of both

Question

Hi,
I have been using WSUS forever and have just made a very painful change over to SCCM 2012 SUP. In a room full of experienced WSUS users and facing a handover of SCCM SUP, I really need to have this question answered - What, if any, are the advantages of
SCCM2012 SUP over WSUS. It's certainly not ease of use, ease of implementation or understandability.
Even if i accept that yes, they are two different things now and i shouldn't think of SCCM as being like WSUS, I still have to compare and contrast, honestly, what they do and how they do it
WSUS is ridiculously easy in comparison to SUP. With WSUS, I install it, create some GPOs and assign to OUs. I create security groups and add the servers in scope to to thoise groups and those security groups to the policy. I have different groups set up
to keep separation of DCs and APP servers and SQL and SCCM and Antivirus servers and workstations
If needs be i have a text list of all my servers/workstations and can individually target using PSEXEC to run wuauclt on any number of clients. It works great and is easily understandable
Now, enter SCCM 2010 and SUP.
The first thing i HAD to know was the last thing i learned. And not from Microsoft.That is that there is really only one method now, imposed by limitations on Software Update Groups and Deployment packages. You can only create a package of 1000 or less updates
This means chopping up your historic updates and having them deployed as a separate strategy from your newer updates cycles
Secondly, every month from now on you will need to create and sort your updates into a meaningful Update Group and Deployment package - even if you set up an Automatic Deployment rule, you still need to manually create your Update Groups
You can only have one deployment package per update group and will need one software update group per "type" of install (available or Required) AND you will need one software update group and deployment package PER COLLECTION!
To make this work as simply as possible, it will mean having two collections Available and Required (for example)
Each collection will have a SUG associated with it (each with a limit of 1000 updates remember). Each group of circa 1000 updates takes about 2+ hours to compile and you will have a minimum of 5 groups per collection to get up to October 2014
After this your ADRs should now do it all for you but lack the ability to create update groups so you have to do this manually every month beforehand. Whew!!
Thirdly, in the background, WSUS still downloads metadata. In SCCM you should be pointing every update group manually to this folder. Same with Deployment packages and ADRs. Why is this not built-in - intuitive? These are then copied and downloaded as full
packages into their respectively (manually) created source folders
Now, when updates expire or are superseded, you have to manually replace them from each SUG
And also quite a big thing i havent heard anyone else comment on, is the fact that these updates are now NOT shown in the Windows Update feature - they now appear in the Software Center - so now the Servers i sent "Available" updates have to be
logged onto and manually installed - instead of being able to individually target them like i did with PSEXEC and wuauclt
And logging?? There are at least 100 different logs to look at using the Trace Log Tool. It's a full time job just figuring out what logs to look at to resolve any problems
This is, in my opinion, a really poor effort and the documentaion is wildly inconsistent across many forums.
Some kind of standard document is needed. And i say this after having followed Microsoft's own documentation and using technet forums
I, for one, just need one BIG question answered for now - how do i remove the SCCM SUP client and revert back to wuauclt on all my clients - if i remove SUP from SCCM will it remove the client from the clients?

Answer 1

HI Jason,
I have spent a long time trying to get this to work. My requirements are to have WSUS deploy updates automatically with as little intervention as possible and to be able to explain and show the process to others who will administer the system long after
I've gone
The reason I still have to think of things in the WSUS way is that I have a broken update infrastructure that doesn't do what my requirements are. So I now currently need to log into all my "Available " Servers to update them manually instead of
being able to remotely execute the updates. I'll look at the SDK but this is the first time I've heard of it
From the top - yes I agree that's a typo it's Update Goups that can only have 1000 updates. Do you agree that this causes a problem for this scenario? Updates since before 2013 amount to several thousand and so I have to break these up into groups of 1000
- one each for Available and Required groups. That means 8 groups straight away
Having to cater for these historic updates means painfully waiting 2 hours or so for each package to be created. I've done this already and its not pretty but its essential (unless I'm doing it wrong but I am following TechNet forums)
My ADRs will absolutely not create the Update Groups and the docs I have read also say that this is a manual monthly process - Create a Group every month and then use an ADR to use that group - is that not correct?
Update groups - you are mixing my words up and saying the same thing in a different way - "Update groups can absolutely have multiple deployments targeted to different collections" change the "can" for a "must" and you see my
problem. You cannot create a single Update Group, package it up and the deploy it to both Available and Required groups. You need two update groups for this. One for available and one for Required.
Metadata - OK then what is it that WSUS downloads to E:\WSUS\WsusContent\...  ? And why is this to be set as the download location for any Update Group, Deployment Package or ADR?? I have to create  or select a deployment package which is another
manually created folder under "sources" for which the download location is set to my WSUS folder. This doesn't work unless I set my download location to Microsoft. But WSUS should already have synced in the background to WsusContent so why would
I want to download from Microsoft. And I only want to actually download the "approved" packages. So as far as I'm aware the WSUS\WsusContent folder only contains metadata which is not downloaded until required. Am I wrong? What/who/how downloads
the binaries and when?
Lastly, What doesn't make sense? The goal used to be automation. If and when I needed to, I used to be able to manually intervene for single or multiple devices using PSEXEC to run wuauclt. With SCCM I can see for example, 2x non compliant devices just now.
In the old days I would just psexec onto them and run wuauclt. In SCCM I err... Hmmm.. what? What do I do? Will look at the SDK
Just one other thing - is there no way at all to continue to use the Windows UPdate control panel and have it show the same available updates as Software Centre? Why can SCCM not just work like Windows Update does? If I run Windows Update on any server it
says up do date but if go to Microsoft to check it always comes back with updates
I just want my internal SCCM SUP to work the same way Microsoft updates works for an internet connected computer. Completely Automatic. No intervention. My group of Availabel servers I would like to be able to remotely and individually install from either
a central console or a script. Again, I will look at the SDK for this
Thanks for your reply and advice. I'll give it one more week. ;-)