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.

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.

Currently a client receives an 'available' SUP list to select a SUP to sync from with the sproc MPGetWSUSServerLocationsWithBGR. This sproc requires a parameter called iContentVersion, which the client receives through machine policy and is the ContentVersion of the Primary SUP, even if the client is using a secondary SUP. The sproc however does not offer SUPs with lower ContentVersions, thus if the client's secondary SUP is at least 1 version behind its Primary's the current secondary (Boundary Group local) SUP won't be offered for the client. Also, if Fallback is enabled and due to the ContentVersion mismatch the secondary (BG local) SUP is not offered, the clients will immediately fall back as the grace period does not apply in this case.

Suggestion is to allow the Secondary SUP with a lower ContentVersion to be offered and/or use the defined fallback time in cases when the current SUP is not available in the list before the client falls back to another SUP.