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 .
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.
Include, at the appropriate timestamps: IQService log which shows the failure, the raw Cloud Gateway response back to IIQ, the full ProvisioningRequest/ProvisioningResult XML showing status=“committed” and the IdentityRequest object. (The raw gateway response is what Pujan asked for twice; it shows that the error made it to IIQ’s boundary intact and was discarded there.)
Please post back what Support concludes. If this is a general problem with the Windows Local adapter’s error handling rather than something specific to your environment, a number of people who use that connector will want to know about it.
@ksuneeth85 Good that you’ve opened a support case — this is definitely the right move given what you’ve confirmed so far. I wanted to add a few additional angles that haven’t been covered in this thread yet, which may help both your support case and others who encounter this.
If you have an AfterProvisioning rule configured on the Windows Local application, verify that it isn’t inadvertently overwriting or resetting the ProvisioningResult status.
There’s a possibility that the IntegrationExecutor layer (which sits between the Cloud Gateway response and the final ProvisioningResult written to IIQ) is not correctly mapping error responses from the gateway into a STATUS_FAILED ProvisioningResult.
Enable DEBUG or TRACE level logging for Windows connector and Cloud Gateway Service and capture the logs.