none
Weird exchange error - Property RoleAssignmentPolicy can't be set RRS feed

  • Question

  • All,

    We recently moved to exchange 2010. Some users are still in 2007. We have ADMA to do the new user provisioning in exchange 2010 (settings in the configure extension property tab- default Exchange2010.dll). Provisioning of 2010 user works fine. But whenever an attribute needs to be updated for 2007 user, i am getting ma-extension-error in AD export error.

    In the event logs,

    Property RoleAssignmentPolicy can't be set on this object because it requires the object to have version 0.10 (14.0.100.0) or later. The object's current version is 0.1 (8.0.535.0).

    It looks like fim is trying to set role assignment policy for the 2007 users. Any workaround to solve this?

    Friday, June 7, 2013 11:48 PM

All replies

  • Did you ever get a solution to this problem? I am experiencing the exact same problem (exact same scenario, too!)
    Thursday, October 23, 2014 8:30 PM
  • What version of FIM are you using? I think one of the fim hotfix solved this issue.
    • Proposed as answer by Jim Mulvey Friday, October 24, 2014 2:58 PM
    Friday, October 24, 2014 1:04 PM
  • Thanks for replying! I'm running FIM 2010 R2, with SP1 (4.1.3419.0).

    Friday, October 24, 2014 1:17 PM
  • You can try updating the version. Also, checkout the values of all 3 mandatory exchange attributes. exch 2010 prov msexchServerName is different from 2010 provisioning. 

    http://www.puttyq.com/fim-2010-provisioning-roleassignmentpolicy-error/

    Friday, October 24, 2014 1:42 PM
  • You were right! There was an update rollup that corrected an issue whereby, if Update-Recipient failed, the entire Management Agent was unloaded leaving the remaining pending exports unattempted. In our case, We have a hybrid environment with Exchange 2007 and Office 365. So there is no Update-Recipient endpoint (2007 or our Hybrid servers) for us to point our ADMA where it will be successful in calling Update-Recipient on both Exchange 2007 and O365 users.

    Now, with this update rollup, we point it to the Exchange 2007 endpoint. We still get export errors when the ADMA makes any attribute change to an O365 user, but the attribute change is made, and is confirmed on the next export. We just have to live with our ADMA giving errors all the time. Which, compared to the many other horribly inexplicable difficulties FIM has in managing the Microsoft cloud, is very acceptable.

    Friday, October 24, 2014 2:57 PM
  • Fortunatley, exchange was completely migrated to 2010. So, I was able to get rid of the ADMA errors.
    Wednesday, October 29, 2014 3:54 PM