Microsoft KB Archive/285208

= Understanding the msMMS-ManagedByProfile Attribute =

Article ID: 285208

Article Last Modified on 1/25/2006

-

APPLIES TO


 * Microsoft Metadirectory Services 2.2 Service Pack 1

-



This article was previously published under Q285208



SUMMARY
This article discusses the msMMS-ManagedByProfile attribute. This attribute only applies to connector space objects; it is part of what the Management Agent Sync Engine (Importt.exe) looks at to figure out what to do with a connector or disconnector object. If this attribute exists on a connector space object, the object will be owned by the metaverse. The metaverse is treated as the authoritative source for this object. This is how Microsoft Metadirectory Services is able to distinguish between connector space objects owned by the connected directory and those owned by the metaverse.



MORE INFORMATION
The msMMS-ManagedByProfile attribute is created and set to a value of TRUE for every connector entry that is created by the Together Administration Management Agent (TAMA), and for every existing connector entry that would normally be created by TAMA. New entries are created without a hologram. If a disconnector exists, this attribute is not added. However, if a connector exists for an object that TAMA has been configured to provision, TAMA takes ownership of the connector space object. After the ownership is assumed, the metaverse is in control of the object.

The following examples illustrate how this attribute affects certain situations. In this example, an HR Management Agent (HRMA) and an Active Directory Management Agent (ADMA) are used:
 * Scenario one: Object originates from an HR Database. It will be provisioned to the Active Directory, or another database.
 * Scenario two: Object originates from both the Active Directory and HR database, and join occurs. Control of the object resides in the metaverse.
 * Scenario three: Object is deleted in the HR database.
 * Scenario four: Object is deleted in Active Directory Database.

Object Originates from the HR Database
In this scenario, the object exists in an HR database. The object is imported by Microsoft Metadirectory Services and placed in the metaverse. A resource would be placed on a metaverse location configured for an Active Directory Management Agent (ADMA). (TAMA rules script can also be used to assign resources.) A TAMA management agent is also created and configured. When the TAMA management agent runs, the metaverse object is created in the connector space below the ADMA. During this process the newly created CS objects are assigned and the msMMS-ManagedbyProfile attribute is set to TRUE. To verify this attribute assignment, view all attributes on the objects.

Object Exists in Active Directory and a Join Has Occurred
In this scenario, the object exists in the HR database as well as the Active Directory management agent. The HR database imports the object first, and then the ADMA imports the same object. A join rule is set to allow the AD projected object to join the HR projected object. A TAMA resource is created as well as a TAMA management agent. TAMA is run and finds existing connectors below the ADMA. When this occurs, TAMA sees that the object already exists in connector space and reconfigures ownership to the metaverse object. In the process of assuming ownership, the msMMS-ManagedbyProfile attribute is configured on the connector object and set to TRUE. This gives control of that object to the metaverse.

Object Is Deleted in the HR Database
After the msMMS-ManagedbyProfile attribute is set to TRUE, the following should happen when the object is deleted from the HR database. After the deletion is issued from the HR database, the object is deleted in the metaverse. This causes the object located in the connector space of the ADMA to become a disconnector. The next time the management agent is run, the object is deleted from Active Directory and the disconnector remains. When the ADMA is run again, this disconnector is removed after the object no longer appears in the import file. For this to happen, msMMS-TimeToLive must be set to the default.

For additional information about the msMMS-TimeToLive attribute, click the article number below to view the article in the Microsoft Knowledge Base:

299392 Understanding the msMMS-TimeToLive Attribute

Object Is Deleted in Active Directory Database
After the msMMS-ManagedbyProfile attribute is set to TRUE, the following should happen when the object is deleted from Active Directory. If the object is deleted from Active Directory, when the management agent (MA) is run again, the object is sent back out to Active Directory as an add. This occurs because once the attribute has been set on this entry it behaves as if it were under a Creator mode management agent, regardless of the actual mode the MA is in. Therefore, it is important to design your Microsoft Metadirectory Services solution so that only the objects that you want to control through the metaverse are stamped with the msMMS-ManagedbyProfile attribute set to TRUE.

The following is a definition of the attribute:

-DN: ZAN=msMMS-ManagedByProfile,F=Attributes

-cn;M: msMMS-ManagedByProfile

-zcOid;M: 1.2.840.113556.1.6.7.1.60.1

-zcSyntax;M: T61String

-zcMultiValued;M: S

Additional query words: Zoomit Via MA zscript genlogs interix mms metadirectory

Keywords: kbinfo kbenv KB285208

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.