[doug]

Yes, we will consider this. Thanks!

-Doug

[doug]

If you run BP in offline mode on the DMZ computer, you can schedule it ‘Download available updates’. It will download the Microsoft offline scan file, and then it will download the updates that are available for the computer that initiated the download to its local cache. It will not download the entire updates repository– it will only download the updates that are available for the computer that initiated the download, based on the filters/settings that you have specified in ‘Tools > Settings > Windows update’. There is not currently any way to schedule the download of the entire offline updates repository.

-Doug

[doug]

Please review the following two links:

Troubleshooting Errors 1611: 64 , 1620: 64 , 1611: 2250 , 1620: 2250

BatchPatch Troubleshooting Guide

[doug]

Only certain BatchPatch actions will utilize the remote working directory and/or leave log data inside of it. You can delete the remote working directory using ‘Tools > Delete remote working directory’ without leaving any residue. You could also put a deletion command inside of a standard BatchPatch ‘remote process/command’ if you want to add it to a job queue or something like that. Just use a NON-logged-output remote command because it will not leave any residue whereas a logged-output remote command will create the remote working directory (though it generally should not leave anything inside of it unless there is some kind of failure). I would also strongly encourage you to use any deletion command, including the built-in ‘delete remote working directory’ command, on a test computer first just to be safe and to make sure it does exactly what you want because otherwise you run the risk of executing an unintended or unexpected deletion command across a lot of computers at once, which for obvious reasons can have a bad outcome, depending on which directory you delete.

-Doug

[doug]

There is not built-in functionality to do this, but you could do it with a custom script (you would have to write the script). At the following links you can see examples of integrating custom scripts into BatchPatch.

advanced-script-integration-with-batchpatch

batchpatch-custom-script-integration-install-windows-updates-only-after-stopping-a-specified-service

using-batchpatch-to-execute-a-custom-script-to-retrieve-the-count-of-cpu-sockets-cores-and-logical-processors-from-remote-computers

[doug]

Thanks for the update.

[doug]

You’ll be able to append a DNS suffix during the sync process in the next version of BP.

Thanks,

Doug

[doug]

Thanks for explaining. Yeah you are encountering a problem with how Windows Explorer is handling the ‘browse’. However, you can still do it with BatchPatch very simply. In that case you just can’t use the ‘browse’ button to specify the shortcut file. Instead just manually type or paste the filepath to the shortcut .lnk file. So for example:

Source file/folder (this computer) E:SomeFolderShortcut.lnk

Destination folder (target computer ): C:SomeFolder

[doug]

I’m sorry to say that I don’t understand the problem that you’re describing.

If the file that you want to copy is placed on the BatchPatch computer in a folder like C:someFolderFileToCopy … and then you use the ‘copy files/folder’ feature and click the browse button for the source file/folder, you would then browse to C:someFolderFileToCopy to select the source file. I don’t understand what Skype not being installed has to do with it. You placed the file there manually, so the file is there regardless of whether or not Skype is installed. On the one hand you are saying that you select it in the source file browser box, but on the other hand you’re saying that you can’t select it in the source file browser box. So I’m confused as to what you are actually experiencing happen. Can you clarify?

[doug]

I was not aware that Skype allowed multiple versions of itself to be installed. I’m not sure that this is intended behavior for Skype. In any case, I am not a Skype expert, so I’m not sure what the best solution would be for your situation, and I don’t know what the result would be if you follow the instructions at the link you posted above. I don’t know if that would remove one or both versions, so I would first try that and see what it gives you. If I were in your shoes I would probably just attempt to remove both versions and then install the desired version after that, leaving you with just one version.

[doug]

Looks like you’re just missing quotes. One or both of these should work:

powershell.exe "get-appxpackage *office* | remove-appxpackage"

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "Get-AppxPackage *office* | Remove-AppxPackage"

[doug]

Thank you for your suggestion. We will consider this for a future build.

[doug]

Thank you for your suggestion. We will consider this for a future build.

[doug]

-2147024843 == ‘The network path was not found’

Since you are only seeing this on a few machines, I can think of a couple things that might cause this…

1. If the target computer does not have a C drive, then there will be no \targetComputerC$ , and so BatchPatch will not be able to create the directory. Check to see if the target computer has Windows installed on a different drive letter such as D or E etc.

2. A firewall issue could cause this. From the BatchPatch computer make sure you can access \targetComputerC$

BatchPatch ‘Getting Started’ page, which includes Windows Firewall Configuration

BatchPatch Troubleshooting Guide

[doug]

I would suggest you review the following posting that explains the limitations to be aware of with the various ‘special items’ in the BatchPatch job queue, such as…

‘Wait for host to be detected online’

‘Wait for host to go offline and come back online’

I’m not quite sure what you are actually attempting or what is actually occurring, but the method of reboot would not have an impact on how either of the above-mentioned special items works. They will always work the same, but this does not mean that they will provide you with the desired results in every case. See the following link for more info:

Understanding the ‘Special’ Items in the BatchPatch Job Queue

[doug]

The job queue only has a built-in option for C. If you wanted to get information about other disks/volumes, you would need to create a custom remote command (logged output). Once you have created/saved the command in BatchPatch it will appear in the list of available items in the job queue. You could use commands like these:

WMIC PATH Win32_LogicalDisk where “drivetype=3” GET deviceid, volumename, freespace, size

WMIC PATH Win32_LogicalDisk where “deviceid=’E:'” GET deviceid, volumename, freespace, size

You can’t see the code behind actions in the job queue. You can, however, see various sample remote commands syntax under ‘Actions > Execute remote process/command > Create/modify’. The bottom part of that window has a list of various types of commands that you can use or modify for your own needs. You can also see a similar list here:

how-to-hard-code-your-own-custom-commands-in-the-batchpatch-actions-menu

[doug]

The issue you are having is not due to a max length situation. First, please note that powershell commands need to be executed with syntax like this:

powershell.exe -command "your command here"

However, in this case for the complex command that you are trying to execute, using the above-mentioned syntax still won’t work. I think this is because the command contains all sorts of characters, and most likely something is causing BP to unsuccessfully interpret the input. BP is not able to execute 100% of commands that can be executed at a cmd prompt. It can handle most but not all.

That said, I would suggest two possible alternatives:

1. The following built-in menu item produces a very similar output to your command: ‘Actions > Get info > Get disk space (available MB) > All disks’

2. Your command can be saved in a FreeDiskSpace.ps1 file and then run in BatchPatch using the BatchPatch ‘Deployment’ feature. Just make sure to check the box in the ‘Deployment’ window to ‘Retrieve console output’. Then when you execute the deployment BP will copy the FreeDiskSpace.ps1 file to the target computer for execution. This avoids any interpretation/parsing problems. You can save the deployment for future use so that it’s available as a single click of a menu item.

[doug]

Thank you for highlighting this. I have looked into this, and I believe we have two bugs here plus one ‘feature’.

1. BUG – Email notifications sent for any grid, regardless of whether that grid is running in the service instance or regular instance, will include a HTML representation of the grid, but this HTML grid does not obey the column display ordering that is set in the main BP grid.

2. BUG – When a grid is loaded into the service instance and then is displayed in the service instance viewer, column display ordering that is set in the main/regular BP instance is not obeyed in the service instance viewer.

3. NOT A BUG – When a grid is running in the service instance and loaded into the service instance viewer, or when a grid is running in the service instance and emailed as HTML via a scheduled task, the resultant output includes the previously hidden columns in addition to all the visible columns.

We will look at fixing 1 and 2 in a future build. We will consider updating the functionality for 3 so that hidden columns are no longer displayed in the service instance viewer nor in the HTML email reports that are sent from the service instance.

[doug]

Thanks for the feedback, André. In the meantime have you considered putting SystemGroup as the first instead of last item in the column? This way you could at least use the sort feature to effectively sort on SystemGroup. Having IP address and OS before SystemGroup in the same column would make this impossible. Anyway that’s just a thought to consider for now since there is not currently a filter option.

-Doug

[doug]

How does BatchPatch show this? I think you are saying that if you execute the BatchPatch action ‘Get pending reboot status’ it reports TRUE in cases where you believe it should be reporting FALSE. Is this correct?

If you look at the entire cell contents of a BatchPatch ‘Get pending reboot status’ result, you will see something like this:

---

---

FALSE             ...



isWindowsUpdateRebootPending: False

isComponentBasedServicingRebootPending: False

isUpdateExeVolatileRebootPending: False

isCCMclientUtilitiesRebootPending: Undetermined



PendingFileRenameOperations: NONE

---

---

Note, Windows does not offer/provide a sanctioned, singular way to determine with certainty if a computer is in need of a reboot. However, Windows does mark in several places in the OS values that can be used to infer that a reboot is required to complete certain operations.

When using ‘Get pending reboot status’ BatchPatch checks the following locations of the target computer(s) to determine if reboot is needed:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto Update:

If a subkey contains “RebootRequired” BatchPatch returns TRUE.

HKLMSOFTWAREMicrosoftWindowsCurrentVersionComponent Based Servicing:

If a subkey contains “RebootPending” BatchPatch returns TRUE.

HKLMSOFTWAREMicrosoftUpdates:

If the UpdateExeVolatile value exists and is greater than 0, BatchPatch returns TRUE.

CCM_ClientUtilities.DetermineIfRebootPending method

If the host has SCCM installed and this method returns TRUE, BatchPatch returns

TRUE.

HKLMSYSTEMCurrentControlSetControlSession Manager:

If the PendingFileRenameOperations value contains any filepaths, BatchPatch displays

them, but this will not cause BatchPatch to return TRUE even though the rename operations will occur upon reboot.

---

---

All that said, when you use ‘Get pending reboot status’ and it returns TRUE it doesn’t mean that you absolutely must reboot the computer. It means that Windows has operations that are pending reboot to be completed. It does not necessarily mean that the computer is in an unstable or problematic state.

If you use one of the BatchPatch methods to install Windows updates, but you do not let BatchPatch also ‘reboot if required’ then you could leave your computers in an unstable/unprotected/vulnerable state since it is the case that some updates will not be “live” until the reboot occurs. However, if you are rebooting the computers after Windows updates are installed, but then at a later date ‘Get pending reboot status’ reports TRUE, it does not necessarily mean that the sky is falling and that you must drop everything and reboot immediately, though it may warrant further investigation to see why BatchPatch is reporting TRUE so that you can determine if you want to reboot the computers or not.

[doug]

Craig – Can you clarify what you mean by “BatchPatch giving false positives for server 2016 reboots” ? Please be as descriptive as possible. At the moment I’m not quite clear on what you’re talking about.

[doug]

The tutorial below demonstrates one way you can automate the process of installing updates on the guest VMs and then the Hyper-V host. You could easily add an email notification to it.

virtual-machine-guest-host-update-and-reboot-sequence-automation

[doug]

You can manually deploy upgrades/updates/builds etc in offline environments using the BatchPatch ‘Deployment’ feature. However, BatchPatch ‘offline mode’ for Windows Update is reliant on the WsusScn2.cab file that Microsoft releases monthly. This file only contains information about security updates, service packs, and select other items.

-Doug

[doug]

We have found that there does seem to be *something* up with Win 10 1803. If target computers are Win 10 1803, but the BatchPatch computer is a previous version of Windows, there are no issues. But if the BatchPatch computer is Win 10 1803 and the target computer is also Win 10 1803, then we get ‘Access Denied.’ This only applies to non-domain computers, and we are confident that the issue is something with Win 10 1803, though at the moment we don’t know what the exact cause is. It doesn’t just affect BatchPatch but will actually affect any remote WMI connections made from a Win 10 1803 computer to a Win 10 1803 computer. We have also discovered other people on the web with the same issue.

[doug]

It sounds like you have already done some troubleshooting to conclude that psexesvc isn’t stopping, but you haven’t really described anything about what you are experiencing in BatchPatch, so I can only guess at what might actually be occuring. However, I would start by reviewing the steps provided at this link.

Error 1611: 3. Failure

If that doesn’t help, then I would need you to provide more detail about exactly what you are experiencing in BatchPatch. What are you executing? What error message/number appears? Is this happening on one target computer or all target computers? Anything else that might be relevant? Etc.

[doug]

The standard reboot commands that BatchPatch issues are executed through WMI. Most versions of Windows will not allow a WMI reboot to be executed on the localhost. You will generally see in BatchPatch:

Reboot/Shutdown: Privilege not held.

To have BatchPatch reboot the computer that is running BatchPatch you would have to use a different reboot method. I believe ‘shutdown.exe /r /f /t 0’ will work on the localhost. That said, if/when the reboot occurs the job queue would still be killed. The subsequent steps in the job queue will not ever be executed if the computer that is running BatchPatch is rebooted.

[doug]

-1047526912 == 0xC1900200

This code comes from the Windows upgrade/installation setup program, and it indicates that the computer is not eligible for the upgrade for one reason or another.

[doug]

Thanks for the feedback. We’ll consider this for a future build.

-Doug

[doug]

That’s great news! I’m glad it fixed things and appears to be working consistently now. Thanks for reporting back.

-Doug

[doug]

I can’t say for sure, but it sounds like PsExec is failing to execute properly on that target. This link should help you confirm if the failure is, in fact, with PsExec. Let me know what you determine after following the steps outlined in that link. Also I’d be interested to know how long it takes to fail from the time that it begins executing. The ‘All Messages’ column will have this information. Check the timestamp on ‘Windows Update: Executing BatchPatchRemoteAgent.exe…’ and compare it to the timestamp on ‘Windows Update: Error 1611: 3. Failure’. How many seconds pass before the failure?

Also one thing to check is to see if the services console on the target computer (start > run > services.msc) still lists the psexesvc service. Normally what should happen is psexec will automatically clean up after itself, and the psexesvc.exe process along with the psexesvc service will both disappear automatically from the target computer. However, if the issue is that it’s failing to clean up after itself, then we should see psexesvc service still exist in the services.msc console on the target. If that’s the case you can try manually removing the service from the target by running the following two commands in an administrator/elevated cmd prompt directly on the target computer:

sc.exe stop psexesvc

sc.exe delete psexesvc

It’s possible that this could completely resolve the issue. It’s also possible that this might only partially resolve the issue by allowing you to then run a single action that relies on PsExec before it stops working again, requiring you to manually remove the service after each successful run. And of course it’s also possible that it won’t do anything to resolve the issue at all.

Other things to try:

1. You could try the free paexec (it’s a psexec clone) instead of psexec. See if it produces any errors or if it works successfully. You can tell BP to use paexec by going to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’ and then enter the complete filepath to the paexec.exe. Alternatively you could just rename paexec.exe to psexec.exe as a test.

2. If you can find an older version of psexec (usually 1.98 or earlier) it’s possible that it could work if/when the latest version 2.11 does not work. We have seen a couple weird cases over the years where if there is a problem with v1.98 on a particular target, switching to v2.11 fixes the issue. And also vice versa where if there is a problem with v2.11 on a particular target, switching to v1.98 fixes the issue. We have also even seen a case where switching versions just for one run is enough to kickstart things such that you can then switch back to the other version and things continue to work. Odd, I know.

3. We have also seen a couple cases where even though there was only one target computer having problems with psexec, putting BatchPatch on a different computer solves it. That is to say that BP is running on computer X and having problems with only target Y (all other targets work fine). Putting BP on computer Z then works for all targets including target Y.

All that said, I actually don’t think we have ever seen 1611:3. 1611:2 is more what we would expect if psexec is having an issue, but I suspect that 1611:3 in your case is also related to psexec. To clarify, 1611 is a BatchPatch code that just indicates a generic failure during the attempt to remote execute. The number after the 1611 would normally be the remote process exit code, but in this case the 3 is not generated by the remote process (BatchPatchRemoteAgent.exe is the remote process but does not have any exit code 3 in it), so it’s either coming directly from PsExec or it’s coming from Windows. If it’s coming from Windows then it’s:

ERROR_PATH_NOT_FOUND

3 (0x3)

The system cannot find the path specified

However, this would still likely point to a problem with PsExec, though it’s unclear what the exact cause would be.

[Author]

Posts