[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

[doug]

We’ve isolated the problem and expect it will be fixed in the next release, which is likely coming in 4 to 8 weeks.

Thanks,

Doug

[doug]

Good question. I don’t think you’re missing a step because I’m experiencing the same behavior. We will look into it and then I’ll get back to you.

Thanks,

Doug

[doug]

And so what happened when you renamed the SoftwareDistribution folder. Did that solve the problem? I think that’s probably your best bet since that is the location where all the update history information is stored. If the update history information is somehow not being stored properly, it seems to indicate a problem or corruption in the datastore in that folder.

-Doug

[doug]

Dennis – The column sizes and column order are both set globally, not per-tab. So, unfortunately you will not be able to have different sizes and ordering remembered on a per-tab basis. If you close all instances of BP and then open just a single tab and set the column order in the way that you want, and then close BP, that order will be remembered when you launch a .bps file.

As far as columns being unhidden that you don’t want to unhide, the current version of BP will unhide any columns the contain data in the .bps file when the .bps file is launched.

There is a button under ‘Tools > Settings > Grid Preferences > “except these columns”‘ which allows you to have BP never open certain columns automatically during action execution. However, when loading a .bps file, if the columns contain data, they will be opened regardless of that setting.

That said, in the new version that will be out in the next month or two there will be a new option that will allow you to bypass the auto-opening of specific columns when loading .bps files.

-Doug

[doug]

Rob –

I also am not able to reproduce the issue on my server 2003 box in the lab. Out of curiosity, what version of the Windows Update Agent do you have on the 2003 servers that are not reporting any update history in BP? To check the WUA version, right click on C:WindowsSystem32wuapi.dll and then check the version tab.

I don’t think this is a BatchPatch problem, per se. The update history is retrieved simply by querying the Windows Update Agent on the target computer. It’s possible that the WUA is simply not properly logging update history entries, though I am not sure why (unless it’s just some weird thing where the WUA needs to be updated, which is why I asked about the version above).

The update information is stored in C:WindowsSoftwareDistribution. If it’s the case that the information being reported is not correct, then I wonder if the datastore is corrupt or otherwise malfunctioning. I would suggest trying to stop the Automatic Updates/Windows Update Agent service, then rename the SoftwareDistribution folder to something like SoftwareDistribution.old, and then restart the service. This should cause Windows to create a new SoftwareDistribution folder, and perhaps this will fix the issue moving forward, though I would expect you wouldn’t be able to know until you install the next round of updates. And of course, if you perform the steps outlined above, you would be doing so at your own risk, and I can’t take responsibility for anything bad that happens as a result. However, I can tell you that I’ve done this many times without ever encountering a problem, and this is suggested all over Windows Update forums on the web when one encounters issues with Windows Update on a computer. That said, I wouldn’t expect it to cause any problems.

-Doug

[doug]

Jeremy – Thanks for sharing! This is a great use of BatchPatch, for sure.

One note: If you’re interested in ditching your .vbs script, you could hardcode the command directly into BatchPatch to retrieve the version number:

WMIC PATH Win32_Product WHERE caption='Symantec Endpoint Protection' GET version

You could input the above command into either of the ‘Create/modify user-defined commands’ sections under ‘Get information,’ or ‘Execute remote process/command’

-Doug

[doug]

Using BatchPatch with Windows Firewall

[Author]

Posts