The reason your Run Script job fails to open Notepad and send the keys like you want is because you have the script configured to run as "Default (local system account)". In most cases you aren't logging into the Windows 10 system using the local system account. You may be using a Local or Domain User, but not local system. To test this change the Run Script "Client Run Environment" to "Run script in console user session" and see if that produces the Notepad effect your after.
However, in testing I found the PowerShell you provided never launches Notepad in the first place. From a test workstation $wshell.AppActivate('Notepad') returns false unless Notepad is already running. I was able to get Notepad to open and add 'test' to an empty document using the following script:
#powershell$wshell = New-Object -ComObject wscript.shell$wshell.Run('Notepad')$wshell.AppActivate('Notepad')$wshell.Sleep('500')$wshell.SendKeys('test')I should also add that this Run Script task is book ended with two additional scripts which bypass and then default PowerShell's default Execution Policy. Unless you've specifically modified the Execution Policy on your machines, a bad security practice security, you have to do this in order for PowerShell scripts to execute properly using a Ghost Run Script task.
Here is the first script which temporarily sets PowerShell's Execution Policy to bypass:
REM Configure PowerShell's Execution Policy to bypassC:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy -ExecutionPolicy Bypass -ForceHere is the second script which sets PowerShell's Execution Policy to default:
REM Configure PowerShell's Execution Policy to defaultC:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy -ExecutionPolicy Default -ForceIn order to get your Notepad example to work you need three Run Script tasks within your job.
- Temporarily configure PowerShell's Execution Policy to bypass.
- PowerShell Script starting with #powershell and set to "Run script in console user session"
- Restore PowerShell's Execution Policy to default.
Now to address your end goal. I don't believe there is a way to specifically target the Windows 10 Login UI; however, there are other ways to accomplish your goal.
If it were me, I'd use
Sysinternals' Autologon application. Autologon allows you to specify a username and password to be used by default when a Windows 10 workstation starts. To accomplish this using Ghost, start by downloading Autologon.zip from the above link. Copy the contents (3 EXE files) to your Ghost Console and then create a new Ghost Job with the following Tasks. Replace username, domain, and password with the values needed. If you're wanting to use a local logon versus domain use a period(.) in place of domain. Autologon will encrypt the password before writing it to the registry.
- Copy File to. Copy the three files from the ZIP to C:\Windows\System32 on the target system.
- Run Script:
REM Use Sysinternals Autologon to configure an automatic logon
C:\Windows\System32\Autologon64.exe {username} {domain} {password} /AcceptEULA
- Power Control. Restart.
When the target workstation restarts it should automatically login using the credentials you provided.
Autologon takes advantage of Windows' built-in automatic logon functionality which is documented here:
Turn on automatic logon in Windows. If you need to disable Autologon after you need to modify the registry keys listed in the linked article. In the alternative to Autologon you could create the necessary tasks to write those registry values manually, but then the password would be store in the registry in clear text.