[doug]

Glad you got it narrowed down to permissions. Thanks for the update.

-Doug

[doug]

When the agent runs on the target system, the first thing is does is create a few .log files. If there are no indications in the application log of a crash, then it is probably not crashing. The fact that it happens on domain controllers might indicate that it’s some type of permissions issue. Hard to say at the moment. At this point I’d want to take a look at some logs to see if we can figure out any more about what might be happening. I sent you an email.

Thanks,

Doug

[doug]

No problem. Glad that you got it worked out.

-Doug

[doug]

Are you deploying the .msi or the .exe?

I just successfully deployed the 2010 ReportViewer.exe from this link:

https://www.microsoft.com/en-us/download/details.aspx?id=6442&751be11f-ede8-5a0c-058c-2ee190a24fa6=True&fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True

I used the settings shown in the screenshot below:

The 1612 error you are receiving is described here as:

ERROR_INSTALL_SOURCE_ABSENT 1612 The installation source for this product is not available. Verify that the source exists and that you can access it.

I’m not quite sure what you’re doing. The fact that I just deployed this successfully without any problems on the first attempt leads me to believe that you are either not performing the deployment in the correct/proper way (as shown in my screenshot above) or that something in your environment is causing the 1612 error to occur. It’s hard for me to say what, but the error that you are receiving is coming from the installation package, not from BatchPatch. If you were to try to run that same deployment manually *without* BP from the command line of the target system, using just

ReportViewer.exe /q

I suspect you would encounter the same error since it’s being thrown by the installer from Windows, not by BatchPatch.

-Doug

[doug]

Mats – Thank you very much for the suggestion. We will definitely consider this for a future version of the app.

-Doug

[doug]

If it just hangs indefinitely then that indicates that you are not executing a silent installation. What’s actually happening is that the package is being executed and presenting a GUI, but the GUI is hidden as a result of the non-interactive remote execution, and so it just hangs indefinitely waiting for input that it will never receive.

When you say you “put in the /S for silent install” I would ask you where did you come up with /S ? What I mean is that all installers have different silent installation parameters. You can’t just assume that /S is a legitimate parameter. You have to first ascertain what the actual silent/quiet parameter is for a particular installation package. More on that at the following link:

Understanding and Discovering the Silent Parameters Required to Remotely Deploy Software with BatchPatch

I just downloaded the Microsoft ReportViewer 2010 Redistributable Setup from https://www.microsoft.com/en-us/download/details.aspx?id=6442&751be11f-ede8-5a0c-058c-2ee190a24fa6=True&fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True (not sure if this is the same one that you are using or not), and then at the cmd prompt I ran

ReportViewer.exe /?

It showed me that the silent/quiet parameter is /q

[doug]

I’m confused. You said it doesn’t complete but it comes back as either SUCCESS (exit code 0) or exit code 1619. Are you saying that even when it comes back as SUCCESS (exit code 0), the installation has not actually occurred? That’s certainly a weird one. Sounds to me like there is a problem with the MSI package.

---

MSI exit codes are listed here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

1619 ==

ERROR_INSTALL_PACKAGE_OPEN_FAILED



This installation package could not be opened. Verify that the package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer package.

---

To be honest, I’m at a bit of a loss here. This is the first time I have ever heard of an issue deploying a .MSI. I think the next step would be to test running the installation remotely with PsExec. Maybe that’s where the problem is occurring.

Try putting the .MSI on the target computer in “C:Program FilesBatchPatchdeploymenttemp”

Then from the BP computer try running the following two commands to see if either one works. BP would run the equivalent of the first command to perform the installation in the SYSTEM account for maximum permissions. The second command will deploy in the regular user account that you’re using.

psexec \targetComputer -s -w "C:Program FilesBatchPatchdeploymenttemp" msiexec.exe /i "C:Program FilesBatchPatchdeploymenttempMicrosoft Report Viewer Redistributable 2008.msi" /q

psexec \targetComputer -w "C:Program FilesBatchPatchdeploymenttemp" msiexec.exe /i "C:Program FilesBatchPatchdeploymenttempMicrosoft Report Viewer Redistributable 2008.msi" /q

Let me know what happens.

-Doug

[doug]

Thanks. So yeah, 200 systems definitely should not be a problem. And even if you had thousands of systems I would not expect the issue you mentioned to occur. Frankly, the issue you described is not one that has ever been reported, and we have never seen it occur here in testing. Keep me posted on how things go in the future.

Thanks,

Doug

[doug]

The remote agent crashing on a target system is indicative of some deeper problems with the target OS. We do not believe there is an issue with BP or the BPRA.

-1073741502 == C0000142

I googled and found this, which may or may not be helpful:

https://support.microsoft.com/en-us/kb/191991

-Doug

[doug]

When you say you re-ran the scans and all found updates, I think you are saying that on the second go-around you did not get any errors, correct? If that’s the case, I would just monitor and see if it happens again. I have never heard of this type of thing happening, and I doubt that it is related to too many systems, though out of curiosity how many are you talking about in the single group? Considering that you are experiencing a few weird issues (mentioned in your other postings), I suspect these are all related to your specific environment. These are very out-of-the-ordinary problems.

-Doug

[doug]

Can you please look in the application log on the target system. This 5 failure might mean that the batchpatchremoteagent.exe is crashing on the target. 5 can also mean that it’s a permissions issue – ‘access denied,’ but normally a permissions problem would not manifest with this generic 1611: 5 error. A permissions issue would typically instead show up in BP specifically saying ‘Access Denied,’ so I think the agent crashing is more likely here.

When you execute the Windows Update action do you see any log files appear in the target working directory (default location is C:Program FilesBatchPatch on the target system)? These log files would likely only remain in that directory temporarily, so you need to watch the directory while the action is executing. Additionally, please check the task manager processes list. Do you see batchpatchremoteagent.exe and psexesvc.exe?

If the batchpatchremoteagent.exe is crashing on the target, then there is likely something specific to those targets causing the issue, but I couldn’t say what. The remote agent crashing on a target system is indicative of some deeper problems with the target OS. BatchPatch is being run on a very large number of target systems around the world without crashing. Every once in a blue moon we here a report of one or two problematic targets where it crashes for unknown reasons that are likely related to lower-level issues with the target OS installations.

Let me know what you find.

Thanks,

Doug

[doug]

Actions > Windows Update > Reattach orphaned Windows Update process

Reattach Orphaned Remote Windows Update Processes

[doug]

What you are describing is not possible in the current version of BP. The exclusions are saved per-row, so you must have host names for them to be saved with.

On a separate note, if you are continually excluding the same updates each month, then I would encourage you to re-evaluate your process.

If you are using WSUS, then you should decline the updates on the WSUS server so that they are not made available to target computers, and then there is no need to exclude anything on targets.

If you are not using WSUS, then you should consider hiding the updates on each target system so that they do not continue to appear each month. To do this, use the ‘Actions > Windows Updates > Hide/unhide…’ option. Once the updates are hidden you will no longer need to exclude them. However, it *is* true that if Microsoft re-releases an update, it will move back into the ‘available updates’ group. One of the more recent examples of this behavior is with updates for GWX (Get Windows 10). People are hiding the updates only to see them re-appear at a later date. This leads me to my next suggestion…

If you are specifically trying to avoid the updates that are involved with the Windows 10 upgrade and GWX, I would suggest you follow the Microsoft sanctioned method for blocking the upgrade, which is described more here: How to Block the Windows 10 Upgrade. Then you do not need to continually try to avoid the same updates from month to month.

-Doug

[doug]

I’m confused by this behavior. You’re saying that you execute a Windows Update action in BatchPatch, but where are you prompted with an authentication window? On the target computer? Is that authentication window from Windows or from custom proxy software?

In any event, the idea here is that if you whitelist the Windows Update domains in your proxy server, then when a computer tries to access those whitelisted sites to download updates, the proxy server will be bypassed altogether and no authentication will be required. If you are prompted somehow for authentication (even if you are able to just click ok without entering credentials), it sounds like something is not setup right. You need to configure the proxy to be bypassed altogether for the Windows Update domains. Currently it sounds like it is not being successfully bypassed.

[doug]

This is not configurable. We will consider it for a future build.

-Doug

[doug]

Yes, I understand. Your screenshot confirms what I was thinking. This is not a bug in BatchPatch. There is nothing we are able to do to “fix” this. The issue is that erroneous progress data is being reported by the Windows Update Agent. I doubt you will see it happen again. Or if you do see it happen again, it will be only *very* rarely.

[doug]

Did the problem occur just one time on those computers? Or has it occurred on those computers many times?

I think there is a very good chance that one particular update that was installed on those computers was the cause of the issue and that you won’t see it again.

I do not think that there is a bug in BatchPatch that can be fixed. We are at the mercy of the progress information that the Windows Update agent provides, which can apparently on occasion not be accurate.

[doug]

Do you see the problem occur regularly on multiple computers? Or is it just something that occur regularly on a single computer? Or is it something that occurred just one time on one or multiple computers?

The only other report of this issue we received was 3 years ago in the posting you referenced. We have never heard of this issue since then nor have we ever experienced it or reproduced it. My best guess is that there are certain cases where the Windows Update Agent reports incorrect progress data to BatchPatch. However, the BatchPatch functionality is not impacted. It would only be cosmetic.

Additionally, please check the BatchPatch.log under ‘Actions > Windows Updates > View BatchPatch.log’ or by viewing it directly on the target computer (default location would be C:Program FilesBatchPatchBatchPatch.log). Are there any download failures? This would be the only potentially legitimate reason that I can think of for an incomplete progress bar.

-Doug

[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

[Author]

Posts