[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

[doug]

Excellent! I’m glad that worked.

Note, the reason that deleting the cache contents didn’t work when you did it is because the cache folder you cleared was not the same cache that the “Re-copy/overwrite updates that have already been cached on target hosts” setting refers to. In this case when you checked that setting, BatchPatch overwrote the cache for that particular update in the actual Windows Update cache directory that is located in C:WindowsSoftwareDistribution on the target computer.

-Doug

[doug]

Mats – Thanks for the information. This is peculiar. Please try checking the box that says “Re-copy/overwrite updates that have already been cached on target hosts” under ‘Tools > Settings > Windows Update.’ Then try again. Let me know what happens. If it doesn’t work again, please paste the same logs upon completion.

Thanks,

Doug

[doug]

Vince – I’m sorry to hear that you’re having problems. I sent an email to the email address that you used to register your forum account. I’ll need more information, including the .bps file you’re using and the actual tasks that are being executed that are triggering the crash, so that I can hopefully reproduce the problem. Please reply to my email as soon as you have a moment.

Thanks,

Doug

[doug]

Mats –

Can you paste the contents of the ‘Local Agent Log’ and ‘Remote Agent Log’ columns here? They should answer the question for us.

My guess is that you have some of the “classification filters” unchecked under ‘Tools > Settings > Windows Updates.’ And so what I think is happening is that you are checking for available updates and finding that there are updates available. But when you try to install the updates, they are skipped because they are filtered out, due to your classification filters. And so you get the message that “There are no updates available for installation.”

Thanks,

Doug

[doug]

Thanks, Andreas. We will consider this for a future build.

-Doug

[doug]

Thanks for sharing that command. I’m glad you have a workaround for the time being.

When BatchPatch detects if reboot is pending, it looks at that same key PLUS 3 other tests. Windows does not have a single consistent/reliable way to determine pending reboot, so to be as thorough as possible BP performs 4 different checks to make the most reliable determination.

The “check for pending reboot + reboot if required” action will be in the next published release, which will probably be in approximately 6 to 8 weeks from now.

Thanks,

Doug

[doug]

This is very interesting and peculiar. I’m going to send you an email so that we can converse bit more easily.

-Doug

[doug]

andydicken – Since the error you are seeing is not the same as the error in this topic thread, I moved our discussion to this topic thread.

[doug]

Hi Andreas – Thank you for the suggestion.

There is currently an option to “Get pending reboot status,” but yes, we will also plan on adding an additional action to “Check pending reboot status + reboot if required.”

With regard to your second question, the job queue has two options:

“Wait for host to be detected online”

“Wait for host to go offline and come back online”

I think that one of these options should be sufficient for your needs. And once we add “Check for pending reboot status + reboot if required” I think you will be covered on all ends. If not, please explain in more detail why they are not sufficient and what *would* be sufficient, so that I can better understand how we might improve things.

Thanks,

Doug

[doug]

Booster – The current build of BP does not have this capability, but we will consider it for a future build. Thank you for the suggestion.

-Doug

[doug]

Andy – I’m a bit confused by what you’ve written. I’d like to make sure I understand everything clearly before proceeding. Please correct/clarify anything below that is not accurate.

1. You were running BatchPatch on a 2008R2 machine. BatchPatch would work successfully when targeting hundreds of machines, but a couple/few specific 2012R2 Hyper-V-enabled target machines were giving you this error:

Windows Update: Error: -1073741819. HRESULT: -2147024894. Could not find file '\xxxC$Program FilesBatchPatchBatchPatchTempResult.log'

2. You tried a number of different things mentioned in your previous posting such as paexec and psexec v1.98 etc, but none of those things fixed the issue.

3. You then launched BatchPatch on a 2012R2 machine (instead of the 2008R2 machine that was having a problem with a few targets), and everything seems to work fine on the 2012R2 machine against ALL target computers.

I don’t understand what you meant when you said “The 2008r2 WSUS server is working fine for hundreds of clients, and indeed this client, if the traditional GUI is used on that machine…” What is “this client,” and what is “the traditional GUI” and what is “that machine”? These references are ambiguous. I thought you said that the 2008R2 computer is the one that was having problems with certain Hyper-V targets. Now you’re saying it’s working fine?

Also, while I can say definitively that the issue is *not* related to the WindowsUpdate.log file, I’m also unsure what you mean when you say “when it connects to the older WSUS server?” What is “it?” And why is “it” connecting to the older WSUS server? I thought you were running BatchPatch console on your WSUS server? And so your WSUS server is not a target computer but is rather the console/source computer that would be establishing connections with all of your target computers.

Please note, I fear that even with your clarifications to the above questions I will still not be able to provide you with a useful answer as to what is causing the problem. Overall, this issue has only occurred for a *very* small number of BatchPatch users on an even smaller number of target computers. We have never been able to reproduce it. I don’t believe the issue is related to any type of configuration problem or group policy problem. Rather, I tend to think that this issue would be more accurately classified as a sort-of nondeterministic bug of some kind.

-Doug

[doug]

Hi Michael –

The current version of BatchPatch doesn not have SSH capability, as you know. That said, I don’t know of a way for you to use the current version of BatchPatch to remotely execute commands on linux systems.

We will consider adding SSH functionality to a future version of BatchPatch. Thank you for the suggestion.

-Doug

[doug]

I sent you an email.

-Doug

[doug]

Your settings are definitely correct.

When you’re launching BatchPatch, are you loading a .bps file or are you simply double-clicking the BatchPatch.exe and using an empty grid?

The behavior in BatchPatch is to abide by those ‘Auto resize settings’ for new empty tabs but not for existing .bps files. When you launch a .bps file all columns that are populated in the .bps file are made visible in the grid. To be honest, I’m not quite sure why this is the case. It might have simply been an oversight on our part, and I will discuss with the team to see if we can modify this behavior. However, can you confirm that you’re experiencing the behavior that I’m describing only for .bps files that you open? What I’m unclear on at the moment is if you are experiencing the issue when you launch an empty grid too or only when you load a .bps file.

Thanks,

Doug

[doug]

It sounds like maybe you just missed one of the settings under ‘Tools > Settings > Grid Preferences’

Note the section in the image below for ‘Auto-resize settings for windows and columns.’ You’ll want to have your settings match the settings in the image, and depending on your preference you might also want to consider unchecking the box that says ‘Allow BatchPatch to unhide columns automatically,’ or you might simply want to leave it checked but edit the columns that can be unhidden by clicking the “except these columns” button.

I hope this helps.

-Doug

[doug]

Andy – Can you confirm the exact error message that you’re receiving, in its entirety?

It’s hard to say if NIC teaming would cause this or not, though I wouldn’t expect it to cause a problem, in general. However, anything is possible, and perhaps it depends on the exact configuration of the team. Are you seeing this only on servers with NIC teaming? Is it occurring on *all* servers with NIC teaming? Is it occurring on the VMs or the actual host machines or both? Are they all producing the *exact* same error message? (note both the error number as well as the HRESULT number because the same HRESULT can be paired with different error numbers)

Does psexec and/or paexec work *without* BatchPatch? Are you able to simply use psexec/paexec at the command line from the computer that runs BatchPatch to one of these problematic hosts? As a test you could try something simple in the CMD window such as:

psexec \targetComputer IPCONFIG

paexec \targetComputer IPCONFIG

[doug]

We published an update today (2015-02-10) that should resolve this issue.

-Doug

[Author]

Posts