I did the following: - added some attributes in the MetaVerse to Person - updated the list of attributes handled by the FIM agent - include the new attributes in the FIM attribute flow The problem is that when I try to use these attributes in an inbound synchronization rule, the new metaverse attributes do not appear in the list of available attributes. I tried without success every workaround suggested in this thread: "Custom Attributes bound to a user/person not availabe in Sync Rule or in ILM MA ". Has someone experienced something similar, or is this a known problem? Thanks, Paolo Paolo Tedesco - http://cern.ch/idm

After some investigations it seems to be, that Metaverse Configuration Object (mv-data) is not being updated when we modify Metaverse configuration. We've added some attributes in the Metaverse and as Paolo has already said they do not appear in a list for an inbound sync rule. We've also tried to DELETE an attribute from the Metaverse and it is still present in FIM list. After a synchronization we have the following error shown in Sync engine: "The destination attribute <deleted attribute> referenced in a flow mapping is not defined within the schema." This proves the fact, that mv-data is not updated. Has anybody experienced this behavior? Any comments? Thanks in advance! Alexey

Small update from Event Viewer: BODY {background-color:#f2f5fe;margin:0px 2px;font-family:MS Shell Dlg 2;direction:ltr;word-wrap:break-word;color:#000000;font-size:9pt;overflow:auto;} DIV#ColorBandedheader {background-color:#ffffff;} DIV#ColorBandedcontent {background-color:#ffffff;} 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. Additional information: Error Code: 0x80230709 Error Message: (The extension operation aborted due to an internal error in FIM Synchronization Service.) Operation: Update MV Name of the MA to replicate: Guid of the MA to replicate: Name of the target MA: FIM Guid of the target MA: <GUID>

I've run into this scenario before but don't recall that error message. The problem in my case was permissions on the FIM MA account. You can start to verify the FIM MA permissions by:1. Try running imports/exports on your existing FIM MA2. Try to create a new FIM MA with the same credentials as your problem FIM MACraigMartin Edgile, Inc. http://identitytrench.com

Hello Craig! FIM MA successfully processes all objects during imports and exports (including new sync rules etc). Have you assigned specific permissions to solve the problem?

I've been struggling with this exact problem myself today. In the end I reinstalled. Sorry I can't be of more help.http://www.wapshere.com/missmiis

Hi Alex, first thing you should do is file this as feedback on Connect. That gets a fresh bug created for the FIM team to triage, like instantly hiring a team of devs and testers to look at your issue ;-)In the interim to troubleshoot, I'd do the following:1. Check the MPR that grants permission on sync resources: Synchronization: Synchronization account controls synchronization configuration resources Maybe it got disabled or somehow maimed. In that case I'd expect an access-denied error instead of internal-error but who knows.2. Turn on tracing in the FIM Service then watch for the error. The error you're seeing in the event log looks like it is coming from FIM Sync, but there is probably more detail on the FIM Service side.If you don't have time to troubleshoot then Carol's method will probably get you up and running sooner.[Update] I can repro your error message by disablin this MPR:"Synchronization: Synchronization account controls synchronization configuration resources"When it happens I do not get anything in the FIM trace log but I do see the corresponding request with an 'Access-Denied' status. So in my case, security is working. In your case you should look for access-denied requests using the FIM portal, then troubleshoot the MPR to see why your FIM MA account does not satisfy the MPR. CraigMartin Edgile, Inc. http://identitytrench.com

Hi Craig, the MPR is not disabled, and it does not look corrupted either. Its definition is as follows: grants permissions: checked requestors: specific set -> synchronization engine operations: create, delete, add, remove, modify resource definition before request: all ma-data and mv-data resources resource definition after request: all ma-data and mv-data resources resource attributes: specific set -> MV Resource ID;Description;Display Name;Expiration Time;Resource Type;SyncConfig-category;SyncConfig-refresh-schema;SyncConfig-import-attribute-flow;SyncConfig-mv-deletion;SyncConfig-provisioning;SyncConfig-provisioning-type;SyncConfig-password-change-history-size;SyncConfig-ma-run-data;SyncConfig-capabilities-mask;SyncConfig-export-type;SyncConfig-dn-construction;SyncConfig-password-sync;SyncConfig-component_mappings;SyncConfig-controller-configuration;SyncConfig-password-sync-allowed;SyncConfig-ma-ui-settings;SyncConfig-private-configuration;SyncConfig-encrypted-attributes;SyncConfig-ma-partition-data;SyncConfig-join;SyncConfig-projection;SyncConfig-export-attribute-flow;SyncConfig-provisioning-cleanup;SyncConfig-provisioning-cleanup-type;SyncConfig-extension;SyncConfig-version;SyncConfig-format-version;SyncConfig-internal-version;SyncConfig-schema;SyncConfig-attribute-inclusion;SyncConfig-stay-disconnector;SyncConfig-id;SyncConfig-sub-type;SyncConfig-ma-listname;SyncConfig-ma-companyname;SyncConfig-creation-time;SyncConfig-last-modification-time We turned tracing on in the service, but we couldn't find more meaningful details in the logs. Also, we noticed that the metaverse configuration is somehow corrupted: the values for the "import flow" of some attributes in the MetaVerse Designer are inconsistent. Check this screenshot: Looks like reinstalling is the only option left :( Cheers, Paolo Paolo Tedesco - http://cern.ch/idm

Don't forget to look in the Request history for requests with Access-Denied. You might see these after you modify the MV schema, indicating a permissions problem, likely caused by an MPR issue.CraigMartin Edgile, Inc. http://identitytrench.com

Hi Paolo,Just to close that the side problem you brought up.The "7" you see is the total number of mappings to that attribute. The Precedence popup UI actually collapses based on MA so that there is only one row per MA. Don't worry, this won't cause you any problems. We already have a work item tracking this clarity bug.

Hey Masters, long time no see us. Recently, I've got the same problem, and the solution was: For the fix the problems I Installed from Catalog Microsoft Update - http://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB978864 The file is (Forefront Identity Manager 2010 Service and Portal Update (KB978864)): AMD64-all-fimservice_kb978864_278035fa26956c67250afaac87b94ff34e490f82.exe And Forefront Identity Manager 2010 Synchronization Service Update (KB978864) AMD64-all-fimsyncservice_kb978864_528513e44779ba22e2e04a3c0013339c5060cb5d.exe Reboot the FIM Server, I'dont know why, but Microsoft windows like so much it! (just a kidding) After that reflesh the schema on Synchronization - Metaverse Agents - FIMMA and Vua ´la It worked!