Forum Replies Created
-
Posts
-
Go to ‘Tools > Settings > Remote Execution > Remote Execution Context > Deployment’ and change it to ‘Elevated token’ + ‘Interactive’.
Hmmm… I can’t reproduce the column issue. I would suggest you make sure all instance of batchpatch.exe are closed on your computer. Then load your grid and adjust the column sizes as desired. Close BatchPatch. Then re-open BP or your grid file, and it should be all set. If for some reason it’s not, in that second opening, reset your columns once more. Then close BP and reopen it, and it should stick.
In ‘Tools > Settings > Grid Preferences’ if you disable “Allow BatchPatch to auto-resize column widths”, then the column widths will be remembered. However, it’s a global setting, not a per-grid setting, so whichever grid is closed last is the sizing that will be remembered on next launch. If you want everything to be identical to before closing BP, then you’ll prob also want to disable all or most of the other settings there too for window and column sizing. That said, we recommend leaving all of the settings enabled because BatchPatch will then automatically resize the columns as needed based on the column contents. There really shouldn’t be any need to be manually resizing the “Ping Reply” column or “Last Boot Time” etc because if you use the default settings then those columns will be properly sized for you by the application to fit whatever contents are in those cells.
Regarding the password thing, we’ll consider this for a future build. Thanks.
I’m not quite sure what you’re describing. However, for further support with licensing issues please reach out to support directly.
The scheduled tasks are saved in the BatchPatch grid file itself. If you don’t save the BatchPatch grid (File > Save), the scheduled tasks are not saved anywhere. The scheduled tasks will only run if the grid is loaded into BatchPatch and the scheduler is enabled, OR if you have enabled BatchPatch to run as a service (Tools > Run BP as a service), and you have sent the desired BatchPatch grids to run in the service instance.
There is no “Scheduled task file.” I’m not sure what you’re trying to do.
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.