1 of 1 people found this helpful
i can only comment on Windows Patching.
For this use-case the only possible method at the moment, that makes sure that the Patch-Payload is not send across the WAN from your App-Server is to
- create a Windows-Patch Catalog that is set to "Agent Mounts Source for Direct Use at a Deployment"
- Use a File-Deploy-Job to sync the created Patch-Repository to a remote server in Asia-Pacific that will act as your "Remote Repository"
- Share that Repository via SMB
- Use this syntax https://docs.bmc.com/docs/display/public/bsa83/URL+syntax+for+network+data+transmission combined with custom Server-Properties to point your targets to their nearest "Remote Repository"
We have created a custom property class called COBA_location for this. The various instances of this class hold the details on all our Patch-Repositories.
In addition we have Server Property called COBA_location, which is of the Type "Property Class" and references the according Property Class.
The reason why Repeaters make no sense here is the fact that for each Patch-Job-Run a new BLPackage is dynamically created. Only when in a single Patch-Job-Run, two or more targets miss exactly the same set of Patches, then i believe the Payload is only transferred once and then distributed to the Targets from the Repeater.
A new Patch-Job run, or a targets that require a different patch-set won't benefit of this and the whole payload would be distributed again.
Have a look at :
for additional information.
Please note, that BMC seems to be aware of this sort of problem and is working on a solution to this issue
Maybe my statements also apply for AIX Patching, but that needs to be double-checked.
Let me know if you need any more details.
It is true that repeaters are only effective where the missing patches on the target match exactly, however I think you would be surprised how often that is true
For one of our customers the patch deploy groups are 10-20 servers at a time and the generated jobs often have 8 targets which match exactly, a couple with two matching and a few single. If the deployment groups where bigger then this would increase.
I think BMC should make this smarter so that it uses the repeaters effectively for all patch situations
i agree with you, when you have an estate that's getting patched regularly, normally i would expect that only the new released Bulletins are missing, so that majority of targets should have the same patches missing.
Unfortunately this is not true for us at the moment, as we constantly add new servers to BL around the globe that formerly had been patched by different solutions, we currently see lot's and lot's of different Patch-Sets.
.... and what's even more important, this only works when you approach the targets within the very same Job-Run.
Which is as well not the case for us everywhere, as different targets have different maintenance windows defined and different schedules are used to patch the targets.
A quick question, what is the parallelism of the job set to? I am planning to setup something like this however want to understand how many targets can mount the shared SMB drive in parallel.
It is more of a standard Windows File server question it is likely to be limited by its network throughput before it hits any limitations on the number of connected clients.
How many managed servers are you hoping to patch concurrently, what is their connection speed to the repeater, what is the network speed of the repeater NIC
I am hoping to patch 25 – 30 servers in concurrently at the initial stage as I do not know how many servers can mount the shared drive in parallel. I think we do not use repeaters in this usecase as we are mounting the drive instead of copying the files to target servers.
That will be no problem for any class of file server, I thought you were going to use the repeaters to share the files if not any file server is fine.
Hi Steffen - I'm wondering whether you'd mind me asking you a few questions regarding BL and Win patching in your environment. If so could you send me an email so I can reply ... firstname.lastname@example.org
thanks in advance
Have send you a mail
Steffen, Thanks for your great explanation how you implemented patching across sides.
We are currently phasing the challenge to implement it in a similar environment.
I think we will also use the explained approach.
If you don't mind I want to have a short chat with you about this ... also in German if you want
Is there a possibility to reach you (mail, Skype, etc)?
Thanks in advance!
Just send me an email to my company address, which is in my profile and we can arrange something.
What should happen though, is that if server1 needs patches 1,2,3 and server2 needs 2,3,4 then patches 2 and 3 will only be copied once, even if they are in different blpackages. there was a recent fix that got the repeater to handle duplicate soft-linked payloads properly.
but to some degree you are right - if you have a bunch of targets that are pretty current on patching, and you push a new box out there then you would not get the benefit of the repeater for that server. maybe you can do slipstreaming of the patches into the OS build periodically (does microsoft still allow that) or update the vm template periodically w/ patches.
That Repeater Fix , is that out yet and included in which version ?
Still, i guess that functionality is only used within the very same Job-Run ?
I’d have to look – I think 8.2.04 and 8.3.02 – something like that.
if the payload of the particular patch is in the repeater cache, from any job, it shouldn’t be copied again.
but like I said – it may not help your case if you are adding unpatched servers.