10 Replies Latest reply on Sep 3, 2014 3:06 AM by Mike Jones

    Strange behavior

    Mike Jones

      Does anyone know what causes the error message "Smart Groups containing Irrelevant Patches are not allowed in Include/Exclude list" to pop up.


      In our environment, some people get this message and others do not, using the same console version with the same role, job and patch smartgroup.


      This causes us an issue because we are currently on 8.2.04 and we have a patch smartgroup with name contains .NET or description contains .NET so we can exclude all .NET patches from patch analysis, but we are now getting this pop up error message for some users and  they cannot create new patching jobs with this exclusion. We cannot add SOFTWARE_PATCH_STATUS_FLAGS* does not start with 1 to the smartgroup because that will add all (non-irrelevant) patches to the exclusion and as we are not at 8.5 yet we cannot do an OR and AND smartgroup definition.


      It is really frustrating as it doesn't matter at the patch analysis level if the smartgroup contains irrelevant patches just in the GUI when you try to use it.


      The strange behavior is that some people don't get the message and others do.


      Any Ideas anyone


      Also, before anyone says just remove irrelevant patches does anyone know what the best practice recommendations are for this, does anyone remove them regularly with blcli or through the console.



        • 1. Re: Strange behavior
          Don Kim

          I also experienced the error "Smart Groups containing Irrelevant Patches are not allowed in Include/Exclude list" in 8.3 for SP2 and SP3 updates. The message seemed to be consistent for all users though. For us the difference was that SP3 added that irrelevant property where it was not present in SP2. I cant speak for the recommendations on this - we have an exclude list that contains irrelevant patches so the fix was easy - adding "does not equal =1" as a condition in the valid groups.

          • 2. Re: Strange behavior
            Mike Jones

            Inigo - thanks unfortunately we cannot use the "does not equal 1" filter because of the fact we have an OR condition in the smartgroup and can't add an AND as well

            • 3. Re: Strange behavior
              Don Kim

              Yeah that makes things a little tricky. Would a logic re-arrangement work? Something like:


              Match any:

              Name does not contain = .NET (or)

              Description does not contain = .NET (or)

              Patch status != 1


              This would keep out .NET and irrelevant patches. Unless there are servers with .NET that you want included.

              • 4. Re: Strange behavior
                Joe Piotrowski

                Mike, if you feel you are getting inconsistent behavior, I would suggest opening a Support ticket.

                • 5. Re: Strange behavior
                  Mike Jones

                  Joe - I think we are going to but I was hoping that someone in this community would be able to answer what actually does the check and why, and when did it change.


                  For example, if I login to Windows with the console on it as a new user I can use the smartgroup in the job,if I log into the same TS with my standard account I cannot. In both cases I connect to BSA with the same user and role and try to edit the same job.

                  • 6. Re: Strange behavior
                    Joe Piotrowski

                    Ahh. How are you applying permissions to the patches? Are you using an ACL Policy within the Patch Catalog? Although if it's the same Role it shouldn't matter...

                    • 7. Re: Strange behavior
                      Mike Jones

                      We do apply ACL policy to the downloaded patches, but as you said it is the same Role.

                      • 8. Re: Strange behavior
                        Yanick Girouard

                        The only think I can see is a potential ACL issue.


                        Some of the patches in the catalog were not created using the right role and/or don't have the proper ACL Policy applied to them, which means that the "Remove irrelevant patches" command probably couldn't run against all of them depending on which role called it last. Some roles can see all the patches, while others can't, so depending on the role used, some of patches returned by the smartgroup query would be irrelevant (have been superseeded).


                        To fix this there's no easy solution. You'll just have to force a reset of permissions on all objects inside the patch catalog using the RBACAdmin SRP account to make sure you don't miss any. Then make sure that there's a proper ACL Policy set in the Patch Catalog so that any future catalog update job creates patches using the right permissions.

                        • 9. Re: Strange behavior
                          Bill Robinson

                          try deleting the workspace folders for the 'old' user ?  the only reason i suggest that is that you are logging in w/ different windows profiles and getting different results when connecting w/ the same bsa account (right ?)

                          • 10. Re: Strange behavior
                            Mike Jones

                            I have already tried that - part of the reason I posted this on communities.


                            In fact, I have even tried renaming the %appdata%\Bladelogic directory for my account so it created a new one and it still fails for my account