[doug]

Thanks for the suggestion. We’ll consider this for a future build. In the meantime one option that you can use that you probably weren’t aware of to reduce the white glare is the transparency slider. It’s not exactly what you’re looking for of course, but perhaps it will help a bit. In the lower right corner of the BP main window you’ll see a small arrow icon. Click that to reveal the slider, and then adjust to make the BP window more or less transparent.

[doug]

This below link has another possible resolution for this error: -102: Failed to execute the search. HRESULT: -2145107921

https://serverfault.com/questions/741083/unable-to-update-windows-server-2012

[doug]

Thanks. We’ll see what we can find.

-Doug

[doug]

Thanks. Do you know were you using CTRL-A to select all rows, then initiate the action, then click on the next grid tab and repeat? Or were you only selecting some rows in each grid? Or were you selecting all rows in each grid but using the mouse to select them instead of using CTRL-A? And what about rotating between grids? Were you doing that with the mouse by clicking on each grid tab header or were you using some other method?

Thanks

[doug]

Thanks. We are looking into it. If you figure out how to reproduce it, please share those steps here.

[doug]

I would direct you to the Microsoft documentation that describes the behavior of this policy:

https://docs.microsoft.com/en-us/windows/deployment/update/waas-wu-settings#do-not-connect-to-any-windows-update-internet-locations

Do not connect to any Windows Update Internet locations

Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Microsoft Store.

Use Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Windows Update for Business and Delivery Optimization to stop working.

Note

This policy applies only when the device is configured to connect to an intranet update service using the “Specify intranet Microsoft update service location” policy.

I’m not sure why you are experiencing it only on your 2016 machines. It might be the specific combination of policies applied. I would start by evaluating every single applied policy to see if any one or combination of policies is causing the discrepancy.

If you have the “Specify intranet Microsoft update service location” policy set, then you should not need the “Do not connect to any Windows Update Internet Locations” policy. However, I would suggest that you pay attention to the possibility of “Dual Scan” being enabled on your 2016 computers. I would suggest that you consider enabling “Do not allow update deferral policies to cause scans against Windows Update”.

More on Dual Scan:

dual-scan-difficulties-with-windows-update-on-windows-10-versions-1607-anniversary-update-and-1703-creators-update

deciphering-dual-scan-behavior-in-windows-10

[doug]

You can create a custom remote command in BatchPatch ( how-to-hard-code-your-own-custom-commands-in-the-batchpatch-actions-menu ) with the following syntax:

taskkill /IM notepad.exe

Then create a job queue that executes this remote command in the step before your deployment is executed. Then when you execute the job queue it will first run the taskkill command to kill your app (maybe firefox.exe or whatever), and then it will run the deployment.

using-the-job-queue-in-batchpatch-for-multi-step-execution

I hope this helps.

-Doug

[doug]

A fix has now been published.

-Doug

[doug]

Thanks. We are working on it.

-Doug

[doug]

Makes sense. I would suggest you try to switch back to using PsExec (unless for some reason you aren’t able to get it working). There are two possible ways PAExec would have been in use… Either it would have been renamed to PsExec.exe and just swapped in, or it would have been specified under ‘Tools > Settings > Remove Execution > Use psexec.exe custom filepath’

-Doug

[doug]

Thanks. We are not currently able to reproduce this.

Can you tell me does the error occur every time you click OK in that window, or did it happen one time and no longer happens?

Did you update your service instance in addition to your main batchpatch.exe?

Does the software crash or does it continue to function normally despite that particular message?

[doug]

BatchPatch is generally used with PsExec, not PAExec. In rare cases if a user is having issues with PsExec he might instead try using PAExec. I’m not sure in your case why you are using PAExec over PsExec, but I assume it’s because you had problems with PsExec functioning properly. That said, I’m not completely surprised to hear that there are PAExec services hanging around on some systems… the reason I’m not surprised is because there is likely something in your environment that was creating an issue for PsExec, and it’s conceivable that the same issue that was causing an issue for PsExec is also preventing PAExec from successfully and completely removing itself from targets where it is being used. BatchPatch does not remove PsExec or PAExec. They remove themselves immediately after they complete execution, but there can be cases where they fail to remove themselves completely/successfully.

You can manually delete a service with the following syntax at the cmd prompt on the server where the service remains:

sc delete ServiceName

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For deploying Windows 10 feature updates/upgrades, I would generally recommend following the method outlined here:

https://batchpatch.com/deploying-windows-feature-upgrades-remotely-to-multiple-computers

[doug]

There are multiple ways to automate the process in BatchPatch, but automatic isn’t always better. Automating things can require testing etc to make sure it works as desired, and this isn’t always going to be quicker/simpler, but that’s up to you.

Possible ways to accomplish the task:

1. Instead of a one-step operation to install all updates, you could use a two-step operation where as your first step you install the servicing stack update, and then once you have successfully performed this step, then as your second step you install the remaining available updates. You can use the graphical or textual filter in BatchPatch on the first operation to make sure that only the desired servicing stack update is installed. Then for the second operation you could clear the filter so that all remaining updates are installed. This method would not be 100% automatic. It would require that you set the filter for all rows to include only the servicing stack update, then launch the installation process for the servicing stack update on all target computers. Then when done, clear the filter and launch the update process for all remaining updates.

filter-which-available-updates-are-included-or-excluded-when-downloading-or-installing-windows-updates

2. You could follow the same concept as described in option 1 above, but instead of two separate manual operations in BatchPatch, you could link together the two operations into a single operation using the advanced multi-row queue sequence. You would create two rows for each target host in the grid. One of the rows would be for installing the servicing stack update with the textual filter applied, the other row would be for installing all remaining updates with no filter applied. Then the advanced multi-row queue sequence would enable you to ensure that the row that installs the servicing stack update is executed before the row that installs the remaining updates.

advanced-multi-row-queue-sequence-video-tutorial

3. You could create a manual deployment in BatchPatch for the servicing stack update. You would have to download the desired KB from Microsoft, and then create a BatchPatch deployment with that KB. You could then setup a regular job queue that first executes the deployment and then subsequently executes a Windows update download/install operation to install the remaining available updates.

4. You could use scheduled tasks for everything. In this case you would create two rows for each target computer, similar to option number 2 above where one of the rows is for installing the servicing stack update (with a textual filter applied to that row for that purpose), but instead of using the advanced multi-row queue sequence to ensure that the servicing stack row is executed first, you could use two scheduled tasks (one for each row) to schedule the servicing stack row to execute 15 minutes before the row that handles all the remaining updates.

[doug]

If a computer has multiple updates ready for installation, it’s the Windows Update Agent on that computer that handles the order that the updates are installed. BatchPatch doesn’t control this when using it normally, and generally this isn’t something that you need to worry about. You should let the Windows Update agent install the updates in the order that it chooses.

However, if you *really* wanted to control the order that the updates are installed, then you could use BP to install only one specific update at a time (using the graphical or textual filter), and then just repeat the installation process one time for each desired update. Or you could download the KBs manually and use the deployment feature in BP to deploy each KB sequentially. But again I wouldn’t recommend doing either of these things. I would recommend just letting the Windows Update Agent handle the ordering.

-Doug

[doug]

Excellent. Note you can also use ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service name’ to change the name of psexesvc.exe running on the target computer to yourcustomname.exe.

[doug]

I believe this is a Windows System error code:

ERROR_SERVICE_REQUEST_TIMEOUT

    1053 (0x41D)

    The service did not respond to the start or control request in a timely fashion.

I haven’t seen this particular error before, but my best guess is that it’s an issue with psexec not able to run properly. Please carefully go through the steps at this link to see if you can pinpoint where the issue is:

batchpatch-troubleshooting-guide

[doug]

I don’t know why you are having problems, but I would suggest you test your script directly on a computer without using BatchPatch. Then you can add some error handling to figure out exactly why it’s failing. For example if you run the following script it will print out the return code and error code if it fails:

strComputer = "."
strRegPathSuffix = "\Software\Microsoft\Office\16.0\Outlook\Resiliency\DisabledItems"
Const HKEY_USERS = &H80000003
 
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = ""
oReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys 
For Each subkey In arrSubKeys
'wscript.echo subkey
	If NOT ((InStr(1,subkey,".DEFAULT",1) > 0) OR (InStr(1,subkey,"S-1-5-18",1) > 0) OR (InStr(1,subkey,"S-1-5-19",1) > 0) OR (InStr(1,subkey,"S-1-5-20",1) > 0) OR (InStr(1,subkey,"_Classes",1) > 0)) Then    
		strKeyPath = subkey & strRegPathSuffix
		wscript.echo strKeyPath
	Return = oReg.DeleteKey(HKEY_USERS, strKeyPath)
		If (Return = 0) And (Err.Number = 0) Then    
			Wscript.Echo HKEY_USERS & strKeyPath & " successfully deleted"
		Else
			Wscript.Echo ".DeleteKey failed. Return value = " & Return & ". Error value = " & Err.Number
		End If
	End If
Next

You can then lookup the return code at this link. Note, the enum is zero based, so wbemNoErr == 0, wbemErrFailed == 1, wbemErrNotFound == 2, and so on: https://docs.microsoft.com/en-us/windows/win32/api/wbemdisp/ne-wbemdisp-wbemerrorenum?redirectedfrom=MSDN

[doug]

Thanks. Unfortunately this is not a BatchPatch issue. It’s a Windows issue. Microsoft made changes in Windows 2019 in how it shows the update history. We actually don’t know if it’s intentional on their part or if they would consider it a bug. There are a couple of things to know:

1. You can see the proper update history if you use BatchPatch ‘Actions > Windows Updates > Generate consolidated report of update history (Windows Update Agent)’

2. On the target computer itself Windows now has two separate views for seeing update history. The two views do not both report the same information. One of them does show at least *some* of the updates that were installed by BatchPatch. The second screen is visible only after you click the ‘Uninstall updates’ link on the first screen or by going directly to the Windows ‘control panel > programs and features > view installed updates’.

These are the two screens that you can see in Windows:

———————————————
———————————————
This is the screen that you you can see by querying the history from within BatchPatch for the same target computer:

[doug]

To delete a single registry key on target computers you could use the syntax described in this posting: deleting-registry-key

If you are trying to delete a key from all users in HKU then yes you could certainly modify the script at this link: deploying-a-registry-key-value-to-hkey_current_user-hkcu-or-all-users-in-hkey_users-hku That script currently uses StdRegProv.EnumKey, StdRegProv.CreateKey, and StdRegProv.SetStringValue. You could modify the script to fit your needs and to use StdRegProv.DeleteKey as the deletion method.

More on the aforementioned StdRegProv methods:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/regprov/enumkey-method-in-class-stdregprov
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/regprov/createkey-method-in-class-stdregprov
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/regprov/setstringvalue-method-in-class-stdregprov
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/regprov/deletekey-method-in-class-stdregprov

[doug]

Great, glad you got it figured out

-Doug

[doug]

I guess I’m confused. Your original deployment works because you followed the instructions in that link to create it. But the second one does not work because you didn’t follow the instructions in that link. I can’t tell from the log you provided exactly what is going on, but I can see that there are some weirdnesses there. For example… when a deployment is performed there is no need to perform a manual separate file copy operation. The deployment itself handles the file copy. Second, the deployment looks to the deployment staging folder for the file that is being executed, but your log shows that it is looking at C:\dnsfix.reg, which is not in the deployment staging folder. I know you said the file exists at that location, but that’s not my point. My point is that what you have created is not a normal/standard/expected deployment, though I don’t fully understand exactly what you have created without being able to see the actual deployment configuration window. At this point where I’m confused is if you had a successful deployment that you created by following the instructions in the aforementioned link, why would you not follow it again to create a new deployment? Why are you trying to do something differently in the new deployment rather than following the instructions for how a .reg deployment is created in BP? It seems, based on the logs you showed, that you have somehow modified the deployment in a way that won’t work (such as, for example, modifying the actual command to execute instead of using the command to execute that BP automatically creates when you setup the deployment).

If you can provide me with a screenshot of your deployment configuration (I mean the actual window where you create the deployment in BP) I might be able to see where things aren’t setup right. This forum doesn’t allow you to upload images, so you would either have to post the image on imgur or similar and then link to it from here, or you may email us through the contact form on our website for further support.

Thanks,
Doug

[doug]

Please follow the instructions at this link, which shows how to deploy a single .reg file:

Deploy Registry Keys to Multiple Computers Using BatchPatch

[doug]

{89820200-ECBD-11cf-8B85-00AA005B4340} is a registry key, not a value. So it needs to be deleted with the syntax for removing a registry key, not the syntax for removing a registry value.

This command does NOT work at the cmd prompt (nor in BP) because the syntax is wrong:

reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components” /v {89820200-ECBD-11cf-8B85-00AA005B4340} /f

This correct syntax works both at the cmd prompt and in BP:

reg delete "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{89820200-ECBD-11cf-8B85-00AA005B4340}" /f

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[Author]

Posts