Forum Replies Created
-
Posts
-
I believe it should just be the WMI and RPC services that you need to make sure are running.
If you continue to have problems, please send us an email and we’ll troubleshoot that way instead of in the forum.
-Doug
nhsitdept – It’s not clear to me exactly how you came to this… in particular what looks odd to me is the quotation marks in your command. It should be something more like:
Tue-13:26:10> Deployment: Executing \JesseTestWin7 -s -w “C:BatchPatchtemp” “C:BatchPatchtempsetup.exe” /configure localonly64.xml
Please try to match your deployment to the screenshot below (obviously you might have a different installer path and a different target working directory, but the rest should be the same). Your ‘localonly64.xml’ file should be placed in the same folder as the setup.exe, which should prevent the need from specifying the entire local path to it, though I don’t think that specifying the full path is where the problem occurred. And you should make sure to check the box that says “copy entire directory contents…”
When you then execute the deployment it should have the quotation marks set the way that they are in what I pasted above, not how they are in what you pasted in your posting. Let me know how it goes.
Steve – With a firewall appliance, the configuration for WMI can potentially be a bit trickier than with Windows firewall, depending on the particular firewall device. WMI connections, by default, are not established on a static/fixed port. Instead WMI uses dynamic port configuration for its connections, which means that the actual ports used for a given connection are established on-the-fly at the time of connection. Each connection will end up using different ports. In the context of a classic hardware firewall, this used to be a problem because hardware firewalls would typically require any open ports to be configured manually. An enterprise firewall administrator could never know in advance which ports would need to be opened. However, fortunately many modern firewalls now implement DCE/RPC, which solves this problem and allows the use of dynamic ports for WMI/RPC. If you have a network level hardware firewall in place between the BatchPatch computer and the target computers, you’ll need to configure it to allow DCE/RPC, so that it can open the necessary ports, on-the-fly, for each WMI connection. More info on DCE/RPC can be found at the following two links:
Steve – This is an issue with WMI not being setup/configured properly, probably at the firewall/network level. The target machine needs to be able to receive and process WMI requests. I have never seen this particular error, but it’s occurring during the attempt to retrieve WMI info from the target machine. If you were to disable all firewalls and put the two computers on the same network, I don’t think you’d see this error. It’s occurring because either the target machine firewall is not allowing connectivity to WMI or a network device in between the BatchPatch machine and the target machine is preventing full connectivity for WMI requests.
I would suggest that you first make sure your firewalls are configured to allow WMI/RPC traffic. See this link for help: using-batchpatch-with-windows-firewall
Next I would google 0x80070776 and/or ‘The object exporter specified was not found’ to see if any of the suggestions made resolve your issue. Here’s a link that might help: https://social.msdn.microsoft.com/Forums/vstudio/en-US/99c278fe-df63-408b-b5b1-b95554b6b630/access-wmi-to-nated-machine?forum=netfxbcl
-Doug
Hi jwiseguy – What you have listed is certainly fine. It seems like overkill to me, but there’s nothing wrong with it. I found that 99% of the time just a one time ‘download and install + reboot if required’ is sufficient. Occasionally a new update might appear after all other updates are installed, so a cycle that includes downloading/installing updates twice is probably sufficient. The third time is likely unnecessary. But overall what you’re doing is fine and it’s certainly not going to cause any problems. It should certainly ensure that you’ve downloaded and installed all available updates.
Note, when you say “all” updates, you might consider modifying your filters under ‘Tools > Settings > Windows Update.’ The only way to install EVERY possible update is to search for ‘Software’ and ‘Drivers’ and ALSO check all the boxes under ‘Update Classification Filtering.’ If you search for only ‘Important’ and/or ‘Recommended’ updates, some optional updates will not be installed. However, these may be updates that you don’t want installed. On my non-WSUS machines I use the ‘Important’ plus ‘Recommended’ checkboxes to download/install the updates that Microsoft deems important.
-Doug
Thanks for reporting back. I’m glad you got it fixed. I would suggest that at some point you try v2.11 again. I wouldn’t be surprised if it started working, as we saw this happen with one other customer who was having the same problem.
-Doug
Interesting! Thanks for the follow-up. Glad you got it figured out.
-Doug
Hello thenew3 – let me refer you to these two other threads. Please review them carefully, and let me know if you have any luck with the suggestions. Essentially, this issue has been reported by only a very small number of users, and it’s always only happening on just one or two of their servers. We have not so far been able to reproduce the problem.
What is the *exact* error text? Please copy/paste the entire thing, verbatim.
Approximately how many of your 2012 R2 servers are working properly and how many are throwing this error?
If you compare the list of installed Windows Updates on a computer that is working properly with the list of installed updates on a computer that is throwing the error, are there any discrepancies between the two lists?
Please also review the below threads carefully, and let me know if you have any luck with the suggestions. Essentially, this issue (if the one you’re experiencing is *identical* to the ones noted below) has been reported by only a very small number of users, and it’s always only happening on just one or two of their servers. We have not so far been able to reproduce the problem.
error-2-hresult-2147024894-could-not-find-file
error-2-very-often-server-2012-r2-on-domain-controllers
-Doug
The Error 0 server 2012 issue was fixed in August 2014 (started occurring after a particular patch that Microsoft released at the time), so please update to the latest version. Also note there were more than a dozen other releases between your version and the current version, so I would highly recommend that you stay up to date as new versions are released. The default config of the software automatically notifies when updates are released (Tools > Settings > Check for updates on startup).
I’m not sure about the other Error 2 issue that you’re experiencing, but let’s see if it’s also addressed by the update.
-Doug
Booster – It sounds like you’re on the right track. I’m not sure how long you left it running before you decided to stop the service and decided that it was running endlessly. However, I think you’re correct that it’s not a BP issue. I’ve seen some cases, in particular when using the WsusScn2.cab file, where a search can take a very long time. If a computer doesn’t have free RAM and plenty of CPU horsepower, it can take a very long time for it to parse the WsusScn2.cab file. However, I think your plan of restarting the machine and renaming the softwaredistribution folder is a good bet.
Good luck.
-Doug
What version of BatchPatch is this? (See Help > About)
What action produces the error 0 and error 2? What is the full *exact* text of the error?
-Doug
Thanks for reporting this, Booster. This shouldn’t happen, as there are already multiple ways that BP is checking for and replacing the file if there is a newer one available. It’s not quite clear what might have caused this in your case, but I think it’s likely a rare set of circumstances. We’ll review the code to see if there’s anything else we can do to prevent this from occurring in the future.
-Doug
Mats – We are aware of this issue. It will be fixed in the next version. The issue is that when you copy/paste directly from Excel, each cell adds a hidden t (tab char). BatchPatch used to auto-remove the t until the most recent version when we made a slight change to the parsing, but forgot to deal with the t from Excel, not realizing that users were so frequently copying directly from Excel. The next version will remove the t once again.
-Doug
Jason – Yes, we are aware of this issue. The next release will allow copy/paste from Excel to work properly again without the extra notepad step.
Thanks,
Doug
Lewok – Your options are to either insert a bunch of 10 min wait periods, or you could have a scheduled task for each row that performs the shutdown. The scheduled task could be on the same grid, or you could create a new grid just for that purpose.
-Doug
-102 is telling us that the target server is not able to communicate with its update server (WSUS or Windows Update or Microsoft Update). This is generally due to a proxy or network issue or similar.
If psexec appears to be working properly when used at the cmd prompt against SCVMM2012R2, but you’re still having a problem with BatchPatch producing the error 2, then I would suggest you take a look at SCVMM22012R2 to see if there is any third-party software such as firewall/anti-virus/HIPS that might be interfering with the process and deleting the BatchPatchRemoteAgent.exe or severing the connection between the BatchPatch computer and SCVMM2012R2.
I would also suggest seeing what happens when you try BatchPatch from a different computer against SCVMM2012R2. Are you able to isolate the issue to SCVMM2012R2?
Since the issue is not occurring with other target computers, it does sound like there is something going on with just SCVMM2012R2.
Some other things to try:
If you can find an old version of PsExec, it would be worth trying one to see if it behaves any differently. Also, there’s a free PaExec, which you can try (rename it to psexec) and see if it has a problem too.
You can also try to look at the SCVMM2012R2 to see if the psexesvc service is listed in the services.msc console. Normally that should only be there DURING executing but should be removed automatically when execution completes. If it’s not getting removed, you could try removing it manually by running the following commands in the cmd prompt on SCVMM2012R2:
sc.exe stop psexesvc
sc.exe delete psexesvc
Please also see the following links, which discuss a similar issue:
It looks like psexec is not executing properly for that particular target computer. The issue has nothing to do with WSUS and group policy.
Try executing psexec at the command line from the BatchPatch computer to the SCVMM2012R2. You can try something like “psexec \SCVMM2012R2 IPCONFIG” as a test (without the quotes).
You need to get psexec working at the command line before BatchPatch will be able to successfully use it.
From the BatchPatch computer you need to be able to access \SCVMM2012R2C$ and \SCVMM2012R2admin$ in order for psexec to work.
The following links might provide some additional help:
using-batchpatch-with-windows-firewall
Thanks for working with me on this. It will be fixed in the next release.
-Doug
I sent you an email.
Thanks,
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
booster – It looks like this is a bug. The issue is that when ‘cached mode’ and/or ‘offline mode’ is enabled, the reboot does not occur when no updates are available for the target host. We’ll get this fixed for the next release. In the meantime, the workaround/solution is to change your job queue from:
Download and install updates + reboot always
Wait for host to go offline and come back onlineTO
Download and install updates
Reboot (force, if required)
Wait for host to go offline and come back onlineThanks for the heads-up. We’ll take a look at it. My guess is that there is a tab character (t) or similar that copying from Excel adds. We modified the host import method slightly in the last build to accommodate some additional functionality, so there’s probably a place in the updated method where we are neglecting to clean up the host entry and strip off things like tab characters. We’ll get this fixed for the next build, but in the meantime you’ll need to copy from Excel to notepad, then from notepad to BatchPatch in order to strip the problematic chars that copying from Excel adds.
Thanks,
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
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
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
Mats – You’re correct. The Task Scheduler functionality is looking for a successful ping of the computer, but that’s it. However, the Job Queue options actually check to see if WMI is responding (WMI doesn’t usually start responding until the computer is mostly booted, whereas a ping will generally respond before the computer is able to accept requests)
Though now that you mention it, I think we will update the Task Scheduler method to check WMI instead of just ping.
-Doug