When parameters are provided on a 'Run Powershell Script' in a task sequence, the SMSTS.log only logs the name of the script. It does not log the full command (including parameters) that are invoked.

For example: if I call Java.ps1 with parameters -level 1 -language eng the SMSTS.log only shows...

Running powershell script: 'Java.ps1'(PkgID: SCM00000) with execution policy 'Bypass'

This would be helpful in troubleshooting what parameters were actually passed to the script that is executing. Otherwise you have to track down the task sequence and assume everything entered is passed and run. Or you have to build your PS1 to output(Write-host) those parameter inputs to force them into the SMSTS.log

The docs that exist for the CM Messaging (note, the messaging SDK is not a part of the larger CM SDK docs here https://msdn.microsoft.com/en-us/library/hh442686(v=cmsdk.16).aspx) is currently a .chm Help file, which is lovably nostalgic.

However it doesn't do justice to the power of the SDK. For instance, Discovery and hardware inventory are barely covered in the SDK docs. I'm troubleshooting an issue now with the Messaging SDK in which a fake CM Client appears with Windows 6.2 NT Workstation, even though it is a fully patched Win10 machine. Weird stuff.

Anyway, it would be great if the docs were not a .chm file, but redone in the lovely style we have here: https://msdn.microsoft.com/en-us/library/hh442686(v=cmsdk.16).aspx

In the interest in making my OS deployment task sequences as fast and as optimized as possible, I always optimize WIM files anytime they're updated or re-created.

In my build/capture task sequence, I add a step at the very end before capture to run DISM /StartComponentCleanup /ResetBase so that all of the superseded updates are removed from the base image before it is captured. This results in a smaller WIM file and obviously, faster deployment times.

With the built-in Offline Servicing option for OS images, once new updates are added, they remain in the component store of the image when the image is unmounted, and also, all of the deleted/superseded files still remain inside the [DELETED] folder in the root of the WIM database because the image is not exported once it is updated by Configuration Manager so the WIM file continues to grow larger and larger every time it is updated using Offline Servicing.

Presently, I have a script I've created, 'Optimize-WIMFile.ps1', that I run against the WIM file source after it is updated via Offline Servicing that does the following:
- Mounts the specified OS WIM
- Runs 'DISM /Image:Mount /StartComponentCleanup /ResetBase' if
the image supports it (i.e. OS version greater than Windows 7)
- Unmounts the WIM
- Exports the WIM file to remove all deleted or replaced data using
DISM module's Export-WindowsImage

Since Offline Servicing is already mounting the WIM for you on the server when updating it, there should be an option (a simple checkbox would suffice) to "Remove superseded updates" after the image is updated that essentially runs DISM /ResetBase against the WIM while it is still mounted before unmounting it.

After the WIM is updated and unmounted, it should then be exported to clean up the removed data - I'm not sure why this is not already a default. The WIM file will only grow in size with all of the old deleted junk every time you update it if it is not exported. You could even make an option for this as well with a drop-down menu that lets you choose the compression level on the WIM when exporting to the final image.

I've tried to automate this process completely by making a script that triggers the OfflineServicing schedule on all of my OS images in Configuration Manager and then calls my Optimize-WIMFile script, but the problem is that I can't find any way to track status of the offline servicing on each image to know when it's safe to begin optimizing the WIM, as Get-CMOperatingSystemImageUpdateSchedule is not returning anything when the schedule is created to run immediately so I have to wait for all of the servicing to complete, and then manually run the optimizations.

This would make sooo much more sense to have built-in to the OfflineServicing since it's literally two simple commands run against the WIM. Please take it into consideration!

It would be helpful to have the ability to select OR as a Connector Value (which only has 2 states AND, OR) for the AddDetectionClause of Add-CMScriptDeploymentType
The best example of this is when trying to create a ConfigMgr Client Update application. The client has a different GUID depending on whether it is x86 or x64.

Why am I making a separate application deployment for the client upgrade as opposed to the built in one? The built in one will not use the files local to itself and pull the entire content accross the WAN again. So building an application that uses "ccmsetup /source:%~dp0" to use local source is a better solution.

#Deployment *******NEED ABILITY TO SET OPERATOR FOR -ADDDETECTIONCLAUSE TO "OR" DEFAULT IS "AND"
$Detect1 = New-CMDetectionClauseWindowsInstaller -ProductCode $APPGUIDx64 -Existence
$Detect2 = New-CMDetectionClauseWindowsInstaller -ProductCode $APPGUIDx86 -Existence
$DeployedApp = Add-CMScriptDeploymentType -ApplicationName $APPName -DeploymentTypeName $DepTypeName `
-Comment $DepTypeComment -ContentLocation $DepContLoc -EnableBranchCache -CacheContent `
-InstallCommand $DepInstProg -UninstallCommand $DepUninstProg -UninstallWorkingDirectory $DepUninstLoc `
-AddDetectionClause($Detect1,$Detect2) -InstallationBehaviorType InstallForSystem `
-UserInteractionMode Normal -LogonRequirementType WhetherOrNotUserLoggedOn `
-ScriptLanguage PowerShell -ScriptText "#" -SlowNetworkDeploymentMode Download

Creating SCCM Collection Queries is an art, and like most art, some of us are more suited to stick-figures while others produce beautiful creations worthy of a place in the Louvre, featuring graceful sub-queries, artful tabbing and good code practices.

When creating a collection, it would be helpful to have an optional 'Community Collection Catalogue' to choose from, which could have a user-voice style 'Most useful' collections list.

Users could create collections here, possibly even having a community 'wish-list' area for those without skills to request from those who would like to share.

Contributions in the community catalog could be counted for MVP or other recognition, possibly displaying badges. Gamification elements could be added, including Facebook or Twitter links to individual contributions.