BatchPatch Forums Home › Forums › BatchPatch Support Forum › Cached mode / offline mode
- This topic has 4 replies, 3 voices, and was last updated 6 years, 9 months ago by doug.
-
AuthorPosts
-
January 17, 2018 at 8:09 pm #8882huibwParticipant
A few datacenters we run BP in don’t have access to the internet, even BP itself has no internet access. So we copy the scanfile and patches to the local BP cache dir and go from there. However, every time BP wants a file, it tries to go to the internet first. What I observe:
– start “download, install, reboot” on 24 clients
– BP tries to download scanfile. Fails after timeout, distributes local copy to the clients
– clients search for updates
– client 1 needs 5 patches, BP tries to download them one by one, but each one fails after timeout and then BP sends locally cached patch
– same story for clients 2 through 24. Client 2 is forced to wait in the download queue until 1 is done. 3 is forced to wait for 2, 4 for 3, etc.
All this waiting for the timeout is taking a long time. And waiting for the timeout is a single thread, you see every client on-hold and only one by one you see the clients continue with patching.
The simplest solution I see is that if BP times out for its scanfile download because there’s no internet, it shouldn’t try to access the internet again for the current session.
January 17, 2018 at 8:38 pm #10241dougModeratorI’m curious to understand how you concluded that BP tries to download each file one by one instead of retrieving from cache? BP does not do this.
The actual behavior of BP is as follows:
1. BP looks online to see if you have the latest WsusScn2.cab file. If it is able to connect to the internet then it will download the latest one. If it is not able to connect to the internet then it will use the one in the cache, and it will mark that session (in this case ‘session’ means that if you selected multiple rows and chose ‘download/install/reboot’ on all those rows in the same action, then they are part of the same session) as having no internet access so that the WsusScn2.cab file is used straight from cache instead of attempting to download the latest one again for other rows in that session.
2. BP copies files to target computers from cache. BP always checks cache for the existence of the file. If it exists in cache then BP does not try to download it from the internet.
3. The process for copying files to target computers in this case is, in fact, single-threaded as you suggested. In the case where there is internet access this prevents multiple rows from trying to download the same file at the same time. For copying the files to target computers when there is no internet access, it’s still single threaded, but the files are copied directly from cache without checks to the internet. So yes it’s true that each row will only copy files to target computer cache after the previous row finished copying files, no internet checks are involved.
If you believe that I am mistaken about the behavior, I would like to see the logs that illustrate what you are describing. The best way to do this is HTML export ‘File > Export grid to HTML’ and then email that to us, please. Thanks.
January 17, 2018 at 9:03 pm #10231huibwParticipantI concluded that BP tries to download each patch because of the time it took to move on. I did not save the results from the last round, but will do so next time.
I selected all 24 hosts and then selected “download, install, reboot”. Then there was the 1 timeout for the scanfile download & fail. Now all 24 hosts are searching. It was a pretty homogeneous environment, they we’re all done with searching within a few minutes of each other. Then I watched every host wait until the previous one had gotten its patches, there was no concurrency. While waiting their Progress or Upd Msg mentioned something about “download” and just sat there.
I did see I used an older version of BP (March ’17). I have updated BP in that DC and will take screenshots and save the results the next time around in internetless DCs. If it still behaves this way I will report back. I don’t have the ability to test this now, all hosts are on strict schedules. In the mean time thank you for your feedback.
January 17, 2018 at 9:41 pm #10232dougModeratorYes, it’s correct that there is no concurrency while the updates are being copied from the BatchPatch computer to the target computers. The copy operation is the only part that is not concurrent.
March 13, 2018 at 9:30 am #10164AnonymousInactivegood question
-
AuthorPosts
- You must be logged in to reply to this topic.