locked
Creating a Tool for Local Publishing RRS feed

  • General discussion

  • I'm considering writing an open-source .NET tool to facilitate local publishing using the WSUS API.  I've spent the last day or two reading over the documentation and MS's stellar overview of the process.  In general, this all appears to be quite doable although the initial setup will be non-trivial and users are going to need some expertise to package the updates correctly since.  I think I have an overall plan that works but I have a few question.

    The ability to redistribute parts of the API, specifically the Microsoft.UpdateServices.Administration DLL file.  This was discussed already [technet.microsoft.com] but I'm not looking at the whole of the Remote Admin Console, just the single Admin DLL.  Which is the relevant license to read?  I could live with the setup involving the user installing the WSUS remote console but it would be nice to eliminate that requirement.

    The local publishing overview, on the topic of creating the metadata, repeatedly says to make use of the API rather than cranking it out by hand.  That sounds good but then their examples start writing XML directly to the IsInstallable method.  Apart from the relevant XML DTD, is there a place where this is documented?  My thought is to cover some of the basics with a wizard but optionally let the user edit it by hand.

    Any other thoughts on this idea, is this a fools errand?


    • Changed type Bryan Dam Thursday, October 22, 2009 1:07 PM
    Thursday, October 22, 2009 1:06 PM

All replies

  • >The ability to redistribute parts of the API, specifically the Microsoft.UpdateServices.Administration DLL file.  This was discussed already
    [technet.microsoft.com] but I'm not looking at the whole of the Remote Admin Console, just the single Admin DLL.  Which is the relevant
    > license to read?  I could live with the setup involving the user installing the WSUS remote console but it would be nice to eliminate that requirement.

    Regardless of what the redistribution rights of the Microsoft.UpdateServices.Administration.dll file actually are -- anybody who's using WSUS to administer updates, locally published or otherwise, is going to need the WSUS Console in order to manage *Microsoft* updates. So why not just make the console a requirement and then you can [a] safely assume it exists, and [b] not worry at all about redistribution rights.

    Truly, are you envisioning a scenario in which somebody would be using your open-source .NET tool for performing local publishing and *NOT* need the WSUS Console, also?
     

    > Any other thoughts on this idea, is this a fools errand?

    I think you may be significantly underestimating the level of effort necessary to produce such a tool, but I certainly encourage you, and wish you the best of luck in your endeavor.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, October 23, 2009 3:35 AM
  • From my experience creating installers, anytime you can provide the specific dll you need rather than relying on someone else to give it to you is a good thing.  MS could change the whole thing at any time.  So it's not so much that I don't envision people having the official console as much as I would prefer to not be forced to rely on it for the whole workings of my own project.  Again, I can live with it, but it seems worth looking at.

    Any specific things you think are daunting?  To be honest, that was my intuition from the start and still is.  However, reading their Local Publishing overview made me optimistic; maybe overly so.  The actual code to publish an update seems almost trivial [msdn.microsoft.com] and doing reporting appears to be a matter of querying the public SQL views which is nothing new under the sun.  The biggest hurdle, and they say it outright, is creating the metadata which will determine if it's already installed and if it can be installed.  For that reason I'm looking to find some documentation about the XML for those elements and how to properly create it.  Creating MSI files where they aren't already provided is another hurdle but it's a hurdle that just about any administrator trying to remotely deploy apps has to face.

    EDIT: I found documentation for the rules: http://technet.microsoft.com/en-us/library/bb531100.aspx .  Also, EmminentWare's Package Wizard looks to be exactly what I was envisioning; it's nice to know it's possible. 

    Also, there apparently is such a thing as an Update Catalog which in theory could be used to import multiple updates.  Anyone know if these are actually shared anywhere out in the wild?
    Friday, October 23, 2009 12:53 PM
  • > Any specific things you think are daunting?  To be honest, that was my intuition from the start and still is.
    > Publishing overview made me optimistic; maybe overly so.

    There's a big leap between using the API to merely get a single package built, approved, and deployed, and actually building an entire User Interface and application around that functionality to support multiple packages from multiple vendors, being administered by users with various skill sets and experience levels.

    When this whole concept was contrived and built into WSUS v3 a few years ago, there were really only two target audiencies for the capability:

    1. The System Center product group -- who needed replacement technology for what has been in SMS since the early 1990s.
    2. Third Party Vendors --- in the anticipation that they would build tools and/or applets for managing their particular product updates and use the WSUS infrastructure to distribute the binaries.

    The WSUS Console does not make visible any third party content. This is the biggest hurdle to overcome. Any efforts to build a "tool" to do publishing will also need to include a console/UI in order to faciliate the approval of those updates as well as the reporting on those updates.

    Your assessment that publishing the package is the trivial part is correct. That is the least significant part of the process. Developing a package creator that produces SDP compliant XML is a big hurdle; developing a UI to faciliate approval and reporting is another. Managing packages once they're created, as well as importing catalogs is high on that list of expensive investments.

    The EminentWare Package Wizard is probably your primary competition in your endeavor -- but not just the package creation wizard, which was new in the '004' update in August, but also the other functionality (managing, approving, reporting) which surrounds supporting an already existing package. The effort is not trivial in the big scope of things.

    As for catalogs.. HP, Dell, Intel, and Citrix are known to have catalogs.

    You might find this webcast I did in September on using WSUS to do 3rd party updates (with the EminentWare Extension Pack) to be of interest.
    Extend WSUS to Deploy and Manage 3rd Party Updates


    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, October 23, 2009 2:59 PM
  • Lawrence, thanks for taking time to discuss this, I greatly appreciate it.

    Based on watching the webcast, what I've read, and what you've said, I think I have the appropriate respect for the task at hand. I also think that if I restrict my focus to only the most basic functionality that, given time, I could create something useful. The initial goal would be a no-frills program that does little apart from create Software Distribution Packages, manages publishing them to WSUS, manages approvals on WSUS Groups, and gives you a list of machines and their status for a specific update. From there, if people find the software useful, they are free to extend it as they desire and hopefully contribute back.

    The only part which truly scares me is the creation of the SDP XML but again my plan there would be to stay focused on just the rules that will initially suit the applications I wish to deploy.
    Friday, October 23, 2009 8:23 PM
  • I have been researching the same problem.  We have no problems reading the database from the backend, or using the API to perform patch management, but the problem with Third-party is the daunting task to define, sign, and upload the packages into WSUS. 

    This is a feature that has very little documentation from start to finish and a tool to take the files from an .xml definition; a MSP, MSI, EXE, etc; and a signature and publishes into WSUS would be very helpful.
    Monday, October 26, 2009 8:02 PM
  • Unless I'm mistaken, the metadata is only tough to create if you're working with an EXE files rather than an MSI or MSP.  With MSI or MSP files the rules basically boil down to MsiApplication(Installed/Superseded/Installable) elements as well as an MSI Product Code element in the metadata.  All of that is given to you by the PopulatePackageFromWindowsInstallerPatch method.  Slap some simple OS and/or Processor rules and you should essentially be all set.  That almost seems too easy ... what am I missing here?

    For my purposes, limiting support to just MSI and MSP files is entirely do-able.  The apps I'm interested in (Flash, Acrobat Reader, Java JREs, and Quicktime) all fall in to one of two categories.  You can either get them as MSI files directly or by snatching them out of the %TEMP% directory when the EXE extracts them out.

    You mention signing and uploading as issues.  Again, maybe I'm missing something here but those don't seem difficult.
    Signing seems to be taken care of by the WSUS server.  The documentation is quite specific on how to do this.  You install your own certificate on the server and on each client. 
    Isn't uploading simply taken care of by the PublishPackage method?  Create an IPublisher object using the SDP file and then publish it using the actual install/patch file.
    Wednesday, October 28, 2009 1:36 AM
  • WOOT!  I just had my first locally published MSI update authored, published, approved, and installed successfully.  The program still needs a ton of work but after a couple weeks of programming it's nice to know that at some level what I have works.  I have the same love-hate relationship that most admins have with Microsoft, but this WSUS API is very well done.
    Tuesday, November 10, 2009 3:03 PM
  • WOOT!  I just had my first locally published MSI update authored, published, approved, and installed successfully.  The program still needs a ton of work but after a couple weeks of programming it's nice to know that at some level what I have works.  I have the same love-hate relationship that most admins have with Microsoft, but this WSUS API is very well done.

    Congratulations, Bryan.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, November 10, 2009 4:28 PM
  • Thanks Lawrence.  Question for you, or anyone else, regarding Install Handler Data.
    The API Documentation for this [http://msdn.microsoft.com ] refers to the InstallableItem.InstallHandlerSpecificData element of the SoftwareDistributionPackage.  However, from what I can tell, it doesn't exist in the API although they say it can be set there.  An SDP [http://msdn.microsoft.com ] has an InstallableItems Collection, but the objects in that collection do not have anything refering to the InstallHandler.  Any idea how we get this data, specifically command arguments for MSIs and MSPs, into the SDP?
    Tuesday, November 10, 2009 11:59 PM
  • Ok, so it appears that the WindowsInstallerItem which inherits the InstallableItems class has the command line parameters.  Supposedly the PopulatePackageFromWindowsInstaller method [http://msdn.microsoft.com ] creates such and object but I can't figure out where since the populate method doesn't return anything.

    EDIT: Nevermind, I figured it out.  I just needed to cast the objects in InstallableItems to be able to prevent the compiler from freaking out.
    Thursday, November 12, 2009 1:22 AM
  • I've made some good progress in the last month. I have support for adding, editing, removing, and grouping all of the basic rule types for the IsInstallable and IsInstalled sections.  I just rolled this out to about a hundred PCs in my company and successfully delivered the latest versions of Flash, Acrobat, Quicktime, and the Java Runtime Environment.

    Recently, Adobe released a newer version of their Flash player which leads me to look at superseding updates but I am wondering if this is really necessary at all.  Can't I just remove the package for the older version and add the new package?  What benefit do I have in keeping the old package around?  The only thing I can think of is that I can see how many users have the old version installed.  Since the installers for the above mentioned programs all delete previous versions this seems to be of limited value; if the new version is installed then the old one is not.
    Thursday, December 10, 2009 3:25 PM
  • Can't I just remove the package for the older version and add the new package?  What benefit do I have in keeping the old package around? 
    And this is the point at which you cross from "writing a utility for myself" to "writing a utility for others".

    While it might work for you to simply remove the older package, it might be a production dependency for another organization to keep the older version available for distribution. Thus the requirement to support supercession information.

    Also, wrt to your Java deployment -- did the Java Installer run in *unattended* mode on your client systems?
    Did any of your clients have IE or JavaApps running while you installed the Java package?
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, December 10, 2009 5:08 PM
  • Thanks again Lawrence for your insight.  Primarily I wanted to know if I should be superseding updates rather then deleting them for some functional reason.  The initial intent here is to write a utility for others to use and extend if they need to.  Right now it's a matter of prioritizing features that have to be in the initial release.  If superseding updates isn't a functional requirement then it can wait.

    The Java install ran in unattended mode, and people were certainly running IE (and Firefox) while the install happened.  I created the package by extracting the MSI and using the command line: "JAVAUPDATE=0 AUTOUPDATECHECK=0 JU=0" based on info gleaned from appdeploy.com.  As such I didn't do anything special to make it run unattended, that apparently just happens when you use an MSI package.  I personally supervised the installs on each machine as I had to distribute the certs by hand and didn't see any prompts.  Was anyone running Java apps?  I doubt it, I certainly didn't test that scenario.  There's only one internal tool that uses Java and it is very rarely, if ever, used.
    Thursday, December 10, 2009 5:49 PM
  • Hi.  We've been using a few homemade scripts for publishing updates through WSUS for over a year now.  The scripts are nothing special, so you've probably got something better already, but if you need some advice I'd be glad to help out.

    A few comments about your earlier postings:

    The rules generated by PopulatePackageFromWindowsInstaller are harmful.  I'm not sure if this is what Microsoft intended, but in practice any new version of the program will have a MSI file with a new productcode.  Once the new MSI file is installed, the WSUS server will decide that the old MSI file is installable and not installed and will schedule a fresh install.  What happens then is up to the MSI file.  Java will install the old version side by side, other programs will revert to the older version or may keep trying and failing to install the old MSI file.

    The install rules for most programs are pretty simple, provided that you only need to patch programs that you have installed yourself.  In that case you don't need to mess about with registry keys to find the right install paths.

    Here's the rules we use for Flash:

    The Prerequisite rule check that the computer is an x86, since amd64 computers will complicate the rules significantly:
    <bar:Processor Architecture="0" />

    The IsInstalled rule checks the fileversion of the plugin and the activex version:
    <lar:And>
        <bar:FileVersion Path="Macromed\Flash\NPSWF32.dll"  Csidl="37" Comparison="EqualTo" Version="10.0.42.34" />
        <bar:FileVersion Path="Macromed\Flash\Flash10d.ocx" Csidl="37" Comparison="EqualTo" Version="10.0.42.34" />
    </lar:And>

    The IsInstallable rule checks for older version of either file. The reversal of the logic is shorthand to include the case when the files are missing:
    <lar:Or>
        <lar:Not><bar:FileVersion Path="Macromed\Flash\NPSWF32.dll"  Csidl="37" Comparison="GreaterThanOrEqualTo" Version="10.0.42.34" /></lar:Not>
        <lar:Not><bar:FileVersion Path="Macromed\Flash\Flash10d.ocx" Csidl="37" Comparison="GreaterThanOrEqualTo" Version="10.0.42.34" /></lar:Not>
    </lar:Or>

    Monday, January 18, 2010 3:08 PM
  • Thanks for the info Nummedal.  What you describe with the MSI routine sounds about what I would suspect.  You're getting into issues of superseding updates which I haven't dealt with in any meaningful way.  When you release the newer version you need to deal with the old version.  There are rules for indicating if the original install is superseded or not but for my purposes I am just removing the old update before publishing the new one.

    I just released my code so if you're interested take a look: http://www.localupdatepublisher.com
    • Edited by Bryan Dam Tuesday, February 23, 2010 12:47 AM
    Tuesday, January 19, 2010 8:35 PM
  • When an update (locally published or not) is reported as Not Applicable is there any way to track down the reason why?  After some searching I can't find anything but I might very well be 'doing it wrong'.

    As I understand it, when publishing MSI files, WSUS and the Update Agent will use the conditions of the MSI file in determining if the update is already installed, can be installed, or is superseded.  When locally publishing we have the ability to add additional rules.  So it quickly can become a bit of a mess and although you can easily test any conditions you add it's tough to test the MSI's conditions without knowing what they are.


    Tuesday, February 23, 2010 12:06 AM
  • When an update (locally published or not) is reported as Not Applicable is there any way to track down the reason why? 

    Making the distinction between Installed and Not Applicable (which in WSUS are reported in the same composite results)...

    Not Applicable is returned when the logic defined in the Applicability Rules returned a FALSE result. Within the SDP schema this is known as isInstallable=FALSE.

    In the case of MSI packages, Applicability Rules are not used. The Prerequisites Rules should be used to determine OS, architecure, and language applicability, and the remainder of the applicability question is actually defined inside the MSI packaging. So your understanding is partially correct, in that the only ruleset that will be considered when locally publishing an MSI package is the Prerequisites Rules. The only rules you should test are the core system applicability rules -- OS/SP, processor architecture, and OS language.

    For MSP packages, which require a pre-existing MSI-based product, you might also include a Prerequisite Rule that confirms the presence of the MSI package -- but the MSP package will do that anyway, so the only real gain from such testing is a bit of efficency in the scanning process by eliminating the MSP package from machines that do not have the full product installed.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, February 23, 2010 5:35 PM
  • Thanks yet again Lawrence.

    With that understanding, a follow up question:
    If the user hasn't added any Prerequisites rules nor any extra Applicability rules then it's the MSI itself that dictates if it is applicable.  In this case, assuming you didn't create the MSI yourself, is there any way to figure out why it is Not Applicable?
    Tuesday, February 23, 2010 7:41 PM
  • I did misspeak about one comment above... the Applicability and Installed Rules will be evaluated on MSI packages... but ideally they should not be used, as all of that logic should be contained within the MSI packaging.

    But, yes, if there are no defined Prereq rules, then the behavior would be exactly the same as running the MSI from the command line in quiet mode, and would apply to every client of the WSUS server.

    From there, I'd start with forcing the MSI to run and see if it will report (log) any particular reason why it's not installable (or note if/why the installation fails).

    Otherwise, you could try to reverse engineer the MSI package, but likely it may be caused b remnants of some other installation. You might also first try the Windows Installer Cleanup Utility and make sure there are no remnants of things still there that should not be.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, February 24, 2010 3:28 PM
  • Thanks for the suggestions Lawrence.  I ran the update (flash player) from the command line with verbose logging (/L*v) and no UI (/quiet).  It installed without a hitch and the log didn't seem to show any problems but it was still reported as NA after forcing the client to report.

    So what I did was create MSI-ProductInstalled rules to make sure it's not already installed as a prerequisite and to check to see if it's already installed at the package level.  Both refer to the program by it's unique ProductCode and are applied on the root SDP element.  This seemed to work, the machine properly reported its status, and since the rules at the InstallableItem level aren't touched the MSI can add any additional checks it needs.  I'll test further of course but hopefully that takes care of it.

    Wednesday, February 24, 2010 10:18 PM
  • I want to know how to use Microsoft.UpdateServices.Administration.dll in VC6.0 not .net.

    I am using #import "Microsoft.UpdateServices.Administration.dll", but complier output load typelib/dll error.

    Help me.
    Wednesday, March 3, 2010 4:18 AM
  • I don't code in Visual C but I assume you need to add a reference for the namespace before you can import it.
    Wednesday, March 3, 2010 1:28 PM
  • I want to know how to use Microsoft.UpdateServices.Administration.dll in VC6.0 not .net.

    I am using #import "Microsoft.UpdateServices.Administration.dll", but complier output load typelib/dll error.

    Help me.

    The first requirement would be to read the WSUS API documentation.

    Were you to do that, you'd find on the very first page in the very first section, this statement:


    Developer Audience

    The WSUS API is accessible by any language that supports Microsoft .NET, including Microsoft Visual Basic .NET, C#, and managed C++.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, March 3, 2010 6:50 PM
  • Thank you.
       I have read wsus sdk. Now I have installed wsus on my 2003 server, also i am developing on this server. We know we just add refernce if using vb. Now my problem is how to config my solution to import Microsoft.UpdateServices.Administration namespace. There is no header file or idl file, so vs2008 can not identify keyword like "IUpdateServer". I am use OleView.exe load the file failed. Later using ILDasm, yes, I have see the namespace and interfaces.
      Please help me!
    Thursday, March 4, 2010 1:49 AM
  • Tommy, unfortunately this forum is not a Visual Studio tutorial forum.

    While we'll be happy to help you with specific functionality questions about objects, methods, and properties inside the WSUS API, it's not practical to try to undertake teaching you the basics of how to use Visual Studio, set references, etc.

    What I will says is that I'm certain almost all of the answers to "How to use?" will be found in the first few pages of the documentation for the WSUS API, and I would encourage you to thoroughly read and study that documentation, rather than quickly skimming through it looking for quick answers.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, March 4, 2010 1:57 PM
  • I've noticed that when I delete a locally published package the corresponding content in ...\WSUS\UpdateServicesPackages aren't removed.  The WSUS Cleanup Wizard doesn't remove them but that's to be expected.  The API has a cleanup call but calling it with the CleanupUnneededContentFiles scope doesn't remove the locally published content either nor do I see anything there that specifies a way to target specific updates.

    In theory I think I could target the specific folder and cab file on the share by using the Installable Item's GUID but that feels like a dirty dirty hack.  Any ideas of how to use the API to do this properly?  It'd be great to be able to delete the a specific package's content directly but a periodic cleaning of unneeded content would be fine.
    Wednesday, March 10, 2010 2:55 PM
  • I've noticed that when I delete a locally published package the corresponding content in ...\WSUS\UpdateServicesPackages aren't removed.  The WSUS Cleanup Wizard doesn't remove them but that's to be expected.  The API has a cleanup call but calling it with the CleanupUnneededContentFiles scope doesn't remove the locally published content either nor do I see anything there that specifies a way to target specific updates.

    In theory I think I could target the specific folder and cab file on the share by using the Installable Item's GUID but that feels like a dirty dirty hack.  Any ideas of how to use the API to do this properly?  It'd be great to be able to delete the a specific package's content directly but a periodic cleaning of unneeded content would be fine.

    The ~\UpdateServicesPackages folder is a staging folder, if I'm not mistaken. It's primary purpose is as an isolated SHARE point so that remote publishing tools can PUSH the content onto the WSUS server. When the update is "Approved", the WSUS server still needs to "download" that content and put it in the ~\WSUSContent folder to be accessible to clients from the http://servername/Content URL.

    If the update has been deleted from the WSUS catalog, it should be perfectly safe to manually delete the source content from the UpdateServicesPackages folder.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, March 10, 2010 5:50 PM
  • You were not mistaken, of course, that is precisely how that folder is used.  The only difference is that the API's publish method causes the package to be loaded into the WSUSContent folder.  So I was able to publish an update, clear the UpdateServicesPackages folder completely, and subsequently approve and install the update.  Which is great, I can clean out the folder after publishing a package.

    Incidentally, the WSUS Cleanup wizard does remove the locally published packages from the WSUSContent folder.

    Regarding your question months ago about Java updates.  They do run unattended but they fail to install if the user has their browser open.  In practice that means it fails until they shutdown their machine and it is installed successfully at that time.  If there's a better way to deal with these let me know.
    Wednesday, March 10, 2010 7:09 PM
  • You were not mistaken, of course, that is precisely how that folder is used.  The only difference is that the API's publish method causes the package to be loaded into the WSUSContent folder.  So I was able to publish an update, clear the UpdateServicesPackages folder completely, and subsequently approve and install the update.  Which is great, I can clean out the folder after publishing a package.
    But what happens if your run a wsusutil reset when the package content has been accidentally deleted from the ~\WSUSContent folder, and is no longer present in the ~\UpdateServicesPackages folder? I would submit that the UpdateServicesPackages folder content should not be deleted as part of the Publish event, and should only be deleted upon decision and action by the WSUS Administrator.

    Incidentally, the WSUS Cleanup wizard does remove the locally published packages from the WSUSContent folder.
    Yes, for a declined update (or deleted/expired in the case of Locally Published) I would expect that to be the case.
    Regarding your question months ago about Java updates. They do run unattended but they fail to install if the user has their browser open.
    Yep! A critical flaw in the Java installer for failing to check for files in use.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, March 10, 2010 11:01 PM
  • >But what happens if your run a wsusutil resets
    Excellent point, I haven't had to use wsusutil yet so I I hadn't considered it.

    That leads to a follow up question then.  Since I shouldn't be clearing the folder in one clean sweep and the API doesn't provide a way to do it then I need to calculate the correct paths to delete individual packages.  In the UpdateServicesPackages the updates I had published were under a single subfolder called "1" and the cab files used the GUID_1.cab naming convention.  Unlike the WSUSContent folder, this subfolder doesn't seem to be taken from any particular part of the GUID.  So will my packages always go into a "1" subfolder or will a "2" folder pop up someday?
    Thursday, March 11, 2010 12:47 PM
  • In the UpdateServicesPackages the updates I had published were under a single subfolder called "1" and the cab files used the GUID_1.cab naming convention.  Unlike the WSUSContent folder, this subfolder doesn't seem to be taken from any particular part of the GUID.  So will my packages always go into a "1" subfolder or will a "2" folder pop up someday?

    The folder in the UpdateServicesPackages folder should be the UpdateID of the update, and that's how you'll uniquely identify it to delete it.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, March 11, 2010 3:48 PM
  • That seems to be part of the naming convention but not all of it.  In testing I have published about 50 or so packages but none of them were put into the root of the UpdateServicesPackages folder.  The only folder in the root was a folder named "1".  In the "1" directory you would get a folder using the UpdateID as well as a cab file with "_1" appended to the UpdateId.  Yesterday, to test this, I cleaned out the UpdateServicesPackages and when I published a new package and it recreated the "1" folder and placed the package in there.
    Thursday, March 11, 2010 4:24 PM
  • Perhaps you've defined the target folder incorrectly and are unnecessarily causing the creation of a folder level that is not needed? Obviously something is creating the folder based on the UpdateID. Your challenge, then, seems to be to get that folder created in the *share* rather than a subfolder of the share.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, March 11, 2010 9:12 PM
  • And right you are.  The MS examples use 'null' for the package directory name.  That doesn't complie in VB so I used vbNull instead.  That works for compilation but rather than use the default directory name it used 1 everytime.  Change it to Nothing and it starts behaving properly.

    Thanks for pointing me in the right direction.
    Thursday, March 11, 2010 9:41 PM
  • This is more likely a quirk/manifestation of VB not being able to initialize objects as NULL, than it is anything else. Forcing the object to "Nothing" after initialization elminates the default initialization of that folder object.

    Consider that the actual code for this product was likely written in VC#, which does not have that limitation with respect to initializing NULL objects.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, March 11, 2010 10:02 PM
  • Question about update categories in relation to local publishing.  When I locally publish a package, WSUS automatically creates a root category  for the Vendor and a subcategory for the Product in which the updates are placed.  What then is the intent of the built-in Local Publisher root category and its Locally Published Packages subcategory?  Nothing seems to be automatically going there, is there a reason to make sure locally published updates get added to that category?
    Tuesday, March 16, 2010 1:24 PM
  • What then is the intent of the built-in Local Publisher root category and its Locally Published Packages subcategory?
    A great question, but not one I have an answer for.

    Packages are created in Vendor nodes, which are peers to the "Microsoft" node, which is the parent of the various product categories provided in the native environment. The "Microsoft" node, and other vendor nodes, are immediate children of a hidden root node called "All Updates", but on my servers with locally published content, I also see nothing contained in the "Local Publisher" node. It's possible this node is designed to contain content that does not have a Vendor, e.g. truly LOCAL content -- created and published by the end-user themselves. A good test would be to create a package and leave the Vendor attribute empty and see what it does when published.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, March 16, 2010 10:25 PM
  • I haven't tested a package without a vendor or product but your intuition is correct.  I read the documentation for the basic metadata more closely and it states that those are the default vendor and product.  From the very beginning I prevented those two fields from being empty so that explains why those categories aren't used.

    Tuesday, March 16, 2010 10:43 PM
  • Most other things dealt with, I'm looking at dealing with update catalogs.  Not as difficult as I might have thought; the API comes through again.  One feature that would be useful, at least for my own project, would be the ability to optionally include the binaries in the catalog CAB file.  This would make is dead simple to create an update in a test environment and then move it to production.  This isn't hard to accomplish but I'm wondering if there's a standard way to do it.  Do you know of any existing catalogs that do this?
    Wednesday, June 30, 2010 4:03 PM
  • Most other things dealt with, I'm looking at dealing with update catalogs.  Not as difficult as I might have thought; the API comes through again.  One feature that would be useful, at least for my own project, would be the ability to optionally include the binaries in the catalog CAB file.  This would make is dead simple to create an update in a test environment and then move it to production.  This isn't hard to accomplish but I'm wondering if there's a standard way to do it.  Do you know of any existing catalogs that do this?


    Your primary challenge with putting binaries in the CAB file (aside from violating the Microsoft specifications for the contents of that CAB file) will be the redistribution rights for the binaries from the vendors. Many vendors require special redistribution agreements for "middle men" ... their primary interest being the assurance of the integrity of the package when it arrives on the end-user's machine.

    For personal use, though, you could certainly do that -- but to what end. The whole point of a catalog file is distribution of content to another person or system -- at which time you've likely crossed the line into being a "redistributor" of the vendor's content and subject to those restrictions anyway.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, June 30, 2010 8:17 PM
  • I agree.  The only rationalization is for transferring odd or customized apps between one's own systems, specifically from a testing environment to production.  It's not a huge use case so I'm not really too concerned about it; if there was a standard way to do it then I would be sure to follow.  To be clear, I have no intention of distributing CABs which include binary files beyond my own organization.
    Wednesday, June 30, 2010 8:47 PM
  • I agree.  The only rationalization is for transferring odd or customized apps between one's own systems, specifically from a testing environment to production.  It's not a huge use case so I'm not really too concerned about it; if there was a standard way to do it then I would be sure to follow.  To be clear, I have no intention of distributing CABs which include binary files beyond my own organization.
    While *you* may not have any intentions, you've made the decision of publishing your code via Open Source, and *others* may have such intentions. If you build functionality into your source library that can cause others to engage (knowingly or otherwise) in illegal behavior (i.e. violating a vendor's binary redistribution licensing) you may have some liability.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, July 1, 2010 3:25 PM
  • Fair enough; thanks for the food for thought.  I'll try and mitigate the issue by using the signed CAB files created by WSUS.  This  would make distribution outside of one's organization worthless since it wouldn't import without identical certificates.

    For what it's worth, if one is to be concerned on this particular point then allowing catalog exports at all is a problem.  Adobe specifically states in their licensing agreement emails that you are not permitted to share the link to their binary files on their site.  So any software (ie. SCUP) that lets you export a standard catalog is open to a similar sort of liability.

    Thursday, July 1, 2010 8:11 PM