[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

[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

[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]

The age of the file wouldn’t be the issue, which is why I suggested looking at the digital signature in order to confirm if the file had been corrupted since the error message that you are getting indicates that the file is corrupted (a corrupted/modified file would not contain a valid signature). If your BP computer can’t download the WsusScn2.cab file then there is either a transient issue with Microsoft’s server or there is some kind of issue with your BP computer… not sure if you have a proxy or a web filter/firewall that prevents it from getting the file. In either of those cases you can certainly put the file there yourself, and then BP will use it.

[doug]

0x8007000D The data is invalid. ERROR_INVALID_DATA

This implies that there is probably an issue (presumably some type of file corruption) with the WsusScn2.cab file that ServerA is using. Either there was corruption when downloading it from Microsoft to ServerA, or the corruption is being introduced when ServerA copies it to the target computers. If you manually inspect the WsusScn2.cab file (both on ServerA as well as on a couple of targets) you can right click on the file and view ‘Properties > Digital Signatures’ as a way to verify that the file has not been corrupted/modified. If the Digital Signatures tab is present with signatures listed, then the file is good. If it is not present or if it is present but with no signatures listed, then the file is not good. If it’s not good then you can delete the WsusScn2.cab file and let BatchPatch re-download it. If it’s good on ServerA but not good on the targets, then the corruption is being introduced during the file copy from ServerA to the targets. This would be unusual, but it would imply that you have issues with your network.

[doug]

Under normal circumstances when performing a deployment, the exit code is actually coming from the setup/installer application, not from psexec or BatchPatch. So if BatchPatch ‘check for available updates’ runs successfully on that same target computer where your deployment fails, then you’ll know that the issue is nothing to do with psexec but rather is due to either a problem with the deployment configuration or is the return code that the setup/installer is returning. Since you said you can successfully run the same deployment on other computers, then that would imply that there could just be an error running the setup/installer on this particular computer. In that case I would remove BatchPatch from the equation and run the setup manually on that target computer and see what it says.

[Author]

Posts