[doug]

Are you using a local WSUS or are the searches being performed on Windows Update/Microsoft Update? Please try both (you can change the setting under ‘Tools > Settings > Windows Update’ in BatchPatch. I’d like to know if the issue only occurs with one or the other or both.

Please review the following posting about 106G. I don’t believe we have ever seen or heard of your particular HRESULT -2145123271, and I don’t believe we have ever seen 106G occur on Windows 2012R2. However, the 106G we have seen just a handful of times with customers. The 106G indicates that there was an error retrieving the search results from the update server, while the HRESULT value is the reason code. There may be a solution/resolution in this posting:

Error 106G

Also, if you are able to retrieve the relevant lines from your WindowsUpdate.log (C:WindowsWindowsUpdate.log) from the target computer, they might help shed some light. I would suggest searching for 80240439 in the log file to find the appropriate lines. Feel free to share your findings here.

-Doug

[doug]

I would suggest that you start by seeing if you are able to install updates at the control panel of any of these computers *without* using BatchPatch or if you get a similar error when performing the operation directly on the computer. Let me know what happens.

-2145123271 == 0x80240439

Some of these search results might also help: Google 80240439

[doug]

Excellent. Thanks for following up. I’m glad that 2 worked. I also understand that 3 does not scale well. I’ll ask the team to re-work the script so that it can be used for any number of fonts without having to fill in so much code.

-Doug

[doug]

I would suggest a few things to try:

1. Change the ‘remote execution context’ to ‘Elevated token’ and then try again and see if it works.

BatchPatch Remote Execution Context

2. Change the \nasserver path in the script to a local/relative path instead of one that reaches out to a remote server. If your script is made to *not* access a remote path and instead is made to access the files locally (locally on the target computer), I suspect it will work.

Deploying a Script with Relative Instead of Absolute Paths

3. Follow the tutorial linked below that explains another way to deploy fonts:

Remotely Install OpenType (.otf) or TrueType (.ttf) Fonts

Please report back and let us know what you try and what works for you.

Thanks,

Doug

[doug]

Yes.

[doug]

No. Give the free evaluation version of BatchPatch a go and you can see for yourself. If you run into any problems or have any questions, just post back to this thread.

-Doug

[doug]

Hi Scott – There is not currently a way to clear column contents from inside of a job queue, but we understand the need/desire, and we are considering this for a future build.

Thanks,

Doug

[doug]

Scott – You found a bug. We’ll have this fixed for the next release.

Thanks,

Doug

[doug]

Yes – there is a bug when using “remember open tabs” that causes them to not stick. however, for the next release of BP we will be having the column order saved per-tab/per-bps file instead of globally, so it will no longer be an issue.

Thanks,

Doug

[doug]

Yes, you can use the ‘server selection’ setting to choose whether updates are searched for and pulled from your local WSUS or directly from Microsoft. Windows Update Installation Filters

[doug]

This sounds like a filtering/settings issue. It does not sound like anything is broken.

Please review the second question in the BatchPatch FAQ

While the question does not describe the exact issue that you are encountering, the solution section should still give you all of the places to look at to figure out why you are not seeing what you expect to see.

If you continue to have issues, please open a support ticket by emailing us through the contact form

Thanks,

Doug

[doug]

Thanks, Andreas. Let me know how it goes.

-Doug

[doug]

Another option that might work is to use the following setting in BatchPatch:

Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service name

This setting allows you to modify the remote service name that is used by psexec from psexesvc to BatchPatchExeSvc or any other custom name of your choice. In the case where anti-virus or other security related software is blocking the remote service from running, changing the name of the remote service with this setting can bypass the restriction for some of those applications without having to add psexesvc to a whitelist.

[doug]

This is unexpected because it used to work properly. We will get it fixed for the next release.

Thanks for bringing it to our attention.

-Doug

[doug]

What is the target computer’s operating system?

[doug]

This indicates a problem with Windows Update on the target computer.

This HRESULT translates to:

0x80040154 -2147221164 REGDB_E_CLASSNOTREG

BITS in Windows 2000 is dependent on SENS and EventSystem services.

If COM+ catalog is corrupted, one of these errors was seen.

I would suggest that you start by making sure the target computer has the most recent version of the Windows Update Agent (WUA). You can get it from here:

https://technet.microsoft.com/en-us/library/bb932139.aspx

If you still have problems after that, it might indicate that there is registry corruption or some other system corruption. At that point I would suggest reviewing the following google search results to see if any of them addresses your issue.

[doug]

Currently the column display index is saved globally, not per-tab. While we are considering adding it to the per-tab settings, for now what you need to do if it does not appear to be saving properly is:

1. Close all instances of batchpatch.exe

2. Launch just a single instance of batchpatch.exe with just a single grid visible.

3. Move the columns to the desired locations. NOTE, the actual location of the column will be affected by which columns are visible at the time that you modify the column locations. So to be sure that it goes right next to the host column, you should first make visible the column that is currently next to the host column. Go to ‘Tools > Customize visible columns’ and check the desired boxes so that you can see which columns are actually right next to the hosts column. Then drag the notes column so that it is in between the hosts column and whichever column was previously next to the hosts column.

4. Once you have the desired ordering, close BatchPatch. When you re-open BP the columns should be in the order that they were previously.

-Doug

[doug]

To understand all the possible reasons for a discrepancy, please review item number 2 in the BatchPatch FAQ

[doug]

Hi Simon – I’m sorry to hear that you are having trouble. The issue sounds like maybe psexec is being held up. Sometimes when you run psexec for the first time Windows prompts you to tick a box to allow it to run, which Windows sometimes forces you to do for programs that are downloaded from the internet. I wonder if that is happening but the window is hidden so that you can’t see it and can’t click on it to continue. I would start by trying to run psexec manually at the cmd prompt. Also make sure that you are running it as the same user that BP is running it as, which would be the logged on user account or if you input alternate credentials into BP then you would need to make sure it runs with those alternate credentials. If you continue to have problems after that, I would suggest start by going through the steps in the troubleshooting guide.

Let me know how it goes.

-Doug

[doug]

Regarding Windows Update: Error 1611: 5. Failure

This likely means that PsExec is failing to work properly.

1. If all target computers are affected then first try ‘Tools > Settings > Remote Execution > Use PsExec -r switch…’ and provide a name in that field such as BatchPatchExeSvc.

If the suggestion in 1. works, then it indicates that probably the issue is being caused by anti-virus or HIPS or other security software in your environment that is blocking PsExec from working. If it does not work, then try 2.

2. Try running BatchPatch from a different computer. If this works, then it indicates that PsExec has somehow broken or failed on the original computer. If this does not work try 3.

3. Try substituting PaExec for PsExec by renaming PaExec to PsExec. See if it also fails. Frequently when PsExec “breaks” on a computer, PaExec also breaks, further indicating something is not functioning properly in the system.

4. If you’re still stuck, try the BatchPatch troubleshooting guide to narrow down the source of the problem.

[doug]

In BatchPatch you can use ‘Tools > Export’ and ‘Tools > Import’

Thanks,

Doug

[doug]

I’m not sure I really understand the question. Could you explain exactly what you mean?

Thanks,

Doug

[doug]

Thank you for your suggestions. As a matter of fact, all of these are already on our to-do list, so keep your eye out for them in a future release.

-Doug

[doug]

Excellent. Keep me posted on how things progress!

Thanks,

Doug

[doug]

My trusted root store shows the same CAs as yours. This is so weird. Are you absolutely sure that you have been providing me with the correct error and HRESULT? Is there any possibility that you mixed things up? The -198 error can occur with a number of different HRESULTS, so possibly you saw -198 but assumed the HRESULT was the same when it was not? This might be a stretch, but I want to confirm because it has happened before with other users.

I think the likelihood of being able to disable signature validation is almost nil. I think that you have a couple of more realistic options…

0. Try running the Microsoft Baseline Security Analyzer on the targets. It uses the WsusScn2.cab also (at least it used to, but I have not used it in a very long time) https://www.microsoft.com/en-us/download/details.aspx?id=7558 See if it scans successfully or if it throws a similar certificate error. If it works and gives you the list of available security updates, then you can download these and install them manually or download them and then use BP to deploy them with the ‘Deploy’ feature in BP.

1. If possible, provide temporary internet access to these computers, and then perform the scan in online instead of offline mode.

2. Manually figure out what updates Microsoft has released for these computers in the past few months, and then download all of them manually for installation. Since Microsoft switched to cumulative update model not that long ago, it might not be that challenging or time consuming to do this (unless Windows 7 isn’t using that same cumulative model– I can’t remember off the top of my head if it is or is not). You could still use BP to deploy the standalone updates to the computers using the ‘Deploy’ feature in BP. But you would need to obtain the correct updates from Microsoft manually first.

3. Try uninstalling May’s updates from these computers and see what happens.

Good luck and keep me posted.

[doug]

Ok no worries. Sorry about that. Based on viewing the cert chain on the WsusScn2.cab file I would think that the certificate that needs to be in the trusted root store is the Microsoft Root Certificate Authority. I conclude this based on looking at the ‘certification path’ tab of the certificate for the WsusScn2.cab. The path ends with the Microsoft Root Certificate Authority. And I can confirm that I have this Microsoft Root Certificate Authority listed in my trusted root CAs snap-in. If I were you I would look to see if you have it showing and if you can see that the dates on it are valid. I hope this helps. Let me know what you find.

-Doug

[doug]

I think you are misunderstanding how it all works. You might consider reviewing general PKI concepts to better understand how it all works, or you may just reach out to a coworker who has experience with PKI and security fundamentals to help you troubleshoot, but essentially the WsusScn2.cab file is signed by Microsoft. The act of “signing” is a way to authenticate that the file actually came from Microsoft. When the scan is initiated the WUA attempts to validate the signature. It sees that the file was signed by ‘Microsoft Code Signing PCA’ and then it looks in its trusted root store to see if it has a corresponding certificate for Microsoft Code Signing PCA which is what tells is that it can trust or not trust a file that was signed by Microsoft Code Signing PCA. If the trusted root does not contain the proper certificate, then it will say that it can’t trust the file. This is not an outright rejection saying that the file is invalid or bogus or cannot ever be trusted. In your case it’s just saying something along the lines of “we don’t know if we can trust this file because our trusted root store does not have a signature that says we can trust it.” Considering that your previous WsusScn2.cab file worked fine in May but no longer works due to this error implies that somehow the trusted root store has been modified, and it no longer contains a certificate for Microsoft Code Signing PCA even though it used to contain the cert and should still contain the cert. But if you can get the appropriate certificate imported once again into the trusted root, then the WsusScn2.cab file should pass the certification check. It’s unclear to me what would have removed the cert from your trusted root. This is peculiar, unless an administrator came in and emptied the trusted root store. Perhaps another option would be to use System Restore and see if you are able to revert the computer back to a time prior to May when things were working properly. This will also end up uninstalling updates that were installed since that time. But that would/should be ok because you can then just install them anew.

-Doug

[doug]

FYI for the sake of google searching I would recommend that you search the HEX representation of the HRESULT, which is 0x800B0109. Searching the decimal representation (-2146762487) probably won’t yield as much.

-Doug

[doug]

I can’t imagine how the HomeGroup Listener service would have anything to do with producing the error that you are seeing.

With regard to your question about PsExec: On the computer running BatchPatch you would see psexec.exe in task manager processes list only *during* execution of remote actions. Also note that not all remote actions will utilize psexec, so you will only see it running for actions that do utilize it. Additionally on the remote computer you will see psexesvc.exe running in the task manager processes list during execution.

NOTE: the certificate error that you are receiving would be completely unrelated to psexec. Psexec appears to be running properly in your case. The certificate error is occurring *after* psexec is already successfully running and after the batchpatchremoteagent.exe is already successfully running on the target computer. The batchpatchremoteagent.exe tells the Windows Update Agent (WUA) to load the WsusScn2.cab file. It’s during this process when the WUA tries to load the .cab file that the WUA returns the HRESULT -2146762487 to the batchpatchremoteagent.exe. This HRESULT means that the certificate chain terminated in an untrusted root certificate. I cannot imagine any scenario in which this error could/would occur for any reason other than something relating to certificates and the trusted root on the target computer.

I hope this helps.

-Doug

[doug]

I don’t think this issue is due to a service being stopped. You can see which services need to run for BP here. However, what you are experiencing is not a BP error, per se. It’s being thrown by the Windows Update Agent, and the HRESULT code in this case is *not* ambiguous. It would be highly unlikely that CERT_E_UNTRUSTEDROOT exception is somehow being thrown erroneously due to some other problem. The issue has pretty much got to be somehow relating to the certificate and root store. It’s very peculiar that you would see the same issue now occur with both the old and new WsusScn2.cab file even though in May the old WsusScn2.cab file did not cause any problems. I believe Windows has, in addition to the trusted root store, an untrusted root store. This is described here: https://blogs.technet.microsoft.com/srd/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store/

Perhaps somehow your problem machines have revoked a valid cert and maybe even the cert that was used to sign the .cab file is located in the untrusted store?

If you believe the issue occurred from a previously installed update, you could consider removing the last group of updates that you applied in May to see if there is an effect. I unfortunately do not have any better suggestions at the moment. If I think of anything I will post it here.

Thanks,

Doug

[Author]

Posts