none
ECMA Agent Configuration too large for Portal/Service ma-data object RRS feed

  • Question

  • Hi,

    We have an agent implemented in ECMA 2.3. The agent has 9 Object Types. Each object type has a large number of attributes (the total number of attributes is 130).

    We've had no problems with the agent until now when we added some more Object Types (and more attributes). The agent imports fine in the FIM Sync Engine, but we get the errors listed below when FIM tries to update the ma-data config object for the agent in the FIM Service/Portal.

    Unfortunately I think we've hit some limit on the size of the agent configuration in the ma-data object (one attribute value becomes too large "String or binary data would be truncated"). The attributes in the ma-data resource should probably all be unindexed strings, but they are not :(

    I guess we're the first to use this many attributes in an agent. Has anyone else run into this aswell?

    Event Log:

     

    A update on the configuration of a MA or MV failed to replicate to a target connector directory that is capable  of storing MA/MV configurations.  As a result, the MA/MV configuration data in this connector directory is not up to date.  Please correct the condition that causes the error, and triggers a resync by updating the password information of the target MA. 

    Error 1:

    Additional information: 
    Error Code: 0x80230020 
    Error Message: (Management agent encountered an error exporting to the connected directory.) 
    Operation: Create MA 
    Name of the MA to replicate: LargeAgentName
    Guid of the MA to replicate: {17380C64-973F-499D-9DA3-94EAA59BD089} 
    Name of the target MA: FIMMA 
    Guid of the target MA: {BE7E9C7E-AB08-44FF-974C-02A79CE61833}

    Error 2:

    Microsoft.ResourceManagement.Service: Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other ---> System.Data.SqlClient.SqlException: Reraised Error 50000, Level 16, State 1, Procedure ReRaiseException, Line 37, Message: Reraised Error 50000, Level 16, State 1, Procedure ReRaiseException, Line 37, Message: Reraised Error 8152, Level 16, State 10, Procedure GenerateRequestOutput, Line 505, Message: String or binary data would be truncated.
       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
       at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
       at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
       at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
       at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
       at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
       at Microsoft.ResourceManagement.Data.DataAccess.DoRequestCreation(RequestType request, Guid cause, Guid requestMarker, Boolean doEvaluation, Int16 serviceId, Int16 servicePartitionId)
       --- End of inner exception stack trace ---
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation, Nullable`1 serviceId, Nullable`1 servicePartitionId, UniqueId messageIdentifier, UniqueIdentifier requestContextIdentifier, Boolean maintenanceMode)
       at MIIS.ManagementAgent.Configuration.SynchronizationConfigurationManager.CreateSynchronizationConfigurationObject(SynchronizationConfigurationObjectType objectType, SyncConfigObject synchronizationConfigurationObject)
       at MIIS.ManagementAgent.Configuration.SynchronizationConfigurationManager.ProcessDescription(SynchronizationConfigurationObjectType objectType, String managementAgentDescription, Boolean update)
       at MIIS.ManagementAgent.RavenMA.DoUpdateSynchronizationConfigurationObject(String identifier, MASyncConfigOp operation, String description)



    Wednesday, January 21, 2015 7:47 AM

Answers

  • Yes, the issue was closed in June 2015.

    There will be no changes made to the product. Instead, Microsoft Premier Support (with help from the Product Team) developed a work around involving making manual changes to the database (i.e. changing the type of a field in the FIMService database from indexed to unindexed).


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!


    Wednesday, March 9, 2016 3:00 PM

All replies

  • A case has been opened with Microsoft PSS regarding this.

    In the meantime, we have implemented a work-around by splitting the agent in two agents. Each agent handles half of the Object Types.

    Thursday, January 22, 2015 3:21 PM
  • A case has been opened with Microsoft PSS regarding this.

    In the meantime, we have implemented a work-around by splitting the agent in two agents. Each agent handles half of the Object Types.

    Has there been further updates from Microsoft or otherwise regarding this issue?
    Wednesday, March 9, 2016 1:28 PM
  • Yes, the issue was closed in June 2015.

    There will be no changes made to the product. Instead, Microsoft Premier Support (with help from the Product Team) developed a work around involving making manual changes to the database (i.e. changing the type of a field in the FIMService database from indexed to unindexed).


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!


    Wednesday, March 9, 2016 3:00 PM
  • I ran into this issue recently on a FIM 2010 R2 installation, and found two possible solutions.

    First off, the issue is caused by the "SyncConfig-dn-construction" field, which by default is an indexed string. 

    The first solution is you build your ecma using MADistinguishedNameStyle.Generic (as opposed to MADistinguishedNameStyle.None). The field "SyncConfig-dn-construction" will be left blank for MA's built using this MADistinguishedNameStyle setting as far as I can tell. However, it seems you need to delete your MA from the portal and MV for this to work - simply rebuilding with the new MADistinguishedNameStyle set and refreshing does not help. And after deletion and re-creating your MA, you need to either re-create all sync rules or point them to the new MA (see https://social.technet.microsoft.com/wiki/contents/articles/13407.how-to-use-powershell-to-fix-incorrect-ma-references-on-portal-sync-rules.aspx).

    The second way to fix this is of course to do the same as MPS - change the definition of the "SyncConfig-dn-construction" attribute in the portal database. Probably not recommended in a production environment without official help from MPS/Product Team, but still a fairly simple operation. I've tried it in a lab environment, and it did work fine. 


    FIM architect - Crayon AS - www.crayon.com

    Thursday, May 11, 2017 8:46 AM
  • Hi,

    Great feedback Elling! Thanks! We also found out that the problem was the SyncConfig-dn-construction-attribute, but never thought to change the DN Style. I wish we had found it  :)

    Thanks again!

    / Leo


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Thursday, May 11, 2017 9:06 AM