There are several registry keys which contain information about the currently installed Operating System as well as Installation/Upgrade history/errors/status information. These keys provide a valuable source of information that could be used for building reports/collections related to OS Deployment. One of the major barriers mentioned for not deploying Windows 10 Feature Updates from Windows 10 Servicing in the console is the lack of visibility/reporting available. Adding these registry keys to the default hardware inventory included in SCCM instead of having to customize inventory would make it easier to share reports/scripts/etc related to this data and could likely be built so that it could all be collected into a single table instead of several separate tables which result from current MOF customizations.

Examples of the keys (and sub keys in most cases) include:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion - shows all current OS installation information including the ReleaseId which is not included in inventory today.

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Source OS * - a new date stamped key is created for each upgrade that is done on a machine. You can use this to build upgrade history reports and distinguish between upgrades and new builds.

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Upgrade - the DownLevelBuildNumber key shows build of the last OS that was upgraded from.

HKEY_LOCAL_MACHINE\SYSTEM\Setup
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\Voatile - This key will show error codes for failed upgrades.
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\SetupDiag - this key is created when you run SetupDiag on a box to check for failure codes.
HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\Tracking - logs the number of install attempts and failures.

We have been extending our inventory to included these keys and it has greatly simplified our upgrade and OSD reporting and remediation efforts.

It would be extremely helpful to have an option in the software update point site system to bypass a proxy for a local address. The only options today are (see Current-SUP-Proxy-Options.png):

- Use a proxy server when synchronizing
- Use a proxy server when downloading content by ADRs

The issue is when an ADR tries to download a third-party software update, it will attempt to use a proxy server and often fail because the proxy doesn't route correctly to the internal WSUS server. For example in patchdownloader.log, you will see something like <Download-Error-PatchDownloader.png>.

There needs to be an option to not use a proxy for local addresses (Third-party software updates being downloaded from the WSUS server) and Microsoft updates would continue using the proxy as needed. Today it's either proxy enabled for all ADR content downloads or for none. Bypassing proxy when the ADR see's it's a local address would be extremely helpful.

We probably get 3-4 cases a week from customers using our Patch My PC solution for third-party software updates in SCCM.

- Justin Chalfant

SCCM 1906 introduced scopes on folders which would be fine for a new SCCM install but not for an existing SCCM infrastructure that relies heavily on RBAC. Users don't understand why they can't find folders others have created in 1906.

During upgrade from 1902 – 1902 SCCM automatically “fixes” all your folders so they behave just like they did with 1902. It does this be setting them with every security scope allowing users to still see these folders in 1906.

Once 1906 is installed any new folder is created with the scope of the user creating it.

Example:

SCCM 1902 - Geneva user with Geneva scope creates a folder in 1902 anyone could see the folder.

SCCM 1906 - Geneva user with Geneva scope creates a folder only users with Geneva scope will be able to see the folder and no other users causing mass confusion in the console.

If RBAC on folders was available when SCCM 1st came out years ago we could have designed RBAC accordingly.

MS can’t just introduce this mandatory “feature” on an SCCM environment that has been up for years without breaking/redesigning RBAC.

RBAC on folders should be something that can be turned off during the upgrade to keep 1902 folder behavior.

WSUS is a well-known pre-requisite for the Software Update Point role yet the user is entirely left to their own devices to install and configure it. The default WSUS installation options are widely regarded as non-optimal. Further, there is plenty of precedent for ConfigMgr installing OS roles.

I would like to see the WSUS OS role be installed and configured as part of the SUP role installation. Where necessary, the wizard can suggest better configuration options than WSUS’s defaults. I’m certain the community will come up with more ideas than this but here’s a few I can think of, some of which already have dedicated UserVoice items:
-Install on the ConfigMgr SQL instance, not WID
-Set a sane IIS private memory limit (8GB?)
-Optionally configure shared database and shared content for multiple SUPs (Default to true)
-Disable Rapid Fail
-Set a sane IIS queue length limit based on the number of clients
-Increase ASP.NET’s ExecutionTimeout timeout (360 seconds?)

With these settings part of the role installation they should also become part of the SUP properties that you can change post-install and configurable via the PoSH cmdlets. That being the case, they now become a really great use case for Management Insights. For example: I see WSUS’s app-pool is constantly running out of memory and recycling … you should increase the private memory pool.

Business Rationalization: I think this one is dead-simple. Forget your customers for a second. They’re whiny and need a good smiting anyways. Do this for you. Treat-yo-self! Are you tired of customers complaining about how awful WSUS is and how it just needs to die? Is your support department inundated with calls that have nothing to do with your product but your dependency on WSUS? Then this is the User Voice Item you’ve been waiting for!
Seriously, I think there is immediate ROI to Microsoft’s bottom line if you helped your customers set up WSUS correctly.

Business Case (I know how you PMs love these):
The current CB 1902 implementation is going to make this conversation part of our helpdesk script:
“What screen is the app on?”
“Can you move that window to the monitor where X is showing?”
“No, not that one.”
“Nope, still don’t’ see it”
“Ok let me reconnect in full screen, please accept the prompt again.”
“No no no, don’t hang up the phone, that’s not how this works.”
“Ok, you should see a prompt to allow me to connect.”
“Nope it’s there, trust me.”
“Got it, thanks. Ok, let me move that over here.”
“Ok, I’m going to reconnect again so I can see what’s going on.”
*Click*
“You just hung up, didn’t you?”

This is going to waste time on support calls and leave both sides dissatisfied with the entire experience. In turn, customers will continue implementing other third party remote control tools. Remove Viewer was absolutely a selling point for ConfigMgr and was one of the features that lured us away from our previous solution.

Solution:
1) The ability to select _any_ single screen connected to the remote device in addition to the current all screen view.
2) The ability to change monitor selection without having to reconnect the remove viewer.

Notes:
I could probably live with automatic reconnection provided that the admin stays in the Remote Viewer app at all times and doesn’t need to retype anything (device name/credentials) nor the end user re-accept the prompt if one is configured.
In my dreams the ability to pick a single screen is built into the full screen mode. In full screen mode the admin clicks a button that overlays each monitor with a number and an outline. If this sounds like display setting’s ‘Identify Monitors’ that’s because that’s exactly what I’m thinking of. However, don’t stop there. In that identification mode make the monitors selectable such that when I click on one it immediately becomes the single monitor I’m connected to.