Forum Replies Created
-
Posts
-
BatchPatch can work for any computers that appear to be on the same LAN as the BatchPatch computer. When working from home this is typically accomplished through the use of a VPN. We’re not able to provide specific instructions for configuring your VPN or your VPN firewall, as they can vary significantly, so this would be up to you and your networking team. However, here are some general guidelines on how BatchPatch port and firewall requirements.
No, but what you can do instead is apply a color to the rows instead of disabling. Use ‘Actions > Modify category, description, location, notes, color, etc.’ or set the row color inside of the job queue with ‘Set row color:X’ in the job queue ‘Special’ menu. Then if you make the ‘Row Color (RGB)’ column visible, you can sort by row color.
There are a few things to note here:
1. The service is created by psexec, and normally it is also auto-removed by psexec when it completes. There are edge cases where for unknown reasons, psexec is not able to successfully remove the service. Usually when this happens, psexec isn’t able to function properly in the first place, but in other cases it’s able to function properly with the exception of the service removal aspect.
2. There was a brief period of a few weeks where the default behavior of BatchPatch was to append a random suffix to each execution such that a new service name would be used. We have since modified BP to no longer use this “append random suffix” option as the default option, and we reverted the default setting for all users. However, it’s possible that even if you got the new version of BP, BP wasn’t able to revert the setting for one reason or another on your instance.
At this time I would recommend a couple of things:
A. Make sure you’re using the latest version of psexec.
B. Go to ‘Tools > Settings > Remote Execution’ and untick the “append random string” option. This will cause all actions to use the same remote service name. This way even if it’s not deleted successfully every time, you will only end up with a single service that stays there and gets reused, instead of numerous orphaned ones that are never reused and only keep growing in number.
C. You can use the following syntax inside of a BatchPatch “Remote command logged output” to list the orphaned services and remove them. Just make sure to use this cautiously/carefully. Make sure it’s deleting the services that you want. The first command will find/list all of the services that contain BatchPatchExeSvc in their name. The second one will perform the same query but then also execute a deletion command for each one too.
Get list of orphaned services:
powershell.exe -ExecutionPolicy Bypass -command "get-service '*BatchPatchExeSvc*'"Delete orphaned services:
powershell.exe -ExecutionPolicy Bypass -command "get-service '*BatchPatchExeSvc*' | ForEach-object{ cmd /c sc delete $_.Name}"The BP host machine needs .NET 4.6, not 4.0. Where did you see 4.0? Let us know so that we can get that documentation updated.
Most interactions with target computers communicate through either PsExec or WMI.
You can add a host multiple times to the grid, so you end up with more than one row for the same host. Then you can include it multiple times in a sequence by including each row in a separate step of the sequence. The only thing that would prevent you from adding a host multiple times to a grid is if you enabled ‘Tools > Settings > Grid preferences > Prevent duplicate host names from being added to grid’
Yes all of those columns are grid-specific, including the Notes column. However, with the Notes column we have that facility where you can keep notes, if desired, in a separate text file, and then any time you have a new grid you can import the notes from that text file. That text file can contain notes for 1000 machines (or any number) if you want. And then let’s say you have a new grid with just 30 machines, you can still use that same file to populate the notes for just the 30 machines that are in that particular grid.
There are several columns in the BP grid that you can use to store various notes about a given row.
Notes
Notes2
Description
Location
CategoryYou can enter data into any of these and save it with the grid so that it’s always there. The Notes import feature that I mentioned in the previous posting is specific to the ‘Notes’ column. The other columns can either be manually typed into in the grid, or you can use ‘Actions > Modify category, description, location, notes, color, etc.’
You can’t export the grid to CSV, but you can export it to XML simply by saving it to .bps. You can then open .bps files in notepad or import into excel etc and modify. Be careful doing this because if you modify something that BatchPatch doesn’t expect or not in the correct format, it will potentially break your grid.
However, you can also accomplish your goal of importing notes without doing that.
You can create a separate text file just to hold the Notes for given hosts. So, a text file in this case might look like:
host1|notes for host1
host2|notes for host2
host3|
host4|notes for host4So then if you have hosts in the grid with those names (host1, host2, host3, host4), you can then use ‘Actions > Import notes’, and it will apply your notes from the text file to the matching names in the grid. Select all desired rows in the grid, import the file that is formatted as shown above, and then notes will be populated for each selected host based on your file’s contents.
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.