Troubleshooting Failed-Modification-Via-Web-Services

Troubleshooting Failed-Modification-Via-Web-Services

You are done with the configuration of your environment, you are starting the first run profiles, and when you run an export run profile on the FIM MA, you are running into this error…

Now what?

The first recommendation is to NOT modify the security settings of your FIM related accounts.
This is really a bad idea. So, please don’t touch them at this point…

The “80% reason” for this error is related to the following two areas:

  1. Your FIM MA account is not configured correctly
  2. Your current MPR configuration needs to be updated

The setup procedure grants all FIM related accounts the required access rights to components.
There is no need to manually tweak them.


Verifying the FIM MA account configuration

The account, you have currently configured to be used by your FIM MA has to be the same as the account you have configured during setup. This account also needs the right to logon locally to your FIM server if your FIM computer is a domain controller. How can you verify whether this is true in your environment?

The answer is by running a script! In the FIM Script Box, you can find a PowerShell script to “test the FIM management agent account”. This script will tell you whether there is an issue with your FIM MA account.

If this script fails to complete successfully, you should re-run the FIM setup and correct the configuration of your FIM MA. To do so, go to the “Programs and Features” section in your “Control Panel” and select the repair mode for your FIM installation.

Verifying the MPR configuration

To perform end-to-end synchronization cycles in your environment, you need to:

  1. make sure that all required MPRs are enabled
  2. verify that your MPRs contain all required attributes

Verifying this is the objective of the PowerShell script to “check your MPR configuration for synchronization”. The script lists the MPRs that need to be enabled if they are not enabled yet and it also lists the attributes that are missing in the related MPRs if this is the case in your environment.

Troubleshooting Steps

See Also

note Note
To provide feedback about this article, create a post on the FIM TechNet Forum.
Leave a Comment
  • Please add 2 and 6 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Page 1 of 1 (3 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Tony Soper_MSFT edited Original. Comment: Added a highlight to focus the reader

  • I have followed the above TroubleShooting steps. The first power shell reported no account issues. The second powershell reported two disabled MBR's to enable. I enabled the two MPR's and ran the script again. It now reports no errors. done. I ran the profile runes again and export continues to give "Failed-Modification-Via-Web-Services". I saw 80% of the time this is how you fix it I was hoping to get the last 20 :).

  • Ed Price - MSFT edited Revision 4. Comment: TOC

  • x

  • Chris Clayton, ILM admin edited Revision 8. Comment: Changed the link for testing the FIM MA account from to as the original thread was deleted.

  • I have also seen where half of my requests get this, half do not.  This seems to be performance related when users are being put into sets.  

    For instance, I was able to export users and sync them just fine into the FIM portal from the FIM Sync Service multiple times.  As soon as I added the employeeType attribute into my sync rule, half of the requests would fail each time with "failed-modification-via-web-services".  So 1000 requests, 500 failures.  The next run is 500 request, 250 failures.  Seems to be related to dealing with MPR set transitions and timeouts.

    Since all these users were being put into "All Employees" or "All Contractors" with those export - I think the SQL server just wasn't keeping up.  A chat with Microsoft the other day also came up with similar findings.

  • Running the powershell script to check MPRs and then enabling the suggested MPRs fixed the issue for me. I restarted the service and FIM Sync after, do not know if that was required.

Page 1 of 1 (7 items)