Correct, users are only flagged as Disconnected Participants either when they try to log into Windchill, or when there's some change to Teams and Groups they're members of. Constantly querying LDAP would not only be a huge drain of resources for the Windchill server, but for the LDAP server as well.
Also, since changes in Team and Group memberships are done in the background using the CtmdRecomputeMembershipQueue, the repairNeeded flag will only be toggled once the particular entry in the queue is processed, which depends entirely on the number of entries in the queue, And the same goes for the EmailQueue for that matter. So there's always going to be some gap between the time a user gets marked as Disconnected and when the Windchill Administrator is notified about it.
As a rule, the vast majority of Disconnected Participants are simply users that have left the company, so log-in failures aren't really an issue. There are infrequent cases where a user is Disconnected because they were moved to a different LDAP branch. When things like this happen, the user will often open a help desk ticket before the Windchill Administrator even has a chance to review the email. And whenever this does happen, you can quickly determine the source of the problem by comparing the user's Distinguished Name as it appears in Windchill to the Distinguished Name in the Windows "Active Directory Users and Computers" MMC snap-in.
Here's the Tl;dnr summary: The primary reason to get email notifications about Disconnected Participants is simply to keep ahead of repairing/deleting them before they start building up and impacting performance. It's usually not critical to act on these emails immediately, but instead set up some email rule to move them to a specific folder and then go through the folder once a day to clean up the Disconnected Participants that are reported. And of course, it's still a Best Practice to do a weekly search for Disconnected Participants to ensure that too many are building up.
