Here is the User experience for the update process as I understand it:

1. System tray balloon appears saying 'software changes are required'

2. System tray balloon appears saying 'downloading and installing software'

3. System tray balloon appears saying 'Restart required: Recently installed updates require your machine to be restarted'

4. *It is here I would like the larger temporary notification reboot window to appear but it doesn't.

5. Permanent notification reboot window appears and stays on the screen

I would like option 4 to be possible. Without this it seems quite easy for users to miss seeing the balloon notification and therefore not know that a restart is coming.

It would be good if there was an option in Client Settings > Computer Restart to automatically show the temporary restart notification window. It would also be good if there was an option here to permanently set the 'SCNotification.exe' in Notification Area Icons to 'show icon and notification' to further improve the visibility to users of pending restarts so they know to save their work before they leave their computer for lunch or when they go home.

I've attached an image of the temporary notification window I am talking about

Thanks,

Andrew

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 in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

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. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

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.

Exposing Configuration Manager functionality through RESTful web API's would open up a whole new world for interacting with ConfigMgr.
E.g. a web Admin console and easier integration with Service Management Automation (SMA).
It should also be easier for 3rd party vendors to create new web based solutions for say an self-service portal or a Windows App for tracking an OS or application deployment on a mobile device or phone.
Personally I would really like any easier way to interact with ConfigMgr. when running in Windows PE (OS Deployment) or a web portal for non-admins to provision new or existing machine for OS deployment.

Problem:
• Current state of windows 10 servicing via upgrade sequence requires full media to take the client through setup.
o Full media is 2x the size of existing ESD (upgrade content)
o The Upgrade Operating System step does not allow the end user to defer the reboot nor does it warn the user of a reboot pending once setup has been kicked off

Change Request (Requirements)
I. The Upgrade Operating System step in the task sequence shall permit the administrator to reference windows 10 servicing content
II. The Upgrade Operating System step in the task sequence shall permit the administrator to define a notification to the end user
III. The Upgrade Operating System step in the task sequence shall permit the administrator to define if the user can defer the system reboot and for how long