Hi. We’re updating this items status to Planned, we’ll update later with which Tech Preview this will appear in.
Awesome. Reading that UserVoice entry shows other helpful ideas as well. Glad to see it's making traction.
Currently, a user can press F8 (if enabled) to bring up a Command Prompt during OSD for some debugging. It would be very helpful to take this a step further to also allow some option (maybe another F key) that would bring up a debug console that allows deeper investigation, such as viewing the current values of all TS variables, the current command line being run, status of packages, launch the log viewer, setting TS values manually for testing, disabling/skipping specific TS steps, verifying the state of the WinPE (ex: .NET/PS installed, drivers, other PE components), etc.
Right now, Compliance in SCCM has a big advantage over Group Policy: Reporting on results. Currently, and not in the foreseeable future, AFAIK, there are no plans to add such functionality to Group Policy.
Giving Compliance the ability to manage the same/more settings than GP would give admins much better insight into their environment by actually seeing the impact of changes that are deployed through reports and queries.
I think that would be an awesome addition.
Our 1901 Tech Preview release has the changes to allow alternate credentials
The new TS Action called "Run Powershell" does not allow Alternate Credentials. That is what this request is for. At least not as of SCCM 2012 R2 SP1.
Thanks. The problem isn't using parameters, it's running the PowerShell script with alternate credentials other than the default account that the TS is running under. This is good if we want to be able to access a share that the default account may not have perms to, or running WMI on the site server, etc.
Right now, the only way to do that is via the "Run Command Line" TS item with powershell.exe, but debugging the -command parameter of Powershell.exe can be difficult.
FYI - That first line should be, "Right now, if I need to run a PS script with alternate credentials in a Task Sequence requires....".
Right now, the process to add registry keys or values that are not already part of WMI for inventory requires modifying MOF files, extending the hardware inventory, and enabling the new WMI classes for collection.
An interface that takes registry keys and values to automatically perform the steps necessary to import the classes, etc. would be a great help.
Expecting people to modify text files, etc for something that should be simple and is likely a pretty common need opens up the potential for errors, and requires more steps than should be necessary.