MicrosoftJon Warnken I would strongly suggest changing your remediation to execute something more like this
Start-Process "cscript" -ArgumentList "//Nologo C:\Windows\System32\slmgr.vbs /ipk $($win10_Y1_Key)" -Wait -NoNewWindow
Start-Sleep -Seconds 5
Start-Process "cscript" -ArgumentList "//Nologo C:\Windows\System32\slmgr.vbs /ato $($win10_Y1_ESU)" -Wait -NoNewWindow
Start-Sleep -Seconds 5
Running the slmgr.vbs directly means that not only are you waiting unnecessary amounts of time, but you are also leaving the executions running in the background which can be spotted very easily in task manager by setting it to show Command Line.
Above example instead will localize it to the console session and not leave it sitting under system context until the computer reboots.
MicrosoftThe sample code has timeouts to address delays that can occur during the key activation and allow the process to functions in as many environments as possible. That said it is sample code that you should test in your environment and update to meet your needs.
I am saying this based off what my own testing showed when I reworked the above to run as a Configuration Manager Baseline.
Though the script had finished/timed out due to the default Baseline duration being I believe 60 seconds, I found that though the script had exited, the child processes where still present and in fact until they where killed by task manager, the Discovery Script would not run and the baseline in configuration manager was still listing no evaluation completion.
Running the slmgr.vbs as part of cscript.exe allowed to avoid the process sitting there clogging the baseline execution completion and the command line being directly visible in task manager until the system reboots.
