Forum Replies Created
-
Posts
-
Or are you saying you want the timer to appear on the BatchPatch computer? Or actually inside of BatchPatch? The short answer is no, there isn’t a built-in way to display a countdown-timer for each row inside of BatchPatch. But you could put a note inside of one of the notes columns for a BP row and put the end-time there for reference. Something like that anyway.
Or you could even conceivably maybe write a script that displays a countdown somehow, but that wouldn’t run inside of BP. So you would have to come up with a script that takes as its parameters hostname and start time. Then have that script display a countdown in a window. You’d then be able to call the script as a local command from inside of BP. Maybe something like that is possible. I’m not sure.
Countdown, no. But you can pop a message box on the target computers that says whatever you want, like “Maintenance will be ongoing until 11:45PM” etc.
‘Actions > Send message to logged-on users’
The filtering mechanism enables you to filter which of the available updates you want to be included or excluded. The key word here is “available.” That is, an update has to be presented as available to then be included or excluded by the filter. If an update is not presented as available, then it can’t be installed.
When Microsoft releases the new cumulative update for a given month, it replaces the cumulative update from the previous month. Similarly, the WsusScn2.cab file from November will contain the cumulative update from November. It won’t contain the cumulative update from October.
If you are in November and want to install the October cumulative update using offline mode, then you would need the WsusScn2.cab file from October. If you don’t have that file then you would need to manually obtain the desired updates from the Microsoft Catalog. After you download the desired updates from the catalog you can then use the ‘Deploy’ feature in BatchPatch to deploy that update to target computers.
In the future if you intend to always be working in offline mode a month behind, then just make sure to download and retain the WsusScn2.cab file from each month. Then when it comes time to perform the installation you can use the WsusScn2.cab file from the desired month.
You have a few options:
You can manually edit those fields directly in the grid by just typing into them. Also see ‘Grid > Enable/disable column editing’
You can use ‘Actions > Modify category, description, location, notes, color, etc.’
You can import the description field when using ‘Grid > Add hosts from directory’ by checking the ‘Import description field’ checkbox.
When using the ‘Grid > Add hosts’ dialog, or when importing a text file list of hosts into the grid (File > Import), the following are all valid (See ‘Help > Usage, tips, shortcuts’) :
The order of values entered must be the same as the order shown below:
# MAC
| NOTES
|| NOTES2
||| DESCRIPTION
|||| LOCATION
|U| USERNAME
|P| PASSWORD
|D| DOMAINSyntax examples for adding hosts with extra values: (Note it is not necessary to include all elements as long as the overall order of elements is preserved)
host1#1C6F65D56413
host2#1B3A65B54322|notes for host2
host3|notes for host3
host4|||Description information for host4||||Location information for host4No problem. If you observe anything that is inconsistent with what I said above, let me know. Thanks.
All grids in the service instance are auto-saved every 15 seconds as well as when the service stopped. That said, while what you are doing sounds like it should be ok for now, I can’t make any guarantees about the behavior that you can expect since you’re doing something that isn’t directly supported in the app. You should definitely test it to make sure it behaves the way that you want and are expecting. Also note that while you might get it working just fine for now, I also can’t make any guarantees about whether or not it will continue to work in future versions of the app (again, simply because you’re doing something that is not directly supported in the app, and it’s possible that we could make a change in a future version that breaks your existing automation).
-Doug
There is a setting in BatchPatch that controls where a BatchPatch search for updates will look when executed against a given target computer:
Tools > Settings > Windows Update > Server Selection
Default / Managed: Uses the target computer’s existing configuration to determine where to search for updates.
Windows Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes only Windows updates.
Microsoft Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes Windows updates AND updates for other Microsoft products. Before using Microsoft Update, target servers must be opted-in to the service. See Actions > Windows Updates > Opt-in…
However, if you have SCCM in your environment, it’s important to understand that SCCM utilizes its own WSUS server. Once SCCM takes control of a WSUS during the setup/configuration of SCCM, that WSUS can no longer be used by a non-SCCM application like BatchPatch to search for updates. So, if your target computers are configured via Group Policy to search for updates on a WSUS that is controlled by your SCCM server, then if you use BatchPatch to initiate a scan for available updates, and if BatchPatch’s Server Selection setting is set to Default/Managed, BatchPatch will always report No applicable updates. In order to use BatchPatch with a WSUS, the WSUS must be independent. It cannot be linked to or controlled by SCCM.
Based on what you have said, it seems like your BatchPatch server selection setting must currently be configured to either use Windows Update or Microsoft Update otherwise if BatchPatch’s server selection setting were set to Default/managed then we would not expect BatchPatch to find any available updates when searching for updates on a target computer that is configured to be using SCCM, even if there are updates available according to the SCCM console.
We have more details on BatchPatch in SCCM in environments here: Can BatchPatch Be Used to Install Windows Updates through SCCM?
We’ll look at making a similar tutorial soon that covers the use case that you are asking about.
Let me know how it goes.
This functionality does not currently exist built-in to the app, but we are considering it for a future version. In the meantime you can still accomplish this in BatchPatch by integrating a custom script. We have a blog posting that shows exactly how to do this with a service, but the script could be modified slightly to suit your needs and search for a process instead of a service.
BatchPatch Custom Script Integration – Wait for Service to be Running Before Proceeding to Next Step in Job QueueSomething is preventing BatchPatch from copying the file to the target computer.
I would suggest you first make sure that you are not attempting to have multiple rows in BatchPatch deploy to the same target computer at the same time. Based on what you’re seeing it seems like there could be something like that occurring. BatchPatch can’t copy the file to that location because the file is already there and in use. You said the file isn’t already there, so that makes me wonder if you have two rows trying to put it there at the same time, and neither is able to do it successfully as a result.
Next I would suggest rebooting both the BatchPatch computer and the target computer.
Next I would double-check the permissions on the target computer remote working directory (C:\Program Files\BatchPatch) and make sure something didn’t get hosed up that is preventing BatchPatch from doing what it needs to do. You can also delete the BatchPatch folder, if needed, and then let BatchPatch create it again from scratch.
Next I would check to see if something on the target computer is somehow locking the file as soon as BP starts copying it there. I’m not sure exactly how this could be possible until the file copy completes successfully, but maybe there is anti-virus or similar security software locking the file for a scan.
Those are all just best guesses. I can’t really say for sure exactly what the issue would be or would be caused by because the issue that you are encountering doesn’t appear to have anything specific to do with BatchPatch. It looks like something in the environment or your particular setup or configuration is creating the block/lock, so you’ll have to examine the computers and your setup/config to see if you can determine what it might be.
Thanks for the detailed explanation. The .PARTIAL file is what BatchPatch places in the BatchPatch local update cache directory while it is downloading the WsusScn2.cab file from Microsoft. When the download completes, the .PARTIAL file is renamed properly to WsusScn2.cab. If the download does not complete or fails for whatever reason, the .PARTIAL file is deleted. It’s unclear exactly what happened in your case, but clearly something just didn’t work properly. Seems like maybe your internet-connected computer just has a poor internet connection? Maybe lots of packet loss or something that is causing the connection to be severed/terminated? I don’t know. Under normal circumstances any type of error/failure during download would result in the .PARTIAL file being deleted, but perhaps something in your case created some weird edge case where things didn’t function properly. It’s hard to say. And you are correct that we would definitely be hearing from other people and would be able to reproduce the issue here if there were a significant issue with the download code, but it’s the same download code that has been in the software for many years and used by tons of people without issues, so at the moment all signs point to something in your environment or internet connection being the culprit for what you’re experiencing. I’m glad you were able to get things working for now. If you make any major discoveries about what is going on, feel free to post back here to let us know. Thanks.
1. Regarding the errors when attempting to download the file in BatchPatch… We occasionally see errors or hear of similar errors from other users. All indications generally always point to Microsoft servers. Any issue that we have ever seen ourselves or had reports of is always transient. Usually the only time we see any such errors on Patch Tuesday when it’s very soon after Microsoft has published the WsusScn2.cab file for the month. Typically we do not see or hear of any issues late in the month.
2. With regard to the difference between downloading manually and downloading through BP. There shouldn’t be any difference between these methods as we are just doing a standard file download inside the software. However, if you are using a proxy for internet access, there is a good chance that it could explain the difference between doing a manual download vs downloading inside of BP. That is, the proxy settings may not be active for the BP download even though they are active for the manual download. See link below where it describes WinHTTP proxy configuration using NETSH.
Using BatchPatch with an Enterprise Web Proxy
3. If you manually downloaded the WsusScn2.cab file, and if it has a valid digital signature, then it should work fine in BatchPatch. Make sure you have UNchecked the setting ‘Do not download newest wsusscn2.cab file if any version is already cached’ in ‘Tools > Settings > Windows Update’. If that setting is enabled, then the new WsusScn2.cab file that you manually downloaded will not get copied to target computers if the previous corrupt version is already on the target computers.
4. Make sure you are putting the WsusScn2.cab file in the correct place. Make sure it is in the directory where BP is looking for it, which is the ‘Local update cache directory’ that is defined under ‘Tools > Settings > Windows Update’.
5. If you receive the error again look at the target computer’s remote working directory (default is C:\Program Files\BatchPatch) and make sure that it has the latest WsusScn2.cab file with valid signature and isn’t for some reason still caching the older corrupt version. Unchecking the setting described above in step 3 would/should resolve any such issue, but I don’t know if possibly there is something else going on or going wrong here. You can certainly always then just delete the WsusScn2.cab file from the target computer’s working directory so that BatchPatch freshly copies the file from the local update cache directory.
You can launch an .exe remotely, but it will *not* be visible to the user who is logged-on to the target computer.
1. Set the ‘Remote Execution Context’ under ‘Tools > Settings > Remote Execution’ to ‘Elevated token + Interactive’ for ‘Remote process/command’
2. Create a ‘Remote process/command 1/2’ in BatchPatch under ‘Actions > Execute remote process/command’ with the following syntax:
-d "C:\Program Files\Google\Chrome\Application\chrome.exe"The -d is a PsExec switch ‘Don’t wait for process to terminate’. If you don’t use -d then BatchPatch will remain ‘Executing’ until the chrome.exe process is terminated on the target, or until the BatchPatchExeSvc/PsExeSvc service is terminated on the target.
As mentioned previously this will launch the exe on the target computer, but the exe will not be visible to the logged-on user, so it doesn’t really do much for you since I assume you want to launch Chrome so that it is visible to the logged-on user and so that the logged-on user can interact with it.
Are you using the latest version of BatchPatch?
This sounds like a bug, but I’m not able to reproduce it. Feel free to contact us directly to share with us a .bps file where this happens. Then we can try to reproduce it. My guess is that if you are using the latest version of BP, then this bug/issue is probably somehow connected to the particular .bps/grid. That is, I can’t reproduce it in my test grid here now, but I suspect that if I try with your grid that the problem will manifest, and then we’ll be able to track down the cause and fix it. If you are not using the latest version of BP, then first try the latest version and see if you still have the issue.
Start-Process is a PowerShell cmdlet, and so it must be executed at a PowerShell prompt, but the BatchPatch remote command features execute at the Windows command prompt, so you must invoke PowerShell first for PowerShell cmdlets to be executed. Tutorial here:
https://batchpatch.com/executing-powershell-commands-on-remote-computers-with-batchpatch
With regard to launching Chrome or any other interactive process or application, you need to be aware of a couple of things.
1. The remote process will be launched in the context of the user account that you use the launch it. This won’t necessarily be the account that is logged-on interactively at the target computer. The process won’t be visible/interactive if the accounts don’t match.
2. Even if the accounts match, the process will generally still be hidden, though in some cases for some processes you might be able to launch them interactively if you use the ‘interactive’ switch. See ‘Tools > Settings > Remote Execution’ and set ‘Elevated token + Interactive’. This is the only remote execution context setting for what you are trying to do that *might* work. It might not though, so you’ll need to test.
Hello – Thank you for your feedback. I have a couple of questions.
1. If you are using SCCM then why do you need to use BatchPatch to control SCCM? Wouldn’t SCCM be what you would use to control SCCM?
2. In order for us to consider any feature suggestions we would need for you to submit an actual feature suggestion. I realize you are asking for more in-depth integration with SCCM, but if we were to consider something we would ask you to please explain exactly what it is that you would like for BatchPatch to do with SCCM.
Thanks.
If you read the log contents you can see that each update is skipped for the same reason:
skipped> Intel Corporation – SCSIAdapter – 17.11.0.1000 – Reason: UpdateClassification-Drivers
Go to ‘Tools > Settings > Windows Update’ and check the “Include ‘Drivers'” box in the Update Classification Filtering section.
This issue is explained here:
Either disable cached mode as described at the above link, or you can just install the update using an alternate method as described at the link below:
https://batchpatch.com/remotely-deploying-windows-feature-update-version-21h2-to-numerous-computers
Hello –
First, I would note that nothing in BatchPatch has changed. The 3 workarounds provided in the link that you included in your posting are still the same 3 workarounds that you can use today. The issue itself has not been “fixed” as there is no way for us to “fix” it currently.
Second, I would note that online cached mode is really not a recommended mode. If you’re able to use online cached mode, then you really should just use online standard mode (non-cached), and then you don’t need to worry about this issue in the first place. If you have access to the internet or access to a WSUS then you generally should be using standard online mode (with NO caching). If you do not have access to the internet or a WSUS, then you would use offline mode. We do not generally recommend using online cached mode.
Third, the job queue can check for a complete failure to download updates, but it cannot check for a “success with errors” which is generally what would happen if the overall operation completed, but an individual download was not able to complete, like in the scenario you are describing. That said, you do have a different option that you could use in the job queue called “If most recent ‘Check for available updates’ found any updates, goto label:X”. So instead of checking for the inability to download a particular update, you could just do a new check for updates, and if it finds any updates available, then it means not all updates have been isntalled yet. And in that case you could then switch to the other mode and do a new download/install to get that missing update installed.
-Doug
I’m sorry to say that I’m not sure what could be causing this in your environment. Generally speaking this is something we would really only expect to see if an AV or HIPS or similar security or endpoint protection software was involved and was severing the connection in the middle of processing. If you haven’t already done so, I would suggest trying to run BP from a different source computer, just to ensure that there isn’t something weird going on with the particular BP computer. However, you said that things work for a few targets, so it could conceivably also be some weird issue on the problematic targets and not an issue with the BP machine. Unfortunately it’s very tough to guess at what else it might be.
The Windows Update control panel is listing that as an optional update, but in BatchPatch you are searching for only “Important” and “Recommended.” You would need to change the search to all “software updates” or possibly “optional software” in BatchPatch to see the feature update appear as available.
This link covers all of the reasons why there might be a discrepancy between what BatchPatch reports as available and what you see as available in the Windows Update control panel on a given computer:
https://batchpatch.com/batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updatesThis link covers how to install feature updates with BatchPatch. There are two methods. If having trouble with one, try the other:
https://batchpatch.com/remotely-deploying-windows-feature-update-version-21h2-to-numerous-computersWhich OS is installed/running on the BatchPatch host and which OS is running on the target? Please be as specific as possible with version numbers, build numbers, service packs etc. You can actually see this info using BatchPatch under ‘Actions > Get Info > Get OS Version’
Which version of PsExec are you using?
Is ‘Tools > Settings > Use PsExec -r switch’ in BatchPatch enabled?
Thanks
Have a look here: Troubleshooting Errors 1611: 64 , 1620: 64 , 1611: 2250 , 1620: 2250
Sounds good. However, just to be clear, when you perform a BatchPatch Deployment operation with logged output, it creates the deployment temp files in a different folder with different name. The default location for deployment logs is C:\Program Files\BatchPatch\deployment (this is defined under ‘Actions > Deploy > Target working directory’. When you select ‘Retrieve console output’ in a BatchPatch deployment, it then creates files in that deployment working directory like this: BatchPatchDeploymentOutputXXXXXXXXX.log. So, since you mentioned specifically BatchPatchRemoteProcessXXXXXXXXX.log, and since a Windows feature upgrade would normally be performed with the BatchPatch “Deploy” feature, not with the “Remote command (logged output)” action, you should probably double-check for the cause of these files since you have BatchPatchRemoteProcessXXXXXXXXX.log files, not BatchPatchDeploymentOutputXXXXXXXXX.log files.
The default working directory on target computers is C:\Program Files\BatchPatch
The default location can be modified under ‘Tools > Settings > Remote Execution > Remote working directory’. It sounds like you have modified yours to be C:\Batchpatch, so that is what I will reference for the rest of this posting.
Each time you execute a “Remote command (logged output)” in BatchPatch, it creates a temporary file C:\Batchpatch\BatchPatchRemoteProcessOutputXXXXXXXXX.log where XXXXXXXXX is a random 9-digit number. When execution of that “Remote command (logged output)” is complete, that file is deleted.
You said that you have 20-30GB of files, so that itself is a red flag that indicates to me that you have attempted in the past (or perhaps currently) to execute a “Remote command (logged output)” that produces a massive output, perhaps due to an infinite loop in your command/script, or perhaps not. In any case, the first thing you need to do is examine your process to figure out what would be creating such a large output. In 99% of cases when a BatchPatch user runs a BatchPatch “Remote command (logged output)” the output is tiny because it’s just the output of a simple command like “IPCONFIG” or whatever. Second, BatchPatch does always delete these temporary files upon completion of the “Remote command (logged output)” so if you are seeing these files there, then it means that there was some kind of problem that prevented them from being deleted. One possible cause for them not being deleted is because BatchPatch is being closed while the “Remote command (logged output)” is still running for a given row/host. The other cause for them not being deleted is because they are so excessively large that somehow the deletion process itself is failing.
The bottom line is that if you are seeing very large files there, then you are running (or have in the past) run “Remote command (logged output)” commands/scripts that are producing massive output. You’ll need/want to address this by modifying whatever “Remote command (logged output)” commands/scripts you are running. In the meantime you should then also delete those large files, as they are temp files. The fact that they are still present indicates that there was a problem of some kind that prevented them from being deleted.
I don’t think Microsoft includes definition updates in the WsusScn2.cab file for offline updating. If they do include it, then BatchPatch will install it, but based on my recollection and a quick test here, they do not include it. I also tested installing the latest cumulative update to see if it included an update for the virus definitions, but it does not appear to include it.
That said, to deploy the latest virus definitions to offline computers you can manually download the definitions file from Microsoft, and then you can use the deployment feature in BatchPatch to deploy it to your target systems.
You can get the updates at the link below. The file is delivered as mpam-fe.exe. You create a standard deployment in BatchPatch ‘Actions > Deploy’, like my screenshot below.
Microsoft site to download the latest definitions:
https://www.microsoft.com/en-us/wdsi/defenderupdates
Defender automatically installs definition updates daily on its own without BatchPatch. However, BatchPatch will also install definition updates when they are available and have not yet been installed by Defender. You would need the checkbox for ‘Include “Definition updates”‘ checked in the BatchPatch settings.
The client itself would be a software update, not a definition update. My guess is that Microsoft could deliver it under any of the update classifications ‘Critical’, ‘Security’, ‘Updates’, or ‘Update Rollups’ depending on the particular reason the update was published. Generally speaking in most cases you should leave all of the left-side update classification filter boxes checked in the BP settings.
I believe the 10/2016/2019 option will work for 11/2022 also. Please try it and let me know if it works or not. Thanks for highlighting. We need to update the GUI there.