Here is my next screencast in my SCUP series. Today’s topic covers “SCUP – Publishing a Catalog”. Enjoy!
Help Customers Better Manage Software Deployments, Security Updates, IT Compliance, and More!
Join the Beta Program
The Microsoft System Center Configuration Manager 2007 Dashboard lets customers stay on top of application and operating system deployments, security updates, the health status of computers, and IT compliance with key regulations—with an easy to use, customizable dashboard.
Some key benefits of the Dashboard are:
· Provides dependable, timely access to key information: the dashboard lets IT Pros easily stay on top of deployments, security updates, client health, and compliance status.
· Easy to build and configure: the dashboard allows customers to create new dashboards in just minutes. And six default datasets provide customers with valuable information “out of the box”.
· Easy to customize: the dashboard can easily be customized to meet the needs of different departments and other groups. Any dataset in the Configuration Manager database can be presented on the dashboard, in chart, gauge, and table formats.
· Flexible & interactive: users can easily filter data and create ad hoc, custom views. Filters allow users to quickly drill down from high-level to more specific data.
Example Dashboard
The screen shot below shows an example dashboard, displaying Configuration Manager metrics. All of this information comes directly from the Configuration Manager database.
Here are some key links and resources:
- System Center Configuration Manager Dashboard website link
- Direct link to the Connect site for the Dashboard beta program
- Link to send feedback
- System Center Configuration Manager website
We’re looking for input and feedback from you, so please join the beta program!
A common question I see frequently on forums and discussion groups is... “What command line options should I use for MSI/MSP updates to allow them to install?” The simple answer is usually nothing. When installing MSI/MSPs through Windows Update Agent the silent install is already enabled. Therefore, unless you have some specific options you need to specify you should leave this field blank. If there are command line option required for the install, they must be in the “name=value” format, meaning “/qn or /q or /silent” options are invalid for MSI/MSPs. In old versions of CUPT and SCUP we used to pre-populate /qn REBOOT=REALLYSUPPRESS to the command line options, we have since removed them as these values are not needed with the Windows Update Agent performing the installation. Hope that clarifies a few things.
We just released an updated version of SCUP 4.5 to support WSUS 3.0 SP2. You can download SCUP 4.5 here. With this released we also fixed a number of customer reported issues.
- Crashes
- Fixed a number of crash bugs in the import and create update wizards.
- If you run into invalid schema (SDP or update) the exception will be displayed on the summary page which will help troubleshoot the issue.
- MSP Updates
- Fixed an issue that was not allowing deployment of MSPs in Configuration Manager 2007.
- Catalog Updates
- Fixed an issue with not evaluating the entire list of “favorite” catalogs. Now all will be checked for updates.
- This feature alerts when new catalogs are available to import.
- Upgrade
- Upgrade works from SCUP 3.0, 4.0 and 4.5 (old build 4.50.1081.0000) to SCUP 4.5 (new build 4.50.1103.0000).
Here is the next in a series of SCUP screencast. Today’s topic covers “SCUP – Create a Bundle”. Enjoy!
Here is the sample code to create a bundle. Use this sample code instead of what was used in the screencast. The snippet I used was incorrect for software updates and won’t be synchronized into WSUS.
<sdp:UpdateSpecificData UpdateClassification="Updates" />
<sdp:BundledPackages>
<sdp:PackageID></sdp:PackageID>
</sdp:BundledPackages>
Here is the next in a series of SCUP screencast. Today’s topic covers “SCUP – Create an Update with a Prerequisite”. Enjoy!
Here is the sample code to create an update with prerequisite.
<sdp:Prerequisites>
<sdp:AtLeastOne>
<sdp:PackageID><!-- My package ID -></sdp:PackageID>
</sdp:AtLeastOne>
</sdp:Prerequisites>
Here is the next in a series of SCUP screencast. Today’s topic covers “SCUP – Resigning an Update”. Enjoy!
Here is the next in a series of SCUP screencast. Today’s covers “SCUP – Revising an Update”. Enjoy!
Here is a new screencast covering SCUP. Today’s topic is “SCUP – Publishing an Update”. Don’t forget you can maximize the screen size to get a better view of the demo. Also here is a link to details steps on publishing an update. Enjoy!
Here is my next screencast, today’s topic is “SCUP – Creating an Update”. If you have any questions or comments please post them in the comments section below. Enjoy!
Here is a great blog article written by colleague Steve Rachui on how to use a third party certificate with SCUP. This has been a frequent customer question and it is great to have an article that covers this topic. Thanks Steve!
Here is my second screencast for SCUP, this time covering finding, managing and importing catalogs. If you have any questions or comments about the screencast please post those to the comments section below Enjoy!
This here is my first screencast, covering System Center Updates Publisher (SCUP) installation. I’m planning on doing several more of these in the future. If you have any topic ideas, please use the “Email” link above to send them to me. Also don’t forget to maximize the screen so you can see everything clearly. Enjoy!
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.
