Need help with script scheduled through Task Manager

[jcristello]

We copied scripts from one server to a new server (Windows 2012 R2).  The scripts call an emulator package that logs into a system and uses the system application to create a text file that is stored on a directory in that system.  The scripts are scheduled to run via the Task Manager.  The scheduled scripts run on the original server but not on the new server.  I scheduled one script and the task shows in the manager as having completed yet no file is ever created on the system.  I can run the script manually on the new server without issue.

I have tried several configurations and none have worked.  Currently the script uses a user account to run under, is set to run with highest privileges, and is configured for Windows Vista, Windows Server 2008.  The UAC setting for the requested execution level is asInvoker and the uiAccess flag is set to false.

Can you please advise on what could be wrong?

[td]

Can't offer any useful advice because you have not mentioned the type of account the task is running under, the version of Windows on the server that your script previously was working on, nor whether or not the task is setup to only run when the use is logged on.   

[jcristello]

The task is running under an admin account, the version of Windows on the current server is Windows 2003 and the script is set to run whether the user is logged in or not.  Please let me know if you need any other information.

Thank you.

[MW4]

do they run manually?

[jcristello]

Yes, when I run the same script manually while logged in under the account on both servers a file is created.  It is just the scheduled task on the new server that isn't creating the file. 

[td]

The task is running under an admin account, the version of Windows on the current server is Windows 2003 and the script is set to run whether the user is logged in or not.  Please let me know if you need any other information.

Thank you.

If you are using a mapped drive that could be the source of your problem.  But that depends on what the UAC settings are on the server and what the Task Scheduler considers 'highest privileges' when the script is manifested to run asInvoker.  Basically, the mapped drive problem results because the restricted admin and elevated admin of the same account have different access tokens and the access token is used to determine which accounts can 'see' a mapped drive.  There are multiple articles in the Tech Database that explain problem better and offer several solutions.

File and folder sharing can cause a similar problem.  For example, a server may be setup to strip the elevated privilege token from an admin process that is attempting to access the share.  This means that a share that is configured to allow access to members of the administrator group is not  accessible by members of the administrator group.   Go figure.

Another cause of your problem could be that your script has some reason to interact with the desktop - an error message, for example.  If that is the case, your script will hang and eventually be terminated by the scheduler.   A scheduled task cannot interact with the desktop unless it is set to only run when the user is logged on.

[td]

A link to one of the previously mentioned mapped drive and UAC articles in the Tech Database:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UAC+Mapped~Drives~Issue~with~UAC.txt

[jcristello]

I can confirm that we are not using a mapped drive and not using a shared folder.  I changed the Task Scheduler setting to run only when the user is logged in.  I stayed logged in and the task fired on schedule.  I was able to watch the script run.  It ran to completion without any prompts or errors and created the file as expected.

I think this confirms it is an issue with the UAC child process not having the admin privileges needed like the parent process has when it is run either manually or when the user is logged in. 

Does this sound correct?

Thank you.

[td]

Assuming nothing else has changed from your previous description of the task's settings, I don't believe that setting a script to execute only when the user is logged will affect the UAC related security level.  However, that the scheduled task works when so configured does suggest that the script interacts with a desktop in some way.  Note that script interaction with the desktop does not necessarily require displaying a message box or some other UI element. 

Scripts can interact with the desktop in many ways that do not evolve the script displaying a UI element. For example, calling one of the WIL Win* functions can result in interaction with a Windows desktop the does not involve the script displaying any UI elements.  One possible scenario would go something like the following: your script calls a WIL function that requires desktop interaction.  When the task runs when the user is logged on, the script succeeds.  When the task runs without ths logged on user, the function fails and generates an error message.  This causes the script to hang because their is noway to dismiss an error message not displayed on any regular user desktop.  The Task Scheduler detects that the task is hung and terminates it.   

[jcristello]

Thank you for the response.  I checked the task history and can see that the script that works does run in interactive mode and the script that fails does not.  I will go back to reviewing the tech database for information.

[td]

Try setting up DebugTrace to get a dump of your script when the associated task is set to run 'whether the user is logged on or not'.  The trace file should show where the script is failing.