How to get software deployment package contents using PowerShell? RRS feed

  • Question

  • Anyone know how to do this?

    I know how to retrieve the package, but I have not found any way to retrieve the contents of a package using PowerShell and nothing comes up using Google/Bing. 


    Monday, August 12, 2019 11:30 PM

All replies

  • Assuming that you mean the source path of the package, it's simply the PkgSourcePath of the IResultObject#SMS_Package object returned by Get-CMPackage; e.g. (Get-CMPackage).PkgSourcePath will list all package source paths for all packages in your environment.

    Jason | | @jasonsandys

    Monday, August 12, 2019 11:52 PM
  • No, I mean the actual content in the package itself. 

    Is that possible?

    Tuesday, August 13, 2019 12:10 AM
    • Edited by NikNicholas Tuesday, August 13, 2019 12:58 AM
    Tuesday, August 13, 2019 12:56 AM
  • No, I mean the actual content in the package itself. 

    Is that possible?

    You can use Jason method to get the source path of the packages .Once you got the package, you can use powershell or any other scripting to copy the content of the source path to location that you want.

    There is no builtin Configmgr powershell that does this for you ,infact getting the content from the source path can be done by various methods like vbscript ,batch ,powershell etc which has no relation with Configmgr.

    what are you trying to achieve from this ?

    Eswar Koneti | Configmgr Blog: | Linkedin: eskonr | Twitter: @eskonr

    Tuesday, August 13, 2019 8:20 AM
  • System Center Configuration Manager Cmdlet Library
    The following versions of Configuration Manager are supported in this release:
    System Center 2012 R2 Configuration Manager SP1

    Specifies the Universal Naming Convention (UNC) path to which you export the package. This path must end with the filename extension .zip.

    Indicates whether to include content in the package.

    Indicates whether to include dependencies in the package.

    Example 1: Export a package by using an ID
    This command exports a package that has the ID ST120001 to the output path \\Deploy01\ExportPackages.

    Export-CMPackage -Id "ST120001" -ExportFilePath "\\Deploy01\ExportPackages"

    However, it does say "This path must end with the filename extension .zip." above. I have seen this before where MS documentation is incorrect and/or incomplete for cmdlts. So I would also try:

    Export-CMPackage -Id "ST120001" -ExportFilePath "\\Deploy01\ExportPackages\" if thier example failed.

    But really, with this:
    Export-CMPackage -Id "ST120001" -ExportFilePath "\\Deploy01\ExportPackages" -WithContent -WithDependence

    Should give you Full Package detail in xml form and package source and dependence source also.

    Tuesday, August 13, 2019 7:15 PM
  • So, I would need to export the package first?

    Okay, maybe this is an easier question, how would I get the contents of a Software Update Group using PowerShell? 

    What I am trying to do is to resign 3rd Party updates that have an invalid cert since ours expired and my 3rd Party ADRs keep failing with the 0X80073633 error. 

    So, the idea is to do to the following:

    1. Get the contents of a SUG, which is better than the package now that I think about it and then.
    2. Then get the properties of the update to find where it is located locally (WsusContent folder).
    3. Then get the .cab file details of the update to find the serial number (Digital Signatures > Details > Advanced > Serial number:
    4. Then compare that serial number with the current WSUS certificate's thumbprint.
    5. If they don't match, then identify that update so it can be resigned.

    This is basically it in a nutshell. 

    BTW, I am using Ivanti patch integrated in the SCCM console. 

    Thursday, August 15, 2019 4:07 PM
  • Software Update Groups don't have any content associated with them so you don't. Content is only associated with update packages.

    What you are asking about above though isn't the source content location of an update group though (as noted, there is no such thing), it's the source/download location for each update. Because an update may have many source files associated with it also, this isn't a simple query and requires traversing a one to many relationship that will involve multiple joins although I don't know what those are off-hand.

    Why not just resign all updates published by Ivanti *and* ensure that they are being signed using authenticode and time-stamping so that certificate expiration is irrelevant? Otherwise, you're just going to have to go through this again.

    Jason | | @jasonsandys

    Thursday, August 15, 2019 4:35 PM
  • Yeah, I guess I could just resign all of them, but if there were any that were deployed earlier which many have been, then i have to re-run a sync, then delete the deployed updates from the package, then go to the SUG and re-download them again. The issue here is that I came in here to help this company out and they have had WAY too many consultant's hands in the SCCM cookie jar and it has become very ugly. So, I guess I will have to just clean up the mess and do what you have recommended. 

    I really wish supposed SCCM SMEs would get up to speed with SCCM best practices and stop creating new deployment packages every patching cycle where they basically remove the benefits of Single-Instance-Store. What they have done was create ADRs that will create new deployment packages every patching cycle and then they would mimic that package in the SUG. So, I have had to explain to the Managers that this not the best way to do it and use at the most two deployment packages per year just to ensure that you dont go over a 1,000 limit which is what I use. So, I am now trying to get this done to clean up the mess by using ADRs that will dump patches every patching cycle NOT in a new deployment package, but the same one, but create new SUGs for each patching cycle and identify them by their patching month (e.g. 2019 - 08 - AUG - Patch Cycle). The other way they were doing it with several new packages, they were duplicate updates from previous patching cycles being tossed in the new packages. They were also using the Date Revised/Released criteria in their ADR which I HATE, so I removed that altogether. 

    Anyway, I need to clean up and will try and get that done without ripping out my hair. 

    Thursday, August 15, 2019 5:28 PM