none
Request stays in Authorizing state even after approval RRS feed

  • Question

  • I've been trying to debug this for days now and it completely breaks my lab - until it fixes itself after some random time and then breaks again

    I created a simple approval workflow which seeks approval from [//Target/Owner] when joining an Owner Approval Group. The request makes it to the Group Owner, but when the group owner approves the request, it stays stuck in Authorizing state and the user doesn't become a member of the group. The WF also remains in Running status even after the request is approved. 

    I've seen some similar problems around on the internet, and all seem to suggest Exchange related issues. I don't have an exchange setup in my lab, but I don't think not being able to send an email would completely break the approval process. Besides, it does seem to spring back to life randomly and it all starts working again before breaking - very intermittent.

    I've been messing around with the PS WF activity (which I use to calculate custom approvers), but I have disabled that WF completely for now and I'm just using OOTB activities and approvers.

    Any suggestions on what the issue could be (apart from exchange)? There are no errors in the event logs either, but there are loads of exchange related errors/warnings which are expected. Alternatively, is there somehow I can disable the "feature" where FIM tries to send an email?

    Thanks


    Thursday, September 4, 2014 5:49 PM

Answers

  • Actually I think you will have to accept that. If it is a lab env just put there local SMTP server and point your FIM to this server as mail server and probably you will see your approval workflow working. 

    That is odd behavior which I came across long time ago and I think it is still not fixed. With some efforts you can look into approval and even see why it is like this :). 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    • Marked as answer by kmittal82 Tuesday, September 9, 2014 9:05 AM
    Monday, September 8, 2014 8:59 PM

All replies

  • You can create two sets - one for users with email attribute, second one without. And send approvals only for those WITH email :)

    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Thursday, September 4, 2014 6:23 PM
  • Trouble is I don't have an email environment configured, so none of my users have the email attribute populated. 

    Having said that, I still find it hard to believe the entire approval chain will break if email is not configured

    Thursday, September 4, 2014 9:31 PM
  • I have approvals working in my lab environment without Exchange configured, so I doubt that this is causing your issue. 

    When you approve the request, is it creating the appropriate approval response? Is there anything in your requests that raises red flags? 

    Thursday, September 4, 2014 11:47 PM
  • Yep, the approval responses are generated but the request still stays in Authorizing with the workflow in Running state. 

    What makes this even more bizzare is the intermittent nature of the issue, it just seems to resolve itself after some time then break again. 

    One thing I have noticed is that the problem starts when I use my custom WF to add approvers to the WF dictionary - the first activity is a powershell activity which calculates the approvers and the next one is the OOTB approval activity which sends an email to [//WorkflowData/Approver]. However, the PS script runs just fine, and the approver gets the request but after approval nothing happens (although approval responses are generated)

    Friday, September 5, 2014 8:28 AM
  • Actually I think you will have to accept that. If it is a lab env just put there local SMTP server and point your FIM to this server as mail server and probably you will see your approval workflow working. 

    That is odd behavior which I came across long time ago and I think it is still not fixed. With some efforts you can look into approval and even see why it is like this :). 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    • Marked as answer by kmittal82 Tuesday, September 9, 2014 9:05 AM
    Monday, September 8, 2014 8:59 PM
  • Thanks for your reply Tomek, guess I have to live with this :)
    Tuesday, September 9, 2014 9:05 AM