Until I can repro this I'll track this issue here... This has cropped up a few times as I'm extending the portal schema. For this most recent experience, I added a new binding for an existing object to a second object class. Here is the breakdown: AttributeTypeDescription System Name: msExchHideFromAddressLists DisplayName: Hide in Outlook Address Books Data Type: Boolean Binding Resource Type: Group Attribute Type: Hide in Outlook Address Books Binding Resource Type: User Attribute Type: Hide in Outlook Address Books Adding the first binding worked, but adding the second binding most recently cause my problem to surface. I have other attributes successfully bound to both user and group that do not present problems. The error presents itself as I am trying to contribute the existing values from my AD MA - flows are setup throughout the FIM MA to contribute the AD value into the portal and it attempts to export but throws a 'failed-modification-via-web-services' error on the export. Looking at the pending export: Only the msExchHideFromAddressLists is being exported (Change=add, Modification type = update, Person object) Previous state of the attribute is NULL (it was never set previously) in the portal Updates to other attributes in the export succeed as long as this attribute is not also listed on the same object (to be expected) Error Information Running management agent: FIM MA Error: failed-modification-via-web-services Connected data source error code: <none listed> Connected data source error: <detail button> Call Stack Information: There is an error executing a web service object modification request. Type: System.NullReferenceException Message: Object reference not set to an instance of an object. Stack Trace: at MIIS.ManagementAgent.RavenMA.DoAttributeLevelExport(DataSourceObject dsObject, String objClass, UninitializedResource resource) at MIIS.ManagementAgent.RavenMA.ExportObjectModification(DataSourceObject dsObject, SchemaManager schemaManager) at MIIS.ManagementAgent.RavenMA.Export(DataSourceObject dsObject) Inner Exception: ----<there was no exception listed> Event Logs: Application: None, other than general 6100 error indicating there were errors on the export System: None Forefront Identity Manager: None (with Verbose enabled) Service Logs: tracing enabled, no errors logged Search Requests (portal): no requests are logged for the failed requests I have made sure of the following: Refresh Schema on the FIM MA, several times Full Import successful on the FIM MA (at least one clean full, but occasionally the "case" issues popup regarding export not reimported errors) Full Sync completed on the FIM MA The same attribute can be modifed directly in the portal without error The fact that I have no request objects tells me this is some issue on the FIM MA side, but I can't get the error to clear. In the past, some combination of refreshing the schema was able to clear this condition. Anyone else come across this? I doubt I could repro it...Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Ok...well, thanks for the catharsis, on a final 'hail mary' I restarted the FIMSynchronizationService and that actually fixed the problem. I'm not sure why, but it did. Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

I keep bumping into this and I think for anyone else who is they'll find this post. I think the best run-down of all the options to try is at Thomas' blog: http://setspn.blogspot.com/2010/06/error-when-exporting-to-fim-ma-failed.html But really, the best solutions that I can find is along the lines of "Turning it off and on again seems to make it work" and this is far from being an actual solution for production systems. From what I can gather, the error presents when you attempt to extend the schema, and then export values to the new attributes you've added. For my particular client, it worked fine in the dev environment but then encountered this error when we went to production. I have noticed, however, that their development environment is running a higher version of FIM than production, so will schedule some time to put the latest version into production - of course, since we'll have some downtime when we do this, we'll try the "turn it off and on again" approach, so it will be hard to know exactly what fixes the problem (if it does). Anyone else got any other suggestions aside those mentioned by Brad or in Thomas' blog? - Ross Currie