none
Failed-modification-via-web-services error RRS feed

  • Question

  • Hi,

    I am back with this error again, I posted earlier and though that I had found the cause of this. Previous post is here: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/01f0a134-06ad-4423-92ae-165eba169419. I had reviewed all my Sets, WF, MPRs and SRs to ensure that there are no conflicting rules.

    the failed-modification-via-web-services error only occur to certain or a few objects, it only occurred on about 56 objects.

    The error detail shown on the object in the Synchronization Service Manager is :

    "Fault Reason: The endpoint could not dispatch the request.\r\n\r\nFault Details: <DispatchRequestFailures xmlns="http://schemas.microsoft.com/2006/11/ResourceManagement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><DispatchRequestAdministratorDetails><FailureMessage>Exception: Other
    Stack Trace: Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other ---> System.Data.SqlClient.SqlException: Reraised Error 2627, Level 14, State 1, Procedure DoEvaluateRequestInner, Line 1073, Message: Violation of PRIMARY KEY constraint 'PK__#A0E8A54__5330D0773EDCE1BF'. Cannot insert duplicate key in object 'dbo.@transitionOutApplicableRuleBuffer'. The duplicate key value is (13520, 43658, 147).
       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
       at System.Data.SqlClient.SqlDataReader.get_MetaData()
       at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
       at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
       at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteReader()
       at Microsoft.ResourceManagement.Data.DataAccess.DoRequestCreation(RequestType request, Guid cause, Guid requestMarker, Boolean doEvaluation, Int16 serviceId, Int16 servicePartitionId)
       --- End of inner exception stack trace ---
       at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation, Nullable`1 serviceId, Nullable`1 servicePartitionId, UniqueId messageIdentifier, UniqueIdentifier requestContextIdentifier, Boolean maintenanceMode)
       at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Put(Message request)</FailureMessage><DispatchRequestFailureSource>Other</DispatchRequestFailureSource><AdditionalTextDetails>Request could not be dispatched.</AdditionalTextDetails></DispatchRequestAdministratorDetails><CorrelationId>6ffcb0b5-2357-4aaa-b044-b59c34cea4fd</CorrelationId></DispatchRequestFailures>"

    All the objects failed with a similar error description. In the FIM portal the request stays in the "Validating" state.  I also confirmed that there are no validations on any attribute that could cause this.  As I have indicated above this only happen to certain user objects.

    By looking at all the requests on these objects, they all had one thing in common - On a few requests there is a remark which states:

    "Requests cancelled by system because it was not recoverable after a service restart, the last requeststatus recorded prior to cancelling was, Validating"

    I think what is happening, is that there are still rules in a queue or buffer somewhere which had not completed yet. The synchronization service is exporting these because no confirmation is received - resulting in the duplicate key error above.

    My question is:

    Is it possible to remove these failed requests without deleting the object in the FIM Portal? (really don't want to do that as that will mean that the business rules will not apply on these objects)

    Thanks

    Johan Marais 


    JkM6228

    Wednesday, May 29, 2013 6:27 AM

Answers

  • Hi All,

    This has been identified as a product issue for FIM build below version 4.1.3508.0and an update KB 2913228 has been released to address the issue

    Regards

    Johan Marais


    JkM6228

    • Marked as answer by Johan Marais Monday, September 29, 2014 8:58 AM
    Monday, September 29, 2014 8:58 AM

All replies

  • Hello Johan,

    I'm running into this error as well. Were you ever able to resolve it?

    Thanks

    Wednesday, November 6, 2013 8:57 PM
  • Aaron,

    I have resolved some of the causes of this, and for one I changed the process to work around the issue.  In my case this happened in the following scenarios:

    1. Conflicting rules in the FIM portal - these I resolved by working through all the rules that are activated when a user moves in or out of a Set, this process can take a long time depending on the number and complexity of the rules in your installation. (It would have been really helpful if there was some tool to indicate which WF, MPRs, Sets and SRs are involved on an object - I have done something in access but it is al lot of manual work :-))

    2.  When the FIM portal is very busy, this also happens.  We are busy rolling out SSPR and sometimes when exporting to the FIM portal I might get this error as well, I then just do another export after which the error goes away

    3.  The third condition which caused this in my case, I have posted here http://social.technet.microsoft.com/Forums/en-US/19cc5e9a-e5b2-48bb-8b67-299c5b0c4522/failedmodificationviawebservices-when-running-an-export-on-the-fim-ma?forum=ilm2 about this issue. With this one I was not able to resolve it and changed the process in how users are handled to work around this issue.

    What I can suggest is to  maybe also take one user with the problem and change the attributes one at a time to see which is causing the problem.

    Hope this helps and give you some idea of what to look for and where to start. 

    Regards

    Johan Marais


    JkM6228

    Thursday, November 7, 2013 5:29 AM
  • Thanks Johan, I appreciate your time so long after your original question.

    It looks like I'll need to find another way to configure the process as well.
    I was able to determine exactly which transition out MPR was causing the issue as you suggested. After doing so I tried a few other things to see if I could solve the problem.

    1. I deleted and recreated the MPR, Set, and workflows with no luck. I also tried creating with different names with no luck.

    2. I narrowed down the set criteria. The set is fairly with 7 is nots on the same attribute and a date time calculation. I removed 6 of the is nots leaving only one. The export still did not work.
    Note: If I remove all the is nots it works but that's because the user is no longer transitioning out

    3. I further narrowed the set criteria down to a single is not and no other criteria and still no luck.

    4. Lastly, like step 3 I limited the set criteria to a single is not and no other criteria but this time with an attribute that was not in the original set criteria. Still no luck.

    One other thing I found strange is that if I make the same exact changes to the user directly in the FIM Service/Portal than everything works fine. It only happens from the sync engine.

    So far my conclusion is:
    With the steps performed above I've concluded that the Sync Engine is unable to transition a user out of a set when the set criteria contains an "is not" and the sync engine is exporting a change on the same attribute that means the user would transition out of the set.
    In other words,
       a. A user starts with a JobCode of 3.
       b. My set criteria is JobCode is not 7. Therefore the user is in the set.
       c. The user's JobCode changes to 7. The sync engine is unable to allow the change so the user is unable to transition out.
    Note: The user's JobCode can be changed to 7 via the portal with no problem and the user transitions out as expected.
    Note: My attributes in the criteria are defined in the "Synchronization: Synchronization account controls users it synchronizes" MPR

    Additional Information:

    • The build I'm working with is 4.1.3419.0

    Johan, does any of your configurations conflict the test I ran above?

    Thanks

     
    • Edited by Aaron Lentz Friday, November 8, 2013 4:20 PM
    Friday, November 8, 2013 4:14 PM
  • Aaron,

    Are you running on FIM 2010 R2? The version I am on is 4.1.3451.0, seems that you are an update behind.

    When you look at the error detail in the sync engine do you also see "Violation of PRIMARY KEY constraint 'PK__#A0E8A54__5330D0773EDCE1BF'. Cannot insert duplicate key in object 'dbo.@transitionOutApplicableRuleBuffer'. The duplicate key value is (13520, 43658, 147).
       at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)" 

    as part of the error, obviously the detail in your error will be different.  Also when I look at the requests in FIM portal, the object with the failed-modification-via-web-services error shows "validating", is yours the same?

    in my case I also found that if a specific value, proxyaddress, is changed manually in AD it causes this error. And in my case this attribute is never used in any criteria.  I doubt if it is the Set condition "is not" which is causing this, I am using "starts with" and have the same problem.  I also found that by changing the value in the portal manually which cause the object to move out of the Set makes the problem go away.

    As indicated in my case it was possible to change the process on the service desk and I split the SR into two parts to apply this, but this will not be possible in any scenario.

    Do you have only one Set based on your JobCode?

    Another question, do you have only WF, MPR and SR applying on the object when the JobCode changes?  if you do the change manually, does the relevant MPR, and other rules apply correctly.

    If I may ask, what happens to a user when the jobcode changes?

    Regards

    Johan


    JkM6228

    Wednesday, November 13, 2013 6:31 AM
  • I have the same issue with "validating" and in FIM Event Log I get

    Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other ---> System.Data.SqlClient.SqlException: Reraised Error 50000, Level 14, State 1, Procedure ReRaiseException, Line 37, Message: Reraised Error 2627, Level 14, State 1, Procedure DoEvaluateRequestInner, Line 1073, Message: Violation of PRIMARY KEY constraint 'PK__#45XXXXX__5330D07746XXXXXX'. Cannot insert duplicate key in object 'dbo.@transitionOutApplicableRuleBuffer'. The duplicate key value is (938880, 150315, 32644).

    Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0.

    Friday, December 6, 2013 7:04 PM
  • Hi All,

    This has been identified as a product issue for FIM build below version 4.1.3508.0and an update KB 2913228 has been released to address the issue

    Regards

    Johan Marais


    JkM6228

    • Marked as answer by Johan Marais Monday, September 29, 2014 8:58 AM
    Monday, September 29, 2014 8:58 AM