Does anybody know what user privileges are needed for the following code needs to successfully execute as a scheduled task on Windows Server 2003:
System.Diagnostics.Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName)
When NOT running as scheduled task i.e. under a logged in user, as long as the user is a member of "Performance Monitor Users", this code will not throw an exception.
When running as a scheduled task under the same user account, it fails.
The only way I can get it to work is to run it as a member of the Local Administrator group.
Any ideas?
My humblest apologies. The user I was using was NOT a member of "Performance Monitor Users" group.
This is necessary for .NET Framework 1.1 implementation of System.Diagnostics.
I have added the user to this group, and all is well.
What user rights assignments have you given the account that is running as a scheduled task? You'll need to give the account in question 'Log on as a batch job' in your local security settings.
Update: Does your app write to any files and if so does the scheduled task user have enough rights?
I just knocked up a test app that writes the process names from the Process[] array returned by Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName) to a file and it works just fine as a scheduled task...even running under the identity of a user that is only a member of the Users group (not even a member of 'Performance Monitor Users'.
The folder it writes to is assigned modify rights to SYSTEM, Administrators and the scheduled task user.
Any chance of pasting your code or at least a small enough snippet that demonstrates the exe failing as a scheduled task so we can help diagnose the problem?
Cheers
Kev
One issue that I have seen with reading the process name is that access to the performance counters can get disabled.
Crack open your registry and see if this key is there:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance]
"Disable Performance Counters"=dword:00000001
You can either set it to zero or deleted it.
Taken from MSDN:
Permissions LinkDemand - for full
trust for the immediate caller. This
member cannot be used by partially
trusted code.
Related
I have a PowerShell script that runs under its own user account for security purposes. It needs to be able to schedule tasks as part of its operation, and uses the ScheduledTasks module to do so. After seeing this question, I granted the script's account Full Control over %SystemRoot%\System32\Tasks, but Register-ScheduledTask still fails with "Access is denied." I have allowed the script's account to log on as a batch job and as a service.
What permissions/configuration changes are needed to make this work right?
I've discovered that the problem was due to me specifying -RunLevel Highest. Apparently you can't do that with a restricted account. Removing that parameter allows it to work.
We have a legacy VB6 application that automatically emails reports. It runs from a scheduled task on a server. Occasionally a user will run the exe - it's in a folder that we can't lock them out of, and it has to remain in that folder for reasons too complicated to go into here. Is there a way to prevent users from running the exe while still letting it run from the scheduled task? I can modify the source code for the exe, so that's an option if someone can help me figure out how.
I'm going to call your existing app AppChild and a new VB6 (or other program language) program AppParent.
Modify AppChild to test for a command line parameter at either Sub Main() or at the first form loaded in the Form_Load() event. If the command line parameter isn't there, AppChild terminates.
AppParent would be in a location not accessible to the other users. The Scheduled task runs AppParent which runs AppChild and passes the required command line parameter. This could be secured somewhat by passing a calculated hash and decoding it in AppChild if needed.
Or, if the users don't have access to the Scheduled Tasks, you could just run AppChild , passing the required parameter from the Scheduled Task. If the users do have access to the Scheduled Task this won't work because they could then see the passed parameter and create a shortcut which passes the required parameter.
You didn't state which OS the server is running but you may have problems using network resources if you try to run the Scheduled Task without a logged in user. Task Manager got a major update to handle security issues to prevent hackers from running tasks without a logged in user. Essentailly, network resources, .e.g. eMail, are not available unless a user is logged in.
https://technet.microsoft.com/en-us/library/cc722152(v=ws.11).aspx
The only way I found around that problem is to run a machine with a user with the correct permissions logged in all the time.
Are you sure you cannot lock the user out?
You could restrict access to the folder so that the user cannot access it and set up the scheduled task to use an account with access to the folder.
Although the users can't be locked out of the folder (perhaps the reports end up in there?), in Windows you can set the permissions on a per file basis. Make a new user that has the full rights (the same as your users). Schedule the VB6 app to run with that user. Remove the rights for the regular users to see the app. You do this by changing the permissions on just the VB6 app.
I'm running into the same problem again and again for ages so I decided to ask my question here :
I added a service account "ZYX" into the Administrators group of my Windows 2K8 Server.
Whenever I try to run a scheduled task (running as "ZYX") that modifies a file located under a folder where the Administrators group has full control, my PowerShell script always gets "Access to the path xxxxxxx is denied".
When I check the effective permissions of my service account on this folder, it is written that it is granted every single permission.
I found two ways to overcome the situation, but I find this really ugly :
Running the scheduled task with highest privileges
Add the service account "ZYX" with full control in the folder Security part.
Im starting believing my service account only gets the rights inherited from the Administrators group when the shell runs in elevated mode.
Can someone explain me why Windows manages the rights like this ?
Do you have any better solution for this ?
Thanks
I need to run an offsite backup .cmd script (batch file) on a Windows 7/8 PC, daily, whether a user is logged on or not. Naturally, Task Scheduler's feature "run if user is logged or not" doesn't work (sarcasm .. thanks M$) because the user has to be logged on at some time then signed out. Moreover, because of the urgency of the task, it must run no matter what. For example, if the power goes out and upon restoration the computer reboots, there will be nobody logged on. So, I need to convert the batch file to a service.
I've used NSSM to convert the batch file into a service, but I don't know how to make the service run on a schedule, because, by definition, it's not meant to run that way - I should be using a scheduled task. So, I'm not sure what to do and all the tutorials I've seen on Google imply that I know VB script and/or C#. Unfortunately, I don't and don't plan to ... I just need a quick fix to work like a Linux cron job.
Thanks!
Task Scheduler's feature "run if user is logged or not" doesn't work (sarcasm .. thanks M$) because the user has to be logged on at some time then signed out.
Are you sure? Because "run if user is logged or not" is an option, not a trigger. It should be combined with trigger "At startup" to achieve desired result:
If everything else fails, you can use nncron to schedule tasks and install it as service.
I have a program which I would like to run every X min
the problem is that the program is accessing a shared network and using AT command I can't use it (due to the fact that AT is running the program with SYSTEM ACCOUNT)
any ideas how to slove this issue ?
thanks
Does the /interactive switch buy you what you want?
"Use this parameter to allow the task to interact with the desktop of the user who is logged on at the time the task runs."
For more info see: http://support.microsoft.com/kb/313565
With the at command your options are either to run as the System user or the user which is currently logged on.
You might want to try having your program run as a scheduled task instead. That would give you the option to run under any account in which you have credentials (username/password). You can either set this up manually, through the control panel, or programatically from C# using this library