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

Available, required, doesn't matter.
Give users a "Plan" button, like we have with required deployments, and allow them to pick a time, and allow them to reboot after the install is done.
Right now, the "Plan" button is only present on Required deployments with a deadline.
Right now, the "Restart automatically my computer if needed" checkbox is only present if you choose "Outside my business hours".

Yes, this is a three-for-one. Inspired by Brian Dam's tweet https://twitter.com/bdam555/status/1220469791284219904

Use case 1: User has been instructed to install an available application, but is busy working. User plans the install for 11:30, where the user goes to lunch.

Use case 2: User has been instructed to run an In Place Upgrade task sequence, but is busy working. User plans the install for 09:00, where a 3 hour staff meeting will take place.

The big difference to Business Hours is that users can plan installs during their own downtime. It might be lunch at 11:30, or it might be the staff meeting at 09:00. Business Hours doesn't work very well for that purpose.

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:

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

HKEYLOCALMACHINE\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.

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

HKEYLOCALMACHINE\SYSTEM\Setup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\Voatile - This key will show error codes for failed upgrades.
HKEYLOCALMACHINE\SYSTEM\Setup\MoSetup\SetupDiag - this key is created when you run SetupDiag on a box to check for failure codes.
HKEYLOCALMACHINE\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.

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.

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.