IsManaged is getting reset to 0 in NS 7.x

Article:TECH160244  |  Created: 2011-05-17  |  Updated: 2012-02-23  |  Article URL http://www.symantec.com/docs/TECH160244
Article Type
Technical Solution


Issue



Computers are being redirected from a Parent NS to a child NS. The clients that were redirected are seeing the IsManaged  and IsLocal attributes both set to 0. The child NS has both IsManaged and IsLocal  set to  1.  What is resetting the IsManaged property on the parent?


Environment



NS 7.0 SP2 - SP5, NS 7.1 


Cause



In NS 7.0 Sp2 and higher is a hierarchy replication process called Hierarchy Resource Owner Conflict.  This handles a problem where a computer exists on two different NSs but with different OwnerNSGuids.

 

                If IsManaged flag is true at one node, but false at a child, OwnerNSGuid will not update when child replicates upwards using hierarchy.

                This is to handle the scenario where an agent reporting to parent, is also known to the child due to discovery

                Without it the Agent will not be local at the parent and many management functions will become impossible

               

                If an agent moves, IsManaged can be true at both parent and child, and the OwnerNSGuid at the parent doesn’t match the child

                It is unclear at this point whether the agent moved  parent to child or child to parent

               

                Therefore we raise an Owner Conflict Hierarchy Event

                The Source and Recipients of the event clear IsManaged flag

 

                True location of the agent will report basic inventory and IsManaged will become 1

                The next replication cycles will be resolve the settings

 

Setting IsManaged to false is needed because when a hierarchy resource conflict is detected, we do not know where IsManaged should be true, and where it should not, except at the parent, but if we don’t clear it at the parent and it was a move to a child, the next replication will just trigger an owner ns conflict again unless we have correctly set the OwnerNSGuid, but what that should be set to is also unknown! (It is different depending on whether the agent has moved parent to child or child to parent or sibling to sibling, but they all present with practically an identical conflict.)

 

In this case, the owner conflict process runs, raises an owner conflict hierarchy event and clears the IsManaged flag on the parent and child NSs. Both NSs involved should have IsManaged = 0 and IsLocal = 1.

If a replication cycle runs on the child and sends up computer data prior to a basic inventory being received on the child,  the data will change IsLocal = 0 and IsManaged = 0 on the parent NS.

Basic inventory is received on the child NS.  IsManaged = 1 and IsLocal = 1 on the child NS

Another replication cycle runs and sets the parent configuration to IsManaged=1 and IsLocal = 0

 

It may take a couple of replication cycles in order for the process to complete updating.

 


Solution



To help facilitate this a couple of things can be done.

 

1)      Modify the hierarchy replication process and break the Computer Replication task out into its own schedule. Schedule it at a time that doesn’t conflict with the other replication schedules.

2)      Create  a filter at child using the following open query:

 

select guid, name from dbo.vcomputer where ismanaged=1 and guid not in (select * from openquery([parentSQLServer], 'select Guid from Symantec_CMDB.dbo.vcomputer where IsManaged=1')) order by name

 

You will also need to create a linked server to the parent  SQL Servre if one doesn't already exist.

 

3)      Create a standalone replication task that targets the computers in this filter and sends basic inventory. These are computers that are out of sync and need another replication cycle for the Owner Conflict update to finish.

 




Article URL http://www.symantec.com/docs/TECH160244


Terms of use for this information are found in Legal Notices