BatchPatch Forums Home › Forums › BatchPatch Support Forum › Batchpatch as a service shared grid
- This topic has 1 reply, 2 voices, and was last updated 1 day, 7 hours ago by doug.
-
AuthorPosts
-
July 14, 2026 at 8:56 pm #14514ryoung99Participant
Hello,
I’m looking to use BatchPatch as a service and wanted to confirm whether my planned workflow is supported.
Using a admin jumpbox, my plan is to configure the BatchPatch service to run under a dedicated non-admin service account (bpsvcuser1). I’ll load a shared grid (GridA) that contains approximately 100 servers, several Execution Rows, and scheduled tasks to send an email communication about the maintenance at 10am and download Windows updates at 7pm (prior to the maintenance scheduled at 9pm for patch install and reboots).
Later, another administrator (User2) would log in to the same admin jumpbox, open the same GridA, and manually execute an Execution Row to install the updates that were downloaded by the service.
My questions are:
1. When the BatchPatch service executes the scheduled email at 10am and download at 7pm, does it save the updated grid state (download status, timestamps, row status, colors, etc.) back to the shared .bps file?
2. If User2 opens the same GridA after the scheduled download has completed, will they see that the updates have already been downloaded, or is that runtime state maintained only within the service instance?
3. Is this the recommended approach for having the service prepare updates while allowing different administrators to manually perform the installation later using the same shared grid?
4. If not, what would you recommend as the best practice for this workflow?Ultimately, my goal is to have the BatchPatch service automatically send email at 10am and download updates at 7pm, while allowing any administrator to later open the same shared grid and simply run the Execution Row to install the updates and reboot without having to download the updates again.
Thanks for your guidance.
July 15, 2026 at 12:14 am #14516dougModeratorGrid sharing is not supported and will cause issues unless the grid is only used by one user (or one service) at a time. If a grid is active in the BP service instance, it will be problematic for another user to launch that grid at the same time. The user could, however, make a copy of that grid without issues instead of using that grid directly. Or the user could just create a new grid that targets the same machines.
If you are using BatchPatch in standard/online mode (not using cached/offline mode), you could pre-download the updates to target computers with Group Policy as described at the following link, but with setting number 3 (Download the updates automatically and notify when they are ready to be installed) instead of setting number 2.
recommended-group-policy-settings-for-batchpatch-standalone-usage-with-no-wsus
Of if you use BatchPatch to pre-download the updates, which is fine, you simply need to avoid grid sharing.
1. The BatchPatch service saves its grid states continuously.
2. Yes, the user will see everything in the grid, but opening a grid that is in use by a different user’s BP instance or a different BP service instance will be problematic and should not be done.
3. The recommended approach is to not ever try to share/use the same grid at the same time. The grid file can only be shared if only one user is ever accessing the grid at any one time. And in that case you’ll need to make sure that your encryption settings are configured such that all users who are using the same grids are using the same encryption key. You can read more about that in Tools > Settings > .Bps File Protection > ? (help button)
4. You could have the administrator who will launch the Execution Row make a copy of the grid and load that instead of trying to load the grid that is currently active in the other user’s BP service instance. Or they could log on to the other user’s BP service instance to remove that grid from the service instance before accessing it directly in a different user’s BP instance. Or you could just use completely separate grids. Or you could perform the pre-download of the updates with Group Policy instead of with BatchPatch (in the event that you are using standard/online mode, not cached/offline mode). Or you could have the user who will be launching the Execution Row be the same user who runs the grid that has the scheduled task to pre-download the updates.
-
AuthorPosts
- You must be logged in to reply to this topic.