This project has moved. For the latest updates, please go here.

who needs permissions?

Aug 1, 2011 at 1:40 PM
Edited Aug 2, 2011 at 3:48 AM

I have learned a great deal about your wrapper in the past few days, and it's working great. I have a permissions question.
I am using your wrapper in a c# asp.net website, and creating a task for each customer, and giving them the rights to set the time of the daily trigger.
I've got it to work mostly on my dev machine, and haven't tried anything yet on my test server. I am wondering where how the access permissions work.
The users, and I in my test scenerio ((I think)*in test I am using my own user, not IUSR I found out) are using the IUSR user through IIS. In code I am using a login/password with much more elevated rights than IUSR and I have been able to create/edit tasks so far. Also, I temporarily added IUSR to the administrators group. <- this was apparently to help confuse me...

My one caveat is that when I try to set the Highest Privledge, it doesn't work. That is why I am maybe confused. If I bring up the actual task scheduler as
my user, I can clearly check the box and everything is Ok.

So, does the user I am need permissions or the user I pass through the principal?

Let me add that I want to run the tasks as a service where no one is logged in, I could also run them as admin with a pwd, I just don't want to give my web app full admin rights thru impersonation.

EDIT: Ok, so I think I understand a bit more. I can set up the task with certain credentials, those are the ones used when the task is fired. But my IUSR user needs the right to add those tasks to the task scheduler. If I pass admin and password with the task, will the task run as a service (no one is logged in)? What rights does IUSR need to properly create the task, and why am I hitting a wall with:

td.Principal.RunLevel = TaskRunLevel.Highest;

I realize this is more of a stream of thought, but I can't find any documentation relating to the fact that there are two levels of permissions. Any insight you have to my multitudes of questions would be welcome.

Thanks!

Aug 3, 2011 at 3:33 AM
Edited Aug 3, 2011 at 4:03 AM

hullo?

Coordinator
Aug 3, 2011 at 6:19 PM

There are a number of other discussions where permissions for creating a task on any system are discussed. Please search through and find those. The run level is about thread priority and only is available on systems post Windows Vista/Server 2008.

Aug 3, 2011 at 7:17 PM

I honestly think I've read all 133 discussions by now. I was able to figure out my issue, I had to set the first parameter of the TaskService to 'Localhost'.
I am using Win7 / Win2008 R2. I did notice that tasks for these OSes are v1.3, and any task I make (including explicitly setting the last parameter to false) is always 1.2.

Thanks again for the kick ass wrapper.

Coordinator
Aug 5, 2011 at 6:26 PM

Thanks for posting your solution. You are correct in your observation. The wrapper actually will report that tasks that return a value of 3 for Task.Definition.Settings.Compatibility will convert that to V2. This is mostly for backwards compatibility sake and will likely be corrected in a future release.