With the introduction of tenant attach, there is a growing need to be able to grant ConfigMgr permissions to AAD objects.

In many environments ConfigMgr admins have following accounts:
- a normal user account which is synced to AAD
- an admin account which is not synced to AAD
- an AAD-only account for the cloud stuff

When you implement the tenant attach, you need an AD account that is synced to AAD & have permissions in ConfigMgr. None of those accounts is a perfect solution.
1) Don't want to grant any ConfigMgr rights to the normal user
2) Don't want to sync on-prem admin accounts to AAD
3) Cannot grant ConfigMgr rights to AAD users/groups

Thus, it would be useful to be able to grant ConfigMgr rights to AAD users/groups, so the admin wouldn't need any additional account for tenant attach operations.

-Problem overview
If you deploy the application under the following conditions, the running application will be killed immediately after the download phase.
The customer has set "Maintenance Windows", and the problem is that the application is killed at a timing outside the "Maintenance Windows" range.

This behavior is reproducible. (Confirmed with MECM 2002) I want to confirm whether this behavior is a by design or a known issue.

-Repro step
1. Set "Maintenance Windows" to the device collection. The next step is to set the installation deadline before entering "Maintenance Windows".

1. In the application's Deployment Type properties, on the Install Handling tab, specify the appropriate process.
   This time, notepad.exe is specified for reproducibility confirmation.




2. Deploy with the following settings.
   (repro-step3.jpg)




3. [Automatically close any running executables you specified on the install behavior tab of the deployment type properties dialog box]
   > Check this item.
   (repro-step4.jpg)




4. On the client side, run notepad.exe, run the evaluation cycle, and receive the new deployment.




5. notepad.exe is killed after the application content is downloaded to ccmcache.
   The application content itself has not been installed yet, so it has been killed immediately after the download is complete.

Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.
This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application, I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears based on the ‘Minimum duration before cached content can be removed’ client setting and there is no problem. However, there is one specific and prevalent use case where it is: stupidly large applications.
There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size on a day-to-day basis. Admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply should not be that for a system designed to deploy applications.
So, what to do? One option would be to simply not cache apps that exceed the limit and/or delete them immediately upon successfully detecting the app. Another option would be to do what Software Updates do: allow them to violate the cache limit. Maybe that becomes a deployment option: Allow deployment to violate cache limits. The only hard limit that should be allowed to break a deployment is the amount of free disk space to
TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

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.

Microsoft Case ID: [Case #:24522893] - TrackingID#120121125002133.

While troubleshooting on the case we noticed that Windows Defender was performing 2 WMI queries through SCCM every minute, even when Defender was disabled on the system. These queries generate about 70.000 events (detected via procmon) related to the registry every minute.

The cause of the query is ccmexec.exe
The queries are (detected via procdump):
select * from _instancecreationevent within 60 where targetinstance isa "win32service" and ( targetinstance.name="msmpsvc" or targetinstance.name="windefend")

select * from _instancemodificationevent within 60 where targetinstance isa "win32service" and targetinstance.state="running" and ( targetinstance.name="msmpsvc" or targetinstance.name="windefend")

Antivirus scans those actions (as any Antivirus program does), and as a result the CPU usage caused by these WMI queries was multiplied.
 
These queries cannot be disabled, while it was confirmed by Microsoft that these queries are not required in case an external thirdparty antivirus program is being used.
 
The advised approach was to try to minimize the amplification by Antivirus, which indeed added a positive impact. Detailed tuning of the antivirus policy with a focus in these WMI queries resulted in a reduction of the amplification.

It was agreed that this solution is an acceptable work around. And for the WMI Queries to be disabled, we already have a Design change request in place with SCCM Team to take this into consideration and validate if this could be resolved in upcoming versions. I was advised to raise this issue in the Microsoft User Voice in order to gain support for this Design change request.

See process explorer printscreen:

For a Task Sequence, any content you have referenced and as long as you have "Download All Content Before Starting" set on the Deployment, it will download the Content into the CCMCache using BranchCache. However, we don't want to "Download all Content before Starting" in several situations, and in those cases, The Task Sequence doesn't leverage BranchCache at all for the download, which is VERY Bad.

Please enable the ability for a Task Sequence to leverage BranchCache during an active Task Sequence when it downloads content during the Task Sequence.

Priority 1, Make this work in Full OS
Priority 2, Make it work in WinPE

As per Microsoft documentation,

While Windows 10 feature updates remain in public preview, when co-managing devices with Configuration Manager and Intune, there is a limitation where feature update policies may not immediately take effect, causing devices to update to a later feature update than configured in Intune. This limitation will be removed with a future update to Configuration Manager.

When is this bug scheduled to be resolved?

We have recently moved the Windows Update workload to Intune and now have to pause the feature upgrades for each WUFB ring every 35 days to prevent devices from randomly upgrading to the latest version of Windows 10.