none
MIM Custom Attributes: Cannot Update Via Web Service Calls (Export/Import-MIMConfig) RRS feed

  • Question

  • I created a pair of custom attributes in the portal, and as I try to update those attributes via powershell with web service calls (Export/Import-FimConfig), I keep getting the error message shown below. Interestingly the script works with attributes that were installed by default with MIM like pwdActivation, for example. Thus I was left with the following question, when I create a custom attribute is there something else I need to do for it to be visible via web service calls? Do I need to add it to some particular MPR? If so, which one? The attributes have been "bound" to the Person object, and they are working already as part of a group membership criteria. Just in case this matters, those attributes were only needed in the portal, so they were not created in the metaverse. 

    Import-FIMConfig : Failure when making web service call.
    SourceObjectID = 7b75cb8e-eba2-4c3e-a0a0-ff1dbbbb7c80
    Error = System.InvalidOperationException: Operation is not valid due to the current state of the object.
       at Microsoft.ResourceManagement.WebServices.Client.AttributeContainerHelper`1.GetAttribute(String attributeName)
       at Microsoft.ResourceManagement.Automation.ImportConfig.ConvertTypedAttributeValue(String objectType, String attributeName, String value)
       at Microsoft.ResourceManagement.Automation.ImportConfig.UnifiedClientPut(List`1 changeList, UniqueIdentifier objectIdentifier, String objectType, 
    CultureInfo locale)
       at Microsoft.ResourceManagement.Automation.ImportConfig.ProcessLocaleBucket(String objectIdentifier, String objectType, Dictionary`2 localeBucket)
       at Microsoft.ResourceManagement.Automation.ImportConfig.Put(String objectIdentifier, String objectType, List`1 changeList)
       at Microsoft.ResourceManagement.Automation.ImportConfig.EndProcessing()
    At C:\powershell-script-name.ps1:79 char:21
    +     $importObject | Import-FIMConfig -Uri $URI
    +                     ~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (:) [Import-FIMConfig], InvalidOperationException
        + FullyQualifiedErrorId : ImportConfig,Microsoft.ResourceManagement.Automation.ImportConfig


    Friday, May 26, 2017 3:50 PM

All replies

  • 1- Yes you need to add them to the MPR that grants access to this object.  Since the PowerShell runs on behalf of the service account, then the service account needs access to modify them.  If you look in "Search Requests" you will find the failed request which will have the respective MPR that is called. 

    It is not a clear cut which MPR, because it depends what is granting access to the other attributes. For instance if the service account is member of Administrators set (most likely the case), it is usually this one "Administration: Administrators can read and update Users"

    2- You need to add them to the Filter Permissions for Administrators.


    Nosh Mernacaj, Identity Management Specialist

    Saturday, May 27, 2017 12:14 AM
  • I have to apologize to you for just now getting back to your response. I got pulled into something else and had to put this task aside.

    Those two custom boolean attributes had already been added to the Filter Permissions for Administrators, and the account I am using is a member of the administrators set. I looked at result of search requests, and I could not find any denied operation for the object I tried to update.

    I have to admit I am somewhat confused with what I just noticed today after resuming this task. I was able to update those two attributes without any error. This time I did see an entry in the list of requests associated with the object.

    Is there something that was updated automatically by the way FIM works in particular with regard to those SQL server agent jobs running on the SQL server? There has not been any modification to the script regarding the export/import-fimconfig calls.

    Thursday, June 8, 2017 8:58 PM
  • After those changes, you need a iisreset.  seems you have now and all is good.

    Nosh Mernacaj, Identity Management Specialist

    • Marked as answer by Celso G. Lima Friday, June 9, 2017 3:28 PM
    • Unmarked as answer by Celso G. Lima Tuesday, August 1, 2017 8:45 PM
    Thursday, June 8, 2017 9:01 PM
  • Thanks for letting me know about that extra step I was not aware of. I definitely didn't do an iisreset following the creation of the attributes. However, one was done earlier this week for another reason.
    Friday, June 9, 2017 3:28 PM
  • I still need help regarding the scenario described in my original post. Nosh pointed out that I needed to do an iisreset, but based on my experience that does not seem to be enough. There is more than just that. I have done that and even restarted the Forefront service.  

    I added yet another attribute to the portal which was included under the filter permission for administrators. It was also linked to the MPR for the synchronization account.  I can add a value to the attribute using the portal, but I cannot do the same via web services (export/import-config).

    I would like to know how I can manually trigger that process, so the attribute can be available pretty much right away.


    Tuesday, August 1, 2017 8:45 PM
  • I still need help regarding the scenario described in my original post. Nosh pointed out that I needed to do an iisreset, but based on my experience that does not seem to be enough. There is more than just that. I have done that and even restarted the Forefront service.  

    I added yet another attribute to the portal which was included under the filter permission for administrators. It was also linked to the MPR for the synchronization account.  I can add a value to the attribute using the portal, but I cannot do the same via web services (export/import-config).

    I would like to know how I can manually trigger that process, so the attribute can be available pretty much right away.


    An iisreset isn't going to affect the FIM Service layer so I don't think that's your solution.

    If you check the FIM Service event log, that stack looks like something that might have a bit more useful detail there. Make sure you have the object type and attribute names cased correctly in your script - they are case sensitive and FIM provides an error similiar to that if you have them wrong sometimes.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Saturday, August 5, 2017 3:27 PM
    Moderator
  • The attribute is being passed to the import operation with the proper case as displayed in both the portal schema and the result set of an export operation. 

    There are entries in the event log for the FIM service, but they don't provide much information to me based on my current level of experience with this product. However, one thing I did catch my attention. Among the entries associated with the import request that was submitted  I noticed a lot of references to "operation on object ''" like the one below.   

    RequestDispatcher is processing RequestIdentifier 'xyz' for a 'Enumerate' operation on object '' with RequestStatus 'Validated'.

    What I am trying to show is that there is no value associated with the object parameter. Nonetheless the operation is reported as completed after going through all the stages of validation, authentication, authorization and completion. 

    Also, there are no entries under Requests & Approvals associated with the request to update the custom attribute. Interestingly the custom attribute works fine in the inbound/outbound sync rules I have set up.  



    Monday, August 7, 2017 7:04 PM
  • The following lines are what I identified as being associated with the import request.  They need to be read from the bottom up.

    #############

    RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' exited RequestDispatcher with RequestStatus 'Completed'.

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Completed'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'PostProcessing' to 'Completed'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'Committed' to 'PostProcessing'.

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Committed'.

      WS: Action.Enumerate.Execute.Exit

      Query: QueryProcessor.ExecuteQuery.ExecuteReader.Exit

      Query: QueryProcessor.ExecuteQuery.ExecuteReader.Enter

      WS: Action.Enumerate.Execute.Enter

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Authorized'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'Authenticated' to 'Authorized'.

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Authenticated'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'Authenticating' to 'Authenticated'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'Validated' to 'Authenticating'.

      Executing initial authentication.

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Validated'.

      Request '3870280f-ab9c-4bce-8e13-d77060cb3554' status was updated in-memory from 'Validating' to 'Validated'.

      RequestDispatcher is processing RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554' for a 'Enumerate' operation on object '' with RequestStatus 'Validating'.

      RequestDispatcher enter processing pipeline;  RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554'; Operation 'Enumerate'; Object ''; RequestStatus 'Validating'.

      Add request '3870280f-ab9c-4bce-8e13-d77060cb3554' to cache with RequestStatus 'Validating'.

      Entered RequestDispatcher with Request Object; RequestIdentifier '3870280f-ab9c-4bce-8e13-d77060cb3554'.

      Request created: 'Enumerate Request'

      Request '' status was updated in-memory from 'NotFound' to 'Validating'.

      XPathDialectParser.ParseXPathExpression.Exit(/Person[AccountName = 'abcdefgh'])

      XPathDialectParser.Enumerate.BuilderResult(/Person[AccountName = 'abcdefgh'])

      XPathDialectParser.ParseXPathExpression.Enter(/Person[AccountName='abcdefgh'])

      Enumerate(/Person[AccountName='abcdefgh']), Principal(ae7799b0-37a7-4d31-bc88-497a28966c26)

      WS: GetCurrentUserFromSecurityIdentifier.Exit

      WS: GetCurrentUserFromSecurityIdentifier.Enter: S-1-5-21-1829661600-213507255-1050178995-1117

      WS: Enumerate.Enter

    Monday, August 7, 2017 7:17 PM
  • That trace looks normal to me. I don't see your corresponding exception in there.

    Thanks,
    Brian

    Consulting | Blog | AD Book

    Monday, August 7, 2017 8:26 PM
    Moderator
  • I just realized I completely misstated when I wrote I had the correct case for the attribute name. I changed the case so many times thinking it had something to do with the problem that I lost track of my troubleshooting. I have to apologize for that. However, I do believe I had the correct case during one of my first runs which gave me the exception. 

    After making sure I had the case in the script matching the case in the portal based on the attribute name,  I was able to update the attribute as intended.

    I still don't understand why the event log didn't report anything back regarding that exception.


    Monday, August 7, 2017 10:09 PM