[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

[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

[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

[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

[doug]

Mats – You have 2 options:

1. Modify the timeout. You can modify this value in the Job Queue window. On the left side of the window there is an option “Wait for host offline / online detection. Global timeout (minutes).” Setting this value to 0 will disable the timeout altogether and cause BatchPatch to wait indefinitely for the host to be detected online.

2. Use the Task Scheduler. On the Task Scheduler window there is an option to “Run task immediately upon detecting target computer online.” Using this option will instruct BatchPatch to wait indefinitely until the computer is detected online before it executes the scheduled task.

[doug]

One user determined that the firewall software in place at his organization was the cause of the issue. He was able to add a new exclusion rule to resolve it.

[doug]

John – “RPC server is unavailable” means that for whatever reason, BatchPatch is not getting a response from the target. Normally this would occur because a firewall is blocking access, but if the firewall is disabled as you mentioned, then I would question what else could be blocking connections. Here are a few thoughts:

1. Some other third-party software, such as host intrusion prevention or anti-virus or some other security software that is essentially providing firewall or similar services without calling itself a firewall.

2. The WMI Windows Management instrumentation service is not running.

3. The TCP/IP NetBIOS Helper service isn’t running

4. The issue is just a straight connectivity problem. If the BatchPatch computer is not able to reach the target machine in question, then you will get the RPC error. So, make sure that from the BatchPatch computer you are definitely able to ping the target machine. Perhaps you have a DNS issue, and you might consider looking at your DNS setup, using a FQDN instead of just a machine name, or trying the IP address instead.

5. Something is hosed up with the OS. Definitely try rebooting if you haven’t already done so. This isn’t really a BatchPatch issue, per se. There is something wrong with WMI or COM or something related to them (or it’s just a connectivity problem). BatchPatch is simply making a standard WMI query, but it’s not getting a response. I would also suggest that you take a look at the results of this google search and see if any of it helps: https://www.google.com/#q=0x800706BA

I hope this helps.

-Doug

[doug]

wiseguy – We are considering this. Yes, it is a lot of work. It’s not a trivial task.

-Doug

[doug]

Yes, you can still use BP.

Licensing, support, and update protection is all explained very clearly here: BatchPatch Purchasing and Licensing

[doug]

egebaek – On disjointed networks behind NAT devices, BatchPatch would work only on top of the existing connectivity that you provide (such as a VPN), but if you don’t provide said VPN or similar connectivity, BatchPatch does not have its own built-in functionality to traverse a NAT device with multiple machines behind it.

-Doug

[doug]

EmreGulluoglu – BatchPatch must be running in order for the scheduled tasks to run. There is not currently a way to run BatchPatch as a service.

-Doug

[doug]

This is definitely peculiar. I think the error is occurring during the authentication process, which is why I suggested trying Integrated Security instead of specifying alternate credentials in the row. I’m not sure what your setup is with this other site, and it’s interesting that it would only occur with a couple of hosts.

-Doug

[doug]

jollyjokester –

1. Only the computer that is running BatchPatch needs PsExec. The target computers do not need PsExec. If you’re having intermittent results with sometimes working and sometimes not working, I question if the computer that is running BatchPatch is currently unstable. Possibly a memory corruption of some kind.

2. Your company purchased a license of BP almost 2 years ago. Did things all of a sudden stop working? I assume things have been working properly for the past 2 years?

I would suggest that you start by rebooting the computer that is running BatchPatch. I would also suggest trying to use Integrated Security instead of specifying alternate credentials per-row. You could also consider launching the entire BatchPatch.exe with run-as a different user. Then inside of BatchPatch you would not need to specify alternate credentials. It’s unclear to me what could be causing this error, and I wonder if there might even be some type of memory problem on the BatchPatch computer, which is why I suggested rebooting it as a first step. You should also consider trying to run BatchPatch from a different computer and see what happens.

-Doug

[doug]

You’re welcome. That’s correct. The new release today, 3/16/2015, contains a fix for this issue.

-Doug

[doug]

Hey JB – I’m glad to hear you’re loving the tool so far!

When you insert auto-logon credentials, BatchPatch creates the following registry values in HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

AutoAdminLogon REG_SZ

DefaultUserName REG_SZ

DefaultPassword REG_SZ

DefaultDomainName REG_SZ

AutoLogonCount DWORD

Currently, BP automatically sets the AutoLogonCount value to 1 in order to provide a sort-of security fail-safe. When the AutoLogonCount value is set, each time Windows is rebooted and auto-logged on, the count is decremented by 1. When it reaches 0 and the computer is rebooted, it will not auto-logon again, and the DefaultPassword value is removed by Windows.

If you were to remove the AutoLogonCount value altogether, Windows would keep rebooting and auto-logging-on indefinitely. The reason we set it to 1 is so that if the administrator intends to remove the password after reboot but forgets, the value will not persist forever in the target computer’s registry and will instead be auto-removed by Windows after the computer is rebooted a second time.

We will consider exposing the AutoLogonCount value as an optional/configurable item in a future version of BatchPatch, but in the current version it will always be automatically set to 1.

I hope this helps.

-Doug

[doug]

OK, sounds good. Keep me posted. I’ll be curious to learn what, if anything, you find.

Thanks,

Doug

[doug]

Sounds like something a bit fishy happening on the computer running BP. Considering the fact that every time you execute it, BP is executing the exact same thing, but sometimes it’s working and sometimes it’s not, it seems to me that you should start by rebooting the system that is running BP, and then reboot the targets.

If you run the psexec command manually a number of times, does it ever fail? I know you said it didn’t fail the one time you tested it, but we also know that BP is not failing every time either. The error that is being triggered in BP is one that should, in theory, never be able to be reached, except in the event that psexec is not behaving properly.

Also, did you check the other posting that I had pointed you to, which mentioned the use of mandatory profiles? That’s the only thing that I’m aware of that will break psexec 100% of the time, and therefore it will also break functionality in BP that utilizes psexec.

In any case, I’d still suggest rebooting the BP machine and targets in question, and see if that has any impact.

-Doug

[doug]

coachep – Please take a look at the following link: Error 1613: Possible parameter count mismatch

Let me know what you determine.

Thanks,

Doug

[doug]

Booster – Thank you for reporting this. The next version will contain updated code for this functionality. After it’s released in the next few weeks or so, please let us know if you continue to have issues.

Thanks,

Doug

[doug]

OK, sounds good. If I get a chance to do some testing later, I’ll report back here.

Thanks,

Doug

[doug]

VY – Thanks for sharing your experience. No one has ever informed us of this kind of behavior. We have heard of AV products treating psexec.exe as a threat in rare instances, but in the worst case the psexec.exe or psexecsvc.exe is prevented from running. We have never heard of any instances where system files were quarantined by an AV product as a result of running a script with psexec. That sounds extremely bizarre, and your decision to open a ticket with McAfee certainly seems like the best place to start. Please report back here after you have it resolved. Let us know what happened.

Thanks,

Doug

[doug]

Jeremy – Maybe try the suggestion at this page:

https://stackoverflow.com/questions/12112182/how-to-add-a-group-with-long-name-to-local-group-from-command-prompt-or-batch-fi

It suggests the following command, which should be runnable directly from the cmd prompt, which means that it should also be runnable directly from the remote command field in BP. I have not tried it, so let me know how it goes:

powershell -command "& { ([adsi]'WinNT://./your-local-group,group').Add('WinNT://YOURDOMAIN/your-really-long-global-group-name,group'); }"

-Doug

[Author]

Posts