Personally I think it will be a bit of task to maintain a server specific blacklist even if you do things outside of BBSA. How many servers are we looking at here ?
Will this be specific to every single server or a set of servers ? E.g. U say these set of patches shld not go for all SQL DB servers ??
I am afraid that this functionality is not what comes out of the box. But this can be achieved by some wrapper scripts.
You can do this OOB in BSA using smart groups. Just point your patch jobs to a smartgroup and then use a series of “server name does not equal” entries to effectively create a blacklist for that patching group. If you are going to maintain a blacklist, then that is the way to do it.
If you want a more categorical approach to “black listing” then add a Boolean property to the server class that is called patch_exclude with a default value of false. Set the value for the servers you want to be on a blacklist to true and set your patching smart groups to only contain systems where the value is false. You can also have a smart group that only contains servers where the value is true, so that way you can quickly look at the servers on your blacklist.
Correct me if I am wrong, U mean using Server smart groups ?
I undestand that he wants to have a blacklist of patches on per server basis.
This way he will still have multiple patch jobs with different patches excluded.
The number might not be to high, but it is a challange to maintain serveral customer platforms that atre highly specialized. The need for a serverbased blacklist is typically for application X. For server platforms like SQL or Exchange the standard routine will most likely be sufficiant.
Thats right. I would like to have the posibility to enable a blacklist locked to a server. This way the servers can be included in the ordinary patch process and we vould not have to use seperate smartgroups and jobs to handle the customers. It might not be very usefull for all installations, but with our customers theese specialized systems tend to have severe penalties if unavailable. So for our situation this would be a very useful feature to have in the "standard patch process".
It would be helpful to understand how many servers and how many variations of blacklists we are talking about.
In a typical environment there are only so many different servers. Server with an app installed and servers without. The Server Smart Group concept would work well here.
If number of blacklist versions is high and the number of servers is high you have a whole different type of problem at hand. An administrative problem how to maintain all the blacklists for all servers.
May i assume that you are already maintaining this infrastructure and if so, may i ask how you do this now?
The number of systems are not that high but they will typically be handled by different people. At present none of theese systems are managed by BBSA. They are to be imported and handled by BBSA in the near future. So at the moment theese systems are handled by using manual lists. This is the reason for me asking for help to se if we can solve this using the tool. If not we need to keep on using manual lists.
We thought this to be a good feature since it would be applied on a server level and leave the need for a seperate smart group or a multitude of jobs to handle these systems. At the same time there would be almost no risk of any human error due to targeting the wrong smart group.
If the blacklist could be handled on a per server basis the administration of this would be fairly minimal.
As I said the number of systems are not that high, but the penalty for not delivering the service is typically very high for theese systems.
could you do this:
store the patch exceptions in a server property or custom property class linked to the server psc. then we use a nsh script job that will read the values from that property/psc/psi and create a blacklist file, then the script creates the paj on the fly w/ the blacklist and target server, then go run the paj and email results, or whatever needs to be done.
Thanks for all the good suggestions in this thread. The two main solutions to this issue seems to be to use RBAC as in seperate roles for this or to build all logic into a script job. Unfortunately we do not have knowledge to create and maintain a nsh script of this caliber. We are all mostly Windows techies running Powersell for a living except for the tasks to be handled by BladeLogic.
We opened a support ticket as well. Support also suggested that this was to be solved by RBAC, using seperate roles for these systems. Still this does do anything major to the human factor of execute the job against these servers by accident.
The conclusion for now is that these systems are not likey candidates for Blade Logic. Maybe later some time.
Just to reiterate, many (if not all) of your servers are unique. Meaning, you want the ability to blacklist certain patches on certain servers? And the patch and server list is always changing? And you currently patch your servers manually with this list in mind?
If so, couldn't this be handled a few different ways within BSA?
- read servers and excluded patches from a master file and generate the proper targets?
- create a custom Configuration File, have that file exist on each server containing blacklisted patches, and use logic to not deploy patches based on those values?
- create a custom Server Property with blacklisted patch vales and use logic in the same way as above?
I have not done any of these personally, I'm just brainstorming different ways BSA might be used to handle your issue.