Error: 5. HRESULT: -2147024894. Could not find file

[MBAperia]

Hello,

Recently finished up our patch cycle, and everything went smoothly. Today, I was looking around to do a few postponed reboots, and noticed that I was getting this error on every server :

Error: 5. HRESULT: -2147024894. Could not find file ‘\,<remoteIP>C$Program FilesBatchPatchBatchPatchTempResult.log’. – 12:58:48

Searching for this brought up responses for “Error: 2. HRESULT: -2147024894. Could not find file”, which is not the exact same error. I tried killing the PSEXECSVC.exe on a few machines, but still came back with the original error. I’ve tried closing batchpatch, and rebooting my workstation. I’ve tried resetting the credentials that are used. I’ve tried updating to the latest version of batchpatch. Coworkers batchpatch works as expected.

Every single server in every single file returns this error, even servers that haven’t been patched in a cycle or two. Since my batchpatch is the only one that gets this error, I’d like to think this is an issue with my workstation. I can perform other commands such as deployments, pings, start/stop services, reboots and shutdowns. Only windows update commands throw this error.

What might be the problem?

[doug]

This is definitely very peculiar. Error 5 generally means “Access Denied,” which points to a permissions issue with the account you’re using. However, I know you said things used to work fine/normally for you, and your coworkers aren’t experiencing the issue. And furthermore, you’re not having any problems with any other functionality in BP, so it doesn’t *seem* like a permissions issue. But there is clearly *something* going on with your setup. I’m not quite sure what.

As a start, could you please watch the C:Program FilesBatchPatch directory on a target computer when you execute the Windows Update action? Do you see any files appear there? Normally we should see the BatchPatchRemoteAgent.exe in that directory, and then soon after that we should see several log files, including the BatchPatchTempResult.log. Do you see any/all of those files?

Please also take a look at the event log on the target machine. It would be interesting to see if there is an associated logon failure in the security log. However, I don’t think you would see this unless you specifically enabled audit failure logging in the local/group policy (https://technet.microsoft.com/en-us/library/dd277403.aspx). So if you’re comfortable enabling failure auditing, it would be interesting to see if the event log sheds any light on what’s happening. It would presumably confirm the access denial.

Thanks,

Doug

[MBAperia]

Doug,

Thanks for the quick reply.

I’ve opened up the C:Program FilesBatchpatch directory on several servers, then did a “check for updates”. Before running the command, only one file was in the directory was “BatchPatch.log”. Shortly after running the command, “BatchPatchRemoteAgent.exe” appeared, then the error (from OP) was shown in my console (after output of “Executing BatchPatchRemoteAgent.exe”), and the exe then disappeared. No other files or logs showed up.

As for windows security logs, I get the following events:

5140

5145

4672

4674

4634

4656

4658

All for the account used to connect to that machine with batchpatch.

[doug]

Ok, so what this tells us is that the BatchPatchRemoteAgent.exe is never even getting executed successfully. Not clear why we’re getting the error 5/access denied message.

Are you using ‘integrated security’ or are you specifying alternate logon credentials? Is the account that you are using the same account that your coworkers are using? Assuming that you’re using integrated security, one interesting test would be to have one of your coworkers log on to your machine and see if he/she experiences the same issue from your machine. Similarly it would be interesting if you logged on to one of your coworkers machines to see if you experience the problem on his/her machine. Right now we don’t know if the issue is specifically tied to your computer or not.

One thing that I believe can cause an ‘access denied’ message when it’s not a permissions problem is if the file gets locked by another process. Is there any possibility that you have some other software, such as antivirus or HIPS or similar security-related software that might be locking the BatchPatchRemoteAgent.exe right after it’s copied to the target? Certainly it doesn’t seem likely, especially considering that your coworkers are not experiencing the issue, but I’m not sure what else could possibly be causing the problem.

Also, as you pointed out, things had been working fine, and then they stopped. Obviously BatchPatch didn’t change what it’s doing, so something in your environment seems to be different now. I’m not sure whether that’s your computer, your account permissions, or something else altogether.

-Doug

[MBAperia]

Doug,

First, thanks for responding this late on a Friday. We’ve got an odd environment, so every entry uses alternate credentials. There are a few different accounts used. I’ve tried using some of these accounts on coworkers machines, and they have no issue running the Check for Updates command.

I’m not sure about the file lock, the only common denominator between the machines are AV and Windows server (multiple versions). I tried adding an exception for the BatchPatchRemoteAgent.exe (thinking it may be a new definition causing the issue), but still got the same error.

[doug]

No problem. Glad to try to assist. Here are a handful of other suggestions:

In addition to the exception for BatchPatchRemoteAgent.exe, please also try one for psexesvc.exe.

Is the account that you’re logging on to your computer with an admin user on that computer? If not, would it be possible to make it an admin user and then try again? Alternatively, if it already is an admin user, would it be possible to launch BatchPatch with admin elevation (right-click run as admin), and then try again?

Since you’re using alternate credentials, please try the following: Instead of entering alternate credentials into each row, please instead try to run BatchPatch using right-click run-as, and run the entire BatchPatch.exe as the alternate user. Then inside of BatchPatch do NOT specify alternate credentials per-row. Instead, please remove any row-specific credentials and see what happens. Does this work?

What version of psexec are you using? Do you have access to any older/newer versions? Please try subbing in any different versions of psexec that you can find. Additionally, you can try subbing in paexec, which is a third-party free psexec clone. You’d have to rename it psexec to test it out. See if subbing in any of these older/different versions has any impact. In the end you’ll want to still revert back to the latest version of psexec because it’s the most secure for alternate credentials. However, the reason I suggest trying different versions is because in a few instances over the past few years, we’ve heard of some weird things happening from users that were magically fixed by trying a different version and then switching back to the original version. Never figured out how/why/what happened in those cases, but it’s worth having you try the same thing to see if it works for you like it has worked for others in the past.

Please verify that you are able to successfully use psexec at the cmd prompt from your BatchPatch computer. You can try something simple like “psexec \targetcomputer IPCONFIG” without the quotes, of course. Clearly if psexec isn’t working at the cmd prompt, then it’s definitely not going to work with BatchPatch. However, judging from everything you’ve already stated, I suspect psexec from the cmd prompt will work fine. Let’s just make sure.

If you’re still not having any luck, if you look at a target computer after you receive the error 5, in the services.msc on the target do you see an orphaned psexesvc listed? Normally this service should be installed by psexec and then removed by psexec after completion. However, I’d like to know if the psexesvc service is not successfully removed after your error 5. If that’s the case, then on the target machine please try to delete it:

sc.exe stop psexesvc

sc.exe delete psexesvc

Then try again to run the BatchPatch Windows Update action and see if you have any luck.

Thanks,

Doug

[MBAperia]

Doug,

The credentials I’m using are in the local admin group of the machines.

I tried psexec from the cli to some of the servers, getting access denied on each one. The same servers I can use the same credentials to RDP to. I’ll try a new psexec and the other recommendations on Monday. Thanks for your help so far.

[MBAperia]

Looks like it’s something with psexec. I haven’t been able to get a single psexec command to work from the cli. I’ve updated to psexec v2.11, but I’m still getting access denied. I found that psexesvc.exe is on each machine, and the psexesvc service is running. I go stop the service, delete the exe, and try again, but I get access denied (and the service starts, and the .exe reappears in the windows directory) I’m also starting to get the following error :

Error: 233. HRESULT: -2147024894. Could not find file ‘\<ip>C$Program FilesBatchPatchBatchPatchTempResult.log’.

[doug]

Some more things to try:

Take a look at the following link and see if any of it applies to your environment. It still strikes me as odd that you’re only having problems from your own computer and not your coworkers’ computers, but I think it’s still worth testing:

BatchPatch Authentication In Domain and Non-Domain / Workgroup Environments

Make sure that from your computer to the target computers you are able to access \targetComputeradmin$ and \targetComputerC$

Make sure that on your computer there aren’t any third-party apps, such as a firewall or HIPS or Anti-virus program that might be causing communication problems between the remote and local processes.

When you’re testing psexec at the command prompt, what happens if you first try the following: cmdkey.exe /add:targetComputerName /user:Domainusername /pass:password

What happens if you launch BatchPatch using right-click run-as, and then run the entire BatchPatch.exe as the alternate user instead of using alternate credentials in each row of BP?

What happens if you log on to your workstation with the alternate user credentials instead of specifying alternate credentials inside of BatchPatch?

I also would still see if you can try paexec instead of psexec, and if possible to locate an older version of psexec (maybe prior to v1.98), if you can find it. See if either has any impact.

I still believe that “Access Denied” in your command line attempts confirms that there is some type of permissions problem. I have never heard of or seen “Access Denied” end up happening due to some other reason.

-Doug

[MBAperia]

Doug,

Thanks for all your help on this. I wanted to post that I’d found the culprit : the Symantec DLP Agent that was deployed the same time we started having issues. The coworkers who could still use BatchPatch didn’t have the Agent, and their BatchPatch (and PsExec) quit working as soon as they had the Agent installed. Once we disabled the agent, BatchPatch (and PsExec) began working as expected. Thanks for helping me troubleshoot.

[doug]

Thanks for following up. I’m really glad to hear that you got it resolved.

-Doug

[Author]

Posts