Windows Server 2012 R2 Task Scheduler access denied (0x80070005), but command works manually in shell

batch-filepermissionswindowswindows-server-2012-r2

I have the following problem. On our Windows Server 2012 R2 is a scheduled task which calls a batch file, which in return calls vb scripts.

Those scripts just download 5 pictures and stores them into a folder under a specified name. If I call the bat directly via command line, it works like a charm but with the scheduler I get following information.

It saves the files in the same partition where the script is located. Just in another folder where the user also has access, because he is added to the admin group.

Event Information: Event-ID: 201  ResultCode 2147943645 successfully completed

The ResultCode seems to match the following access denied message.

Result of the last execution: Access denied 0x80070005

My researches lead me to try some config changes.

Run the task in the Schedule with highes rivileges -> same error
Change the security for %windir%/system32/cmd.exe -> user already in
the admin group
Remove " from start in -> there is nothing, also adding the
folder, where the script is located doesn't change anything

Thank you in advance for any hint, question, information to this problem.

Best Answer

I think that should check Task Security Context of your schedulled task.

Do you have store user's password in the task?

The error can be caused by lack of network access.

Related Solutions

Windows – Useful Command-line Commands on Windows

A little known one is

getmac

It shows the MAC address(es) of your network adapter(s).

Screenshot of running getmac from a Windows commandline window.

Windows – Access denied using NET USER command via SSH session

Even though you say you checked the group memberships, it really sounds like your "admin" account doesn't have the same group memberships as the "Administrator" account.

The Windows "whoami.exe" (not the Cygwin whoami) with the "/ALL" parameter will show you each user's group memberships so that you can compare them.

(In theory, it would be possible to modify the permissions of user objects in AD to deny the "admin" user rights to change their password while still having "admin" be members of the same groups as "Administrator", but I think that's highly unlikely.)

To rule out anything to do with the cygwin SSH altogether, why not logon locally to the server comuter with the "admin" credential and try your "NET USER" from an NT command prompt?

Edit:

There really isn't any kind of group policy setting that affects the ability to change passwords, per se. If your "admin" account is a member of "Enterprise Admins" it should be able to reset the password of any other account in the Active Directory. Like I said above, there are "tweaks" that one could have made to AD that would change that behaviour, but I find it highly unlikely that any of that would've been done. I think that something else is happening.

If you don't have failure auditing of account management events enabled, now is a good time to either create a new GPO linked to your "Domain Controllers" OU (the preferred) or to modify your "Default Domain Controllers" GPO (not preferred-- you really shoild leave this GPO "stock) and turn on account management event failure auditing. Dig down into "Computer Configuration", "Windows Settings", "Security Settings", "Local Policies", and "Audit Policy" and enable failure auditing on "Account management".

Run a "gpupdate" on your domain controller comptuers, try your "NET USER" again, and examine the Security Event Log on all your DC's to see which one is recording the failed password change.

I'm keen to figure out what's going on. Like I said, I expect that it's something simple that's being overlooked... We'll see...

Related Topic