Today, when you install the CM Console, the PowerShell module will be placed under the %CMInstallDirectory%\AdminConsole\Bin\ConfigurationManager.psd1

This makes sense given where the user is choosing to install the console, and that's fine. But placing it here off the beaten path means that it is not importable using PowerShell's module autodiscovery features. For instance, if a module is found in any of the standard user or system paths (or registered under the $ENV:PsModulePath) the user can easily import the module without having to specify the full path, a big user quality of life win. This is the way that SQL Server handles their modules, and they are the golden child, beloved by all PowerShell nerdoes like me.

So, my suggestion is to continue placing it where it is today, and also register the path using the standard mechanism, excerpted below.

https://msdn.microsoft.com/en-us/library/dd878350(v=vs.85).aspx

My idea is to have the scenario described below supported.

When running Save-CMSoftwareUpdate command on a CMSite-PSDrive that connects to a ConfigMgr site in a different domain (used Get-Credential to pass credentials in New-PSDrive call) than the user account the PowerShell window is running as, I get error 'The RPC server is unavailable'.

I can successfully change location to the PS drive, and run other ConfigMgr PS cmdlets.

Commands:
New-PSDrive -Name <sitecode> -PSProvider 'CMSite' -Root <siteserverFQDN> -Credential (Get-Credential)
Set-Location <sitecode>:
Save-CMSoftwareUpdate -SoftwareUpdateName <name> -DeploymentPackageName <name> -Verbose

Verbose output from Save-CMSoftwareUpdate call:

VERBOSE: Start: Execution of WQL query: Select * from SMSSoftwareUpdatesPackage where Name='Office 2016'
VERBOSE: Finish: Execution of WQL query: Select * from SMSSoftwareUpdatesPackage where Name='Office 2016'. Processed 1 results in 00:00:00.0533413.
VERBOSE: Performing the operation "Save" on target "SoftwareUpdate: Name="Office 2016"".
VERBOSE: Start: Execution of WQL query: SELECT * FROM SMSSoftwareUpdate WHERE LocalizedDisplayName IN ( 'Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition' )
VERBOSE: Finish: Execution of WQL query: SELECT * FROM SMSSoftwareUpdate WHERE LocalizedDisplayName IN ( 'Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition' ). Processed 1 results in 00:00:00.0858704.
VERBOSE: Start: Execution of WQL query: select distinct cic.ContentID from SMSCIToContent cic where cic.CIID=16796196 and cic.ContentID not in (select pc.ContentID from SMSPackageToContent pc where pc.PackageID='ECN0006C') and (cic.ContentLocales='Locale:0' or cic.ContentLocales = 'Locale:9')
VERBOSE: Finish: Execution of WQL query: select distinct cic.ContentID from SMSCIToContent cic where cic.CIID=16796196 and cic.ContentID not in (select pc.ContentID from SMSPackageToContent pc where pc.PackageID='ECN0006C') and (cic.ContentLocales='Locale:0' or cic.ContentLocales = 'Locale:9'). Processed 1 results in 00:00:00.0000256.
VERBOSE: Start: Execution of WQL query: select * from SMSPackageToContent where ContentID=16790019 and PackageID='ECN0006C'
VERBOSE: Finish: Execution of WQL query: select * from SMSPackageToContent where ContentID=16790019 and PackageID='ECN0006C'. Processed 0 results in 00:00:00.
VERBOSE: (SMSPackageToContent.ContentID=16790019,PackageID='ECN0006C') does not exist or its IsContentValid returns false. We will (re)download this content.
VERBOSE: Using 64-bit content downloader
VERBOSE: Downloading update content CIID='16790019' Content Source Path='\ecn-badcm\updatePackages\Office 2016' Download Location='' Provider='ecn-badcm.BoilerAD.Purdue.edu' Second Chance='False'
VERBOSE: Result: 1722 (0x000006ba)
Save-CMSoftwareUpdate : The RPC server is unavailable
At line:1 char:1
+ Save-CMSoftwareUpdate -SoftwareUpdateName "Update for Microsoft Offic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidResult: (Microsoft.Confi...reUpdateCommand:SaveSoftwareUpdateCommand) [Save-CMSoftwareUpdate], Win32Exception

+ FullyQualifiedErrorId : DownloadContentError,Microsoft.ConfigurationManagement.Cmdlets.Sum.Commands.SaveSoftwareUpdateCommand

Save-CMSoftwareUpdate : The following updates failed to successfully download: Update for Microsoft Office 2016 (KB4018322) 64-Bit Edition
At line:1 char:1
+ Save-CMSoftwareUpdate -SoftwareUpdateName "Update for Microsoft Offic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (Microsoft.Confi...reUpdateCommand:SaveSoftwareUpdateCommand) [Save-CMSoftwareUpdate], InvalidOperationException

+ FullyQualifiedErrorId : DownloadUpdateFailed,Microsoft.ConfigurationManagement.Cmdlets.Sum.Commands.SaveSoftwareUpdateCommand

Monthly updating of applications like FlashPlayer, Java, Chrome, Reader DC, Office 365 Client, etc. are repetitive and tedious, so I like to automate monthly applications updates as much as possible. When creating a new application using powershell, I cannot set the "Uninstall content setting" located under the Deployment Type and the Content tab. This allows me to save on downloading large sets of files to uninstall when either an "MSIEXEC /X {GUID}" handles it with no files required, or something like Office 365 Client where 1.5 GB is needed to install, but only 5MB or so to uninstall.

The command I figure this should be a part of is both, "Add-CMMsiDeploymentType" and "Set-CMMsiDeploymentType". Something like "-UninstallContentSetting" with set values of : <SameContent | NoContent | DifferentContent>. Then you'd need another parameter to specify the location if you choose "DifferentContent", something like "-UninstallContent" or alias "-UninstallContentLocation" with a <String> path to the folder.

Without this command capability automation is broken and I have to manually make the change. (I do have automation breaks with Detection Methods and Requirements as well due to complexity of trying to use the PS method, but back to the point). If I've missed something and this is indeed available already, do let me know how to do it.

The Import-CMPackage cmdlet does not provide much in the way of verbose output with the -verbose flag. This would be useful to identify what the cmdlet is performing in the background to determine if package already exists with the same name or not.

Steps attempted:
$Global:VerbosePreference = "Continue"
$Global:DebugPreference = "Continue"
$Global:CMPSDebugLogging = $true

import-cmpackage -ImportFilePath "\localhost\c$\Users\Testing\TestPkg.zip" -Verbose

Output: Verbose: Performing the operation "Import" on target "Package: ".

Trace-Command -Name metadata,parameterbinding,cmdlet -Expression {Import-CMPackage -ImportFilePath "\localhost\c$\Users\Testing\TestPkg.zip" -WhatIf} -PSHost
DEBUG: ParameterBinding Information: 0 : BIND NAMED cmd line args [Import-CMPackage]
DEBUG: ParameterBinding Information: 0 : BIND arg [\localhost\c$\Users\Testing\TestPkg.zip] to parameter [ImportFilePath]
DEBUG: ParameterBinding Information: 0 : COERCE arg to [System.String]
DEBUG: ParameterBinding Information: 0 : Parameter and arg types the same, no coercion is needed.
DEBUG: ParameterBinding Information: 0 : Executing VALIDATION metadata: [System.Management.Automation.ValidateNotNullOrEmptyAttribute]
DEBUG: ParameterBinding Information: 0 : BIND arg [\localhost\c$\Users\Testing\TestPkg.zip] to param [ImportFilePath] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : BIND arg [True] to parameter [WhatIf]
DEBUG: ParameterBinding Information: 0 : COERCE arg to [System.Management.Automation.SwitchParameter]
DEBUG: ParameterBinding Information: 0 : Parameter and arg types the same, no coercion is needed.
DEBUG: ParameterBinding Information: 0 : BIND arg [True] to param [WhatIf] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : BIND POSITIONAL cmd line args [Import-CMPackage]
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK on cmdlet [Import-CMPackage]
DEBUG: ParameterBinding Information: 0 : CALLING BeginProcessing
DEBUG: Begin execution of cmdlet: Import-CMPackage
DEBUG: Acquiring ConnectionManager
DEBUG: Using property 'SiteCode' for site code discovery if applicable.
What if: Performing the operation "Import" on target "Package: ".
DEBUG: ParameterBinding Information: 0 : CALLING EndProcessing
DEBUG: End execution of cmdlet: Import-CMPackage Execution time: 00:00:00.0020000

Companies are looking for alternatives to the large public CA authorities like Verisign and DigiCert, one such alternative is Let's Encypt. They offer free public-signed certificates, the only problem is the certificates need to be renewed every 90 days. The renewal can be automated using Certbot.

However there does not appear to be any functionality in the current ConfigMgr release to allow for automated certificate replacement/renewal. This seems to be a gap in the PowerShell functionality.

Sure its only a few minutes every 90 days to log into the console open up the CMG instance and update the certificate, and this is not an issue if you only have 1 CMG but if you have multiple CMGs or CDPs that need updated certificates this could become very time consuming.

Automation is the key and if we had an ability update these certificates from a PowerShell cmdlet it would help with the whole automation process.

Paging Adam Meltzer.
I’ve spent the last couple of weeks writing a PowerShell script to provide end-to-end maintenance of software updates. My goal was to use the CM cmdlets as much as possible. While I think I have everything working the experience leads me to make the suggestions below. In all honestly; maybe I’m just doing it wrong and there is a way to do the things I couldn’t figure out.
The documentation for Get-CMSoftwareUpdateDeploymentPackage says that it returns a CMSoftwareUpdateDeploymentPackage object but it’s actually returning WqlResultObjectBase. Maybe I’m just supposed to cast it but I failed trying.

I could not find a way to map a given update to the update groups (SUG) that it was a member of.

I could not find a way to map a given update to the deployment package that it was part of.

I could not find a way to map a given deployment package update to its subfolder in the source directory and had to rely on a WMI query on SMS_PackageToContent.

There appears to be no Remove-CMSoftwareUpdateFromDeploymentPackage cmdlet. So even if I could figure out what deployment package an update is in I’m not sure I could remove it.

It would be beneficial to have Remove-CMSoftwareUpdateFromGroup support an -All flag that intelligently removes all SUG memberships. Currently I forced wildcard handling and passed it ‘*’ for the SUG name. It works but is super inefficient as it tries to remove it from every SUG rather than just the ones it’s a member of. That’s a problem that scales by the number of SUGs. This would be alleviated if I could determine SUG membership and selectively remove.

Lastly, the Get-CMSoftwareUpdatePointComponent, Get-CMSoftwareUpdatePoint, and Get-CMSoftwareUpdatePointComponent cmdlets don’t have direct properties like their Set counterparts. You’re forced to parse a props array and figure out which of the value members.

Again, maybe I’m just doing it wrong in which case feel free to simply that out.