The Current Branch 2002 release introduced a feature to install SSUs first but only when triggered by the deadline.
From the docs:
"SSUs are installed first only for non-user initiated installs. For instance, if a user initiates an installation for multiple updates from Software Center, the SSU might not be installed first."

A lot of work has been put into encouraging user-participation in the patching process. I want the user to decide when they're ready to install the updates and avoid situations where the deadlines impact their work. In those scenarios the behavior introduced in 2002 therefore not helpful.

I realize that if a user manually triggers the installs one-by-one that there's not much you can do about it. However, in pretty much every other scenario I would like to see the SSU install first.

For example:
User schedules the install from the update notification dialog.
User clicks 'Install All'.
User select multiple updates, including an SSU.

When deploying third-party updates using CMG, the client will detect it's on the internet. In the CAS.log, you will see it things it should reach directly out to windows updates (WUMU) in the CAS.log. The DP returned on ContentLocation.log is actually the internal WSUS location of where the third-party update was downloaded. This path is not resolvable from an internet client and shouldn't be used.

If the client detects it's on the internet, it should never attempt to download from windows updates, since these updates are not applicable for that scenario. The update will timeout after 3 minutes and 3 download failures and will then fallback to CMG. This timeout can cause a lot of time.

For a repro, please see our YouTube video here: https://youtu.be/rZXexnGyee0?t=1041

Given a scenario of an application group which contains more than one application: if any application in that group requires a reboot the whole application group is terminated with an error (AppGroupHandler - InternalProcessAppRules failed with error 0x87d0032e) even though the application which demanded the reboot was installed correctly.

The expected behaviour is to perform the reboot and then continue with the next application in line in the application group after the reboot.

It would be beneficial if any reboot request in the application group process were internally remembered and only one reboot request would be sent to the user after the completetion of the whole application group.

It would be even better if any application in an application group could demand a reboot and the request would be sent to the user. After the user reboots the machine the application group should then continue with the next application in line.

When a user clicks on an application in Software Center while it is available (or pre-deadline) then all dependent and superseded applications should ignore the user's maintenance window. The current behavior is that if a reboot is needed in the chain then the user has to click install again in Software Center. This could be handled by a deployment option so that the current default behavior isn't impacted.

Example:
User Clicks on App1
App1 has a dependency on App2
App2 requires reboot
When user clicks App1, App2 should install, then reboot, then App1 should complete installation and reboot if needed without another key press by the user or waiting for a maintenance window.

Add a custom Return for applications. "Clears Install History"

I'm currently deploying office 365, which when launched, prompts users to close apps and continue, however they can click cancel. If they click Cancel, it returns a code to CM which is then logged as a failure. I would like to have a Return Code option in the App DT that says, it the App returns code "123456", then exit out as if it never ran, no failure, no success. So in the software center, the icon says "Install" instead of "Retry", and not show a previous failure. It makes our metrics look bad and causes questions, when there wasn't a real failure. The user just decided to "defer" until later.

As we move workloads to Intune, there may be an existing, legacy mechanism that prevents the workloads from successfully being enabled. A Management Insight would alert the admin, if a client scoped for co-management, was also assigned a policy that would prevent the workload from moving successfully.

For Example:-

1. Moving the WUfB workload to Intune.

A legacy GPO that "Disables Automatic Updates" will render updates disabled after the workload is moved to Intune - there is not an equivalent CSP that "Enables Automatic Updates" that gets pushed from Intune Policy to override/block the GPO

1. Move Office C2R Apps to Intune

The OfficeMgmtCOM remains enabled when moving the workload to Intune. The COM+ app needs disabling by setting the registry value
HKEYLOCALMACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate OfficeMgmtCOM = 0

Clients that have the workload moved to Intune for Office C2R Apps may still be in scope for a GPO or Client Setting that re-enables the OfficeMgmtCOM

Currently, when "Suspend BitLocker PIN entry on restart" is set to Always, if the user initiates the restart Bitlocker PIN entry will not be suspended. This makes sense if we assume that the user is sitting at their computer when they trigger the restart. Unfortunately, due to COVID-19, we currently have many users accessing their onprem computers via RDP. If ConfigMgr prompts them to reboot and they click reboot over RDP, there computer will reboot and prompt for PIN entry, requiring the user to physically go in to the office and enter the PIN.

Bitlocker Network Unlock would likely be the best way to address this issue. This option requires additional infrastructure to be built.

One way to address this would be to rename the current "Always" option to "If User Not Present". Then, add a new option that will always suspend PIN entry for reboots initiated by the ConfigMgr client.

We need a way to use PowerShell (script) to trigger a Reboot using the Software Center Dialogs. This way we can trigger a reboot at the end of an install which will leverage the CM built-in notifications.
https://docs.microsoft.com/en-us/configmgr/core/clients/deploy/device-restart-notifications

Currently, if you have a deployment that triggers a pending reboot, the machine with NOT actually reboot after the install, but instead waits for the deadline. Or if the Deployment had no deadline, the machine will never actually reboot.

We need a way to have CM trigger a reboot that we can call in a script, so at the end of an application install (or other use case), we can call the command to have the CM Reboot Countdown trigger (based on client settings) and reboot the machine.

More info in this Thread: https://twitter.com/adammeltzer/status/1249756471211909121