Short term: Add an exception to the rule for "AND UserLogonFailure.DestinationAccount DOES NOT EQUAL 0" to keep the rule from firing erroneously.
Medium term: Search the logs in nDepth, look for all user logons or failures where the destination account is 0. Does it ever successfully logon? Could it be a local account somewhere else trying to connect to Exchange, maybe for a script or task? If you look at the source events (versus just the rule e-mail) does it show a source machine?
Very unlikely: The LEM calls the user profile for the default "Admin" LEM account "0" on the back-end, but I am 110% sure there is no way the LEM is trying to logon as that account to Exchange (it wouldn't know how).
Maybe it's a LEM bug, but I think a lot of people see real issues in their environment with LEM and then have no idea how to correct or chase down those issues, so assume the LEM is broken. In the course of my duties as a Sales Engineer, I once had a potential buyer refuse to purchase LEM because during his trial he saw messages on his Cisco switches about a MAC flapping back and forth between ports/devices. He didn't want to see those errors, so decided not to buy a log aggregator/SIEM. That was certainly one way to stop seeing the errors! He got frustrated because we (at Solarwinds) couldn't tell him how to find the root cause for an issue being reported by his Cisco devices (it doesn't say "Cisco THWACK Community" at the top of the screen). So his solution was "I'll just stop looking at the errors."