[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

[doug]

Very peculiar. At the moment I don’t have any great thoughts, though it might be interesting to see if the old WsusScn2.cab is still able to scan successfully without producing this error. Are you able to test with the old .cab file that you used successfully back in May?

[doug]

In the way that you describe, the list could not be auto-imported into BP. You would have to manually pull the list into BP and execute the desired Windows Update action.

However, let me propose two alternate ways that you could accomplish what you are trying to do:

1. The BP job queue has an option ‘Wait for host to have zero logged-on users’ in the “Special” list. You could create a job queue that looks something like this:

Wait for host to have zero logged-on users

Download and install updates + reboot if required

Then create a scheduled task to execute that job queue. The only issue I see here is that if you choose to have the scheduled task repeat daily, and if the computer has logged on users each time the task runs, I’m not 100% certain how things will go if the previous day’s task is still waiting for the host to have zero logged-on users when the next day’s task executes. I think this will cause multiple ‘wait…’ actions to start (one ‘wait…’ action for each day). When the computer finally has zero logged on users, one of those ‘wait…’ threads will probably execute just fine with all of the other ‘wait…’ threads then failing to execute. This might end up working just fine despite the fact that you would see a bunch of failures/errors, but I’m not positive. Also, I believe it would create a thread leak because BP would create a new thread each day for each host that is doing nothing but waiting for there to be no logged on users. The leak would be cleaned up only when those threads are returned to the pool when the target host finally has no logged on users.

---

2. To avoid the potential issue that I described in method number 1 you could write your own script to check for logged-on users and return 0 if no logged-on users are found but return any non-0 integer if logged-on users are found. Then you could add that custom script to a BP job queue that looks something like this:

Execute custom script

Terminate queue if previous action fails/errors

Download and install updates + reboot if required

In this way your custom script would execute first. If it returns 0 then BP will execute ‘Download and install updates + reboot if required’, but if it returns a non-0 value then BP will terminate the queue. If you have this queue set to execute daily via scheduled task, it should give you exactly what you want. There is an example of integrating a custom script into BP posted here. If your script simply returns the number of logged-on users, that would be sufficient for this to work because when 0 logged on users are found your script would return 0, which is what would be needed for this to function as I described.

-Doug

[doug]

Error -198 indicates that there was a problem when BatchPatch tried to add the scan package service for the WsusScn2.cab file. The HRESULT value is the reason code.

---

HRESULT -2147024894 translates to:

0x80070002 -2147024894 ERROR_FILE_NOT_FOUND

The System cannot find the file specified

This would only happen if the file itself did not exist on the target computer when the scan was initiated. It sounds like you got this resolved.

---

HRESULT -2146762487 translates to:

0x800B0109 -2146762487 CERT_E_UNTRUSTEDROOT

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

This indicates that the certificate on the WsusScn2.cab was signed by an untrusted CA. This is not the same problem that you read about in other forum postings that described some cases where the WsusScn2.cab file contains no digital certificate. In this case the .cab file is signed, but the issue is that the certificate is not trusted by the target computer(s). I suspect that you have not used Windows Update on these target computers for a very long time, and now the certificate authority that Microsoft is using to the sign the cab file is not in the trusted root store of the target computers. This does not mean that there is a problem with the WsusScn2.cab file. Probably the file itself is fine and legitimately signed. However, since your target computers are probably either an old OS (you didn’t mention which OS they are) and/or they have not been updated in a very long time, the trusted root store simply does not contain the CA that Microsoft used to sign the .cab file.

I think you just need to get the CA to be included in the trusted root store on the target computers in question. I’m not sure the exact path to make this happen. You might be able to simply view the details of the certificate (right click on the WsusScn2.cab file and then select the ‘digital certificate’ tab, and dig in to ‘view certificate’), and then once viewing the certificate you might be able to simply click a button to import that cert. I think this might depend on which OS you are running on the targets, and I’m not 100% certain that this is the exact correct method. When I look at the cert for the most recent .cab file that I just downloaded, the CA is ‘Microsoft Code Signing PCA.’ I believe historically the way that Microsoft has modified the trusted root store on Windows computers is by publishing a Windows Update with the desired/needed updates. In your case since the computers do not have internet access it seems like you would need another way to get the trusted root store updated. If the method that I described above does not work, then I wonder if maybe you can export the cert from a computer that has it to then import on the computers that do not have it. I’m not sure, but hopefully I’ve given you enough information to go on so that you can get it worked out. If/when you get it worked out it would be great if you could post here with the exact steps you took to get the trusted root store updated.

-Doug

[doug]

Hi Stephen – I’m sorry to say that I don’t fully understand what you are asking. What kind of list do you want BatchPatch to read? And what would reading such a list accomplish? In the way that your current question is phrased it’s unclear what you are trying to accomplish. What does reading a list have to do with using the task scheduler to install updates? What is in the list? What should BatchPatch do with the information that it reads from the list? Please clarify with as much detail as possible in describing exactly what you are trying to accomplish.

Thanks,

Doug

[doug]

This is peculiar. I don’t recall ever seeing something like this happen before. I would suggest that for the sake of troubleshooting it would be best to not use the service instance, and instead to just manually test running actions. This way we can first make sure that things work when BP is used manually. Then once things are working manually, then we can try the service to see what happens. For things to simply stop at “Initiating…” every day is very odd. There is no error message and no further action. My best first guess is that this is being caused by a problem with WMI on the target computer. It seems as if the WMI connection is being received but is just hanging, indefinitely.

My first suggestion is to reboot the target computer and reboot the BatchPatch computer. Then after rebooting both computers you should test by manually executing ‘Actions > Windows Update > Download and install updates.’ If it still gets stuck at ‘Initiating…’, then go ahead and follow the steps for troubleshooting Windows Update actions in the BatchPatch troubleshooting guide. Let me know what happens.

Thanks,

Doug

[doug]

BP doesn’t currently have the built-in If/Else that you are looking for, but you can still use BP to execute the deployment as desired. To do that you would just need to create a simple script that checks the OS of the local computer, and then if it’s the desired OS the script then executes your .exe with the appropriate parameters. Then you would put the script file and the .exe together in a folder on the BP computer, and then create a deployment in BP to deploy the script to target computers. The key here is that you would be deploying the script, not the .exe. And in the deployment configuration you would check the box to “copy entire directory” so that both the script file and the .exe get copied to target computers for execution. When you execute the deployment the directory containing the two files will be copied to target computers, and then the script will be executed on target computers. Target computers that pass the OS check, per the code in your script, will then have the .exe run. Target computers that fail the OS check, per the code in your script, will not run the .exe.

-Doug

[doug]

In BatchPatch you can schedule or manually execute the download/install/reboot at any time that you want. Also, you can schedule or manually execute the download/install/reboot to all happen together at the same time or to happen separately at different times. It’s your choice.

-Doug

[doug]

Yes, in the ‘Alternate credentials’ field if you uncheck the box that says ‘Domain’ you’ll notice that ‘$computer’ is automatically populated in the ‘domain’ field. So if you had a local account on each computer with the same username, that would be one way you could handle it.

-Doug

[doug]

EM – It is not possible to use %logonserver% in the alternate credentials form.

-Doug

[doug]

PsExec.exe only needs to be on the computer that is running BatchPatch. It does not need to be on the target computers.

In 99.9% of cases PsExec.exe can simply be placed into C:Windows on the BatchPatch computer. In rare cases this might not be sufficient. If you have already tried putting PsExec.exe into C:Windows with no luck, then the next step is to put PsExec.exe into the same folder/directory as BatchPatch.exe. Then when you launch BatchPatch.exe it should always find PsExec.exe without problems.

Another option is to modify where BatchPatch looks for PsExec.exe by going to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’

Thanks,
Doug

[doug]

In some additional testing that I did I found that if you run BatchPatch.exe from inside BatchPatch.zip it causes problems. What I mean is if you do *not* first extract the BatchPatch.exe from the .zip file and if you instead try to launch BatchPatch.exe directly from inside the .zip file, this causes Windows to create a temp copy of the BatchPatch.exe, and if you then install the service from this temp running copy of BP it causes the service to get stuck “starting.” The reason seems to be related to how permissions are getting applied when BP installs the service. So, if you are having the service stuck “starting” then uninstall it and delete the entire service installation directory. Then reboot and make sure that there is no BatchPatch Service showing in the services console (start > run > services.msc). Then go ahead and make sure to extract your BatchPatch.exe file to some location on the computer such as your desktop or wherever. Then from there launch it and install the service.

-Doug

[doug]

Excellent.

[doug]

As noted in my previous posting from 3 days ago, the psexec -r switch is already included in BatchPatch under ‘Tools > Settings > Remote Execution > ‘Use PsExec -r switch to specify remote service name’

[doug]

Thanks. Keep me posted.

-Doug

[doug]

One other option to try is in BatchPatch ‘Tools > Settings > Remote Execution > ‘Use PsExec -r switch to specify remote service name’ and then you can specify a custom name, which might cause your anti-virus software to not block it, but I don’t know whether or not it would be likely to work, so you’d have to test it and see.

-Doug

[doug]

On the BatchPatch computer psexec.exe needs to be able to run. On the target computers psexesvc.exe is what needs to be able to run. To confirm that the antivirus software is the cause of the problem you should disable or uninstall the antivirus software and then test the application. If that appears to resolve the issue then the next step would be to whitelist those applications in the antivirus software. If you have trouble whitelisting those, you should reach out to your antivirus vendor for instructions.

I hope this helps.

-Doug

[doug]

Add an exception in your antivirus configuration that allows the service to install/run. The antivirus product should have whitelist capability.

[doug]

I should also point out that you can put a range of IP addresses into BatchPatch instead of host names, and then you can use ‘Actions > Get info > Get host name’ to to essentially a reverse lookup. You’ll end up connecting by IP to the target computer, and then the target computer itself (rather than DNS) will tell you what its host name is. This should help, I think.

-Doug

[doug]

Glad you figured it out.

-Doug

[doug]

And to be clear you’re seeing this on *some* Win 7 targets but not *all* Win 7 targets? It does sound like there must be a driver on those problematic targets that does not exist on the other targets, though of course it’s not clear why the search results are coming back as unparsable.

At the moment I do not have a solution, but perhaps one possible workaround would be to identify the driver on the target computer and disable it there so that the update search does not try to include it. This might work, though I realize it’s not a great workaround even if it does work.

Another option would be to build a WSUS that is not linked to your SCCM. I think there is a good chance that if you point these systems to a WSUS then you won’t have any issues with the search.

I will report back if/when I have any other suggestions.

-Doug

[doug]

First I would recommend testing psexec at the command prompt (start > run > cmd). You can try a command such as:

psexec \targetComputer IPCONFIG

If you determine that this command does not work, then you should look at making sure you can access the target computer’s admin$ share. Go to ‘start > run’ and then type:

\targetComputeradmin$

If you are not able to connect, that would indicate the source of your problem is due to this share being disabled on target computers.

Another place to look would be at any security policies that might have been enacted in your environment, which includes Anti-Virus applications or Host Intrusion Prevention/Protection applications that might be blocking psexec.

I would also suggest that you review the steps outlined in the BatchPatch Troubleshooting Guide to help further narrow down the source of your problem. You posted in this forum posting that you were receiving the same error that’s described in that posting (Windows Update: Error 1611: 5. Failure). As noted in that same posting, this would indicate a permissions issue on target computers. If it’s stopped working all of a sudden on all of your target computers, it would imply that a security policy was applied to your environment that is blocking the psexesvc from running on target computers.

-Doug

[doug]

Strange. This is very similar to what we saw in the WindowsUpdate.log in the case of the other error mentioned at the top of this post (-2145124338 => 0x8024000E WU_E_XML_INVALID). I don’t think this is going to work, but what happens if under ‘Tools > Settings > Windows Update’ you choose ‘Search for *all* software updates’ or ‘Search for *only* important updates’ ? Do either of those settings work? Make sure that ‘search for *all* drivers’ is UNchecked.

You are correct that with your WSUS server being controlled by SCCM, BatchPatch will never find any available updates when the target computers are pointing to the SCCM-controlled WSUS. You would have to set up a new/separate WSUS that is not controlled by SCCM in order for BatchPatch targets to search for updates against WSUS.

-Doug

[doug]

OK, the conversion for -2145067007 is 8024E001:

0x8024e001 -2145067007 WU_E_EE_UNKNOWN_EXPRESSION

an expression handler was passed an expression that it

doesn't know about

We have only ever heard of this error once before (you can see the user, jcity, posted about it higher up in this same thread). He ended up resolving the issue by installing a WSUS server in his environment. When the machine searched for updates against the WSUS, they no longer produced this error.

Do you currently have a WSUS? I know you said you have tried both Microsoft Update and Windows Update and that you see this error with both, but I’m curious if you have a WSUS and what happens when these machines are pointing to it?

Another thing that might provide more information about the cause of the error would be look in the WindowsUpdate.log, which is on the target computer at C:WindowsWindowsUpdate.log . Do a search in the WindowsUpdate.log for ‘8024E001’ without the quotes, and then copy the relevant line(s) into this thread (just make sure the timestamp matches the time that you saw the error in BatchPatch, so that we know for sure that we are looking at the right thing). I’m curious to know what it says.

Thanks,

Doug

[doug]

Excellent. I’m glad you made some progress.

-Doug

[doug]

Chris – It still sounds like there is something weird happening with permmissions. From the computer that is running BatchPatch are you able to reach the target computer by going to “start > run” and then typing:

\targetComputerNameGoesHereC$Program FilesBatchPatch

What happens when you do that? Also please go through all of the steps in the troubleshooting guide to see which other steps you can or cannot complete successfully.

-Doug

[doug]

This appears to be a permissions problem. Windows System Error code 5 means ERROR_ACCESS_DENIED. What is peculiar in this particular example is that normally if there is a permissions problem BatchPatch will spit out an ‘Access Denied’ error before ‘Executing BatchPatchRemoteAgent.exe.’ However, what you are seeing indicates that the failure occurs later, at an unexpected place, which would seem to indicate that there are partial permissions but not complete permissions. If you are not seeing a C:Program FilesBatchPatch folder on the target computer, then it would indicate that BatchPatch was not able to create folder, though again that seems slightly odd only because normally BP would try to create that folder and then say ‘Access Denied’ if it couldn’t. Whereas based on what you are reporting the failure occurs later AND the folder still does not exist. Please start by going through the steps in the troubleshooting guide. This should help reveal where exactly the problem is occurring. Report back with your results.

Thanks,

Doug

[Author]

Posts