The Configuration Manager team now has a team blog.  You can find it here: http://blogs.technet.com/configmgrteam

Here you will find in depth content regarding anything Configuration Manager related.  Enjoy!

There have been some questions regarding the new update types introduced in System Center Updates Publisher (SCUP) 4.0.  Here I will try to clarify a few things.

First off the SCUP console does not support creating, editing or duplicating any of these update types.  If you need to create them the best option would be to use the schema files (found in the “data” folder) and generate the updates manually with a XML editor then import it into SCUP to publish.   The only actions the SCUP console supports are importing, exporting, publishing, expiring and deleting. 

Here is more detailed information on the new update types…

Bundle
Bundles are a logical grouping of one or more updates.  Bundles themselves do not have a payload (binary update) but instead reference other updates that do have payloads (or other bundles).  An example of a bundle is when you have a single type of machine, lets say “Model 123” which has updates for the video card, sound card and NIC card.  You can group all those updates into “Model 123 January Bundle” which allows the IT administrator to approve the bundle verses all the individual updates.

Driver
Driver updates are exactly what it sounds like.  Driver updates don’t have the typical, Prerequisite, Installable and Installed rules but rather uses driver metadata to determine if the update is needed.  Driver properties such as hardware ID, driver ID, manufacturer, model, class and version are used to determine applicability.

Prerequisites
Updates can now reference other updates as prerequisites.  Which means that before an update can be installed it must have the prerequisite update installed.  There are a couple common uses for this, one would be to define detectoid prerequisites (more on that in the detectoid section) and another would be to reference another update that the main update is dependant on.  For example if you have an update for a product that does not roll up a prior update, then you can reference the first update as a prerequisite to the new update.  This will force that the first update is installed before the new update is applied.

Detectoid 
Detectoids are really a root level rule.  Meaning detectoid updates do not have a payload and only include Installed rules.  An example of a detectoid would be one with a single rule that verifies the OS language is English.  Or an update with a single rule that verifies the CPU architecture is x86.  Detectoids verify a single object, such as OS language, OS version, product version or CPU architecture type.  A single detectoid would not look for both OS version and OS language, that would be two separate detectoids.  To use detectoids with an update you need to reference the detectoids as a prerequisite to your update.

Updates that use detectoids are preferred over individual updates that just use prerequisite rules defined in the update itself.  This might be a little confusing so let me clarify.  There are now prerequisite updates which are references to another update(s) that must be installed before this update can be installed.  Secondly there are prerequisite rules, those are the rules defined inside the update itself that determine if the core requirements are met before going forward with scanning for the update. 

A list of well known detectoid IDs can be found here. Lastly here is some information on how to create correct detection logic as well as detectoids.