One of the things SCCM is not good at is real-time anything. I like SCCM but it's not a "real-time" solution for anything really. It requires the SCCM client side agent to gather info and send back to the server - that happens often and fast (usually) but not in real-time.
that said, Look at advertisement status web reports, and clicking into some of the links in those reports will get you slightly delayed status for a computer that is running an advertisement. Those are probably the reports I go to most.
This was answered in a TechNet thread.
SCCM 2012's splendid version control increments its SUP catalog version every time it downloads new updates, as seen in the Catalog Version column under Monitoring -> Software Update Point Synchronization Status. Every update that the SUP adds is entered as a row in the CI_ConfigurationItems table in the SCCM database. One column in this table, SDMPackageDigest, contains XML metadata, including a line that specifies which Catalog Version number the update was added to: <Property Name="MinCatalogVersion" Value="[x]" />, where [x] is a decimal integer. When upgrading from 2012 SP1 to 2012 R2, we imported our entire database to the new server, which meant that all updates had an entry for the MinCatalogVersion, reaching at least as high as 2200. However, SCCM stores the catalog version in registry keys, which were not imported, which meant that on the new server, the version number was restarted at 1. Thus, the SUP would not install updates that had a higher MinCatalogVersion than the catalog version, which was...essentially all of them.
The fix for this is to change three registry values on the SCCM server, all located in the key HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER.
- ContentVersion
- LastAttemptVersion
- SyncToVersion
After restarting the SMS_Executive service, updates promptly became available to all workstations they were deployed to.
I acknowledge that the proper thing to do would have been to use XQuery to search the XML data in the SQL table for the highest value for MinCatalogVersion; however, I was on a very tight deadline to fix the issue and did not have time to try to figure out an appropriate query. Thus, I just set all three of the registry values to 10,000 (decimal) and hoped for the best.
Best Answer
The build 1606 is called System Center Configuration Manager (Current Branch) 1606.
There were some issues so it's now been moved to pre-release status. (You can see features on the Administration - Cloud Services - Updates and Servicing - Features. If it's not enabled and you want to enable it, be sure in Hierarchy Settings, 'Consent to use Pre-release features' is enabled before you enable the feature )
The Server Group Settings are configured in the properties of a device collection. You can put your 'desired' systems (what ever cluster or normal systems) in a device collection and then configure server group settings on this device collection.
The software update deployment is using the typical deployment process. The Server Group configuration adds functions that you can control:
In case that you have got a collection with child collections, the settings of a parent collection is separated and has nothing to do with a child collection configuration. The parent collection just read the memberships of a child collection, not the other configuration.
As I said, as long as all your desired system is member of the collection, you can do the configuration.