I’ve just been troubleshooting sporadic export errors through the FIM MA in a Test environment. The export would fail a couple of times in a row with a failed-modification-via-web-services or failed-creation-via-web-services and the detailed error said something about “AttributeNameViolatesSchema”. Eventually the export would succeed all on its own, without anything else changing.
It turned out to be due to a second FIM Service server that had not had a service restart since some schema updates were applied.
This Test environment has two FIM Service servers but no load balancer, so we have the DNS names pointing to only one server, and the second is a “warm standby”. Even though the DNS name, pointing to only one of the servers, is used in the FIM MA config, since R2 the FIM MA knows about all your FIM Services and can use any one it pleases.
Reference:Â Release Notes for Forefront Identity Manager 2010 R2
It turned out that the standby server had been rebooted recently and the FIM Service had restarted and begun helpfully servicing export operations from the FIM MA. I’ve now set the FIM Service startup to “Manual” on that server so it shouldn’t happen again. Just restarting the FIM Service on the standby server would have fixed the issue as well – but while there may be further schema updates to go into Test I don’t want to run the risk of this happening again.
Note that the snippet above mentions the receiveSynchronizationRequestsEnabled parameter in the Microsoft.ResourceManagement.Service.exe.config file as a way to prevent one or more FIM Service instances from servicing the FIM MA. This is useful in architectures where you have “user facing” and “back end” FIM Service instances, and you only want the FIM MA to talk to the back end server/s. It’s not so good in a warm standby scenario as it’s easy to forget to change the setting if you need to switch to the other server.
