Forum Replies Created
-
Posts
-
You might also consider sending them a message popup (actions > send message…) to notify them that you’re about to perform the upgrade so that they don’t reboot or shutdown while it’s in progress, which could render the machine unbootable.
Yes, that’s possible.
First let’s just quickly go through the other ways that you can install feature updates.
1. Under ‘Tools > Settings > Windows Update’ tick the ‘Include “Upgrades”‘ checkbox. Now, if your target computer is being offered a feature update either by your local WSUS or by Windows Update or Microsoft Update, it will be downloaded/installed the next time you use ‘Download and install updates’ (or similar action) in BatchPatch.
2. You can deploy a feature update by extracting the ISO, and then executing a BatchPatch deployment as outlined here: https://batchpatch.com/remotely-deploying-windows-feature-update-version-20h2-the-october-2020-update-to-numerous-computers
——————————-
——————————-Now, to answer your question, the BatchPatch ISO deployment method is essentially the two steps that you described, but it’s combined into one action. So when you setup a BatchPatch deployment and then execute it, BatchPatch first copies the setup files to the remote system, and then it executes the installation command. If you want to separate the copying of the files from the execution of the installation command, you can do that.
1. Extract your ISO contents to a folder on the BatchPatch computer. For the sake of this example let’s call that C:\Extracted_ISO_setup_files.
2. Create a BatchPatch copy job/command under ‘Actions > Copy file / folder’. After you execute the copy job you’ll have C:\Extracted_ISO_setup_files on the target computer(s).
3. Create and execute a custom remote command in BatchPatch with the following syntax. FYI it’s probably best to use the SYSTEM remote execution context for this command (you can adjust the remote execution context under ‘Tools > Settings > Remote Execution’). The remote command to execute to perform the installation when the files already exist on the target computer in the specified folder:
"C:\Extracted_ISO_setup_files\setup.exe" /auto upgrade /quietNo worries. The “local” is local to the computer where you’re running BP. I totally understand how you could interpret it in the opposite way.
BatchPatch local command runs the command on the BatchPatch computer, not the target computer. BatchPatch remote command runs the command on the target computer. So, you’re comparing the results from the BatchPatch computer to the target computer instead of target computer to target computer.
Strange. Thanks.
While I’m glad you’re making progress, I would love to understand what is actually going on here.
Running as admin is only required for when targeting the local computer in the grid. For remote computers this is not required. Were you trying to use “opt-in” on the BP computer all along and not on a remote computer? I’m a bit confused because this wouldn’t make sense. Also when you use ‘opt-in’ regardless of whether BP is running as admin or not, it will give you feedback. And when you say there is now feedback in the logs, what is the feedback that now appears that was not appearing before? And what was there previously?
The more information that you can provide to me, the better we will be able to potentially address this issue (if there actually is an issue) in a future version. At the moment it sounds like something is not right, so I’m hoping you can help me understand exactly what’s going on because we would like to make this experience better for end users in a future version, and we can’t do that without understanding what is happening.
Thanks!
We have never heard of any issues with opt-in not working. Can you answer the following questions so that we can try to figure out what’s going on here?
1. What version of BP are you running? Please provide full version number that appears under ‘Help > About’
2. What version of PsExec are you using? Right-click on the psexec.exe file, then view ‘Properties > Details > File version’
3. What OS version is BatchPatch running on? Please put the BatchPatch host computer name into the BatchPatch grid as a target (so you’ll be targeting the local computer) and then use ‘Actions > Get information > Get OS version’, and then paste the complete result here.
4. What OS version is the target computer where this problem is occurring? Again please use ‘Actions > Get information > Get OS version’ but this time for the target computer(s).
5. You mentioned that Opt-in was not working on multiple/numerous computers, and the problem is not limited to just the server core OS. Can you check a few of the problematic machines that were running the full/gui version of Windows. Are they all running the same OS as the server core target? Or do we have a variety of target OS versions having the issue?
6. When you run the opt-in command in BatchPatch, what is the result that is reported in the ‘All Messages’ column? Can you paste the verbatim result text here?
7. Under ‘Tools > Settings > Remote Execution’ what do you have the ‘Remote Execution Context’ values set to for ‘Remote process/command’ ? SYSTEM or Elevated token? Is ‘Interactive’ selected too or not?
Thanks,
DougThe ‘Remote Execution Context’ setting is divided into 4 subsections:
**Get information (user-defined commands)
**Remote process/command
**Remote process/command (logged output)
**DeploymentEach of the above 4 settings applies to that particular type of command. That is, the ‘Deployment’ section of ‘Remote Execution Context’ applies to when you execute a BatchPatch deployment that you have created. The ‘Remote process/command (logged output)’ section of ‘Remote Execution Context’ applies to when you execute a ‘Remote process/command (logged output)’ that you have created. And so on.
Starting with PsExec v2.33, ‘Elevated token’ will *only* work when ‘Interactive’ is also checked/ticked. SYSTEM does not require ‘Interactive’ to be checked/ticked.
@waldog – The resolution I posted above is definitely correct for your situation. I would suggest going back and reviewing the setting again. Right now BatchPatch thinks your PsExec.exe is C:\Windows\SYSTEM32\ntdll.dll. You need to modify ‘Tools > Settings > Remote Execution’ to point to the actual PsExec.exe on your system. I would suggest putting PsExec.exe into C:\Windows, and then put C:\Windows\PsExec.exe into the setting noted above. Make sure to save the setting instead of canceling/Xing the window. Also make sure you apply it to the correct user profile. That is, if you run BatchPatch as userA, but you make the setting change after launching BatchPatch in the context of userB, then only userB will have the setting change.
Yeah it would be a similar thing… you need the uninstall command for the particular app. And then you can execute that command with BatchPatch.
First, you should upgrade to v2.33 of psexec. It mitigates a potential pipe squatting attack. BatchPatch popped a message about this in the latest version, so you would have been notified but perhaps just closed the message quickly without realizing. Or maybe you didn’t update your BatchPatch to the latest yet.
Second, we have gone back and forth on what is the best default setting for all four of those values, and we have changed it a couple of times. Right now I would suggest putting them all on ‘SYSTEM.’ And then if you have a specific need to change one (or more of them), then do that as needed. Deployments will obey the ‘Deployment’ setting. Remote process/command (1/2) will obey the ‘Remote process/command’ setting. Remote process/command (3/4) logged output will obey the ‘Remote process/command logged output setting.
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.