Forum Replies Created
-
Posts
-
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:
MAC address is for Wake On LAN only. You need to use host name or IP address for everything else.
Please see:
With regard to feature updates (upgrades)… the filter is now there so that BatchPatch recognizes them and distinguishes them from other updates. However, at this time BatchPatch cannot install feature updates through the normal/standard BatchPatch Windows update actions. This is due to how Microsoft is distributing them differently from all other software updates. Instead they can be deployed using the method outlined here:
Remotely Upgrading Windows 10 to the ‘Creators Update’ version 1703 (or to the ‘Anniversary Update’ version 1607)
As for the driver updates in question, it’s a similar situation. In Win 10 and Win 2016 we have noticed that Microsoft doesn’t even show these updates in the Windows Update GUI anymore. BatchPatch still shows them, but they appear to not be installable. Frankly, chipset drivers were probably not ever installable through Microsoft Update. We recommend that if you are using Microsoft Update that you then also use ‘Important/Recommended’ instead of ‘All software updates’ and ‘All driver updates.’ Or at the least I would suggest that you uncheck ‘All driver updates.’
-Doug
Please review the following posting about 106G. 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 the following posting. You are seeing a different HRESULT, which we have only ever seen or heard of from gestay. The following posting discusses solutions for the same 106G but a different HRESULT. However, I think your problem will be resolved in a similar way. You might even just decide to build a new WSUS (or rebuild your existing one) because that might be the quickest/simplest fix:
It might be caused by your anti malware software blocking psexesvc.exe on the target computers. Try setting a custom name for this process under ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify remove service name’ You could use something like BatchPatchExeSvc.exe. This might be enough to bypass the anti malware app. If not then you could try whitelisting the exe files in the anti malware app.
See also this posting, which explains the most common reason for getting stuck on “Attempting to initiate Windows Update”: https://batchpatch.com/batchpatch-stuck-attempting-to-initiate-windows-update
Based on reviewing their instructions I think there are a couple things you need to do.
1. From their description it sounds like there are more installation files than just the MCR_R2017b_win64_installer.exe. If there is an entire folder of installation files then you must check the box “copy entire directory” in your BatchPatch deployment configuration.
2. They are saying that you need to create a properties file template, which you can name installer_input.txt. After you input the needed/desired properties into this file according to their instructions, then you can create the deployment.
3. The deployment configuration must copy the entire directory that contains the MCR_R2017b_win64_installer.exe along with the installer_input.txt file to the target computer. This is accomplished by having the installer_input.txt file in the same folder as the MCR_R2017b_win64_installer.exe. Then tick the box as mentioned in step 1 to “copy entire directory”. Additionally you would need to add the following parameter to the parameters field in the deployment configuration of BatchPatch.
-inputFile installer_input.txtYou will *not* need to modify the ‘command to execute’ field in BatchPatch. However, when the deployment is properly configured it should show:
"MCR_R2017b_win64_installer.exe" -inputFile installer_input.txtIt sounds like something in your environment has changed. Access Denied generally means that there is a permissions issue. Please start by going through the troubleshooting guide step by step to help pinpoint where the issue is.
The ‘multiple tasks schedule’ does not support recurrence, and I’m not sure if/when it will. Your options are:
1. Add two rows to the grid with the same target computer in each row. Then create a recurring scheduled task for each row.
2. Use the multiple tasks schedule and simply pick the exact dates and times you want the tasks to run instead of using the recurrence option. You can schedule the tasks as far in advance as you would like, so it would not take very long to schedule a couple years or more worth of monthly tasks.
I hope this helps.
-Doug