Forum Replies Created
-
Posts
-
Sorry I misunderstood. I thought you were saying you wanted to temporarily modify the registry value so that the printers could be installed/updated, and then set the reg value back.
Depending on how your printers are setup, you should generally be able to execute a single command and the command prompt of a target computer to perform the installation. Some quick googling will reveal which command to use in your environment. Once you have figured out which command does what you need and works successfully to perform the installation manually at the command prompt of a given computer, you can then easily port that to run remotely from BatchPatch either in a BatchPatch remote command or in a .cmd file that you then deploy to each target using the BatchPatch deployment feature.
You can make registry changes easily with BatchPatch. You don’t need to write an elaborate script. You can just use the Windows ‘REG ADD’ command in a BatchPatch remote command:
https://batchpatch.com/an-alternate-way-to-deploy-a-registry-value-to-remote-computers
Other methods:
https://batchpatch.com/deploy-registry-keys-to-multiple-computers-using-batchpatchhttps://batchpatch.com/remote-registry-updates-with-batchpatch
If you want to continue to allow non-admin users to install printer drivers, then you can use a registry value to revert the behavior to how it was before the August update. However, this is probably not a great idea to permanently revert.
But a reasonable option might be to only allow users to install printers if they contact you first. Then when they call you, you can temporarily modify the registry value to enable them to do the printer installation. When complete, you can then undo the registry change.
Another option would be to give all users a local admin account that they are allowed to use only for elevation, such as in cases where they need to install a printer driver.
Another option is to simply make sure you get your printer drivers all included in the image that you deploy to new computers.
We’ll consider this for a future build. Thanks.
In the lower right corner of the BatchPatch window there is a row count value. It shows selected rows / total rows.
We aren’t aware of any changes at this time.
There is not such an option in BP, but we will consider it for a future build. In the meantime I would suggest you simply move your disabled computers into their own OU in the directory, then don’t synchronize that OU.
‘Tools > Settings > General > Remember open tabs from last session’
There is not currently a built-in way to share them. However, you can use ‘Tools > Export’ to export the user-defined items to a file. You can then use ‘Tools > Import’ to import them somewhere else. Also these items are stored in each user’s profile under C:\Users\%USERNAME%\AppData\Local\Cocobolo_Software,_LLC\BatchPatch\user_defined\user_defined.xml
Excellent!
OK let’s do a couple of things.
1. Are you using the latest version of BatchPatch? Start with just making sure you have the latest version of BP. (Help > Check for updates)
2. Next, make sure that the service instance is up to date. If you go to ‘Tools > Run BP as service’ is there an update available? If yes, apply it. If there is no update available, there will be no option available to “update service.”
3. Start with a brand new grid. Do not use/load an older grid/.bps file.
4. In the new grid create a scheduled task, but don’t use the email notification option. Instead create a scheduled task to ‘Execute job queue’, and make sure the task is set for a time a few minutes in the future. Then save the grid and send it to the service instance. Then launch the service instance viewer so that you can watch it in real-time. To do this go to ‘Tools > Run BP as a service’ and then select the .bps file in the list of “Currently active .bps files”, and then click ‘Launch selected .bps file in viewer’.
The goal here first is to see if there is an issue specifically with ‘Send email notification’ running in the service (or perhaps with how you are using ‘Send email notification’) or is there an issue with *any* scheduled task running in the service instance. So I want to know if ‘Execute job queue’ works in the service instance or not. The job queue itself can remain empty, so when ‘Execute job queue’ runs at the scheduled time, the ‘All Messages’ column will show something like this:
08/01 20:54:47> Job Queue: Queue is empty
08/01 20:54:47> Job Queue: Queued…
08/01 20:54:47> Scheduled Task: Initiating ‘Execute job queue’ – Sunday – 08/01/21 – 20:54.You have to add a grid to the service instance. You can do this by either right-clicking on the tab header of a grid and choosing ‘Send grid to service instance’ or you can manage which grids are in the service instance under ‘Tools > Run BatchPatch as a service’
The link you posted contains simple instructions for how to implement a workaround for the vulnerability:
Vulnerable systems can enable ACL inheritance for files in the %windir%\system32\config directory by running the following command from an elevated prompt:
icacls %windir%\system32\config\*.* /inheritance:e
Once the ACLs have been corrected for these files, any VSS shadow copies of the system drive must be deleted to protect a system against exploitation. This can be accomplished with the following command:vssadmin delete shadows /for=%systemdrive% /Quiet
Confirm that VSS shadow copies were deleted by runningvssadmin list shadowsagain. Note that any capabilities relying on existing shadow copies, such as System Restore, will not function as expected. Newly-created shadow copies, which will contain the proper ACLs, will function as expected. Please see KB5005357 for more details.Each of the three commands mentioned above can be simply dropped, individually, into a ‘Remote Command (Logged Output)’ in BatchPatch.
icacls %windir%\system32\config\*.* /inheritance:e
vssadmin delete shadows /for=%systemdrive% /Quiet
vssadmin list shadowsNot really. Currently the only other way to do it would be to modify the queue to run in a loop every 15 minutes, and to insert a custom script that checks the time of day and terminates the loop if the time of day is between 1900 and 0700. However, while this other method job queue would only be several steps instead of ~96 steps, I’m not sure that it’s any easier since it involves creating a custom script.
We’ll consider other simpler options for a future version.
This information is pulled from the Windows Update Agent (WUA) history database on the target computer. We’ll take a look to see if we have any way to improve/fix this, but I think it is probably stored in the database in such a way that I don’t think there is anything we can do. I don’t think it’s something that BatchPatch has any control over. If we figure out a way to improve/fix it, we’ll do that in a future version. Thanks.
Please see: Troubleshooting Common Errors in BatchPatch
What is “Executing export report” ? Please be as specific and detailed as possible to describe exactly what you are clicking on, and then exactly what you are seeing when you click on that.
I’m not sure what could be causing that aside from everything I mentioned previously. Did you try the suggestions that were posted further up above? And to create brand new everything from scratch, including brand new deployment configuration, brand new grid, etc, along with everything else suggested in the posting I made a few days ago.
‘Actions > Windows Updates > Check for available updates’ not ‘Help > Check for updates’
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.