Aftercreate/Aftermodify script/Rules is not triggering

[vishnujothi]

Context: We are trying to migrate one of our IQservice to a new server.

As part of it I am testing the provisioning of users in Active Directory.
And while all the provisioning and deletion of user accounts in AD is going through as expected, the Aftercreate and Aftermodify powershell script are not triggering in the new IQService machine.

What could be the reason for this strange behavior?

So far we have ruled out or verified the following things.

• The IQ service server connection parameters.
• Access permission of service account used to connect to the IQService server
• The required connection ports
• The file path of the powershell scripts.
• Even reinstalled the IQService.

I am pondering if I need to reinstall Client/Server authentication certificate to rule out possible TLS issue, But I did feel like it is not the issue since the VA to IQservice server SSL port test was successful.

What could cause this Issue? Have anyone else came across something like this? Any Suggestions on how to solve this?

[sukanta_biswas]

@vishnujothi -

Since AD CRUD is working but the AfterCreate/AfterModify PowerShell isn’t firing on the new IQService host, the connector → IQService round-trip is fine; the failure is almost certainly on the IQService box or in the source’s script configuration. Here’s a focused runbook that usually flushes out the culprit fast.

---

Quick wins (the usual culprits)

1. Script hook actually enabled on the Source

• In ISC → Connections → Sources → (your AD source):

  • Verify the After Create Script and/or After Modify Script sections are filled and enabled.

  • Confirm the path is local to the new IQService (not the old host) and is identical to what IQService will call (watch out for drive letters, spaces, and quoting).

2. Execution policy / script trust

• On the new server (open both 64-bit and 32-bit consoles just to be safe):

  $PSVersionTable.PSEdition
  $env:PROCESSOR_ARCHITECTURE
  gcm powershell | fl Source
  Get-ExecutionPolicy -List
  
  

• Make sure LocalMachine or Process isn’t set to AllSigned or Restricted.

• If the scripts were copied from another machine or downloaded, unblock them:

  Unblock-File "C:\Path\To\AfterCreate.ps1"
  
  

• To test quickly (temporarily):

  Set-ExecutionPolicy Bypass -Scope Process -Force
  
  

3. Service account context

• Confirm the Windows service “SailPoint IQ Service” is running under the intended domain service account (not LocalSystem if your script needs domain access).

• That account needs Log on as a service, local Read/Execute permission on the script file/folder, and network share rights if the script touches UNC paths.

• If the script uses the ActiveDirectory module, ensure RSAT / AD PowerShell module is installed and available in the same architecture IQService uses (more on x86 vs x64 below).

4. AppLocker / WDAC / AV

• If the org enforces AppLocker or Windows Defender Application Control, PowerShell may be in Constrained Language Mode or blocked entirely.

  • Check: Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB and Event Viewer → Applications and Services Logs → Microsoft → Windows → AppLocker and Windows PowerShell (Events 400, 403, 600).

  • Ask security to whitelist powershell.exe (and pwsh.exe if you use PowerShell 7) for the IQService service account and allow the script path.

5. 32-bit vs 64-bit mismatch

• Some environments end up launching 32-bit PowerShell; modules like ActiveDirectory may only be installed in 64-bit.

• In your script’s first lines, log the bitness:

  '[{0}] PS: {1} 64Bit:{2}' -f (Get-Date), $PSVersionTable.PSEdition, [Environment]::Is64BitProcess |
    Out-File C:\IQS\ps_hook_trace.txt -Append
  
  

• If you need to force 64-bit, explicitly call:

  C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  
  

  (Avoid SysWOW64.)

6. Path & quoting

• If the path has spaces, ensure the source config quotes it properly. Prefer a simple path like:

  C:\SailPointScripts\AfterCreate.ps1
  
  

---

Prove whether the hook fires at all

1. Create a trivial script on the new host:

# C:\SailPointScripts\_ping.ps1
"[$(Get-Date -Format o)] hello from $env:COMPUTERNAME as $env:USERNAME 64bit=$([Environment]::Is64BitProcess)" |
  Out-File C:\SailPointScripts\_ping.log -Append -Encoding utf8
Exit 0

2. Point AfterCreate (and/or AfterModify) to that file and provision a test user.

• If _ping.log does not update, the script isn’t being invoked → focus on policy blocks, permissions, execution policy, or the source toggle/path.

• If it does update, your original script likely fails early (module missing, path not found, etc.). Keep logging and add Start-Transcript for more detail.

---

IQService diagnostics

• IQService logs (default install dir) often show entries like “invoking external script.” If they’re too quiet, enable DEBUG/TRACE in IQService.exe.config / log4net config (varies by version), restart the service, and repro.

• Windows Event Viewer:

  • Application log: errors from IQService host process.

  • Windows PowerShell log: script engine start/stop and errors.

• If you see PowerShell 7 (pwsh) on the box and you rely on Windows modules (like ActiveDirectory), prefer Windows PowerShell 5.1 (powershell.exe) for compatibility.

---

Environment mismatches vs the old server

Things that often differ after a migration:

• RSAT / ActiveDirectory module not installed (or only in 64-bit while caller is 32-bit).

• Credential context changed (LocalSystem vs domain svc acct).

• ExecutionPolicy locked by GPO on new OU.

• AppLocker/WDAC/InTune policies stricter on the new host.

• Antivirus blocks powershell.exe for services.

• Script path points to an old drive letter or a share the new service account can’t reach.

• TLS/cert: not relevant to script invocation (that’s local). Since the AD ops are succeeding and VA↔IQService SSL test passes, reinstalling the IQService certs won’t fix a non-firing script.

---

Minimal verification checklist

• Source has AfterCreate/AfterModify set and enabled on the new host path.

• Test ping script writes to a log when you provision/modify.

• Get-ExecutionPolicy -List allows execution (scripts unblocked).

• Service account runs IQService and can read/execute the script; UNC shares accessible.

• No AppLocker/WDAC/AV block; PowerShell event logs are clean.

• Correct bitness and modules present (RSAT AD).

• IQService logs show “invoking external script” (enable DEBUG if needed).

Cheers!!!