BatchPatch Forums Home › Forums › BatchPatch Support Forum › HRESULT -2147024891: Access to the path … is denied.
- This topic has 5 replies, 2 voices, and was last updated 10 years, 3 months ago by doug.
-
AuthorPosts
-
September 9, 2014 at 11:45 pm #9354julianParticipant
Hi, I’m waiting for approval to buy batchpatch. Meanwhile I’m hoping you can help resolve this.
When I try to do something with Windows updates on a target machine (happened on several others too) I get this a lot. Seems to go away if I reboot the machine, but it then happens again fairly quickly. Hoping not to have to reboot everything before I can patch them.
Windows Update Messages
Error 1610. HRESULT -2147024891: Access to the path ‘\wlfssC$Program FilesBatchPatchBatchPatchRemoteAgent.exe’ is denied. – 11:36:51
The progress column says “Searching” but I’m not sure if that’s true.
I also see this:
Get Information Output Log
Could not find file ‘\wlfssC$Program FilesBatchPatchBatchPatchRemoteProcessOutput1730738134.log’.
(That file does not exist on the system. I had tried to do a ‘list all services’.)
The server is running Windows Server 2012.
Cheers, appreciate your help.
September 10, 2014 at 12:00 am #11579julianParticipantStrange, now I see this error instead (different HRESULT number)
Windows Update Messages
Error: 64. HRESULT: -2147024894. Could not find file ‘\wlfssC$Program FilesBatchPatchBatchPatchTempResult.log’. – 11:55:24
I’ve checked that the ID BatchPatch is running as on my workstation (win 7) is a domain admin.
September 10, 2014 at 12:15 am #11580dougModeratorThese all sound related though strange/unexpected.
First, please make sure you are only running one action at a time per target computer. Running multiple actions at the same time against the same target can, in some cases, produce weird results when one action severs a connection and ends up killing a different action in the process.
Second, do you have any type of anti-virus or intrustion protection/detection software running on the target machine or on the BatchPatch computer?
It seems like something is interrupting either psexec and/or the BatchPatchRemoteAgent that runs on the target. I would start by examining any software that is running on the target that could possibly be doing something along those lines. Try disabling or uninstalling (or testing on a machine that doesn’t have the same app installed) to rule it out.
The ‘Access Denied’ message does indicate a permissions problem, but I could also believe that it’s related to the other errors. Certainly it’s the case that under normal circumstances the domain admin would have local admin permissions on the target, but you should still verify the permissions to be sure.
It sounds like you’re using “run-as” to run the entire BatchPatch.exe as a domain admin user, yes? Could you try running as your regular logged on user and then input the alternate credentials into a BatchPatch row in the grid for the target host? Does this make a difference (it shouldn’t, in theory, but let’s see). Another test would be to log on to your computer with the domain admin credentials and then run BatchPatch without using run-as and without entering alternate credentials. Let me know what happens.
When you execute BatchPatch, try watching the target computer’s working directory (C:Program FilesBatchPatch). You should see the BatchPatchRemoteAgent.exe appear and then you should see several temp/log files appear that are created by the executing BatchPatchRemoteAgent.exe. Let me know if you do or don’t see this happening.
Also, please watch the processes list in task manager on the target. You should see the BatchPatchRemoteAgent.exe as well as psexesvc.exe. Do you see these or not?
Lastly, please check the services on the target machine. Normal psexec behavior is to install a temporary service called psexesvc, which lives for however long the process runs, and then it is removed. Does this service get orphaned on the target instead of being removed? If it is orphaned somehow, that could be why you get different error the second time around. If that’s happening, try removing it with these two commands.
sc.exe stop psexesvc
sc.exe delete psexesvc
What is the percentage of your targets that you’re seeing this behavior on? Or is it just a single one?
-Doug
September 10, 2014 at 2:39 am #11581julianParticipantHi, thanks for the reply. Here is some feedback covering most of your message:
– Yes, only running one action at a time.
– Tried without a/v running on both the target server and the client workstation.
– My account is a Domain Admin. The Domain Admins group is in the Local Admins group on the target server. I was able to browse to c:program filesbatchpatch from another server where I was logged on as my admin account, and was able to create a text file in there.
– I will take a quick look at the processes and services, and test while logged in to windows with my admin ID soon and come back to you. Meanwhile, see the below…
– Then I watched the working directory..
+ Deleted (moved) the files that were in there.
+ Ran “Windows Updates | Check for available Updates” from my workstation
+ BatchPatchRemoteAgent.exe appeared in the folder along with BatchPatch.log, BatchPatchTempCurrent.log and BatchPatchTempProgress.log
+ The row in BatchPatch showed “Executing BatchPatchRemoteAgent.exe” for a while, and the Progress column said “Searching”, which seemed good, but after a long time it still said this.
+ The all messages windows says this a lot:
Wed-12:19:54> Windows Update: Error 1610. HRESULT -2147024891: Access to the path ‘\10.4.40.22C$Program FilesBatchPatchBatchPatchRemoteAgent.exe’ is denied.
Wed-12:19:42> Windows Update: Attempting to initiate Windows Update (Action: Search for updates. Server selection: Default / Managed) …
Wed-12:19:42> Windows Update: Establishing connection…
Wed-12:19:42> Windows Update: Initializing…
Wed-12:19:42> Windows Update: Queued…
+ While the windowsupdate.log says this. These two sets of logs don’t appear related, looking at their timestamps, but that’s because I have mucked around a bit. I could show you that an attempt as above and the windowsupdate.log as below match in terms of timestampts if you want me to.
2014-09-10 14:32:08:859 2076 8e0 Misc =========== Logging initialized (build: 7.8.9200.16924, tz: +1200) ===========
2014-09-10 14:32:08:859 2076 8e0 Misc = Process: C:Program FilesBatchPatchBatchPatchRemoteAgent.exe
2014-09-10 14:32:08:859 2076 8e0 Misc = Module: C:WindowsSYSTEM32wuapi.dll
2014-09-10 14:32:08:859 2076 8e0 COMAPI
2014-09-10 14:32:08:859 2076 8e0 COMAPI — START — COMAPI: Init Search [ClientId = BatchPatch]
2014-09-10 14:32:08:859 2076 8e0 COMAPI
2014-09-10 14:32:08:859 2076 8e0 COMAPI
2014-09-10 14:32:08:859 2076 8e0 COMAPI — START — COMAPI: Search [ClientId = BatchPatch]
2014-09-10 14:32:08:859 2076 8e0 COMAPI
2014-09-10 14:32:08:874 2076 8e0 COMAPI <<– SUBMITTED — COMAPI: Search [ClientId = BatchPatch]
+ Interestingly, I tried to empty out the BatchPatch directory again on the server to start the test again, but got a message saying I couldn’t delete BatchPatchRemoteAgent.exe because it was in use.
So I can repeat the test if you want me to, but hopefully you can see something in there. Seems odd that it’s holding on to BatchPatchRemoteAgent.exe?
September 10, 2014 at 2:43 am #11582julianParticipantWhen I tried it on several servers a few weeks ago (older version) this was the situation on most of them. Most of our servers are Server 2012.
September 10, 2014 at 3:39 am #11583dougModeratorOK, thanks for the info. The logs you sent are not consistent with what you’re describing. What I mean to say is the log that errors with 1610 is erroring and then exiting BEFORE execution of the BatchPatchRemoteAgent.exe ever occurs. Yet, you’re telling me on the other hand that you’re seeing execution take place (this is confirmed by the appearance of “Searching…” and “Executing BatchPatchRemoteAgent.exe” in the console as well as the 3 .log files appearing in the target working directory. I’ve emailed you so that we can try to get things figured out.
-Doug
-
AuthorPosts
- You must be logged in to reply to this topic.