Video Screencast Help

Automatically change ownership of several objects

Created: 09 Apr 2013 | 3 comments

Hi all.

I'm using ITMS 7.1 SP2 MP1. I have a Lab environment and a Prod environment. In each environment I have defined a hierarchy with just two NSs (a parent and a child). When I need to create a new policy, report... I first made it in the lab environment, and when it is finished, I replicate the object (or I export/import it) in production.

When running a replication in prod, I get a lot of errors with the following text: "The specified GUID does not refer to a item (GUID: xxxxxx)

After having a look at this article https://www-secure.symantec.com/connect/forums/specified-guid-does-not-refer-item-how-find-it (thanks bbiggs and
Telefragger for the solution provided) it seems that this is what is happening in my environment (I have looked at some object I know I exported from Lab and all they have the "trustee invalid" message)

Now, my problem is that I have a big number of items which ownership is invalid.

Does anyone know of a way of automating the changing of the ownership of several objects?

Thanks in advance... 

Operating Systems:

Comments 3 CommentsJump to latest comment

The Gaffer's picture

First find the guid of the trustee account or role which you want to be the owner of these items. You can search the SecurityTrustee table for this information:

select Guid, Name
from SecurityTrustee

For example, the 'Symantec Administrators' role has the guid: 2E1F478A-4986-4223-9D1E-B5920A63AB41

Now, you can update the SecurityEntity table and reassign the ownership of any item which is owned by an unknown trustee, by running this query:

UPDATE SecurityEntity
SET OwnerGuid='2E1F478A-4986-4223-9D1E-B5920A63AB41'
FROM SecurityEntity se
INNER JOIN SecurityTrustee st
ON se.OwnerGuid = st.Guid
LEFT OUTER JOIN vItem vi
on vi.Guid = st.Guid
WHERE vi.Guid IS NULL

This will assign the ownership of these items to the Symantec Administrators group.

You will still have references to these accounts in the SecurityTrusteePermission and SecurityACEData tables and may still see errors in the log files when the servers try to replicate items from one server to another. These errors should not effect the functionality of the servers.

John

Falquian's picture

John:

Thanks a lot for providing this piece of code. It really has helped me in fixing the ownership of the "orphan" objects.

I'd like to ask you for more help in something related to this issue: Changing the ownership of the offending objects has helped, but I still keep on getting error messages in the logs saying that "The specified GUID does not refer to a item (GUID: xxxx)"

I've seen that, although the ownership of the objects now is fixed, the objects keep references to the offending GUID in their security settings, granting permissions to the non-existing user/group represented by the GUID.

Can you help me in finding those references, and changing them to a valid GUID in the new environment?

As a detail that worries me, yesterday I imported a set of reports I found in the connect forum and, as I expected, the security information related to the user that shared these reports was also imported in my CMDB (which, of course, generated the "The specified GUID..." error entries in the log)

Thanks again:

             Falquian

Kind regards:

     Falquian

If this post is useful to you, remember to mark it as a solution ;)

SaschaH's picture

Wouldn't it be simpler to use, all the invalid trustees here also dont have any name associated in SecurityTrustee here.

UPDATE SecurityEntity
SET OwnerGuid='2E1F478A-4986-4223-9D1E-B5920A63AB41'
FROM SecurityEntity se
INNER JOIN SecurityTrustee st
ON se.OwnerGuid = st.Guid
WHERE st.Name ís NULL

And what speaks against cleaning up SecurityTrusteePermission? If we run the Update first at least Admin should have permissions on all of the Items.

DELETE
FROM SecurityTrusteePermission se
INNER JOIN SecurityTrustee st
ON se.TrusteeGuid = st.Guid
WHERE st.Name ís NULL

And SecurityACEData should be fine as we switched the OwnerGUID in SecurityEntity whose Guid is used in SecurityACEData.

We also have Test, Release, Produktiv and Hierarchy with different domains and some different users. So a lot of those invalid trustee errors because of moving(export/import) software resources through all systems during the release process and different users involved.

Bechtle – your strong IT partner. Today and tomorrow

If that seems to help, please "Mark as Solution"