[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

[doug]

-2145107941 converts to 8024401B, which indicates a proxy authentication issue of some kind. It doesn’t sound like BatchPatch issue, per se. It sounds like an issue with the Windows Update Agent on the target computer being able to access the Windows Update server. See these google search results for reference:

https://www.google.com/#q=8024401B

Also, please take a look at this link too:

Windows Update Proxy Settings and BatchPatch -2145107941 / 8024401B

-Doug

[doug]

Indeed, that is strange. It sounds like you’re using BatchPatch in cached mode. One other thing you might try to resolve this issue is to have BatchPatch overwrite the Windows Update cache on the target host(s) in question. If the .NET installation file on the target host is somehow corrupt, this could be a potential cause of failure.

There is a setting available in BatchPatch called “Re-copy/overwrite updates that have already been cached on target hosts,” which is available under ‘Tools > Settings > Windows Update.’ Please check this box and then try again. Let’s see if that has any impact.

-Doug

[doug]

After examining the WindowsUpdate.log we found this line:

COMAPI WARNING: ISusInternal::GetEulaText failed, hr=80240033

It turned out the issue was with a particular Silverlight update on the 2008 SP2 WSUS. Andy was able to remove the approval for the Silverlight update, then run:

WSUSUTIL RESET

And then rerun the approval rule. This fixed the issue.

-Doug

[doug]

Hedi – You emailed us last month citing similar issues with installation failures when trying to install .NET updates. However, all other updates were installing successfully. Generally this means that BatchPatch is working properly. .NET installation failures are likely due to a problem with the target computer that has nothing to do with BatchPatch. I would recommend that you try installing the .NET updates separately from all other updates. See if that helps. If not, you should research the error message/number in google to see if you can find a solution.

Thanks,

Doug

[doug]

Thanks, Booster. We’ll see about adding these in a future build.

-Doug

[Author]

Posts