Forum Replies Created
-
Posts
-
You said all tasks remain in “Deployment: XXX queued…”
Is this definitely the exact message you see? If yes, then I don’t think it would be an issue with the target machines. It’s almost definitely *just* on the BP machine.
If the above-message is not the exact message that you see, then what is the exact message?
Also, you said everything else works. Can you confirm what happens when you use “Check for available updates” ?
It’s very unlikely that a setting would be the cause of this issue. However, you can certainly test it and see what happens. The easiest way would be to just launch BP under a different user account since all of the BP settings are saved on a per-user basis. Launching it under a new user account would be equivalent to wiping your own account’s settings, but without having to deal with actually doing that. However, if you want to wipe your account’s settings, you can do that too by closing all instances of BP (also uninstall the service instance first if you have that installed – check ‘Tools > Settings > Run As Service’), and then delete registry key HKCU\Software\BatchPatch and C:\users\yourUsername\AppData\Local\Cocobolo_Software,_LLC If you have saved commands/deployments/queues/etc that you don’t want to lose, then you should export them first (Tools > Export), and you should consider backing up the two locations noted above before deleting them.
We have never heard of a situation where a deployment is queued even when there are no other deployments active. Frankly, I can’t even imagine how that could happen. It simply doesn’t make sense. Normally the only thing that can/would cause deployments to queue is if the max number of concurrent threads or max number of copy jobs are already reached (these settings are under ‘Tools > Settings > General > Concurrent Thread Max’ and ‘Tools > Settings > General > Concurrent File-Copy Operations Max’). However, you describe that it’s happening even after a reboot and after executing the deployment for just a single row, so your issue wouldn’t be caused by reaching the maximum threads or copy jobs.
The only other thing that I can think of that you should try before you do any of the stuff noted above is to try a brand new grid (don’t use a saved grid, in case somehow the grid file itself got corrupted), and to create a brand new deployment (don’t use a saved deployment, in case somehow that’s where the issue is).
It’s hard for me to guess at what could be going on. I would suggest you start by rebooting the BatchPatch computer. Then try performing the deployment on just a single row and see what happens.
This video tutorial may help you understand it better.
You can temporarily directly modify the registry values that control the group policy setting. Group policy will automatically set these back to the group policy controlled values when group policy is refreshed, but this page shows you how you can use BatchPatch to temporarily directly modify the registry values.
https://batchpatch.com/using-an-alternate-wsus-server-for-batchpatch-windows-update-actions
https://batchpatch.com/using-an-alternate-wsus-server-for-batchpatch-windows-update-actions-part-2
Your post was stuck in moderation for the past several months. We didn’t see it because the forum thought it was spam. Sorry about that. It’s possible you’re seeing ‘Remote Command Exit Code -1’ for some reason that has nothing to do with your PsExec settings, though I can’t say for sure. In any case, you can see the -r setting config under ‘Tools > Settings > Remote Execution’. I would suggest in that GUI you tick the box for “Use psexec.exe custom filepath”, and then set that location to point to the actual location of your copy of the latest version of psexec.
This posting outlines the cause and resolution for ‘Exit Code: 1’ when uninstalling individual updates. Note, you mentioned -1, not 1, so this may not apply to your situation, since -1 is definitely not the same as 1.
Your posting was stuck in moderation queue for the past couple of months. Sorry about that. The forum thought it was spam, and we never saw it. Anyway, your screenshot links are dead… however, if you use ‘right-click > view cell contents’ directly on the cell, or you use <middle-click> on the cell, you can see the entire cell contents instantly.
No problem. Turns out actually that you don’t need to press ALT. I was confusing it with something else. You can simply drag and drop column headers to re-order them.
You have a few options here. Please read through all of these before trying anything. This way you can see which option makes most sense for your needs.
1. You can modify the default column ordering for new tabs/grids by going to ‘Tools > Settings > Grid Preferences > Modify column display order for new tabs: column order for new tabs’ This won’t change the order of columns in existing grids, but I wanted you to be aware of this setting in case you want to make changes to the default ordering for new tabs at any time.
2. I don’t know why it would be taking seconds for each click when using ‘Customize columns’ but I’m guessing it probably has to do with the amount of data that you have in the grid. I could believe that when there is a large amount of visible data in the grid, changing the order could be a bit slow. I suspect that if you hide the columns by unticking the boxes, then move them while they are all hidden, then tick the boxes again to make them visible, it might solve this issue.
3. Another way to move columns in a grid is by using left-click ALT drag/drop. So you would left-click on the column header, hold down the ALT key, then drag the header to the desired position and drop it there. The only issue with this method is if you have a lot of hidden columns, it could place the visible column that you dragged/dropped in between two hidden columns. This isn’t a problem but might just be not exactly what you want in the end. You could get around this by first making all columns visible, then close the ‘Customize columns’ window, then drag/drop column headers to re-order, then re-open ‘Customize columns’ and hide the desired columns.
4. This is probably the quickest option. Save and close the grids. Then make a backup copy of the .bps files just for safekeeping in case you break the originals. Then open the .bps files in a text editor such as Notepad++ or Sublime Text. Near the top of the file you will see:
<SettingName>ColumnDisplayIndex</SettingName>
<SettingValue>There will be a string of numbers in this field</SettingValue>If you copy the entire SettingValue section for the ColumnDisplayIndex, you should be able to put that into the .bps file for another grid. Then save and close, and then open that .bps in BatchPatch, and it should take on the same column ordering as the source grid where you copied it from. Just be careful when you do this. If you don’t copy the field exactly as-is and replace it properly… you will probably break the grid. Leaving an extra space or linebreak, or deleting a single character, or modifying it in any way will likely prevent the grid from being able to open without error. Or if it opens without error, it could still throw an error later. So just be very careful when doing this and you should be fine.
Glad that worked. The setting didn’t change. What prob changed is you upgraded your version of PsExec. The new PsExec now usually can’t work with ‘Elevated token’ unless also enabling ‘Interactive.’ BatchPatch tries to detect your psexec version and apply settings accordingly but it cannot always successfully detect the PsExec version, so in your case it left your previous settings intact.
Please check the ‘Remote Execution Context’ under ‘Tools > Settings > Remote Execution’
Try setting it to just ‘SYSTEM’ *without* ‘Interactive.’ This should work for most items.
If that still gives you problems, try setting it to ‘Elevated token’ *with* ‘Interactive’ and see how that goes.
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.