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.
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
Yeah that makes things a little tricky. Would a logic re-arrangement work? Something like:
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.
Mike, if you feel you are getting inconsistent behavior, I would suggest opening a Support ticket.
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.
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...
We do apply ACL policy to the downloaded patches, but as you said it is the same Role.
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.
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 ?)
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