Startup Script + Local System user = no functional program UI

group-policyiis-7scheduled-taskuser-managementwindows-server-2008

I currently have a group policy startup script (CMD file). It runs during startup, as expected, but there is no UI for the program the script invokes.

For example purposes, let's say I have this command as my startup script:

rundll32 shell32.dll,ShellExec_RunDLL "C:\Windows\System32\notepad.exe"
echo foo > C:\foo.txt

^ This invokes "Notepad" to run, and writes output to a textfile (foo.txt). Pretty simple. When group policy runs this script, the text file is produced and Notepad is running. The problem is that Notepad has no UI. The only way I can tell it is running is through Task Manager/Processes. I have verified it working, but I need Notepad to show up in my taskbar, while running.

…According to TechNet/Microsoft here:
Assign computer startup scripts w/ Microsoft

Startup scripts are run as Local System, and they have the full rights that are associated with being able to run as Local System.

My problem is that I really need the Notepad program UI to display and cannot seem to make this happen when it runs under "Local System".

Is there a way to have my startup script run as Administrator? Or is there a way to enable Local System user to have necessary priveleges to fully run Notepad?
Do I need to alter my CMD script to "RUN AS" a different user?
Should I ditch group policy for scheduled tasks? Scheduled tasks are easier to setup. it seems like a toss-up to me?

I would like to point out that I have also tried this with "Scheduled Tasks" under Control Panel/Administrative Tools. I have the same results and same situation, where my script runs successfully but Notepad UI is never displayed. I am open to suggestions using Task Scheduler as well, or different approaches. Thanks!

Best Answer

Getting the UI to display is going to be a real pain.

First, I'd consider wrapping these programs in a service wrapper (like Non-Sucking Service Manager, for example) and letting the Service Control Manager start them on boot. From the sound of your comment these programs really should be coded as Windows services anyway. (I'd love software vendors to stop writing non-Service "service" programs that require my servers to sit logged-on, etc. Crappy timeclock polling programs seem to all be this way, for example.)

This doesn't solve your UI problem. You're not going to get a GUI interface to launch on top of Winlogon in Windows Server 2008 without "helping" the program. You could get programs running via Startup Scripts in Windows Server 2003 to display their UI on top of Winlogon. To do such a thing now you'd need to create a process with a duplicate of the Winlogon token with the desktop set for the Winlogon desktop.

You may get the UI to pop up after logon by allowing the Service-wrapped programs to interact with the desktop. Maybe. You're probably also exposing yourself to "shatter" attacks, too.

If these are in-house programs you should consider altering them so that they work like real Service programs should. The management UI should talk to the back-end service process via an RPC mechanism. Do this over TCP/IP and, as a bonus, you can run the management program on other machines. Your monolithic Service-and-UI-together approach isn't going to give you the best results.

Related Solutions

Windows scheduled task fails to complete with error code 0xc000013a

Troubleshooting scheduled scripts:

If you haven't already, check the Scheduled Tasks log file, in the GUI under Advanced > View Log. Search the file for "***" to find the most recent entries, and you may see a little extra error info.
Define a log file to capture output, and send both standard out and standard error there. Change any echo OFF to echo ON to be sure you're not supressing any error messages.
For example, if your script is called ftp.data.cmd then your scheduled task might look like this,

cmd /c ftp.data.cmd >> ftp.data.log 2>&1
Is the script hanging? Maybe the task scheduler is killing the script (hence the CTRL+C error code) after some specified period of time. Add some of these at strategic points in your scipt,

echo %DATE% %TIME%
Are you sure the account running the script has permissions / access to everything in the script?
If you can't get any joy, run this command and post the output here, maybe we can start with the scheduling,

schtasks /query /v /fo LIST /s YOURSERVER

How to Run a .bat File in a Scheduled Task Without a Window

You could run it silently using a Windows Script file instead. The Run Method allows you running a script in invisible mode. Create a .vbs file like this one

Dim WinScriptHost
Set WinScriptHost = CreateObject("WScript.Shell")
WinScriptHost.Run Chr(34) & "C:\Scheduled Jobs\mybat.bat" & Chr(34), 0
Set WinScriptHost = Nothing

and schedule it. The second argument in this example sets the window style. 0 means "hide the window."

Complete syntax of the Run method:

 object.Run(strCommand, [intWindowStyle], [bWaitOnReturn])

Arguments:

object: WshShell object.
strCommand: String value indicating the command line you want to run. You must include any parameters you want to pass to the executable file.
intWindowStyle: Optional. Integer value indicating the appearance of the program's window. Note that not all programs make use of this information.
bWaitOnReturn: Optional. Boolean value indicating whether the script should wait for the program to finish executing before continuing to the next statement in your script. If set to true, script execution halts until the program finishes, and Run returns any error code returned by the program. If set to false (the default), the Run method returns immediately after starting the program, automatically returning 0 (not to be interpreted as an error code).

Best Answer

Related Solutions

Windows scheduled task fails to complete with error code 0xc000013a

How to Run a .bat File in a Scheduled Task Without a Window

Related Topic