Forum Replies Created
-
Posts
-
FYI regarding absolute vs relative paths: https://batchpatch.com/deploying-a-script-with-relative-instead-of-absolute-paths
You likely have a couple of different options:
1. BatchPatch Deployment:
*The file deploy will be set to point to
\\server01\install\Office365-SCCM\setup.exe*The parameters will then be set to the relative not absolute path of the configuration.xml file
like this:/configure configuration.xml
not like this/configure “\\server01\install\Office365-SCCM\configuration.xml”*The ‘Copy entire directory’ box will be checked/ticked
*When this deployment executes, BatchPatch will then copy the entire Office365-SCCM to the target computer, and then BatchPatch will execute the setup.exe on the target computer, and the configuration.xml file will be in that same Office365-SCCM directory, so it will be found without specifying an absolute path to the server location. In this case the deployment can be run under the ‘SYSTEM’ execution context (see ‘Tools > Settings > Remote Execution’
————————————-
2. It might be possible to run your command as-is (
“\\server01\install\Office365-SCCM\setup.exe” /configure “\\server01\install\Office365-SCCM\configuration.xml”) inside of a BatchPatch remote command. However, before you even attempt it, make sure your remote execution context is set to ‘Elevated token’. And if you are using the current/latest version of PsExec v2.33, then you’ll need to also have the ‘Interactive’ box checked/ticked. See ‘Tools > Settings > Remote Execution’.In a BatchPatch remote command, you should first try remote command 1/2. If no luck, you can also try 3/4. They work a bit differently under the hood, so there are some cases where one can work where the other can’t.
Thanks. We’ll take a look and consider it.
Deployment exit code 1619 is a MsiExec error, not a BatchPatch error. From the Microsoft documentation:”
ERROR_INSTALL_PACKAGE_OPEN_FAILED
1619
This installation package could not be opened. Verify that the package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer package.If you’re a customer with active support and you want to troubleshoot this further, we would need to see the full contents of the batch file, as well as a screenshot of the deployment configuration, and a HTML grid export. In that case, please contact us directly so that we can get those things from you.
What exactly did you have in mind when you talk about BatchPatch integration with Meshcentral? This is a pretty nebulous request. It’s hard to know what you’re really looking to be able to do that you can’t already do. To be honest, it’s probably unlikely that we would do such an integration (none of us here are familiar with Meshcentral), but it’s not something we could even really seriously consider without more of an understanding from you about what you’re looking to do with such an integration. Thanks.
No, that’s not an option. However, if your goal is to know when there are zero logged-on users on a target computer or to execute an action automatically when there are zero logged-on users, you can use the job queue. There are a bunch of different ways you could use it. Here are three of the possible ways, for example:
Job queue option 1:
*Wait for host to have zero logged-on users
*Send email notificationJob queue option 2:
*Wait for host to have zero logged-on users
*Set row colorJob queue option 3:
*Wait for host to have zero logged-on users
*Download and install updates + reboot if requiredOr you could do something else that similarly is triggered off of the “Wait for host to have zero logged-on users” option that is available in the job queue.
Windows servers in Azure aren’t any different from Windows servers in a different environment. We use BP on Azure servers all the time. ‘RPC server is unavailable’ generally indicates a firewall problem or a network communications issue of some kind. It essentially means that the BatchPatch computer is not getting a response from the target computer, and it’s the same error that you would get if you input a non-existent target computer into a row in the BP grid.
I would suggest that you try enabling the setting:
‘Tools > Settings > Remote Execution > Use PsExec -r switch’
You can use a name like BatchPatchExeSvc or similar. See if that resolves the issue for you. Normally the cause of 233 ERROR_PIPE_NOT_CONNECTED is due to anti-virus or HIPS or similar security software running on the target computer. It severs the connection that PsExec makes. If the above-mentioned setting ‘Use PsExec -r switch’ does not work, then I would suggest you either disable the AV software (or similar software) altogether, or try whitelisting the name that you use such as BatchPatchExeSvc or whichever name you have used.
The -102 error occurs when BP issues the “Search” command to the Windows Update Agent (WUA). The WUA in this case is returning 0x80072EE2 -2147012894 ERROR_INTERNET_TIMEOUT. A few things to note:
1. ERROR_INTERNET_TIMEOUT may not specifically be referring to the “internet”. It could potentially just be referring to a network call, in general. There isn’t a way to know for sure in this case.
2. The only time we have seen this error occur is in the case where a proxy was the cause, but that doesn’t mean that a proxy is the *only* cause of this error.
3. When running in offline mode, the search for updates is performed against the WsusScn2.cab file, not a WSUS, and not a Microsoft public Windows Update server. However, the WUA operates somewhat as a black box, and it’s hard to know what specifically it’s hiccuping on in this case. There are really only a few things that come to mind:
A. Check for dual scan.
Deciphering “Dual Scan” Behavior in Windows 10
B: Also check all Group Policies, particularly the ones related to Windows Update. I would suggest that if you have two computers that are seemingly identical in their configurations but with this problem occurring on one computer but not the other, it makes sense to do a full group policy audit on the two computers to compare the policies that are enabled. It seems like there is a decent chance that you’ll see immediately that there’s a particular policy that’s enabled on one computer but not the other and is causing the issue.
C: Check the WindowsUpdate.log to see if it reveals the culprit. There was a time when this log was much more useful than it tends to be nowadays, but it’s definitely still worth taking a look. ‘Actions > Windows Updates > View Windows Update Log’ Note, this might be a problem to retrieve because I believe the process it has to go through to convert the log into human-readable form requires it to be able to download symbols from the internet.
It’s not clear to me how this error could be possible under cached mode. Furthermore, while BatchPatch is capable of running on a computer and targeting itself (so BP computer is both source and target), BP does require that the computer have a NIC, even if it’s not connected to an actual network. I just did a test where I ran BatchPatch on a computer with no NIC (where I entered the computer that BatchPatch was running on as a target computer into a row in the BatchPatch grid), and the error that I see in BatchPatch is “Error 1800: Failed to create remote working directory” which is what we would expect because while BatchPatch does not need internet access to run in offline mode, it does still require a NIC in the computer and for the local network to be functional (because BatchPatch essentially will make network calls to the target computer in that case, even if the target computer is also the source computer), so it’s a network call to itself, effectively, when no network cable is even plugged in. That said, I don’t know how you could have gotten the error that you got in the situation that you described. If you have an active support contract with us, please reach out to us directly. We will want to see an HTML grid export of your grid that shows the entire context of what you’re doing. In this way we’ll be able to see exactly what’s going on in your situation and if there might be any other ways to accomplish what you’re hoping to do. It might simply not be possible, but I’m unsure at the moment with the limited info we have on the situation.
BatchPatch tries to detect the path of your PsExec, and somehow it detected ‘C:\Windows\SYSTEM32\ntdll.dll’. Not sure how that happened but go to ‘Tools > Settings > Remote Execution’ and modify the PsExec custom path there to point to the actual PsExec.exe on your system.
No, but there are a couple of ways to still get what you want.
1. You can use ‘Tools > Export’ to create an export file. Then in BP you can delete the saved entries that you hid. Then you can do another ‘Tools > Export’ to have just the visible entries in their own export file. Then you can re-import your original export file to get back to where you were before you started.
2. You can manually modify the export file (it’s xml, so is relatively simple to manually edit).
3. You can do the full export and then when your colleagues import on their computer have them delete the commands that they don’t need/want.
Great, thanks. Glad you got it worked out. I see that the ghacks link you posted above mentions some registry values that enable/disable the .NET Core updates from being available in Windows Update, so perhaps you just need to tweak those so that you can see them through Windows Update? Not sure. Worth looking at though. Take care.
This is a generic failure HRESULT value. I couldn’t tell you why it’s failing, but it could be just that it needs another try. Or it could be that you’d have to reinstall .NET MVC on there, or reboot the system and try again etc.
With regard to “I guess I’ll need to hunt for the .net core patch individually” I’m not sure if I understand what you mean.
The ‘Remote Agent Log’ column in BP is where you can see the details and reason for the update installation failure for the current Windows Update operation. You can view the historical log under ‘Actions > Windows Update > View BatchPatch.log’
Use ‘Actions > Windows updates > Opt-in to Microsoft Update (enable updates for other MS products)’ to turn on the setting for the selected target computer(s)
Then set BatchPatch server selection to use ‘Microsoft Update’ under ‘Tools > Settings > Windows Update > Server Selection > Microsoft Update’
.NET, in general, is normally considered part of Windows and typically does not require the setting to be enabled. It’s interesting that they would treat .NET Core differently. Kinda makes sense, but kinda doesn’t. Oh well. Good to know either way. Thanks.
You’re finding optional, “seeker” updates. In Windows 10/2019 build 1809 or newer, if you go to the Windows Update control panel on a machine that was recently updated, you may find additional optional updates available if you use the ‘Check for updates’ button. Microsoft releases these optional updates usually toward the end of the month. Microsoft says that while the updates do not contain any new functionality, they may contain fixes for specific outstanding issues. They are released through what is essentially a completely separate channel that is only available to “seekers” who use the ‘Check for updates’ button. At the time they are made available to “seekers” as optional updates they are not yet released to WSUS nor are they released to the normal automatic updates channel in ‘Windows Update’ or ‘Microsoft Update.’ However, Microsoft generally moves them from optional status into the normal release channel in the following month after they are initially released to only “seekers” who manually use the ‘Check for updates’ button in the Windows Update control panel.
In BatchPatch you can find these optional updates by selecting the checkbox under ‘Tools > Settings > Windows Update > Search for only optional software updates’
Unless you have a specific need for one of these optional updates, we generally do not recommend installing them. We believe that unless you have a specific need for a fix that is included in one of these updates, it usually makes the most sense to wait until the following month when Microsoft moves them from optional status to the normal deployment channels.
Thank you for the suggestion. We’ll consider this for a future build.
They released PsExec v2.33 yesterday (March 23, 2021). We believe the issue is now properly resolved in this version.
Thanks.
They released PsExec v2.33 yesterday (March 23, 2021). We believe the issue is now properly resolved in this version.
Thanks.
If you don’t see it then yes you should download the latest version. Use ‘Help > Check for updates’ in the app. The default behavior of the app is to notify you of any available update each time you launch the app, but maybe you disabled that.
See the column that says “Visible” with all of the checkboxes…
We’ll consider additional organization options for a future version
They’re all sortable by name already. I’m not sure what you’re doing. For example, go to ‘Actions > Deploy > Create modify’ and in the ‘Saved Deployments’ grid on the right side of the window you can organize your commands by sorting them and/or by making them either visible or invisible in the BatchPatch action menus.
Yes. If you select “Include Upgrades” to install a feature update, then BatchPatch will not be able to install any “regular” updates until you de-select the “Include Upgrades” box and re-select the other classifications. For the other classifications we generally recommend selecting the entire left-hand column of classifications:
Critical
Security
Definition
Updates
Update RollupsCorrect. If you leave it set to “Search for only optional software updates” then moving forward it’s not going to find any regular updates and will only find optional updates, which generally we do not recommend installing except in cases where you specifically need one like you did in this particular instance.
Excellent. You’re welcome.
Go to ‘Tools > Settings > Remote Execution’ and uncheck the ‘Interactive’ boxes. That should do it. Please let me know if it resolves the issue.
Thanks.
It looks like this is being delivered as an “optional update” through the normal Windows Update and Microsoft Update channels. This means that in addition to deploying the KB directly as a standalone .MSU file using the instructions at the link you posted above (using the standard BatchPatch deployment method), you can also use the normal Windows Update actions in BatchPatch to deploy this, but you’ll have to first go to ‘Tools > Settings > Windows Update’ and check the box for “Search for only optional software updates”
It appears that the current version 2.32 doesn’t actually fix the root issue, so while the original PoC for the LPE doesn’t work on 2.32, the researcher who found the issue was able to quickly modify his PoC to work on 2.32. That said, we believe Microsoft is now working on another update, so it might make sense to wait for that to be released, but of course this is up to you. As an alternative you could also use PaExec if you want. With PaExec, if you specify alternate credentials (not an issue when using integrated security), it obfuscates but does not encrypt them when sending them across the network. While this is not optimal, it’s also not necessarily a deal-breaker, but there’s a tradeoff to consider. You can read more on that tradeoff here: https://batchpatch.com/psexec-v2-1-all-network-communication-is-now-encrypted
As for updating… You can just replace the psexec.exe on your computer with the new one (though you should keep a backup of the old one too in case you want to revert to it). Or you can use ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’ to point BatchPatch to any version of PsExec or PaExec you want.
I don’t know how you have “downloaded and staged the install” …
However, I can tell you that BatchPatch can apply feature updates in two different ways, either by using the built-in Windows Update actions (make sure the update classification ‘Upgrades’ is checked under ‘Tools > Settings > Windows Update), or by using a deployment with the ISO media: