Symptoms
Error messages being logged approximately every 5 minutes:
"24148 The User Manager 127.0.0.1 returned an empty queue."
"64007 Provider did not return a result for K2:DLXUserK2:DLXOtherUser on GetUser"
Diagnoses
The "24148" error typically means there is a role defined somewhere that is not resolving any valid users. This can happen when a role contains a group, and that group's users are removed (or K2 cannot resolve the group's membership so it assumes the group is empty). This can be something as simple as a role that isn't in use anymore, in which case you really don't "care" that the error is being thrown.
The "64007" errors are for the same three "users" every time. These are actually 3 strings that contained malformed lists of users. This may be the result of trying to assign destination users without properly delimiting the list, which caused K2 to cache this "user" to the Identity.Identity table.
These are not valid users, so K2 is unable to resolve them against Active Directory. You SHOULD be able to disable these identities and not have this happen anymore.
In addition, in the ADUMerror file, were some errors that are usually permissions-related, trying to bind to a specific LDAP server by IP address on port 389 (which is the default LDAP port), as well as errors resolving "ForeignSecurityPrincipal" for specific Organizational Units.
Resolution
1) The 24148 errors in the HostServer log may be safely ignored, as long as two things are true:
1. The log file is not getting rapidly filled with that message
2. You are not seeing any errors related to missing destinations
2) There are rows in the Identity.Identity table that do not belong there, but are Enabled. For this reason, K2 keeps trying to lookup their properties in AD, and throwing errors. Disable those users (using SQL script provided by K2 Support), and check back after 2-3 days to ensure those errors are no longer being logged.
3) For the ADUM errors, perhaps the IP address is hard-coded somewhere in a connection string and maybe no longer good. I would guess those Organizational Units may have more restrictive permissions. I probably wouldn't worry about those errors unless you notice an issue with one of the accounts mentioned in that ADUMerror.txt file.
