Administrator doesn't have permission/rights to run tasks !?

Hello everyone,

I'm trying to run a simple task. I'd like Vista's "task scheduler" to
periodically run a .bat file that I made which goes to the following two
directories and deletes the IE7 cookies that are stored there.

C:\Users\User\AppData\Roaming\Microsoft\Windows\Co okies\Low
C:\Users\<usersname>\AppData\Roaming\Microsoft\Win dows\Cookies

However, I am told that I do not have permission to access these
directories. How can that be, since administrators should have access to all
files and directories on the computer. The other error that I get is that
"task scheduler" tells me that I do not have the "batch rights" to save this
task.

Any insight into this would be a big help.

Paul

"Paul" <> wrote in message
news8193AFB-75CE-4951-877B-...
> Hello everyone,
>
> I'm trying to run a simple task. I'd like Vista's "task scheduler" to
> periodically run a .bat file that I made which goes to the following two
> directories and deletes the IE7 cookies that are stored there.
>
> C:\Users\User\AppData\Roaming\Microsoft\Windows\Co okies\Low
> C:\Users\<usersname>\AppData\Roaming\Microsoft\Win dows\Cookies
>
> However, I am told that I do not have permission to access these
> directories. How can that be, since administrators should have access to
> all
> files and directories on the computer. The other error that I get is that
> "task scheduler" tells me that I do not have the "batch rights" to save
> this
> task.
>
> Any insight into this would be a big help.
>
> Paul
>

Because even thought you may have created an account that is a member of the
administrators group even you installed Windows Vista that account is
subject to UAC (User Account Control) and thus protected from doing certain
tasks without reconfirming etc.
This includes the ability to access al files and folders on the system by
default. If you need access to certain files and folders then you may need
to grant that account access and the appropriate permissions to them.
The same is true of certain privileges (rights) within the system.

As a member of the administrators group you can use the appropriate tools to
grant these rights and permissions to yourself.
Windows Vista is just a little more secure by default to prevent people who
think they are admins from making mistake.
If you are an experienced and competent administrator then just use the
tools to grant yourself what you need.
--

Mike Brannigan

But...

I was trying to share a mounted drive (Z so that the UNC path indexer
works and created a batch file to do it for me.

However, even though I am a member of the admin group AND have set my
individual perms to FULL control on Z I get "access denied err 5" - I do not
get a UAC or other prompt for a confirmation password.

If however I "run as admiistrator" "CMD" - say OK to UAC and then run the
batch file it is fine.

This seems inconsistent to me (and if there's one inconsistency it would not
be inconsistent with Murphy's laws for there to be more...)

Thoughts?

there is a way to run COMMAND with elevated prompt and then allow you to include the batch file name.
do not know what the switch is for the elevated prompt.
maybe someone can pitch in.







"Paul" <> wrote in message news8193AFB-75CE-4951-877B-...
Hello everyone,

I'm trying to run a simple task. I'd like Vista's "task scheduler" to
periodically run a .bat file that I made which goes to the following two
directories and deletes the IE7 cookies that are stored there.

C:\Users\User\AppData\Roaming\Microsoft\Windows\Co okies\Low
C:\Users\<usersname>\AppData\Roaming\Microsoft\Win dows\Cookies

However, I am told that I do not have permission to access these
directories. How can that be, since administrators should have access to all
files and directories on the computer. The other error that I get is that
"task scheduler" tells me that I do not have the "batch rights" to save this
task.

Any insight into this would be a big help.

Paul

Paul wrote:
> Hello everyone,
>
> I'm trying to run a simple task. I'd like Vista's "task scheduler" to
> periodically run a .bat file that I made which goes to the following two
> directories and deletes the IE7 cookies that are stored there.
>
> C:\Users\User\AppData\Roaming\Microsoft\Windows\Co okies\Low
> C:\Users\<usersname>\AppData\Roaming\Microsoft\Win dows\Cookies
>
> However, I am told that I do not have permission to access these
> directories. How can that be, since administrators should have access to all
> files and directories on the computer. The other error that I get is that
> "task scheduler" tells me that I do not have the "batch rights" to save this
> task.
>
> Any insight into this would be a big help.
>
> Paul
>

Hello,

In Windows Vista, even though you are an administrator, only programs
that ask for your permission ("Windows needs your permission to
continue") are allowed to use your admin rights.

This isn't meant to protect you from yourself; rather, this prevents
programs that you do not start from using your admin power.

If you need a program you are starting from task scheduler to run with
admin rights, you will need to run the task with 'highest privilege' by
checking the appropriate box, or running it in the context of a system
account.

At what time do you receive the batch rights / access denied errors?

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Hi Jimmy,

In my case the access denied occurs on the Net Share command.

I appreciate the protection from things running things without my permission
but

1. I have runas in the batchfile and I must give it my password - that
should be enough
2. Even though it clearly isn't enough, when it gets to the Net Share, why
don't I get a UAC prompt? why does it just go ahead - and fail?

[I run with Admin rights all the time now as it makes no difference to UAC
for the reasons you outline but at least I can click to continue rather than
having to enter a password each time]

[Incidentally, when I accidentally "ranas" with the wrong user account
("Admin" instead of my username, but obviously an account with Admin rights)
I also got an access denied on running SyncToy (the next line in the batch
file) because it was Julian's app - I think - it doesn't make any sense to me
to block things like this]

I hope someone can answer mikeyhsd's Q about an appropriate switch for COMMAND

Thanks

Julian wrote:
> Hi Jimmy,
>
> In my case the access denied occurs on the Net Share command.
>
> I appreciate the protection from things running things without my permission
> but
>
> 1. I have runas in the batchfile and I must give it my password - that
> should be enough
> 2. Even though it clearly isn't enough, when it gets to the Net Share, why
> don't I get a UAC prompt? why does it just go ahead - and fail?
>
> [I run with Admin rights all the time now as it makes no difference to UAC
> for the reasons you outline but at least I can click to continue rather than
> having to enter a password each time]
>
> [Incidentally, when I accidentally "ranas" with the wrong user account
> ("Admin" instead of my username, but obviously an account with Admin rights)
> I also got an access denied on running SyncToy (the next line in the batch
> file) because it was Julian's app - I think - it doesn't make any sense to me
> to block things like this]
>
> I hope someone can answer mikeyhsd's Q about an appropriate switch for COMMAND
>
> Thanks

I am confused - are you or are you not starting the batch file from task
scheduler?

There's no need to use runas when you're using task scheduler - you can
specify using task scheduler what user to run the batch file under - and
by checking the highest privilege box, it will allow the file to use the
admin power.

The reason entering a password into runas isn't good enough for
elevation is because other programs can run this command on your behalf
without your knowledge. The UAC prompt ensures that you are actually the
one performing the action, in such a way that programs can't fake.

The reason task scheduler can do this but runas cant is because task
scheduler is only accessible to administrator programs that have already
prompted, while runas can be used by any program.

Unfortunately, command-line programs don't prompt for admin power
on-demand when they are run (which would make this scenario possible).
They must be ran from a command prompt that you have started with admin
power by right-clicking it and clicking run as administrator. But even
in that case, runas wont work like you want it to (and I don't have a
good reason why this happens, either; one would think it would).

I'm not exactly sure why it was designed that way.

Using runas to run a program under a different account does not elevate
the program to administrator status, even if the user is an
administrator, nor is there any way to cause it to prompt for elevation
that I am aware of.

I highly recommend not using runas for this purpose and instead use the
task scheduler to run the batch file in the context of the account you want.

However, if you must have runas work as you expect it to, you can enable
the built-in administrator account from an elevated command prompt (net
user administrator /active:yes) and then set its password to something.

If you use the runas command to run something in the context of the
built-in administrator account, that program *will* have admin power and
it *will not prompt for permission*.

While this makes things easier, it is less secure than using the task
scheduler, because 1) the admin password is stored in plaintext and 2)
the access permissions on your batch files are less strict than the ones
on the task scheduler, unless you manually modify them.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

> The reason entering a password into runas isn't good enough for
> elevation is because other programs can run this command on your behalf
> without your knowledge. The UAC prompt ensures that you are actually the
> one performing the action, in such a way that programs can't fake.

Actually, after thinking about it some more, it is probably more to keep
your password secure from other programs that to keep other programs
from using your password.

It would be different if runas was hooked into UAC to allow it to
securely ask for the info, but then it would have a dependency on UAC,
which wouldnt work for the people who turn it off.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Sorry for any confusion - my issue is related to but different from the
original post - I wasn't claear enough about that: this has nothing to do
with the task scheduler.

Must confess I didn't understand the point that

>The reason entering a password into runas isn't good enough for
>elevation is because other programs can run this command on your behalf
>without your knowledge.

because I hadn't found a way to pass a password into runas - I don't find a
parameter for that so I can't see how another program could run something on
my behalf (and where would it get the password from??)

I am very tempted to join the "UAC OFF Club" - after three months now I am
heartily sick of jumping through hoops. I read the technique (was it yours?)
for using scheduler to get UAC-causing tasks to run without UAC prompts at
startup but it seems that to make a Microsoft omelette breaking the eggs is
just not good enough - they have to be painstakingly disassembled according
to some obscure specification.

Thanks for the feedback though - it was illuminating...

Julian

"Jimmy Brush" wrote:

> Julian wrote:
> > Hi Jimmy,
> >
> > In my case the access denied occurs on the Net Share command.
> >
> > I appreciate the protection from things running things without my permission
> > but
> >
> > 1. I have runas in the batchfile and I must give it my password - that
> > should be enough
> > 2. Even though it clearly isn't enough, when it gets to the Net Share, why
> > don't I get a UAC prompt? why does it just go ahead - and fail?
> >
> > [I run with Admin rights all the time now as it makes no difference to UAC
> > for the reasons you outline but at least I can click to continue rather than
> > having to enter a password each time]
> >
> > [Incidentally, when I accidentally "ranas" with the wrong user account
> > ("Admin" instead of my username, but obviously an account with Admin rights)
> > I also got an access denied on running SyncToy (the next line in the batch
> > file) because it was Julian's app - I think - it doesn't make any sense to me
> > to block things like this]
> >
> > I hope someone can answer mikeyhsd's Q about an appropriate switch for COMMAND
> >
> > Thanks
>
> I am confused - are you or are you not starting the batch file from task
> scheduler?
>
> There's no need to use runas when you're using task scheduler - you can
> specify using task scheduler what user to run the batch file under - and
> by checking the highest privilege box, it will allow the file to use the
> admin power.
>
> The reason entering a password into runas isn't good enough for
> elevation is because other programs can run this command on your behalf
> without your knowledge. The UAC prompt ensures that you are actually the
> one performing the action, in such a way that programs can't fake.
>
> The reason task scheduler can do this but runas cant is because task
> scheduler is only accessible to administrator programs that have already
> prompted, while runas can be used by any program.
>
> Unfortunately, command-line programs don't prompt for admin power
> on-demand when they are run (which would make this scenario possible).
> They must be ran from a command prompt that you have started with admin
> power by right-clicking it and clicking run as administrator. But even
> in that case, runas wont work like you want it to (and I don't have a
> good reason why this happens, either; one would think it would).
>
> I'm not exactly sure why it was designed that way.
>
> Using runas to run a program under a different account does not elevate
> the program to administrator status, even if the user is an
> administrator, nor is there any way to cause it to prompt for elevation
> that I am aware of.
>
> I highly recommend not using runas for this purpose and instead use the
> task scheduler to run the batch file in the context of the account you want.
>
> However, if you must have runas work as you expect it to, you can enable
> the built-in administrator account from an elevated command prompt (net
> user administrator /active:yes) and then set its password to something.
>
> If you use the runas command to run something in the context of the
> built-in administrator account, that program *will* have admin power and
> it *will not prompt for permission*.
>
> While this makes things easier, it is less secure than using the task
> scheduler, because 1) the admin password is stored in plaintext and 2)
> the access permissions on your batch files are less strict than the ones
> on the task scheduler, unless you manually modify them.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ - http://www.jimmah.com/vista/
>

Julian wrote:
> Sorry for any confusion - my issue is related to but different from the
> original post - I wasn't claear enough about that: this has nothing to do
> with the task scheduler.
>
> Must confess I didn't understand the point that
>
>> The reason entering a password into runas isn't good enough for
>> elevation is because other programs can run this command on your behalf
>> without your knowledge.
>
> because I hadn't found a way to pass a password into runas - I don't find a
> parameter for that so I can't see how another program could run something on
> my behalf (and where would it get the password from??)
>
> I am very tempted to join the "UAC OFF Club" - after three months now I am
> heartily sick of jumping through hoops. I read the technique (was it yours?)
> for using scheduler to get UAC-causing tasks to run without UAC prompts at
> startup but it seems that to make a Microsoft omelette breaking the eggs is
> just not good enough - they have to be painstakingly disassembled according
> to some obscure specification.
>
> Thanks for the feedback though - it was illuminating...
>
> Julian
>
> "Jimmy Brush" wrote:
>
>> Julian wrote:
>>> Hi Jimmy,
>>>
>>> In my case the access denied occurs on the Net Share command.
>>>
>>> I appreciate the protection from things running things without my permission
>>> but
>>>
>>> 1. I have runas in the batchfile and I must give it my password - that
>>> should be enough
>>> 2. Even though it clearly isn't enough, when it gets to the Net Share, why
>>> don't I get a UAC prompt? why does it just go ahead - and fail?
>>>
>>> [I run with Admin rights all the time now as it makes no difference to UAC
>>> for the reasons you outline but at least I can click to continue rather than
>>> having to enter a password each time]
>>>
>>> [Incidentally, when I accidentally "ranas" with the wrong user account
>>> ("Admin" instead of my username, but obviously an account with Admin rights)
>>> I also got an access denied on running SyncToy (the next line in the batch
>>> file) because it was Julian's app - I think - it doesn't make any sense to me
>>> to block things like this]
>>>
>>> I hope someone can answer mikeyhsd's Q about an appropriate switch for COMMAND
>>>
>>> Thanks
>> I am confused - are you or are you not starting the batch file from task
>> scheduler?
>>
>> There's no need to use runas when you're using task scheduler - you can
>> specify using task scheduler what user to run the batch file under - and
>> by checking the highest privilege box, it will allow the file to use the
>> admin power.
>>
>> The reason entering a password into runas isn't good enough for
>> elevation is because other programs can run this command on your behalf
>> without your knowledge. The UAC prompt ensures that you are actually the
>> one performing the action, in such a way that programs can't fake.
>>
>> The reason task scheduler can do this but runas cant is because task
>> scheduler is only accessible to administrator programs that have already
>> prompted, while runas can be used by any program.
>>
>> Unfortunately, command-line programs don't prompt for admin power
>> on-demand when they are run (which would make this scenario possible).
>> They must be ran from a command prompt that you have started with admin
>> power by right-clicking it and clicking run as administrator. But even
>> in that case, runas wont work like you want it to (and I don't have a
>> good reason why this happens, either; one would think it would).
>>
>> I'm not exactly sure why it was designed that way.
>>
>> Using runas to run a program under a different account does not elevate
>> the program to administrator status, even if the user is an
>> administrator, nor is there any way to cause it to prompt for elevation
>> that I am aware of.
>>
>> I highly recommend not using runas for this purpose and instead use the
>> task scheduler to run the batch file in the context of the account you want.
>>
>> However, if you must have runas work as you expect it to, you can enable
>> the built-in administrator account from an elevated command prompt (net
>> user administrator /active:yes) and then set its password to something.
>>
>> If you use the runas command to run something in the context of the
>> built-in administrator account, that program *will* have admin power and
>> it *will not prompt for permission*.
>>
>> While this makes things easier, it is less secure than using the task
>> scheduler, because 1) the admin password is stored in plaintext and 2)
>> the access permissions on your batch files are less strict than the ones
>> on the task scheduler, unless you manually modify them.
>>
>> --
>> -JB
>> Microsoft MVP - Windows Shell/User
>> Windows Vista Support FAQ - http://www.jimmah.com/vista/
>>

Windows Vista is a big change from XP, which will inevitably require
learning new ways of doing the same thing.

We can only hope that there will be some benefit as a result of changing
over. I am convinced there is.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/