Relationship In Trash Won't Delete Away After Full Sync
The relationship is in alert. See the related links below.
Special Case - changing aliases cause relationship to go into alert
This was an interesting find and shows a bit more how Exchange works and how A2E logs in. A2E logs in by default Email address. If that email address changes, then the relationship will go into alert. You can fix the relationship so it can clean up and remove destination copies easily with the Recovery and Migration Manager tool.
But this may be why it happens. If you change the email address this will put the relationship in alert. However, if you change just the ALIAS of an account in Exchange 2010, it automatically changes the default email address for the account if Exchange is set that way.
And if there was an Add2Exchange relationship, it will no longer validate and will normally go into alert.
Interestingly though, since the relationship was an RGM template relationship, it did not go into alert, Relman deleted it, because it did not find the account by the old email address. However, that relationship was in the trash in alert status. Older versions of Add2Exchange would keep the empty trash switch on once set, so that alerted relationship could potentially be deleted and since it could not log in to remove the copies, that would leave orphan items in the destination folder or if you manually empty the trash.
Use Recovery and Migration Manager to fix the relationship and resync.
If the account is to have a new alias, or the alias changes, then uncheck in Exchange Management for this account to automatically update email address and set default reply to the original:
The will take the relationship out of alert and clean up the old copies and then copy them back with the new relationship Relman creates.
If the account is not to have the new alias, change that newly created (default) email address to the secondary or old address, and thus making it the default and Add2Exchange will be able to log on and remove the destination items.
Another way to do it would be to run Recovery and Migration Manager and pick the mailbox, and then it will be able to log in, using the new alias (may have to pick it from the Gal dialog box during RMM) - and then if the user is still in the Dist list, Relman will spin off another if it hasn't already.
The simplest way to fix this is there are duplicates in a destination and two rels, one in alert and one not, run Recovery Migration Manager to fix it.
See also these related posts:
Recovery and Migration Manager Essential Tools: http://www.diditbetter.com/a2e-essential-tools.aspx
Deleting Alerted Relationships: http://support.diditbetter.com/Forums/Thread.aspx?pageid=1&mid=2&ItemID=1&thread=73&postid=168