What criteria should I use for the monthly updates

Question

I am just starting to setup Software Update for SCCM 2012 R2. The configuration is done with the Classifications and Products selected and working.  I selected the Classifications:
Critical Updates
Definition Updates
Security Updates
Service Packs
Update Rollups
Updates
Now I am just looking for the criteria to use for my Software Update Groups.
I watched this GREAT VIDEO "SCCM 2012 SP1 and the new way handling Software Updates explained", URL: 
http://technet.microsoft.com/en-us/video/sccm-2012-sp1-and-the-new-way-handling-software-updates-explained.aspx regarding the "new way" we are to be doing the groups and updates.  The video is
very informative and explains a lot, but it does not say what criteria is used.
This is the breakdown from the video, but again it doesn't say what criteria may be:
 • Keep Software Update Groups (SUG) Limited to 1,000 updates
 • Don't split products into different SUG's
 • Enabled Delta replication for the Software Update Points (SUP)
 • Set High priority for the Software Distribution Group
Software Update Groups
 • Exceptions group (not to deploy)
 • TMG Definition Updates
 • SCEP 2012 Definition Updates
 • Outlook Definition Updates
 • 2003-2010_All Updates
 • 2011_All Updates
 • 2012_All Updates
 • 2013-01_All Updates
 • 2013-02_All Updates
Deployment Packages
 • TMG Definition Updates
 • SCEP 2012 Definition Updates
 • Outlook Definition Updates
 • 2003-2010_All Updates
 • 2011_All Updates
 • 2012_All Updates
 • 2013_All Updates
Automatic Deployment Rules
 • Microsoft Outlook 2010/2013 Definition Updates
  ○ Run after synchronization
 • Monthly Updates
  ○ Every Month on day 16 of the month
  ○ Uncheck "Enable the deployment after this rule is run
 • SCEP 2012 Definition Updates
  ○ Run after synchronization
 • TMG Definition Updates
  ○ Run after updates
I am specifically looking mostly for the Monthly updates and to make sure they are only those needed.  Most I have seen use:
Superseded:  No
Expired:  No
Bulletin starts with "MS"
I don't really know what the "MS" limits things to.  Sorry a lot of information and not very clearly laid out. 
Find this post helpful? Does this post answer your question? Be sure to mark it appropriately to help others find answers to their searches.

Answer 1

I am specifically looking mostly for the Monthly updates and to make sure they are only those needed.  Most I have seen use:
Superseded:  No
Expired:  No
Bulletin starts with "MS"
I don't really know what the "MS" limits things to. 
I use a similar approach, as one part of my routine.
When you filter/search on Superseded=NO, that discards the updates which are flagged as superseded, but this depends totally upon your routine and understanding of the nature of supersedence, and it's also time-sensitive, since CM12 will by default, kill off
superseded updates after a time. A Superseded update *is* deployable, but you'd likely only do that, if the superseding update is unsuitable for your environment for some reason, e.g. it introduces a bug or regression that you can't afford.
Expired=NO, well, again that's to limit your filter/search results. Since an expired update is not deployable, why bother to have it in your results list, if you are building a deployment. It's handy to know that something is, or has become, expired, if
you are troubleshooting or analysing a "why did/didn't xyz happen?", but for deploying, expired updates are just useless clutter.
Bulletin starts with "MS" can be handy to filter out the "non-security" updates, since "security" updates are always issued with an MSyy-nnn bulletin ID.
Note that the bizarre MS definition of "security update" does not mean that security bulletins cover *all* security-related updates, since there are updates that are released, which do provide security fixes, enhancement, etc, but they don't always attract
a security bulletin ID, so it really pays to look at "starts with MS" and also "does not start with MS" - I use both, when searching/filtering, as a way to slice the assessment/analysis task in "half" (not evenly sliced ;).
And also note that some updates (security advisories, hotfixes, rollups) may not fall into the classification you might expect, or, might not be published into the MU/WSUS catalog feed at all..
An example of a unexpected classification, is the recent 2917500, which is classified under "Feature Packs", even though it is an updated set of revoked root certificates (due to yet another compromised root CA cert). [I noted you didn't mention the Feature
Packs classification, you might want to revisit that choice...]
Personally, I'm not yet using ADRs, not because I don't like them, but because our security ops team are being especially painful at the moment and keep changing their mind about stuff, plus, we are undergoing a massive application change cycle and the change/release
team are hypersensitive just now.
One method I also use, is to periodically run the "updates needed but not deployed" report, as it reveals to me where I need to sync a new product, or have overlooked an update or misunderstood/incorrectly assessed as "we don't need that, or that doesn't
apply to us". it also reveals where I have mucked up and not been diligent about taking a templated approach to deployments, e.g. if I forget to distribute to all DPs or whatever.
I find that even though I might take what I consider to be a very generic approach, others in the forums clearly have different environments/operational models to me, and different needs. For patching, I mainly focus on Windows client OS and Office,
and not really on Windows server OS, since somebody else handles server builds and patching in my org.
Don
(Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)