[doug]

OK – so yes you are correct that under normal operating circumstances, the psexesvc is removed after the command is executed. We have seen instances where it doesn’t get removed properly. Sometimes this is an issue and other times it is not an issue. And to be clear, I’m not sure that it’s an issue so much as a symptom of whatever the problem actually is. Over the years we have had a small handful of users experience problems with psexec, but they have always been strange. Here are the things we have observed and some things to try:

1. We have seen cases where the issue actually appears to be tied to the machine that is running BatchPatch and PsExec, *not* the target host. Even though the target host is where the failure appears to occur, in some cases the problem ceases to exist when BatchPatch is operated from a different computer but with the same target computers.

2. Test psexec at the command line without BatchPatch. So for example you could run

psexec \targetComputer wuauclt /resetauthorization /detectnow

Does it complete successfully? If it doesn’t complete successfully, then we’ll know for sure that it’s the source of the issue. However, note that it might complete successfully even if the problem still actually is related to PsExec. Let me know.

3. We have seen cases where switching to an older version of PsExec solves the problem. In particular I would suggest trying version 1.98 (or older) if you can find a copy. We can’t distribute it due to the way that it is licensed. In one of these cases the user was able to switch back to the latest version of PsExec once things started working, and then he never had a problem again. Also note that PsExec sends credentials in clear text with versions prior to 2.1, so ideally it’s best to use the latest version. However, this is only an issue when specifying ‘Alternate Credentials’ in BatchPatch. Additionally, even when specifying alternate credentials, on most switched networks this isn’t really a major concern because the only people who could conceivably monitor the network traffic on a single port are people who have administrator access to the switches.

4. Another option is to try the free PaExec https://www.poweradmin.com/paexec You can rename this to psexec.exe and then BP will use it. Note, in the alternate credentials use case, it sends the credentials obfuscated (not encrypted).

[doug]

Jay – Those error translate to:

ERROR_NOT_CONNECTED

2250 (0x8CA)

This network connection does not exist



ERROR_BAD_EXE_FORMAT

193 (0xC1)

%1 is not a valid Win32 application.

It’s hard for me to say definitively what’s happening here. No one else has reported these errors, so I suspect it’s something that is specific to your environment. My best guess is that you have some type of anti-virus or host-intrusion-prevention or similar security related software on the target computer that is causing the problem. I think possibly what might be happening is that BatchPatch copies the necessary files to the target computer to execute, but then right before or during remote execution, the files are removed by the local security software on the target. This then manifests in BatchPatch as a 2250 or 193 error. I think specifically the most likely cause is related to PsExec because that is what is being used to execute the commands you mentioned.

See if you can whitelist psexesvc.exe in your antivirus/security software on target computers. I think that’s probably the one that your security software would be targeting. Another possibility is to change the name of that exe/svc in BatchPatch under

'Tools > Settings > General > Use PsExec -r switch to specify a remote service name: BatchPatchExeSvc'

After changing the above setting you might still need to whitelist BatchPatchExeSvc on target computer (or whatever name you used in that field, if not BatchPatchExeSvc).

Let me know how it goes.

-Doug

[doug]

z10n – You don’t install those processes on the host. When BatchPatch runs it creates them automatically on the target host.

-Doug

[doug]

First you need to assess if BatchPatch is actually executing on the target machines in question. Considering that you said in some cases it will do the download and install after hours, it sounds to me like BatchPatch is executing the task, but the task is taking hours to complete. However, first let’s just make sure of what is actually happening.

1. Execute the Windows Update action, and then look at the target machine’s list of active/running processes in task manager. Do you see batchpatchremoteagent.exe and psexesvc.exe on the target computer processes list?

2. While the task is executing look at the target machine’s working directory (default is C:Program FilesBatchPatch). You should see the batchpatchremoteagent.exe and a few .log files here (BatchPatchTempCurrent.log, BatchPatchTempProgress.log, BatchPatch.log etc). Make a note of exactly which files you see, and report back to me.

3. If the task appears to be executing, based on the findings from the above two steps, then the issue is that it’s just taking a very long time to complete. Generally speaking when Windows Update actions take a long time to complete, it is not slow due to BatchPatch. The slowness typically is in Windows Update, and it happens regardless of whether or not you use BatchPatch or if you simply execute the check for updates at the machine’s console, using the Control Panel Windows Update GUI. BatchPatch invokes the Windows Update process on the target computer, but BatchPatch does not have control over how long this process takes to complete.

4. If you find that the task is simply not executing in the first place (or is executing and immediately “dying” or getting killed without notifying, then you need to look at what is killing the process.

Let me know what you find.

-Doug

[doug]

I’m surprised to hear that you downloaded any standalone updates from Microsoft in .cab format. I only recall ever seeing updates downloaded from Microsoft in the form .msu/.msi/.msp/.exe

My first thought/suggestion is that if you have a .cab, you should probably find the .msu/.exe version. I’m curious what is the KB number of the update that you are referring to? I think it’s highly unlikely that a KB update would not have a .msu/.msi/.msp/.exe but let me know.

In any case, if for some reason .cab is truly the only available format (this would be pretty surprising to me but certainly not impossible), then you need to first work out the proper syntax to silently install the .cab from the command line. Once you have the command line syntax, you can use that syntax in BatchPatch to deploy it. Essentially you would use that syntax in the “Command to execute” field of the BatchPatch Deployment form. However, you would absolutely need to get your command line syntax working properly from the command line without using BatchPatch before you try to use it inside of BatchPatch.

-Doug

[doug]

BatchPatch has a built-in feature ‘Actions > Windows Updates > Update + reboot cycle’ that will enable you to customize a routine to continually download/install + reboot over and over as many times as you want. This ‘Update + reboot cycle’ is essentially just a BatchPatch ‘Job Queue’ so you can also use the ‘Job Queue’ feature to do the same under ‘Actions > Job Queue > Create/modify’

Job Queue Tutorial 1

Job Queue additional info

-Doug

[doug]

‘-198: Failed to add scan package service. HRESULT: -2146885619’

We have now been able to reproduce the above error. It seems that in some cases when downloading the WsusScn2.cab file from Microsoft, there is no digital signature on the file. This seems to be due to some kind of error/mistake at Microsoft, but it’s hard to say for sure. This month, in particular, I’m seeing this behavior for the first time. I suspect that they have multiple copies of the file hosted on their servers, and they simply forgot to sign one of them. When you download the file from them, depending on which server you download it from, you either get a signed or unsigned version.

You can confirm the digital signature by right-clicking on the file and selecting ‘Properties > Digital Signatures,’ which you can see in the screenshot below.

If the ‘Digital Signatures’ tab is missing, then you will receive the following error in BatchPatch when using offline cached mode:

‘-198: Failed to add scan package service. HRESULT: -2146885619’

To resolve the issue, delete the wsusscn2.cab file from your BatchPatch cache folder, and then let BatchPatch re-download the file. Verify that on the re-downloaded file the signature is intact.

At the time of this writing, even though BatchPatch will download a new WsusScn2.cab file to the BatchPatch cache directory, it will not replace the WsusScn2.cab file on target computers if the file appears to BatchPatch to be the same version of the file. In a future release of BatchPatch we will likely provide functionality to overwrite the target computer WsusScn2.cab even if the source file is the same version. However, until such a time when this functionality exists in BatchPatch, you will need to delete the missing-signature-WsusScn2.cab file on target computers, so that BatchPatch can copy the signature-included-WsusScn2.cab file.

To delete the WsusScn2.cab file on target computers you may use the following BatchPatch command:

Remote Command 3/4 (logged output):

del /Q "C:Program FilesBatchPatchwsusscn2.cab"

[doug]

OK glad you got it figured out. You can use ‘Tools > Delete remote working directory’ to get rid of that dir on all the systems, but just be careful and use it with caution, of course.

As for slow check for Windows Updates on some systems, please have a look at this link, which might resolve your issue: checking-for-available-windows-updates-on-windows-7-targets-take-too-long

Generally speaking I have never witnessed better performance from the WsusScn2.cab vs online Windows Update, but you can see how it goes.

The WsusScn2.cab file will only provide you with security updates, but in our tests we have found that inevitably it seems to not include some updates that one would expect to be included. This is something that you’ll have to test and compare and decide for yourself.

-Doug

[doug]

The only time we have ever seen a failure to add the scan package service is when the wsusscn2.cab file is corrupt/partial/incomplete. To resolve this, delete the wsusscn2.cab file in the BatchPatch cache folder. This will force BatchPatch to re-download the file and re-copy it to target machines for consumption.

The actual error code is produced by the Windows Update Agent, and its translation is:

0x8009200D -2146885619 Crypt_E_Bad_Msg Not a cryptographic message or the cryptographic

message is not formatted correctly

You may also see this message, which has a similar cause:

0x80096010 -2146869232 Trust_E_Bad_Digest The digital signature of the object did not verify

I believe that this message confirms that the wsusscn2.cab file that you have is likely failing a signature validity check, so you should re-download it and try again.

---

Separately, I would personally suggest/recommend that unless you are truly very bandwidth-contrained that you just use regular mode (not cached mode and not offline mode) because regular mode will be significantly faster, and because it is less complex.

Additionally, if you really want to use cached mode, then go ahead. It certainly works nicely. However, I would then suggest that you do not use offline mode unless you truly require it. Offline cached mode will be even slower than online cached mode, and it also does not include 100% of the updates that Microsoft offers via the regular Windows Update channel. It really is intended for usage on computers that have no access to update with the other methods. Again, it works nicely, but I think it’s only worth using in situations where the other options are not possible.

This is just my personal opinion. You are of course welcomed to use any of the options that you desire.

-Doug

[doug]

The group policy configuration is saved in the registry. You can view it using BatchPatch by selecting ‘Actions > Get information > Get registry key/value’ and then input the following:

Registry key: HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU

Value name: AUOptions

[doug]

Hi DJ – You can export all the host names in the grid by selecting ‘File > Export…”

You can also use ctrl-C to copy only the selected rows to then paste into a text file or Excel etc. Only the visible columns are included in the copy.

I hope this helps.

-Doug

[doug]

No problem at all. I’m happy to hear that you like the tool so much and that it’s working well for you!

-Doug

[doug]

Tools > Export / Import

-Doug

[doug]

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

-Doug

[doug]

This is not currently possible because the filters are set globally, not per-row/host. We will consider per-host settings in a future build of the app.

Thanks,

Doug

[doug]

I would recommend that you utilize the ‘Update Date Filtering’ setting under ‘Tools > Settings > Windows Update.’ The setting allows you to “only install updates that were published / approved at least X days ago.” I think this will give you what you need. For example, if you set it to 30, then it will only install updates that were published or approved at least 30 days ago. Any updates released in the past 30 days will be skipped.

-Doug

[doug]

Hi DJ – We agree with you, and we’re working on it. However, at the moment we do not have a solution in place. We hope to have something workable ready for next release.

Thanks,

Doug

[doug]

Richard – I have never seen nor heard of this error before. In order to assist I need you to please answer the following questions.

1. What *exactly* are you doing to produce this error? Please describe the exact steps taken to produce this error.

2. What version of BatchPatch are you using?

3. Please paste the ‘All Messages’ column showing your BatchPatch actions that cause this error as well as the error itself if the error is displayed in the ‘All Messages’ column.

4. Please paste the ‘Remote Agent Log’ column that shows this error.

-Doug

[doug]

Thomas – I have never seen or heard of an issue where IP worked properly but computer name did not work, except when DNS or NetBIOS was at fault. However, your issue does sound particularly strange. It seems to me that as a workaround you should just make sure to use IP address for those 2 machines until you are able to resolve the root cause of the problem.

As for whether or not it could be a PsExec problem, it’s certainly possible but it’s hard to say for sure, especially considering that PsExec is working properly for you when you run it at the command line. However, if you still suspect an issue with PsExec, then certainly you can/should try a different old version of PsExec if you’re able to obtain such a version, or you could try to use the free PaExec (rename PaExec to PsExec and test). You can/should also try any other suggestions in that other forum posting. Another option is to try running BatchPatch from a different computer in case the problem is not the target computers but rather is with the computer you are currently using to run BP.

[doug]

Thanks for the suggestion, Andreas. We will take a look at this for a future build.

However, please also note that in the meantime you do not need to use a domain administrator account or separate local administrator accounts. You can use a single regular domain user account that has been added to the local administrators group of each target computer.

-Doug

[doug]

This error is a bit peculiar because normally we would expect to see ‘Access Denied’ if there were a permissions problem. Nevertheless, to enter a username and password a given row, select the row and then select ‘Actions > Specify alternate logon credentials.’ Alternatively, you may use run-as to run the entire BatchPatch.exe as a different user.

-Doug

[doug]

That’s very peculiar. If IP address works but name does not work, then it sounds like maybe it could be some type of issue with DNS or NetBIOS, but I’m not sure. It could probably also be something else, such as anti-virus, firewall, or host intrusion prevention software.

-Doug

[doug]

Magnus –

First, you will not see anything appear in the Windows Task Scheduler. BatchPatch tasks have nothing to do with Windows scheduled tasks.

Second, it’s unclear to me what the problem is that you are encountering. BatchPatch must be running in order for tasks to be executed, so perhaps that’s where you’re going wrong. I would suggest you review the tutorial for using the BP task scheduler here: Using the Task Scheduler in BatchPatch

Third, to test what you configure, I would recommend that you create some testing tasks that are scheduled to execute just a minute or two in the future, so that you can watch and make sure that they execute accordingly. If they are using monthly recurrence then you can also modify your system time temporarily to trigger a task to run if it’s scheduled for next month, just to make sure you understand how everything works and that everything executes as expected.

I hope this helps.

-Doug

[doug]

Please have a look through the following links which contain some possible solutions/fixes for the issue you are encountering. To me it sounds like PsExec is not working properly, but it’s hard to know why. Note that the error 2 you are receiving might be reported a bit differently than how it is reported in the links below because those are old postings where older versions of BP reported the error a bit differently. In your case you are seeing “Error 1611: 2. Failure” which indicates that PsExec is returning exit code 2. The 1611 just indicates the location in BP where the 2 was returned. It’s not relevant otherwise. The “2” is the relevant part of the error you are receiving because it’s the actual exit code being returned from the attempt to run the remote process.

error-2-very-often-server-2012-r2-on-domain-controllers

error-2-or-error-0

error-2-hresult-2147024894-could-not-find-file

Let me know how it goes.

-Doug

[doug]

The task scheduler in BatchPatch allows you to run a task on any day of any month or year.

Using the Task Scheduler in BatchPatch

-Doug

[doug]

As you pointed out, this is likely an issue with the proxy setup in your environment. Specifically, I believe this is related to proxy authentication. I know you said that the 3 computers are all configured the same, but if they were exactly the same then they would behave the same. They are not behaving the same, so therefore there must be something different about one of them.

Please review the instructions:

'Scenario 2: The Windows Update Agent on target computers is properly configured to use the corporate proxy, but the proxy requires authentication'

Using BatchPatch with an Enterprise Web Proxy

-Doug

[doug]

Kennis – Thank you for reporting your success with declining the single update ‘AMD driver update for Pci Bus.’ I’m very glad to know that this fixed the issue for you!

-Doug

[doug]

Sorry about that. The report currently lists the install date per update per computer.

-Doug

[doug]

Yes. Please use ‘Actions > Windows updates > Generate consolidated report of update history.’

[doug]

The 1611 is sort-of a generic error indicator. It means that the remote agent process exited with an unexpected code, with the unexpected codes being 59 and 5 on your two targets. The unexpected codes are Windows system error codes.

5 is normally:

ERROR_ACCESS_DENIED



5 (0x5)



Access is denied.

However, 5 could also mean that there was an access violation on the target, which would essentially mean that the remote agent crashed unexpectedly. If this were the case you would see something in the application event log of the target computer. Normally an ‘Access denied’ error would be reported differently in BatchPatch, which is why I suspect that in this case you might instead be dealing with an access violation unexpected crash of the agent.

59 is:

‘ERROR_UNEXP_NET_ERR

59 (0x3B)

An unexpected network error occurred.’

---

I would suggest that you start by rebooting the target computers. Then see if it happens again. You might find that these are transient issues, especially if you have not had any issues running BP with these computers in the past.

-Doug

[Author]

Posts