[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

[doug]

Hi Michael – I emailed you (as you had requested), but I never heard back. I deleted the posting where you asked me to email you because it contained your email address in plain text, and I didn’t want you to start getting spammed (trust me, your address would have been scraped quickly by numerous bots :).

-Doug

[doug]

Thank you for the suggestion. We will consider this for a future build.

-Doug

[doug]

ombra17 – The key information in the error here is “The network name cannot be found.” It sounds like either you have entered the name of computer that does not exist on your network, or perhaps you have mis-typed the name, or it could be a DNS issue or a DNS suffix issue. It could also be a non-existent remote working directory path on the target computer. Verify your working directory path in ‘Tools > Settings > Remote Execution > Remote Working Directory’. Make sure that path exists. In particular make sure the drive letter exists. So if your remote working directory is set to ‘Q:\Program Files\BatchPatch’, but there is no Q: drive on the computer, the ‘network name cannot be found’ error will be generated. If the Q: drive exists, then BatchPatch will be able to create the directory successfully (or if it cannot because of a permissions problem or something like that, then we would see a different error). However, the bottom line is that BatchPatch can’t get to or create the network path that is specified in the ‘remote working directory’ field.

If you take that same computer name and go to the cmd prompt and type “ping <ComputerName>” and it can’t find the computer, BatchPatch also will not be able to find it. You might need to use the FQDN or have your network adapter automatically append the appropriate DNS suffix. Alternatively you could use the IP address instead of the name.

-Doug

[doug]

Thanks for the update. This setting does not require a reboot or a restart of BatchPatch. I’m not sure how it’s possible that the concurrent file copy maximum is being ignored for you. I could certainly believe that the CPU is still spiking even with just one file copy taking place (my CPU still spikes but only to about 12% with 1 active copy, so it’s possible that yours still spikes to 100%), but I can’t figure out how it’s possible that the setting is being ignored and more than one row is executing the wsusscn2.cab copy at the same time even while the concurrent file copy maximum is set to 1. What *should* happen is only one row copies while all other rows say “queued file copy” or similar. Then when the first row finishes copying, the next row begins, and so on. In any case, we have fixed the CPU utilization issue. It should be published within the next month or two.

-Doug

[doug]

Thanks for the suggestions, Mats. We will consider this for a future build.

-Doug

[doug]

Newman –

The ‘Access Denied’ issue is caused by a problem with your permissions. Please see the following link for more information on resolving: BatchPatch Authentication in Domain and Workgroup (non-domain) Environments

The ‘Invalid namespace’ error generally indicates that WMI on the target computer is broken or corrupt in some way or another. Start with rebooting that target machine. Sometimes that’s all it takes to fix. If that doesn’t work, I would recommend doing some googling to troubleshoot WMI corruption and/or invalid namespace errors. A good starting point is here: http://blogs.technet.com/b/askperf/archive/2009/04/13/wmi-rebuilding-the-wmi-repository.aspx

I hope this helps.

Thanks,

Doug

[doug]

Hi Michael – I’m glad to hear that you like the product. 🙂

Thank you for the suggestions. I have a few questions below.

1. We will consider this for a future build. I understand what you are describing and why it would be convenient to have.

2. I understand that you currently use a “dummy” row setup to send a $grid before and after patching. This makes sense. However, I’m not quite clear on what you are suggesting/requesting. How is what you are requesting/suggesting different from what you are currently doing to accomplish the task? I’m curious to hear as much detail as you’re able to provide. Are you just saying that you want a simpler way to accomplish the same thing because creating “dummy” rows doesn’t feel like an elegant solution? (admittedly, it’s not particularly elegant, but it works 🙂 Or do you have something in mind that provides a different functionality?

3. I understand what you mean by “locking” the columns. We will consider this for a future build. However, in the meantime there are two ways to accomplish this task.

If you go to ‘Tools > Settings > Grid Preferences > Allow BatchPatch to unhide columns automatically’ you can either uncheck the box altogether so that BatchPatch does not automatically unhide any columns, or you can click on the button that says “except these columns,” which allows you to configure BatchPatch to auto-unhide only certain columns. If you uncheck the box altogether, this is the same as “locking” the grid, like you are suggesting. However, it applies to all grids, not just the active grid. Then you simply need to make sure the columns that you want to see are manually made visible before the patching begins. They will remain visible during the patching, but no new columns will be auto-opened.

Thanks,

Doug

[doug]

Jason – They should *not* remain open. In fact, if PsExec.exe is remaining open, then that means it is not finishing its work, and I would expect that you would not see progress in the BatchPatch grid either. The fact that you’re saying the connections are also remaining open on the target server as well is another indication that the process simply is not completing. The normal behavior is for you to start the action in BP, then psexec is launched for the duration of the action, and then psexec terminates and BP reports the status. If psexec doesn’t terminate, then BP will not update the grid with any changes, so essentially what I’m saying is that if psexec isn’t terminating then BP basically isn’t going to be able to complete most actions, including all Windows Update actions.

When you say that the connections remain open, consuming server resources and slowing/stopping BP, I think you might have it backwards. Obviously I haven’t looked at your server, so I can’t say for sure, but it seems like BP is “stopping” simply due to the fact that the psexec instances aren’t returning (or they aren’t returning quickly enough – not sure how long you waited or how quickly you expect them to return, but it depends on the action), but it’s not “stopping” because of a resource problem. It’s simply waiting for the psexec connections to close so that it can continue doing what it’s doing. If you’re installing 200 windows updates, it could take a couple hours, depending on the setup). 50 rows in a grid all running at the same time shouldn’t require a ton of resources. Maybe something like 100 megabytes of RAM for all the psexec instances. If the psexec connections never close, then BP simply waits, indefinitely for them to close. BP relies on the psexec processes to end because that’s how psexec works. If psexec is never ending, then it means it’s not working.

My question to you is has BP ever worked on your system? Is this a new problem? There is no configurable timeout for the psexec connections in BP. BP waits for them to close, otherwise BP can’t do what it needs to do. If none of them are returning then it does sound like there’s a problem, and BP basically isn’t working at all. I have never experienced nor heard of this happening before, so something might be jacked up with your system. As a start I would suggest you reboot the machine that’s running BatchPatch. After that you should make sure you have the latest version of psexec and then test running psexec at the command line to make sure that it is behaving properly. So for example you could run “psexec \targetcomputer IPCONFIG” in a cmd prompt. The normal behavior is for psexec.exe to open for just a handful of seconds. The target computer would see a psexesvc.exe in its processes list for that same handful of seconds. After the IPCONFIG command returns output to the cmd prompt, both psexec.exe and the target machine’s psexesvc.exe disappear. If psexec isn’t behaving properly when run from a cmd prompt, then BP certainly isn’t going to work.

I can’t really think of any reason why such a problem would occur. The only thought that comes to mind is what is the network connection like between the BP machine and the target machines? If there is very little bandwidth and a lot of latency, then perhaps that’s where your issue is. In that case you simply might not be able to execute 50 at a time. You might have to do just a few at a time. Not sure. It would require some experimentation. I’ve never run BP on such a severely limited network.

You probably already know this, but just in case you weren’t aware– you can kill all the psexec connections with a single command “taskkill /IM psexec.exe”

I hope this helps.

-Doug

[doug]

Yes, the setting will limit the number of rows that can copy files simultaneously from the BatchPatch computer to the target computer. This applies to cached mode as well as for software deployments.

The reason you don’t experience the issue with the KB copies is because we use a different underlying method for the WsusScn2.cab file copy. We are able to reproduce the problem that you encountered. As soon as there is more than one WsusScn2.cab copy happening, the CPU hits 100% and the copy rate decreases drastically by 100x!

We have isolated the cause of the problem, and we expect to have it fixed in the next release of the software. In the meantime, I think your best bet is to set the concurrent copies to 1. Even though it will only do one copy at a time, the overall copy rate should still be much faster. Also, once you’ve done one check for updates using the latest WsusScn2.cab file, BatchPatch will not re-copy that file to targets until Microsoft releases a new WsusScn2.cab file. So, after the first run, you could switch the concurrent file copies value back to 6, if you want, so that the KB files can be copied simultaneously to more than 1 host.

-Doug

[doug]

To close the loop on this, I did a bit more testing/research.

First, there was a missing ‘where’ clause in your command. So, the proper command would be:

WMIC product WHERE name="Notepad++" call uninstall /nointeractive

If we execute the new command *with* the WHERE clause, we then get the following output:

No Instance(s) Available.

Essentially that means that nothing where name=”Notepad++” was found. So, I ran another query:

wmic product get name

The list turned up *without* Notepad++, which explains the previous “No Instance(s) Available” message. It seems that the Notepad++ installer does not register itself with the system in such a way that we can use WMIC to uninstall it.

[doug]

Hi John –

Generally when you execute a script remotely on a target computer using BatchPatch, that script will only have access to resources on the target computer. The script will *not* have access network resources. This is why your script isn’t completing.

You *might* have luck if you explicitly supply credentials for the row in BatchPatch using ‘Actions > Specify alternate credentials’ Let me know if that works. It might, but it might not.

Assuming the above suggestion does not work, then the way to do this is successfully is to *not* rely on any network resources for the installations. You would need to write your script so that it does not include network locations and instead just includes the relative paths/locations. Then put all files in a single directory and use the BatchPatch ‘Deployment’ feature with the ‘Copy entire directory’ option.

There’s an example of this type of usage at the following link. Hopefully you can use this as a template/example to model your script/deployment:

Deploy Multiple MSU files in a single action

I hope this helps.

One other option that you might consider is to create a separate deployment in BatchPatch for each application that you want to install. Save each deployment in the BatchPatch deployment window. Once each deployment configuration has been saved you can then create a ‘Job Queue’ that installs each deployment that you previously created, sequentially. You can then also save that job queue for future use. This would give you a one-click way to install all the apps in a single action.

-Doug

[doug]

Thank you for making us aware of this issue. We are looking into it. I will report back here when I have more information.

For the time being it seems that limiting the concurrent file copies to just 1 will prevent this from happening. See ‘Tools > Settings > General > Concurrent File-Copy Operations Maximum.’ Setting this value to 1 should both prevent the CPU from pegging at 100% and also dramatically speed up the copy. The overall benefit should be positive, even though less concurrent copies are taking place.

Thanks,

Doug

[doug]

Mats – I tried to uninstall Notepad++ at the command line, using the syntax you provided, WITHOUT using BP. So, I launched a command prompt as administrator, and then I ran the following command:

WMIC product name="Notepad++" call uninstall /nointeractive

It did *not* uninstall Notepad++ and instead gave the following output:

ERROR:

Description = Invalid query

That said, since I cannot uninstall Notepad++ *without* BP using the command you provided, I certainly do not expect to be able to uninstall Notepad++ *with* BP using that same invalid command. Before you ever try to use BP to perform a remote action, you should confirm that the syntax you want to use works when you’re at the command line *not* using BP.

---

---

To successfully uninstall Notepad++, use BatchPatch Remote Command 1/2 (Remote Command 3/4 will not work with this syntax), and enter the following line:

"C:Program FilesNotepad++uninstall.exe" /S

[Author]

Posts