SP8 Clear Provisioning Queue

[Former Member]

Hi all

Having just put in SP8 I went to clear the provisioning queue through the management console and, lo and behold, the menu option is gone (Right click on the Identity Store > Management > Clear Provisioning Queue).  I assume the functionality still exists somewhere.

Has anyone found it before I head to the database with a hammer and a delete query?

Thanks

Peter

[Former Member · Accepted solution]

Hi Peter,

this was removed intentionally. Deleting the provisioning queue may lead to inconsitensy and privileges stuck in pending state. We tried to highlight this using SAP notes, but still customers deleted the provisoining queue without beeing aware of the consequences...since it was possible using the MMC and  thus easy to do.

The intention for this option is for migrating from 7.1 to 7.2. Now once you are in 7.2 pure mode this option is gone from the MMC.

If you for some reason still want to delete the provisoning queue, and now what you are doing incl possible consequences, you can do it using SQL query.

Br,

Are Hegdahl

[Former Member · Accepted solution]

Thanks Are

I understand the reasoning (and in this case agree). Just don't go too far - I've had massive arguments with MS about their software 'protecting' people from themselves by removing functionality.

Peter

[former_member2987 · Accepted solution]

Peter,

You can do just about anything if you know enough about the back end database, however just because you can do it, doesn't mean that it's always advisable.  Trust me, in my years with IDM and MIC before it, I've blown up more Identity Stores in more ways than you've even thought of!

I think that Are's point was more of being careful than anything else!

Good luck,

Matt

[former_member2987 · Accepted solution]

,

What would you recommend as the proper way to do this (besides don't )?

I'm thinking you should probably shut down the dispatchers / event agents after resolving as many approvals as possible and then run the Clear Provisioning queue job from a separate dispatcher or directly from the database console.  I would think this would reduce the chances of bad things happening.

Cheers,

Matt

[Former Member · Accepted solution]

Hi Matt

I was doing it by hand from the DB console but I created a job as well to make it easier when I am no longer 'in residence'.  It's one of a suite that gets left permanently disabled with warnings all over it so it can't be done accidentally.

Peter

[Former Member · Accepted solution]

Hi Matt,

..you are right on don't:-)

If you still want to, here is how i do it:

1)     1. Stop dispatchers

2)     2. Update mxp_audit set provstatus=1100 where auditid in (select auditref from mxp_provision)

3)     3. Delete from mxp_provision

4)      ---If Oracle: COMMIT

5)     4. Start dispatchers

Set provision-status to OK (1100) i audit tabellen.

Alternatively you can set mxp_audit.provstatus to 2000 («task deleted»).

To be on the safe side, copy/backup mxp_provision and mxp_audit table between step 1 and 2 above.

I.e:

Select * into dbo.backup_mxp_provision from dbo.mxp_provision    -- SQL-Server

create table backup_mxp_provision as (select * from mxp_provision);    -- Oracle

Br,

Are

[former_member2987 · Accepted solution]

Thanks Are,

I don't think anyone ever wants to do this in production, but sometimes it is necessary.  It's also good to know how to do it the best possible way!

BR,

Matt

[Former Member · Accepted solution]

There's a huge difference in the complexity of the tables between 7.1 and 7.2. In 7.1 it was reasonable easy to fix the "customer has deleted the provisioning queue" problem by closing the audits.

In 7.2, such a delete provision job, should it exist, would need to close the open audits of tasks in the queue, set the state of links & approvals that are in pending state to OK or Failed, or atleast set mcChecklink to the current time and clear the and add/del/mod audit so its re-evaluted. And also most likely need to delete the PVOs that were in process, and the potentially grouped PVOs from both mxi_entry & mxi_values and fix the other related tables that could otherwise cause changes/approvals/assignments to fail or not process at all for the foreseable future. Most of the tables that needs to be patched are not writable by the runtime account so I'm not really seeing how a job can do this properly, atleast not for production environment use. This is not the description for how to create such a job, its all from memory and probably missing a few vital things

We (Are, me & others in the team) have spent quite a lot of time on support-calls where the source of the problems were deletions of the provisioning queue that someone had decided must be a perfectly normal way of solving performance problems or accidental updates because the option was right there in the menu. We even shipped a job with the product that did the same as a template if I remember correctly with the intent for it to be used in development systems. Production was were it ended up usually. So this option had to go, and good riddance to it! 🙂