this is a permission issue check if the Role/User that is executing the Update Catalog job has the WindowsSoftware.* assigned to it.
thank you for your reply.
Yes it has that permission.
I'm trying to push the ACL on all windows server, maybe the permission needs to be pushed for that role.
I'll let you know.
Unfortunately it still appears...what can I check further?
which user/role was used to create the Update patch catalog job? You try creating a new one with the logged on user/role as a test (provided it has the WindowsSoftware.* permission )....
1 of 1 people found this helpful
Do you have an ACL Policy tied to your Patch Catalog? If not, I believe the permissions of the new patches downloaded are tied to the user running the job.
1 of 1 people found this helpful
Could you please provide the following information?
1. what is your version of BSA?
2. What is the OS catalog you are trying to update?
3. How many filters do you have inside the catalog you are trying to update?
4. How many times have you tried this update in the past?
5. Which role or roles did you try to run the update with?
Look in the catalog smart groups (maybe create one that shows all bulletin objects if that doesn't already exists) for this particular object. see what the permissions are on this object. this has nothing to do w/ server acls. probably a role ran the CUJ and created the object, and now a different role is running the cuj, the second role cannot see the object because it lacks the permissions and this message is thrown. so you will probably need to do a couple things:
1 - update the acls on all the objects in the catalog so that all roles that need access to it can see all the objects
2 - setup a acl policy that grants these roles access and set that as the acl policy in the catalog as joe mentions.
3. one: "Microsoft Windows Server 2003"
4. First time
5. Once with BLAdmin and once with a role that we use to access and work with Windows servers.
@Greg: you mean the user or which role was used?
@Joe & Bill: "probably a role ran the CUJ and created the object, and now a different role is running the cuj". Yes, as I answered in question 5, once with BLAdmin and then using another role.I have an ACL policy. But I think that something has mismatched in the app server.
BTW: due to hurry, I removed the catalog and I'll try to create it from scratch.
Thanks to all guys. :-)
EDIT: in this case, may I assign the correct answer to Bill?
yes, i get all the correct answers
it's possible the acl policy wasn't set in the catalog when one of the cujs ran as the 'other' role. otherwise not sure.
I felt bad so I marked it correct for you. You need the points.
related to this topic I've another problem: I was able to delete the Patch Catalog using Bladmin Role.
Now if I check the host repository, where the patches were downloaded, the folder still contains all the patches.
Does it affect the new Catalog I'm going to create? Or should I remove them by hand before?
I'm not sure to do the hand removal, since there would be a conflict on the DB match...I think...
May you clarify this step please?
Those patches will not affect new catalog.
They are left there so that if you create a new catalog with the same repository location you don’t end downloading the existing patches again..
If I'm not mistaken, the catalog update process will look to see if the binary already exists in the repo location. If it does, it won't download it again.
I created a new Patch Catalog and everything is fine now, update worked properly.
Thank You to All.