Running a step as a user prevents you from using the TSEnvironment in order to store any data returned.

The step could be anything, like getting a byte array of a certificate, ad-groups of the computer or primary user or as in this example, getting the TPM OwnerAuth from MBAM.

I would rather store it directly in the TSEnv instead of in a temporary file and run another script to read the file just to be able to use the password, as a variable, from a “Run commandline”-step.

The only other workaround I’ve found this far is running the step the normal way and supply the credentials in the command line or within the script it executes.
Storing a pw, even if encrypted, in a package which every user has default access to isn’t optimal and using a password, in clear text, in a run command line step has security impacts as well.

Suggestion: Add the possibility to store the output/data returned from a "run command line"-step as a task sequence variable, even if runasuser is chosen. (see pic)

When I started working with SCCM years ago I was told that you're not really an SCCM admin until you accidently deployed MS Office to the whole company. Through my years of working with SCCM I've seen many people update a collection not knowing that there was a mandatory deployment attached which resulted in the deployment getting sent to systems that were not intended.
I would like to see a check/notification box added when a query based collection is updated that reminds you of the required deployments attached. This message will only show if an unexpired required advertisement is still set. This would ensure that admins understand the potential impact of their collection change.

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.

Setting the AD computer object description should be allowed inside a task sequence during the domain join operation.
Whether or not this is on the dialog box, is not important to me. I'd be happy setting a TS variable (ie. OSDComputerObjectDescription)

Alternatively, we could use a PowerShell script using different credentials (which Task Sequences also do not allow). Similar to the way
the "Run Command Line" allows the input of credentials.

Right now we have to use a kludgy "Run Command Line" using credentials and run
a batch file that calls something like: PowerShell.exe -executionpolicy Bypass -command pscommandhere
or: PowerShell.exe -executionpolicy Bypass -file .\powershellscript.ps1