[doug]

stevedev – This is very interesting, and it sounds like you’ve made some progress. Out of curiosity, would you mind describing a bit about your environment? I’ve never heard of the

The object exporter specified was not found. (Exception from HRESULT: 0x80070776)

error that you were receiving, and I’d be curious to know more about your infrastructure to understand why it was occurring. I’m glad that you got it resolved, but it’s peculiar that it was happening in the first place. The article you linked to above mentions a NAT setup. Are you somehow trying to connecting to WMI through a NAT device? Is it a one-to-one NAT? I can’t imagine how it could work in a many-to-one NAT/PAT setup.

As for the new Access is denied error, can you confirm that the Domain Admins group is the in the local administrators group on the target machine?

Please also take a look at the following link for some additional suggestions. See if any of the options listed here are able to work for you.

batchpatch-authentication-in-domain-and-workgroup-non-domain-environments

Ultimately I can tell you that I have never seen the Access is denied error be inaccurate. That is to say that if you’re getting Access is denied then it’s surely a permissions (or similar) issue, as opposed to there being some other underlying problem.

Another quick test to try is to just make sure that local WMI connections can be made on the box. So instead of trying to remotely connect, try to run BatchPatch directly on the machine in question. However, when you launch BatchPatch on that machine, make sure to run it with elevation using right-click run-as administrator. Then add the localhost (using the machine name) to the grid. Then see what happens. Do you still get the Access is denied error or is it successful?

Also, for the sake of testing, I would suggest using just the “Get last bootup time” action. This is a WMI-only action, whereas the Windows Updates actions use WMI plus PsExec, which requires additional access beyond WMI. It’s prob best to first make sure that the WMI-only actions, such as “Get last bootup time,” work properly first before trying the actions that use WMI in addition to PsExec.

Keep me posted.

-Doug

[doug]

BatchPatch automatically provides the proper quotation marks, so the “command to execute” need not be manually edited by you at all. When you create the deployment as specified in the screenshot, the “command to execute” is automatically populated as you see in the screenshot. I did *not* manually edit it, nor should you.

Thanks,

Doug

[doug]

ombra17 – What happens when you try to access \\targetComputer\admin$ and \\targetComputer\c$ from the BatchPatch computer? This is where BatchPatch is throwing the error. BatchPatch tries to access \\targetComputer\c$ so that it can create the remote working directory. If you try to access these locations manually by going to

start > run > \\targetComputer\C$
start > run > \\targetComputer\admin$

What happens?

[doug]

I believe it should just be the WMI and RPC services that you need to make sure are running.

[doug]

If you continue to have problems, please send us an email and we’ll troubleshoot that way instead of in the forum.

-Doug

[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.

[doug]

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:

https://en.wikipedia.org/wiki/DCE/RPC

http://wiki.wireshark.org/DCE/RPC

[doug]

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

[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

[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

[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

[doug]

Interesting! Thanks for the follow-up. Glad you got it figured out.

-Doug

[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.

error-2-hresult-2147024894-could-not-find-file

error-2-very-often-server-2012-r2-on-domain-controllers

[doug]

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

[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

[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

[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

[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

[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

[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

[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

[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.

[doug]

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:

error-2-very-often-server-2012-r2-on-domain-controllers

error-2-hresult-2147024894-could-not-find-file

[doug]

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

getting-started-with-batchpatch

batchpatch-ports

[doug]

Thanks for working with me on this. It will be fixed in the next release.

-Doug

[doug]

I sent you an email.

Thanks,

Doug

[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

[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 online

TO

Download and install updates

Reboot (force, if required)

Wait for host to go offline and come back online

[doug]

Thanks 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

[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

[Author]

Posts