Running v3 .exe using AT command

[compaqme]

I am trying to run a compiled .exe that is trying to run an application .exe on another server. This particular application does not install on the local machine, so the domain user account I created has to run the .exe file off the database server to run the program. I wanted to lock down the machine, adding this user account to the Guest group for the local computer policy. When I create an interactive AT command to run the compiled AutoIt .exe, it conveys that access is denied. But when I manually try and run the compiled .exe logged in with that domain account, it runs fine.

Has anyone ever ran into this? If so, what was your workaround? I looked at the permissions for the compiled AutoIt .exe and the domain account had full rights. Please help as the ultimate goal is lock down the PC but be able to run the application .exe without any issues.

Thank you.

[Skruge]

1) What OS are you running? The NT "Scheduler" service works differently than the "Task Scheduler" service of 2K/XP.

2) Does the necessary account have "Logon as a Service" privileges?

3) Is the "Access denied" error coming from your exe or the exe on the other server?

If your AutoIt exe is running, but can't launch the other exe, then it could be your code. (Post it here)

If not, then it's not an AutoIt issue.

[TheCuz]

I have run into this before, I tried to do the same thing on a NT4 server and it would run fine when I would do it from the command line, but when I had AT run it, an error would say access denied.

AT doesn't run under the account that you are logged on as, it runs under a different account that is not listed in the user manager. I never did find a way to use AT to do it.

There is a way that you can have your AuotIT script check the PC time and then run the command.

Look in the help section on using the @HOUR and @MIN to check for what time it is.

Hope this helps some.

[compaqme]

Here are my responses to your questions:

1. I am running Windows 2000.

2. The guest account on the local computer does not have Logon as Service privileges as it is under the Guest group.

3. The access denied is coming from the local computer trying to run an .exe on a shared folder to Everyone (with full rights) on the database server.

I'll see if I can try scheduling with AutoIt, as Task Scheduler is not available with users under the Guest group. But if the Guest account, which is a domain account, can access the share with no issues, why does AT not recognize that. The computer is in the domain and should theoritically have no problems getting to the share. The AT account was executed as interactive. Here is the code:

AT command:

at 12:00 /interactive c:\AutoItScripts\Phase_1

AutoIt script:

Run("\\dbserver\application\APP.EXE")

WinWaitActive("User Login")

Send("username{TAB}password")

Send("{ENTER}")

The error I get says Access Denied on Phase_1. Cannot open APP.EXE is pretty much what it is saying. But if I run Phase_1.au3 manually under the same guest account without using the AT command, it works fine. Any guesses?

[BigDod]

Here are my responses to your questions:

1. I am running Windows 2000.

2. The guest account on the local computer does not have Logon as Service privileges as it is under the Guest group.

3. The access denied is coming from the local computer trying to run an .exe on a shared folder to Everyone (with full rights) on the database server.

I'll see if I can try scheduling with AutoIt, as Task Scheduler is not available with users under the Guest group. But if the Guest account, which is a domain account, can access the share with no issues, why does AT not recognize that. The computer is in the domain and should theoritically have no problems getting to the share. The AT account was executed as interactive. Here is the code:

AT command:

at 12:00 /interactive c:\AutoItScripts\Phase_1

AutoIt script:

Run("\\dbserver\application\APP.EXE")

WinWaitActive("User Login")

Send("username{TAB}password")

Send("{ENTER}")

The error I get says Access Denied on Phase_1. Cannot open APP.EXE is pretty much what it is saying. But if I run Phase_1.au3 manually under the same guest account without using the AT command, it works fine. Any guesses?

Has Phase_1 been compiled or is it still a script (ie .au3). If it is still a script it could not be executed with task scheduler as you are running it.

[jefhal]

When I create an interactive AT command

This might shed some light. From Microsoft:

The Windows NT Command Scheduler

Windows NT provides a special feature called the Schedule Service that can execute any command or application periodically or at a specified time and date. Scheduled commands can execute even if there is no user logged on to the computer. The Schedule Service is therefore ideal for running periodic maintenance tasks, such as file backups. For example, the REPL.BAT sample script in Part II uses the Schedule Service to provide periodic file replication services.

The Schedule Service is controlled through several shell commands. These commands can control the service either on the local computer or any computer on the network (assuming that the user has sufficient rights to access that computer). The ability to control the Schedule Service remotely is particularly useful for system administrators managing many servers.

The two most common mistakes made when using Windows NT involve the setup and use of the Schedule Service:

First, the Schedule Service, like all services, logs on by default as the LocalSystem account. Typically, this account has insufficient rights to perform many operations (such as accessing network drives).

Second, because the Schedule Service operates independently of a user logon, drive mappings and other per-user settings are not necessarily available when a scheduled command executes. For example, the environment available to a command executed by the schedule service is restricted to the system environment set via Control Panel.

Fortunately, both these problems are easily solved. Creating a special account exclusively for the Schedule Service (named, for example, ScheduleService) solves the first problem. This account is then assigned whatever access rights and group memberships are needed to ensure that any scheduled commands are successful. Explicitly mapping all required resources within a scheduled script (such as network drives) solves the second problem. Alternatively, use UNC names directly in commands.

For example, assume a logon script maps drive X: to \\SERVER\COMMON. This command, which operates correctly when used interactively, fails when used with the Schedule Service: