Forum Replies Created
-
Posts
-
Well I guess the first question is if you are suggesting that BP is reporting an incorrect result, how are you determining that there are applicable updates for the computers that BP is not reporting?
If you have only gone through *most* of the steps, as you said in your posting, I would suggest going through *all* of the steps because all of the steps are all of the possible reasons why BP would give you unexpected results. There really aren’t any other possible reasons, or at least none that we are currently aware of.
-Doug
Please review the BatchPatch FAQ for the following question (number 2 in the FAQ):
“Why does my search for available updates at the Windows Update control panel GUI not report the same number of available updates that BatchPatch reports when I use it to check for available updates on the same target host?”
Hi James – If you have multiple users logging on to a computer, how do you determine the SID of the ‘primary user’ ? What criteria do you use to make the determination of who is primary vs who is secondary?
I’m actually not quite sure what you are referring to. I’ll try to cover all possibilities here…
1. In BatchPatch you have the ability to enter ‘Alternate Credentials’ for any row/host, which enables you to remotely perform actions on a target host with a logon account that is different from the logon that is used to run BatchPatch.exe. When you save a BatchPatch grid to a .bps file, the default behavior is for BatchPatch to encode/obfuscate the ‘Altnerate Credentials’ password that you entered into the row (or rows) in the .bps file. The password is not in plain text, but still this does not provide any real protection because it’s not encrypted, so if you want to *really* protect the .bps file then you need to either use your own encryption or you may use BatchPatch built-in encryption under ‘File > Password protect’. You can also optionally use ‘Tools > Settings > General > Require/force password protection to be used for all grids’ which forces you to use ‘File > Password protect’ for all grids.
2. Windows provides the ability for a computer to automatically logon with username/password that you store in the registry of the computer.
How to turn on automatic logon in Windows
This information is stored in plain text in the registry, and it has nothing to do with BatchPatch other than that BatchPatch provides the ability for you to input the information into a target computer’s registry automatically so that you don’t have to do it manually. BatchPatch provides this feature under ‘Actions > Reboot > Configure autologon after reboot’
I hope this helps.
-Doug
I’ve sent you an email for further troubleshooting and to see screenshots etc.
Dennis – If ‘dual-scan’ is enabled, it really has nothing to do with BatchPatch. BatchPatch doesn’t bypass your local WSUS– it’s a Windows OS issue. Windows is the culprit for this behavior.
Those articles that I linked to previously explain exactly how to determine if dual-scan is enabled and exactly how to disable dual-scan. It is very specific, and the instructions must be followed carefully and exactly. One of the articles even explains the cause of the error that you mentioned (-102: Failed to execute the search. HRESULT: -2145103860) in the ‘Additional Notes’ section. This error is caused by enabling a particular GPO, but that GPO is *not* the solution to disabling dual scan, so it seems to me that you may not have followed the *exact* instructions in the links that I provided to you.
I would ask you again to *please* follow the instructions *exactly.*
You need first confirm if Dual Scan is enabled or not. The process for this is described in the section titled:
‘How To Confirm If “Dual Scan” Is Or Is Not Enabled’ which appears in the following article:
Deciphering “Dual Scan” Behavior in Windows 10
And then if it is enabled you must follow the instructions to disable Dual Scan under the section titled:
‘How to Disable “Dual Scan”‘ which appears in the following article:
Antivirus or other security related software could be the culprit. If you can you should whitelist psexec.exe, psexesvc.exe, and batchpatchremoteagent.exe. Another thing to try is using a custom remote service name under ‘Tools > Settings > Remote execution > Use PsExec – r switch’. This is sometimes enough to bypass antivirus software.
Great! Thanks for confirming that it worked.
-Doug
Grace – When you posted about this last week I asked you to contact support directly to troubleshoot. When you contacted us directly you then told us that you are not going to manage this server anymore and that we should drop the ticket. And now you are posting about this same error again in a new thread. Would you please instead reply to my last email… In that email I had made a suggestion for you to try and also requested more information if that suggestion failed.
Thanks.
BatchPatch does work with Windows 2000 targets (SP3 and SP4). However, we do not officially support Windows 2000. I would recommend reviewing the following link to help get to the bottom of the issue:
‘Access Denied’ is always a permissions problem. Please review the following two links:
I’m glad you got it worked out. When BP installs the service, it does not allow you to change the user. It must be installed as the user that is running BP. In order for it to be set to Local System, someone would have had to have gone into the services console and changed it. This would definitely break it.
-Doug
Based on what you are describing it sounds like you might have “dual-scan” enabled on these computers. Microsoft introduced new behavior to the Windows Update Agent (WUA) recently that can cause computers to scan against Windows Update or Microsoft Update instead of your local WSUS, and it sounds like you might be affected by it.
We have two blog postings about this topic that explain what it is, how to tell if it’s enabled, and how to disable it. Please read through them very carefully and thoroughly. Let me know what you find.
Deciphering “Dual Scan” Behavior in Windows 10
Other possible reasons for why different updates might be displayed when checking for updates directly on the computer through the Windows Update control panel vs checking for udpates through BatchPatch are explained in question 2 in the FAQ
-Doug
You can certainly try uninstalling/reinstalling though I’m not sure that it will have any effect. The error in your service installation log indicates that you cancelled the installation one time when you first went to install it. It’s not a big deal. I assume you were just testing and then soon after you completed the installation, it seems.
We can see in your log that the BatchPatchServiceInstance.exe starts successfully but then stops or is killed soon after. The question is why does it stop or why is it killed. Do you have any software on the computer that could do such a thing? Antivirus? HIPS? Can you also confirm that you are not launching BatchPatch.exe from within the BatchPatch.zip? This can cause issues. You must first extract BatchPatch.zip so that BatchPatch.exe can be launched on its own instead of directly from within the .zip file.
Anything interesting in the BatchPatchService.log file? This file will be in the directory where the service is installed. Default location is C:Program Files (x86)BatchPatchServiceDOMAIN.AccountBatchPatchService.log
Anything interesting in the Windows application log in the event viewer?
Thanks. This is the same error that was in your WindowsUpdate.log that we discussed last week. It’s a Windows Update error, not a BatchPatch error.
0x80072F8F -2147012721 ERROR_INTERNET_SECURE_FAILURE ErrorClockWrong
One or more errors were found in the Secure Sockets
Layer (SSL) certificate sent by the server.Googling I found the following link, which has some potentially helpful information:
If you are not able to resolve it based on the suggestions in that link then might need to keep googling 0x80072F8F and see what other things you can find that help.
You are the only BatchPatch user who has ever reported this error, so it must be something specific to your environment that is causing it.
I would suggest starting by making sure that your BIOS clock and your Windows time in the OS are accurate. If they are off too much from real-time or from your WSUS, that could be the problem. Also make sure that the certificate installed on your WSUS does not have any issues or timestamp problems etc.
Dennis – The entire posting about declining the updates on the WSUS server was for troubleshooting/resolving the 106G error that you originally posted about and that is the main topic for this entire thread. However, now it appears that you are instead talking about the completely unrelated -102 error and not the 106G error. When you first mentioned the -102 error last week I asked you for the HRESULT value, but you never gave it to me and you never again mentioned -102. All subsequent references in both your postings and my postings were to the “106G error.”
In any case, the -102 error should be simple to resolve because it has nothing to do with a problematic update on the WSUS and nothing to do with the complicated 106G error. However, in order to understand why the -102 is occurring we need to know the HRESULT, so once again I shall ask you to please provide me with the HRESULT value for the -102 error. You can find this in the ‘Remote Agent Log’ column as well as in the BatchPatch.log file on the target computer in the BatchPatch remote working directory, which by default is C:Program FilesBatchPatch. It will say:
-102: Failed to execute the search. HRESULT: -XXXXXXXXXX
-Doug
0x80246007 -2145099769 SUS_E_DM_NOTDOWNLOADED The update has not been downloaded.Are you using cached mode? If yes, try ‘Tools > Settings > Windows Update > Re-copy/overwrite updates…’ and see if that fixes it. If not, please contact us at BatchPatch Contact Form to troubleshoot. We will ask you for an HTML grid export (File > Export grid to HTML) along with the target computer C:Program FilesBatchPatchBatchPatch.log file.
Thanks
I think maybe you can fix it by changing the ‘Language for non-Unicode programs’ in Windows, as described by this link: Language for non-Unicode
Yes, you can do this in BatchPatch. Your job queue would look something like this:
Step 1: Run the local command, which executes your script. The script must have a built-in function to wait 1 minute and loop and try again if the result is 1.
Step 2: Use one of the following special job queue items, depending on your needs. Failure/error is any non-0 return value from your script. If your script returns 0 then step 3 will execute. If the script returns a non-0 value then step 2 will terminate according to which item below you have used in the job queue:
*Terminate queue if previous actions fails/errors (terminates just the job queue for just the executing row in the grid. The rest of the multi-row sequence will continue.)
*Abort basic multi-row sequence if previous action fails/errors (terminates the entire basic multi-row sequence)
*Abort advanced multi-row sequence if previous action fails/errors (terminates the entire advanced multi-row sequence)
I hope this helps.
-Doug
From my posting above in this same thread:
“Then I would suggest that you decline all of the ~20 updates that you approved on the new WSUS. Wait a few minutes after doing that because all SQL activity on the WSUS server has to complete/stop before the declination will be complete in the WSUS database even though the WSUS GUI will appear to indicate that the declination is instantaneous. Once the declination is *truly* complete and all SQL activity on the WSUS stops (you could wait a little while like 20 minutes just to be absolutely sure), then you can do a new check for available updates in BP. At this point the search should complete and there should be no updates found because there are none approved. Then starting with one update at at a time you can approve just the one update. Then wait a couple of minutes until all SQL activity stops on the WSUS, and then test BP again. The goal is to find which update is causing the problem by approving just one update at a time and testing the BP check for available updates in between each approval. But it’s also important to wait until SQL activity stops after initiating the approval (or a declination) because otherwise you will get misleading results if you initiate the BP check for available updates too soon after making the approval or declination.
Now, since you did not receive the exact same HRESULT that is described in the other Error 106G article, I cannot guarantee that the problem will be fixed by finding a problematic update and declining it. However, at the same time, we have not yet experienced or reproduced this problem here. I understand that it seems to be affected by using the German time and region settings, so it is something that we can try to reproduce and test here, but it will take some time. Also, it’s important to understand that with 106G, it’s not likely something that we can fix/change/modify in our code, because the problem is that the search result that the WSUS server sends back to the client during the update search is what has problems, not the BP code. The key is to find out what is causing the WSUS to return unusable results, and in the past the issue seemed to always come down to a particular problematic update on the WSUS. And in your case there seems to also be a relationship to the German time/region setting.”
What do you see inside of BatchPatch before you save the report as .bpurl? Do the question marks appear in that report before saving it or only after saving it and reopening the .bpurl file?
When you say “open” what do you mean? How are you opening the .bpurl file? Are you opening it on the same computer that you created it? Or is it at least the same region/language setting?
Aside from seeing the question marks, what kind of problem does this actually present?
-Doug
If you have not configured the ‘Specify intranet Microsoft update service location’ then the computer will use Windows Update, not a WSUS server. If you do not want computers to download or install updates until you tell them to, then yes you would choose option 1 to notify for download and notify for install. If you want to further reduce internet bandwidth consumption for Windows updates, then you should look at BatchPatch ‘cached mode’ too.
To prevent your computers from automatically installing updates you need to use the ‘Configure Automatic Updates’ Group Policy setting. This is described more at the following link. Note, the link talks about configuring BP to use with WSUS, but even if you are not using WSUS the ‘Configure Automatic Updates’ policy is what you would use to prevent your computers from auto-updating. Do *not* disable the Windows Update service.
BatchPatch Integration with WSUS and Group Policy
More here from Microsoft: https://technet.microsoft.com/en-us/library/cc720539(v=ws.10).aspx
Dennis – If you are still experiencing the 106G error, I would ask you to please follow the instructions that I gave you in my previous postings above. So far you have not actually tried any of those suggestions, so I cannot really make a new suggestion if you are not willing to try the existing suggestions.
-Doug
The 8024000C is normal and not a concern.
However, I don’t think I have ever seen 0x80072F8F before. It translates to:
0x80072F8F -2147012721 ERROR_INTERNET_SECURE_FAILURE ErrorClockWrong
One or more errors were found in the Secure Sockets
Layer (SSL) certificate sent by the server.
I’m not sure if the 0x80072F8F error has anything to do with the problem you are encountering. It might, but it might not. The error that is being returned to BatchPatch, according to your original posting, is not the same, so I don’t know if one has anything to do with the other.
Googling I found the following link, which has some potentially helpful information that might explain why you have the issue with only some computers:
Honestly, this sounds like user error of some kind. If you contact us via email we’ll trade screenshots etc to make sure you are doing everything correctly. I suspect there is something very simple that you are missing that is causing you to have problems.
-Doug
Thanks for the information, Dennis. 106G generally means that the XML data that is being returned by the WSUS to the client has something wrong with it. In your case the particular HRESULT is not documented anywhere, but I believe it’s still likely to be a very similar cause as the one described in this link: Error 106G
I understand that you rebuilt the WSUS. I also understand that when you check for updates using the Windows Update control panel directly on the target computer that it does not have the same issue. This is because Microsoft has a private API that they use that we (and other third party vendors) do not have access to. And so it is unfortunately not possible to directly compare the results that are obtained when using the public API with the ones that are obtained when using the private API.
The problem, I suspect, is related to a particular update that has been approved. The link above (I also linked it in my previous posting) has very detailed information on how to (most likely) solve the problem. Rebuilding the WSUS was not meant to be a complete solution, and I’m sorry if I was not clear about that. Rebuilding the WSUS was to help figure out which approved update is the culprit rather than trying to figure it out on an existing WSUS that has potentially thousands of approved updates. I would suggest that you still please read the entire aforementioned link for a general understanding of the issue. Then I would suggest that you decline all of the ~20 updates that you approved on the new WSUS. Wait a few minutes after doing that because all SQL activity on the WSUS server has to complete/stop before the declination will be complete in the WSUS database even though the WSUS GUI will appear to indicate that the declination is instantaneous. Once the declination is truly complete and all SQL activity on the WSUS stops, then you can do a new check for available updates in BP. At this point the search should complete and there should be no updates found because there are none approved. Then starting with one update at at a time you can approve just the one update. Then wait a couple of minutes until all SQL activity stops on the WSUS, and then test BP again. The goal is to find which update is causing the problem by approving just one update at a time and testing the BP check for available updates in between each approval. But it’s also important to wait until SQL activity stops after initiating the approval (or a declination) because otherwise you will get misleading results if you initiate the BP check for available updates too soon after making the approval or declination.
Now, since you did not receive the exact same HRESULT that is described in Error 106G, I cannot guarantee that the problem will be fixed by finding a problematic update and declining it. However, at the same time, we have not yet experienced or reproduced this problem here. I understand that it seems to be affected by using the German time and region settings, so it is something that we can try to reproduce and test here, but it will take some time. Also, it’s important to understand that with 106G, it’s not likely something that we can fix/change/modify in our code, because the problem is that the search result that the WSUS server sends back to the client during the update search is what has problems, not the BP code. The key is to find out what is causing the WSUS to return unusable results, and in the past the issue seemed to always come down to a particular problematic update on the WSUS. And in your case there seems to also be a relationship to the German time/region setting. As a start it would be very helpful if you are able to provide me with the following information:
1. A list of all the ~20 updates that you approved on the new WSUS.
2. The exact OS version and build number of the WSUS server. The easiest way to provide this info would be by using BP ‘Actions > Get info > Get OS version’
3. The exact OS version and build number of the target computer.
With regard to the -102 error that you got, what is the HRESULT value? This will appear in the ‘Remote Agent Log’ column and in the BatchPatch.log file on the target computer. Am I understanding correctly that this error appeared after you changed from German time/region to US time/region on the target computer? I think we will have to evaluate this error somewhat separately from the other error because -102 generally means that there is a communication problem between the target computer and the WSUS. Therefore it seems less likely that the two issues are directly related, though I do understand that based on your testing it seems that the -102 only appeared after you made the change the to region/time settings, so we will see what we can figure out.
Please review the following link: