@PhilRawlings1 -
Since two of the failures turned out to be the stored password on the Log On tab, I’d assume the others are the same until the System log says otherwise. A service whose logon fails never launches its process, which matches what you’re seeing. The IQService trace log is empty because nothing ran to write it. Recovery does nothing because Windows queues failure actions when a running service process terminates abnormally (Microsoft’s SERVICE_FAILURE_ACTIONS_FLAG doc covers the trigger; applying it to logon failures is my reading, not something I’ve tested).
The reason is in the System log, not the IQService log. Filter on Service Control Manager. 7000 and 7038 give the logon error (7038 reference). 7041 means the account doesn’t have the right to log on as a service, so check whether a GPO is overwriting the local right. 7031 or 7034 mean the process started and then crashed, which is a separate problem.
PowerShell:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Id=7000,7031,7034,7038,7041} -MaxEvents 30 | Format-List TimeCreated,Id,Message
cmd:
wevtutil qe System /q:"*[System[Provider[@Name='Service Control Manager'] and (EventID=7000 or EventID=7031 or EventID=7034 or EventID=7038 or EventID=7041)]]" /c:30 /rd:true /f:text
On each failing host, re-enter the password on the Log On tab and restart. Check the primary, secondary and UpdateService entries. Also make sure the account isn’t expired, locked, set to change password at next logon, or restricted by logon hours. The IQService troubleshooting page lists each of those errors.
As for why the quiet servers: a running service keeps its logon session, so a password changed or expired in AD only bites at the next start (reboot, patching, auto update). UpdateService stops and restarts IQService, and per the FAQ it waits until no transactions are running and updates one instance at a time. Idle hosts are the natural first to update. IQService-August-2026 starts auto-updating on October 19, so I’d fix the accounts before then.
If password drift keeps happening, a gMSA removes the stored password. It needs Strong (SASL) authentication, the AD PowerShell module on the IQService host and port 88 open, so read that page against your trust setup first.
If it turns out to be crashes, raise the IQService trace to level 3 and post the matching Application log entry:
iqservice -l 3 -f "C:\Sailpoint\IQService\iqtrace.log"
iqservice -t
PowerShell: .\IQService.exe -l 3 -f "C:\Sailpoint\IQService\iqtrace.log", then .\IQService.exe -t