I’m reposting this over here because I haven’t gotten any responses in the Compass forum. I’m curious if anyone else has experienced issues with IIQ not sending some email occasionally. We are on IIQ 8.0p1, and have IIQ configured to send email through an email relay server, so it doesn’t login to an SMTP server. Normally we have no issues with this for most email communication, but we have noticed that at some point we will stop getting emails out of IIQ, not all, but some of them. This is typically seen with our password expiration policy for AD accounts. These don’t show up in the audit logs as an emailFailure so the only way we know about them is to check under the “Request” objects in debug, which has a record for each one that failed. This issue isn’t identity specific, our password policy will send email for 15 days, and we have had the same user get 10 in a row and then the 11 won’t send and shows up in the request table. It also isn’t task server specific. When we stop and restart our task servers, they will then send all the “queued” messages. The problem is that this can happen three or four weeks after it should have been sent which causes confusion with our user base, because it can show up long after they have already reset their password. We do have 20 retries configured for the email settings, but I’m assuming since this isn’t really failing, it doesn’t retry? The log files after a restart will show the following lines for each queued request:
Is anyone aware of a fix for this issue, besides not using an email relay? I have started just manually deleting these records from debug whenever we have to restart so that these old email aren’t sent, but that definitely doesn’t feel like the right thing to do. I’m wondering if I could write a small beanshell script to restart these without have to restart the servers?
HI! We use IDN - and are having folks raise the same issue with us specifically to the AD password reset required…I can’t see anything in the logs either.
We just upped our timeout for the provisioning side, but I was coming in here to see if anyone had a solution as well.
I had spoken with a SP Support person asking “How can I tell in the logs for this scenario” and got nothing but crickets.
I have reached out to some of the users as of late to find out if they are really getting the emails or not at all. Those that said “not at all” I have them checking for an Outlook Rule, or that they blocked/sent to Junk.
Thanks for your response, interesting that you are seeing this issue in IDN as well, look forward to any updates you might have. We are currently upgrading to IIQ 8.3, but may migrate to IDN next year.
As a result of not getting any response from SP in the forums regarding this issue, I took to “resolve” it myself by writing a short beanshell script that I run as a task after my policy refresh. It basically just looks for the requests with our expiring password email template in the name, a null “type” value, and a not null “launched” value. Once it gets a list, it just does a “request.setLaunched()” to null, which will cause IIQ to try the send email process again. This is very similar to how the “Partition Maintenance” script works on stalled request partitions. The second attempt always seems to complete successfully, and the emails are sent. Why it doesn’t work the first time is total mystery.
I will have to save this cuz it seems to have picked up more and more in recent months that we are getting failures or folks say “they did not get it”.
You can adjust these is the Email request definition. 10 get sent out at a time and the rest get queued as request objects. I would avoid a relay if possible.
cuz it seems to have picked up more and more in recent months that we are getting failures or folks say “they did not get it”.