Windows local connector showing request status success even it is failed at target end

Which IIQ version are you inquiring about?

8.4p2

We have a windows local connector and we are connecting to target using cloud connector gateway and we have IQservice also for provisioning. In UI , we have changed the target service account password , we can see that , aggregation is failing , but when I placed a access request , I can see provisioning transaction is committed and request status is completed successfully. But after running account aggregation with right password , the requested changes are not applied. i.e. the request status is showing as success even if it is failed. Is that intended behaviour ? we have not enabled even optimistic provisioning flag .

Hi @ksuneeth85,

Could you check the IIQ logs and IQService logs at the exact timestamp of that provisioning transaction and see whether there’s any RPC/IQService error logged there?

Also, Can you also see the ProvisioningResult status from that request.

Hello Suneeth. I would first try to confirm where the failure is getting lost.

With the incorrect Windows Local service-account password still configured, run Test Connection, then submit another access request and check the ProvisioningResult along with the IQService and Cloud Gateway logs.

Optimistic Provisioning should not be the cause here. It only affects when IIQ updates the Identity Cube. It should not make a failed connector operation return committed.

If Test Connection fails or the IQService logs show the target operation failed, but the AccountRequest still shows <ProvisioningResult status="committed"/>, that would suggest the failure is not being propagated correctly through the Windows Local → Cloud Gateway → IIQ path. In that case, I would raise a SailPoint Support case with those logs and the provisioning transaction.

I would also confirm that IIQ and Cloud Gateway are both on 8.4p2, since their versions are required to match.

we have checked the iiqservice logs, it is failed only. Then cloud gate way is returning the same error to windows multi adaptor class. Then it is changing into committed state and ignoring the iqservice error

@ksuneeth85 Would you mind sharing the error logs from IQService at that timestamp, along with the raw response Cloud Gateway sends back to IIQ for that same call? Want to see exactly what’s coming back so we can pin down where it’s getting lost.