Forum Replies Created
-
Posts
-
I’m not certain what’s happening here. I would need to see more details. You can send us an HTML export (File > Export grid to HTML), as well as a screenshot of ‘Tools > Settings > Windows Update’ for review by reaching out at the BatchPatch contact form.
Thanks
For computers that will act as both the source BatchPatch computer AND the target computer, the updates will need to be put in the source location, which is on the BatchPatch computer in the directory defined under ‘Tools > Settings > Windows Update > Local Update Cache directory’
Let me try to explain again more clearly:
1. The BatchPatch cache directory on the BatchPatch computer is defined under ‘Tools > Settings > Windows Update > Local Update Cache directory’. This can be any folder/location of your choosing on the BatchPatch computer. This is where you will put the update files that you have downloaded previously on a different computer. Just make sure you put the update files in the folder that is defined under ‘Tools > Settings > Windows Update > Local Update Cache directory’.
2. The target computer cache directory is defined under ‘Tools > Settings > Remote Execution > Remote working directory’, which I recommend leaving at the default setting of C:\Program Files\BatchPatch, which will cause the cache directory to be created as C:\Program Files\BatchPatch\cache. This setting is ONLY defined in BatchPatch. There are no settings stored on the target computers. BatchPatch uses the directory defined in this setting when BatchPatch is executing actions on target computers. You will NOT copy the cache folder to all systems. You will ONLY copy the cache folder to the BatchPatch computer. Then when the BatchPatch action is executed to download/install updates on target systems using offline mode, BatchPatch will then handle copying the files from its local cache directory to the cache directories of all target computers.
This is all explained in detail in the scenario 4 and 5 tutorials that you will be following at https://batchpatch.com/cached-mode-and-offline-updates
I would suggest you download the free evaluation software from our website, and then you can simply follow the tutorials yourself to see how it works. It’s pretty simple and straightforward once you start doing it, and so I think you will answer most or all of your questions by simply performing the operations. https://batchpatch.com/download
Yes, this is a BatchPatch scheduled task. See the tutorial linked above for details.
In BatchPatch under ‘Tools > Settings > Remote Execution’ you can choose the location for the BatchPatch working directory on target computers. I recommend leaving it set to the default value, which is C:\Program Files\BatchPatch. The cache folder will get created by BatchPatch under that path as C:\Program Files\BatchPatch\cache
I forgot to include this link in the previous posting: Creating a Recurring Scheduled Task in BatchPatch
Hello –
1. No, this is not currently possible. We will consider it for a future build.
2. Yes, you can use a standard recurring scheduled task for this. However, note that in order for this to work as desired/expected, you would have to separately handle getting not only the new updates into the cache directory before the scheduled task runs, but you would also have to include with the new updates the new WsusScn2.cab file.
0x80244007 -2145107961 WU_E_PT_SOAPCLIENT_SOAPFAULT
a SOAP Fault was returned by the server. See the more specific WU_E_PT_SOAP_xxxx mappings when a SOAP fault was returned by the server.
SOAP client failed because there was a SOAP fault for reasons of WU_E_PT_SOAP_* error codes.This is probably an issue on your WSUS.
We discussed one possible cause here:
https://batchpatch.com/forums/x/topic/102-failed-to-execute-the-search-hresult-2145107961/Microsoft discusses another possible cause here:
https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/error-80244007-when-wsus-client-scans-updatesAside from the two possible solutions mentioned above, other options to fix or workaround the issue might include:
-Cleanup your WSUS database. This might resolve it.
-Configure BatchPatch to get updates from Windows Update instead of your local WSUS (‘Tools > Settings > Windows Update > Server Selection’). This doesn’t solve the issue with the WSUS but it should work to get the recent updates installed. It’s also possible that once the recent updates are installed that the machines will once again be able to properly communicate with the WSUS without modifying/fixing the WSUS itself.
I don’t have this Microsoft software installed to see what it looks like in the registry, but in the example you’re describing it sounds like DisplayName is the registry value that you’re searching for. The action that you’re using in the job queue can tell you whether or not DisplayName exists. It can’t tell you what DisplayName is actually set to. What it’s set to is considered the ‘value data’, but the value itself is DisplayName. “If specified registry value exists, goto label:X’ can be used to goto label:X if DisplayName exists, regardless of what the value data for DisplayName is.
There is no “Check if Registry Value” exists option in BatchPatch, so I’m not sure specifically which BatchPatch action you’re using. There are registry actions in BatchPatch, of course, but there are several different ones, and none of them is named that exactly, so I don’t know specifically where you are entering your registry path. That said, the first thing that I would ask you is are you inputting a path to a registry key but using one of the registry value options in BatchPatch? To be clear, a key is a key, and a value is a value. If you are searching for a registry key, you have to use a registry key function in BatchPatch. If you are searching for a registry value, you have to use a registry value function in BatchPatch.
Are you using integrated security or alternate credentials in the rows that connect to target computers? After just looking at the tutorial and script, I think it would only work for integrated security and would not work if the account that is being used to run the BatchPatch.exe does not also have permissions on the target computers.
We’ll look at updating the tutorial at some point in the future to account for this, but the best workaround right now is to NOT write the output to a single local file (because you won’t be able to with this method), but instead create a BatchPatch deployment that deploys the VBS script to the target computer. In the ‘Deployment’ configuration window check the box that says “Retrieve console output”, and type $computer in the parameters field. Then when you execute the deployment, the script will be copied to the target computer for execution, and the results will be reported in BatchPatch in the ‘Deployment output log’ column.
Remote command 1/2 provides NO logged output. It just executes the command.
Remote command 3/4 provides logged output and is how you would see the results of the command.
That said, I think in order to see the currently logged on user’s information you would have to either specify alternate logon credentials in BatchPatch to run the command with the account of the currently logged on user, or you would have to specify the account to connect to inside of the ‘net use’ command, as described in the documentation for ‘net use’
‘Get list of installed programs’ looks in the following places:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\UninstallUsually people just create a new row for a new host name. However, you can modify it if you want: ‘Grid > Enable/disable column editing‘
As mentioned in the previous posting, it’s the psexec service running with a custom name. There is nothing different about it now as compared to the previous version of BatchPatch because it’s not part of BatchPatch but rather is the psexec service component that is created by psexec. Approximately a year ago the version of BatchPatch that we released changed the default setting to use a custom name instead of the default psexesvc.exe, but if you have not updated your BatchPatch in the past year, then it’s possible that with this current BatchPatch it’s the first time you’ve had a custom name applied, and perhaps the custom name BatchPatchExeSvc-servername.exe as compared to the old name psexesvc.exe is what triggered the detection. I could only guess.
PsExec is sometimes detected by anti-malware apps because malware apps like to use psexec, and many anti-malware apps are not being particularly intelligent about what they are flagging. It would be kind of like flagging all red cars as being malicious just because some criminals like to drive red cars. But they’re just red cars and have nothing to do with the malice of the drivers.
There is no list. That file is the psexec service set to run with a custom name assigned under ‘Tools > Settings > Remote Execution’. That file needs to be allowed to run/execute. It’s not likely that anything else would trigger your anti-malware software.
Try ‘Help > Check for updates > View change log’
This ‘View change log’ link is in the same window that automatically popped up to notify you that there was an update available.
No worries. I’m not sure how that opt-in status could have been changed on its own unless possibly the act of installing a feature update or some other update might have somehow reset it. We haven’t heard of any instances of something like that happening, but it’s the only thing I can think of that might make sense (unless someone else has access to the machine and opted-out manually at the Windows Update control panel.
The full error text that appears in the ‘All Messages’ column contains the resolution:
Error -115: Failed to execute the search. Unknown update service. If attempting to use ‘Microsoft Update’ you must first opt-in to the service. See ‘Actions > Windows Updates > Opt-in…’
No problem. Glad you got it working.
The ‘Deployment’ column only shows the deployment configuration, not the status of execution. The ‘All Messages’ column turns blue on exit code 0, but if there was a different exit code then it would not be blue. If any subsequent action was executed after the exit code 0, then it would not be blue either because whatever it printed to the ‘All Messages’ column would be black (or orange in the case of an error).
What do you see in the ‘All Messages’ column?
Well… have you actually executed/initiated the deployment? The deployment field shows the configuration of the deployment that you pasted, but the ‘All Messages’ column is where the status/activity will be reported. You need to actually execute the deployment in order for it to begin, and it kinda sounds like maybe you just applied the deployment to the row but you didn’t actually initiate execution.
Create a local command in BatchPatch (‘Actions > Execute local process/command > Create/modify local commands‘) with the following syntax:
cmd.exe /c start \\$computer\c$or
cmd.exe /c start \\$computer\SomeOtherFolderYou will then see your local command under ‘Actions > Execute local process/command > Execute saved local command‘. You can also add a toolstrip button with ‘Tools > Customize visible toolstrip buttons‘. Just scroll to the bottom of the ‘Customize Toolstrip’ window and check the box next to the local command that you created.
Use remote desktop to connect to the jump server, and then use BatchPatch inside the remote desktop window.
If the connection drops enough to break the download, it is not resumable, unfortunately.
BatchPatch first does a ping, if the ping is successful, it does a WMI query. If the WMI query is successful, BP considers the target host to be online.
The method for how you determine that a machine is online is probably less important than how you determine that the machine has first actually gone offline and then come back online. If you want to speed up your current process so that you are not always waiting the full 5 minutes in between reboots, if you’re dealing with physical hosts then I would suggest that you consider the job queue option for “Wait for host to go offline and come back online.” If you’re dealing with VMs that can reboot extremely quickly, then this item can be problematic. The issue is that if a reboot of a VM occurs within just several seconds, which isn’t uncommon, then the machine won’t be successfully detected by BP as having ever gone offline. For physical machines, which generally take many seconds (or even minutes) to perform their reboot process, we have not ever observed this to be an issue.
Another way to do this that you could consider is using a custom script that you write that checks the last bootup time property on the target computer before it executes a reboot, and then checks the last bootup time property again on the machine after that. The script can then compare them to determine if the machine has definitely been rebooted and is now back online. We might add something like this in a future version of BP, but at the moment you’d have to script it out yourself.
That sounds right:
0x80244022 -2145107934 SUS_E_PT_HTTP_STATUS_SERVICE_UNAVAIL Http status 503 - temporarily overloadedMy first question is what is the purpose of having step 2? What is the advantage to checking for a logged-on user and logging that user off before you reboot in the following step? And what is the purpose for even checking pending reboot if you’re going to reboot no matter what in step 3? Why not just skip those steps? In the queue you posted they appear to have no real utility that I can discern. What I mean is that a reboot will automatically log the user off anyway, so what advantage is there to logging the user off first and then doing the reboot? For what you have described it seems sufficient to simply do the reboot.
Additionally, consider that what you’re describing with first checking to see if anyone is logged on before executing a logoff procedure would also be unnecessary. That is, if you really want to perform a logoff operation separately from a reboot, you could simply execute a logoff command without ever checking to see if anyone is logged-on. Simply executing a logoff command would be sufficient. It wouldn’t matter whether or not someone was logged on or not.
You can use the following syntax inside of a BatchPatch remote command to perform a standard logoff:
powershell.exe -ExecutionPolicy Bypass -command "(Get-WmiObject -Class Win32_OperatingSystem).Win32Shutdown(0)"or a forced logoff:
powershell.exe -ExecutionPolicy Bypass -command "(Get-WmiObject -Class Win32_OperatingSystem).Win32Shutdown(4)"