- This topic has 8 replies, 3 voices, and was last updated 8 years, 5 months ago by .
-
Posts
-
Note that I was running into the 1601 E_ACCESS_DENIED error on some machines when attempting to run BatchPatch. I checked all of the common debug steps for this error on this page:
Troubleshooting common errors in BatchPatch
I also tried disabling antivirus, verifying a number of services were running, but nothing helped. I then ran the WMI Diagnosis Utility:https://msdn.microsoft.com/en-us/library/aa394603(v=vs.85).aspx
It informed me that the DCOM service was not running, and that I run this command to fix it:
REG.EXE Add HKLMSOFTWAREMicrosoftOle /v EnableDCOM /t REG_SZ /d Y /f
After a reboot, I was now able to successfully run BatchPatch. Just FYI in case you want to add this debug step (or at least a link to the WMI Diagnosis Utility) to the BatchPatch common errors page.
Thanks. We actually do have it linked off the bottom of the authentication troubleshooting page, which is linked off the troubleshooting page you mentioned, but we’ll add it directly to the troubleshooting page too. It sounds like you did look through the authentication page on our site but most likely just didn’t see the Microsoft WMI troubleshooting link there because it was at the bottom of the page.
-Doug
Well I think you have a couple options. Considering that you got everything working last week, then either those systems have been modified since last time, or something that you are doing is different. You said that other tools that use WMI are still working fine. This to me is the key. BatchPatch does not have some special way of using WMI. WMI is WMI, and there is only one way to use it. That said, if you are successfully using WMI in other tools, then it sounds to me like maybe in BatchPatch you are executing with an account that does not have the appropriate permissions. I know you said that you’re using an account with permissions, but considering everything else that you’ve said, I would suggest taking a step back, closing all instances of BatchPatch, and then start from scratch. Verify the account that is in the local admins group on the target computer. Then since you’re using option 1, I would even suggest logging off of your own computer and re-logging back on with the same account. Maybe the password changed or expired? Then launch BP. Then test again. I can assure you that whatever problem you’re experiencing, it’s not a BP issue. If BP says “Access Denied” then it’s a permissions issue.
Doug-
I work with amartin, so I hope you don’t mind me jumping in. I re-imaged a machine using our imaging solution — this put it in a state that is analogous to how the machines were when we successfully ran batchpatch. However, I found that I was unable to run it against that machine.
It seems like something on the host machine changed — it is running under the same account that would have permissions (as amartin said), but I did try closing and re-opening batchpatch and restarting the machine anyway, but that did not work.
Recently (having a hard time finding the exact date, but potentially between the last successful run and now), several applications on the machine had versions changed. Are there any programs that are known to cause issues with BP?
There are not any programs that are known to cause issues with BP, nor would I expect any programs to cause issues with BP. The issue that you are describing is a Windows OS permissions issue, not a BP issue, and not likely related to a third party product, unless it was a security product, which I suppose could theoretically alter OS permissions/settings. I agree with you that something must have changed either on the BP host machine or on target machines. Usually an ‘Access Denied’ issue is a permissions issue on the target computer, not the host computer.
You might consider re-going-over the Microsoft WMI troubleshooting steps as a starting point to get WMI permissions working. Perhaps something has changed again with DCOM, which was the original source of the problem that amartin fixed. Sometimes just having a second set of eyes or a fresh look is all that it takes:
https://msdn.microsoft.com/en-us/library/aa394603%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
And also re-go-over the BP authentication stuff:
Unfortunately I don’t really have any other great suggestions other than to just reiterate that you are encountering a permissions issue of some kind. There is no case where ‘Access Denied’ has ever been produced when permissions were not at the core of the problem.
-Doug
So I started to do some testing with powershell and a simple WMI command:
wmi-getobject win32_operatingsystem -computername <computer>
I found that using the same credentials I use with BP, I can run that query from any computer against any other computer EXCEPT for the machine that actually has BP on it. On that machine, I cannot get the query to work going out or coming in. However, it will run against itself (i.e. a localhost query). This machine seems to have the same WMI settings as other machines. Do you have any suggestions on how I can further test this machine?
While it would be nice to fix that issue, for now, we will run BP from another box that is not afflicted.
The Microsoft WMI troubleshooting link posted above is really the best source I know for troubleshooting WMI issues. For now I agree with you that simply running it on a different box is the best plan.
-Doug
- You must be logged in to reply to this topic.