Object reference not set to an instance of an object

Lessons learned:

1. Run the Do a FIM MA account configuration quick test script.

2. Always refresh the schema of the FIM MA using the real FIM MA Service Account which we usually call svc-FIMMA.

Scenario:

You have just modified the schema of FIM Service by creating a new Boolean attribute and have bound it to the user resource type. You refresh the FIM Schema, select the new attribute setup a direct export attribute flow from the corresponding Boolean metaverse attribute to the FIM MA attribute. You sync and the only pending export is to this attribute, and then when you run the export to FIM MA you get:

failed-modification-via-web-services

Then when you click on details:

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:

I have encountered this twice and Brad once. The first time (1 month ago)  I discovered that the FIM MA was set to use the svc-fimws (this is the credentials used to run the FIM Service) user account instead of the svc-fimma (the account that actually belongs to the Synchronization Engine Set and therefore has all of the permissions to modify objects in the portal and bypasses the authn and authz workflows and is sometimes referred to as the Built-in Synchronization account). So I changed the FIM MA to use the svc-fimma account and when prompted clicked yes Refresh Schema.  The Do a FIM MA account configuration quick test script had told me that the two weren’t the same (go FIM Scriptbox!)

Which means that when I ran the refresh schema the first time it was under the svc-fimws account not the svc-fimma account.

The second time we refreshed the schema using the credentials of an admin user as opposed to the svc-fimma credentials. I tried refreshing the schema with the svc-fimma account but of course it said no changes. I tried stopping and starting all of the services. I turned on messaging logging (this isn’t even sending messages it is dying on the MA without even talking to the web service). So after carefully studying my memory (foolish me I didn’t blog it or make a note) and the request history on the other system I remembered what the root problem and solution had been. But I had already checked if the MA was using the true Built-in Synchronization Account using the Do a FIM MA account configuration quick test script . So then I thought what if I create the exact same problem I had last time and then fix it. So I changed the FIM MA to use an admin user account and when prompted clicked yes Refresh Schema. Then I changed the FIM MA to use the svc-fimma account and when prompted clicked yes Refresh Schema. Then my export worked!

Lessons learned:

1. Run the Do a FIM MA account configuration quick test script.

2. Always refresh the schema of the FIM MA using the real FIM MA Service Account which we usually call svc-FIMMA. (Anyone from Microsoft want to give an official statement of best practice on that?)

I plan to repro this in a test environment to ensure this is the problem.

http://feeds.feedburner.com/IdentityLifecycleManagerilmBestPractices