Configuration Manager with Jason Lewis
SCUP Catalogs Best Practices
Follow me on Twitter @JLewisMS
The link below is a video one of my co-workers (Bryan Keller) did at the end MMS last week. It covers some of the things we are working on for Configuration Manager SP1 & R2. Enjoy...
Note: This is only for SCUP 3.0 or 4.0. With SCUP 4.5 this is no longer an issue.
I’ve received a couple of questions regarding System Center Updates Publisher (SCUP) when behind a proxy server. Some customers have reported problems downloading catalogs and updates when behind a proxy server. To clarify, SCUP uses the proxy server settings set in Internet Explorer but is only able to connect through the specified proxy server when it allows anonymous access. Therefore if your proxy server requires authentication you cannot use SCUP to download catalogs or publish updates to Windows Server Updates Service (WSUS). You will get an error similar to “(407) Proxy Authentication Required”. To manually workaround this issue you can do the following…
Hope this helps, if you have any questions please let me know.
For the past several months I’ve been working on two System Center Configuration Manager 2007 Configuration Packs. Configuration Packs are definitions for the new Desired Configuration Management (DCM) component in ConfigMgr 2007. DCM allows you to assess the compliance of computers against a defined configuration. A configuration pack consists of one or many configuration items and zero or more configuration baselines. A configuration baseline is a group of configuration items. A configuration item defines a set of rules for which to check configuration compliance of an entity. That entity could be an application such as Internet Explorer or SQL Server that you have a configuration baseline defined. Or it could be a business rule that needs to check user machines don’t have any non NTFS partitions. Anyways, hope that defines what Configuration Packs are. The two that I worked on and released are (sorry for the long names)…
System Center Configuration Manager 2007 Configuration Pack (download)This Configuration Pack helps track configuration compliance for Configuration Manager 2007 site server roles, such as management points, distribution points, and software update points.
System Center Configuration Manager 2007 Vulnerability Assessment Configuration Pack (download)This Configuration Pack helps track common software misconfigurations which might make client computers more vulnerable to attack. This is a replacement for the Scan Tool for Vulnerability Assessment in System Management Server 2003 R2.
I’ve met with a few customers over the past month that had similar questions regarding deploying custom updates. I wanted to write a quick high level summary on how to this in a small environment.
First step is to setup System Center Updates Publisher (SCUP) to publish updates to your Windows Server Updates Service (WSUS) server that is being used with System Center Configuration Manager (ConfigMgr 2007).
Setup SCUP to use an update serverOpen SCUP-> Settings-> Update Server Tab-> Check “Enable publishing to an update server”-> (set local or remote update server)-> Test Connection.
If you do not have a signing certificate specified you will receive the following message, “The test connection succeeded. However, no signing certificate was detected for the update server. You will not be able to publish content to the update server without first registering a signing certificate”. If your company does not have a specific certificate they want to use you can create what is called a WSUS Publishers Self-signed certificate. By clicking the “Create” button WSUS will create a certificate that will be used for all future publishing. Once a certificate is either inserted or created it does not need to be re-created until it expires or needs to be replaced due to some business need.
Note, anytime you change (or re-create) your signing certificate you will need to execute the rest of the certificate steps below again in order to get those updates signed by the new certificate to deploy. By changing your signing certificate you won’t invalidate your currently deployed updates in ConfigMgr 2007 but unless you follow the below certificate steps again the new updates will not deploy.
Now that you have a signing certificate specified you need to add it into two locations, “Trusted Publishers” and “Trusted Root Certification Authorities” on all machines where custom updates will be deployed. The signing certificate will also need to be added to the two above locations on your SCUP machine and WSUS server if different. Follow these steps to first export the WSUS signing certificate and then re-import it to the appropriate locations.
To open Certificates (Local Computer) in MMC.Open MMC-> File-> Add/Remove Snap-In…-> Add -> Certificates-> Add-> Computer account ->Next-> Finish-> Close-> Ok
To export signing certificate.Go to Console Root-> Certificates (Local Computer)-> WSUS-> Certificates-> Select certificate-> Right Click-> All Tasks-> Export…-> run through wizard using all defaults-> provide file name-> Finish Wizard.
To import signing certificate to “Trusted Publishers” and “Trusted Root Certification Authorities”Go to Console Root-> Certificates (Local Computer)-> (Trusted Publishers [and] Trusted Root Certification Authorities ) node-> Right Click-> All Tasks-> Import…-> enter path to exported certificate-> follow rest of defaults and complete wizard.
I know this can be a pretty manual task, but there are ways to automate it. One way that I know works is to use "CertUtil.exe" to deploy the certificates. In ConfigMgr 2007 you can create a program that contains CertUtil.exe (found in Windows Server 2003 Administration Tools Pack) and your exported certificate. You want to call run both commands on each machine by advertising each program.
To place in "Trusted Root Certification Authorities" store call "certutil.exe -addstore ROOT <certname>.cer"To place in "Trusted Publishers" store call "certutil.exe -addstore TrustedPublisher <certname>.cer"Now that you have the signing certificate stored in all the right places the last setup step is to tell Windows Update agent to accept updates signed by entities other than Microsoft.
To set Group Policy to allow custom update deployments Note, the below step needs to be executed only once, even if you change your signing cert.Active Directory Users and Computers -> Right Click on your domain-> Properties -> Group Policy Tab -> Edit. Then Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Enable “Allow signed content from intranet Microsoft update service location”.
After following these steps you will be able to publish your updates to ConfigMgr 2007 using SCUP and then deploy the updates in your environment as you would any other update. Hope this helps clarify things, if anybody has questions please send mail or leave a comment.
If you ever created an update that uses MSI rules you are bound to see a warning message letting you know that the scan agent cannot detect an MSI if it was installed per-user and that you should use different rules to help detect if the update is applicable or installed. There is another similar warning when you select a MSI update that allows per-user installation when inside the Create Update Wizard.
So what are these warnings about? The purpose of the warnings is to inform you that we do not support detection of per-user installed MSI updates using MSI rules. The reason behind this is that if you have installed a MSI under the “User A” account and then scan for the update it will not be detected by the scan engine (running under a different account) and thus cannot be patched. The scan engine runs under the local system account and therefore can only detect MSI’s that are installed system wide.
So what should you do if you must deploy an update for a per-user installed MSI? Don’t rely solely on MSI based rules to detect if your update is applicable or installed. You should use file or registry rules since these will not be user based.
If you don’t know if your update is per-user enabled or not we can help you find out. During the creation of the update in the Create Update Wizard’s “Select Package” page when you browse to your MSI/MSP we will check to see if it has per-user installation enabled. If we detect that it is enable we will display the warning message described above.
In both System Center Updates Publisher (SCUP) and Custom Updates Publishing Tool (CUPT) there are three different types (or sections) of detection rules in the Create/Modify Update Wizard. These rules types are prerequisite, applicability and installed rules. The definitions are as follows:
Prerequisite Rule: High level detection rules for checking operating system version, processor architecture, operating system language and other similar checks. These rules are executed first (in CUPT only) to determine if an update is applicable (or installable) on a system. For SCUP the prerequisite rules are combined with the applicability rules (with AND logic).
Applicability Rule: More specific detection rules used to verify that the specific update is applicable to the system. Examples of these types of rules would be file exists, file version, file created date, registry key and other similar rules.
Installed Rule: Rules which are used to validate that the update was successfully applied to the system. These are also specific detection rules such as file exists, file version, file created date, etc.
How these rules are interpreted and used are slightly different, especially between SCUP and CUPT. The first thing to note is that only in CUPT are prerequisite rules executed first when scanned on a system. This is due to using the Inventory Tool for Custom Updates (ITCU) scanner to execute the checks. The ITCU scanner was designed to first execute the prerequisite rules first (then installed followed by applicability rules), which helps with scanning performance since all updates that aren’t associated with that type of machine are quickly discovered and skipped before executing the rest of the checks. This is not the case with SCUP. In SCUP we publish updates to a Windows Server Updates Service (WSUS) server which then moves the prerequisite rules into the applicability rules. The reason for this is that CUPT and SCUP store updates in Software Distribution Package (SDP) schema xml, while WSUS updates are stored in Software Update Services (SUS) schema xml. In SUS xml prerequisites are not defined in the same way therefore they most move our SDP prerequisites to SUS applicability rules.
Another difference between the rules is how they act when not defined. If no prerequisite rules are defined in an update it will evaluate to true (or prerequisite rules passed) when scanned. However, if you do not define an applicability rule it will evaluate to false, meaning the update will never be applicable (this is bad as no warning is given in the UI). If an installed rule is not defined then the update cannot be published (the UI will not allow you to flag an update for publish with no installed rules defined).
To summarize, always use prerequisite rules when defining an update even if you don’t get the performance gain from ITCU. Also keep your prerequisite rules general as in OS or CPU checks. You should not be doing detailed file checking in your prerequisite rules. Lastly always define applicability and installed rules; otherwise you will not have a useable update.
Catalog Updates is a feature in Custom Updates Publishing Tool (CUPT) and System Center Updates Publisher (SCUP) that allows you to maintain a list of catalogs. This list of catalog gains you two things, first the ability to detect when a catalog is updated by the vendor and secondly the ability to bulk import all of your catalogs in one single import session.
To use this feature you will need to add catalogs to your Catalog Updates list, there are two ways to do this. The first is to manually add them (Click on “Settings -> Add” on Import List tab). This will bring up a form where you can enter the catalog information. The second option is to automatically add them with the “Discover and Add External Catalogs” feature (Click on “Settings -> Find” on the Import List tab). This option will find all the partner catalogs that are included in the Microsoft catalog (http://www.microsoft.com/smserver/partners/itcucat.mspx).
After adding the catalogs to your Catalog Updates list you can now detect when they are updated. To do this you hit the refresh button on the “Catalog Updates” control in the center pain. You can also configure CUPT/SCUP to automatically check for new catalogs every time you start the program (Click on “Settings -> Automatically check for updates to my catalogs on startup” on the Import List tab).
Lastly, now that you have catalogs in your Catalog Updates list you can bulk import them by simply clicking on the “Import” action. You will see on the first page “Bulk Catalog Import” option is now enabled.
In Custom Updates Publishing Tool (CUPT) there were two export options, now with System Center Updates Publisher (SCUP) you have three. Today I’m here to tell you what the difference is between all of them.
Export Option 1
First is the option “Export selected updates to a cabinet file that can be imported by other publishers” in SCUP. This is the exact same option as “Export a cabinet file that can be imported by other publishing tools” in CUPT. This option was designed to be used to export your selected updates to a cab file. This cab file then can be imported into any other publishing tool. This is a great option if you have more than one user who authors a single update. For example you might have a marketing team start creating the update and entering information such as title, description, vendor and product. Once the marketing team is done they can export the update and hand off to the developer of the update to import into their SCUP/CUPT and fill out the detection rules.
One thing to note here is what I mean by selected updates. There are only a few ways to select an update, below is a list.
As you see there is no way to pick and choose across different vendors or products without selecting them all, that is where option 3 comes in.
Export Option 2
The second option is called “Export selected updates to a test catalog XML file and supporting scan file for testing” in SCUP. The corresponding option in CUPT is called “Export a test catalog XML file and supporting scan files for testing”. This is the “Export for Test” option when you want to test your selected update’s Software Distribution Package (SDP) before releasing to the public or your corporate environment. This option will create SDP XML without CAB’ing. Specifically this option exports the raw SDP XML into a user specified folder along with RunScan.cmd and executable to test your updates. All you have to do at that point is double click on “RunScan.cmd” which will then run the test scan engine and report your results in the form of “TestResults.xml”. This results file along with the scan engine log can be used to verify or troubleshoot your update SDP.
Export Option 3 (SCUP only)
The third export option is called “Export all updates in the update publisher database that have the publish flag set” and can only be found in SCUP. This option was originally inside the Publish Wizard in CUPT but was moved to the Export Wizard in the new release. The primarily difference versus the first two options is that it exports only those updates which are flagged (Publish Flag set). This can span across multiple vendor and product nodes unlike the two above selecting options. The other main difference is that this option also produces a signature file (XML) that is used in conjunction with the CAB when publishing online. This signature file stores when the catalog was created and can be consumed by SCUP/CUPT subscribed catalogs feature. The subscribed catalogs feature is used to keep a list of catalogs you want to be alerted to when they are updated. Independent Software Vendors and Line of Business developers should use this option when they want to create a final catalog that is to be consumed by their customers.
I am proud and excited to announce the release of System Center Updates Publisher (SCUP). This is the updated and rebranded Custom Updates Publishing Tool (CUPT) from Systems Management Server (SMS) 2003 R2. To read more about SMS 2003 R2 please read here or here. This version of the tool works with the System Center Essentials (SCE) and the future release of System Center Configuration Manager (ConfigMgr) 2007. SCUP is available to download here.
With a new version come changes, listed below are some of the bigger ones.
Just as CUPT had pre-requisites, SCUP does too but with this release there are a few more. The main one, which is not included in the installer package, is Windows Server Updates Service (WSUS) 3.0 Administration Console. SCUP uses some of the WSUS public APIs for publishing (more on that later) and update creation. This will have to be downloaded and installed onto your workstation prior to installing SCUP. You can find WSUS 3.0 here. Other than Microsoft Management Console (MMC) 3.0 (more info here), all other pre-requisites are bundled into the installation and installed automatically.
The biggest change is that SCUP publishes updates to WSUS 3.0 to be consumed by SCE and ConfigMgr. This is changed from the CUPT release where it directly published updates to Systems Management Server (SMS) 2003 R2 sites servers. Therefore SCUP cannot be used in an SMS 2003 R2 environment for publishing. If you publish updates to SMS 2003 R2 you will need to continue using CUPT.
The Software Distribution Package (SDP) schema has slightly changed in SCUP. There are a couple of rules that were deprecated in the new version. SCUP no longer supports software update definitions using the Registry Binary Value rule and the Digest attribute in the File Exists rule as it did in CUPT. Also there is a new schema addition for expiring an update. This new feature will be used to expire updates in WSUS which will then stop them from being included in future deployments.
Due to the fact you now have SCUP and CUPT which can create/edit/publish updates with different schema’s there needed a way for an Independent Software Vendor (ISV) to publish one catalog which can be consumed by SMS 2003 R2, ConfigMgr 07 and SCE. To enable this scenario “Compatibility Mode” was created, which will only create valid SDP that can be consumed by both CUPT and SCUP. Meaning when “Compatibility Mode” is turned on you will produce SDP that does not contain expired updates and deprecated rules.
To enable “Compatibility Mode” open SCUP, click on Settings -> Advanced Tab -> Check “Enable compatibility mode with previous update format”.
Exporting/Publishing UI changes
The main UI change made in SCUP was to remove the creation of the published catalog to the “Export” wizard. This enabled the “Publish Update(s)” wizard to only do publishing to WSUS. Unlike when you publish in CUPT, you no longer need a catalog of updates pushed to the SMS 2003 R2 Site Server’s package source for scanning with the Inventory Tool for Custom Updates (ITCU). With SCUP you publish each individual update in to the WSUS database directly, no catalog generation is necessary. Therefore it was necessary to remove the creation of the published catalog to the Export wizard. This allowed all export catalog options to be located in the same wizard. Now when ISVs want to publish their catalogs to the web they can by choosing the “Export all updates in the updates publisher database that have the publish flag set” option in the Export Wizard. This option will create the catalog (cab file) as well as the signature (xml file) that can be posted online for use with SCUP/CUPTs subscribed catalogs.
Microsoft Update Catalog
In SCUP, you now have a link (Microsoft Catalog) on the main page to the Microsoft Update Catalog website. Imbedded into the link are required parameters needed to download and directly import your updates into your WSUS environment to be used with ConfigMgr and SCE. Microsoft Update Catalog website provides updates, including hotfixes which are generally provided by Microsoft Customer Service & Support.
Hello, my name is Jason Lewis, and I am a Software Development Engineer in Test (SDET) on the System Center Configuration Management (aka Systems Management Server) eXtreme Team here at Microsoft. I’ve been with the team for 2 ½ years. I’ve worked on products such as System Management Server 2003 SP2 and R2 including the Custom Updates Publishing Tool (CUPT), Inventory Tool for Custom Updates (ITCU) and System Center Updates Publisher (SCUP). I’ve created this blog to get in touch with customers and to help educate them on the use of these new products. Most of the topics will be covering products that I’ve worked on or am working on including “FYI” and “How To” topics. If there are any topics you would like covered please email your suggestions.
Look for some blog entries in the coming days.