I wonder if anyone out there has had some issues when they have applied ‘Send-On-Behalf‘ or ‘SendAs‘ permissions with powershell or on the ECP?
What issues … well considering you are using one of the versions of DirSync/AAD Sync & you apply thee permissions to an account & then later delete the account in the AD; have you experienced that even after a sync runs one of the two permissions are still there?
Well, with the ‘Send-On-Behalf‘ Microsoft considers it a feature. AS a safe-gaurd in case someone is accidentally deleted or had a license removed. Some feature ! And it creates another problem. Well, the problem is that if a deleted is still appearing then you’ll get an error when trying to add more to the list. Luckily, the solution is fairly simple for ‘Send-On-Behalf‘ . If you from powershell or ECP you should still be able to remove the account. Then advise your customers to add these rights in the AD under ‘publicDelegates‘ .As I rule I highly recommend not using ‘Send-On-Behalf‘ rights & most certainly never mix the 2 rights. As then they won’t function properly. ‘Send-On-Behalf‘ is a delegation right & usually when applying it a delegation is created and a person that has these rights may see some weird behavior such as getting updates when a person make a calendar change or accepts an appointment. But if you still need to apply ‘Send-On-Behalf‘ rights do it in the AD under ‘publicDelegates‘. Now, I originally experienced this about 2 years ago & I already pointed out MS’s response. Since then until lately; it actually seemed that the issue was actually cleared up. But it has reared its ugly head again. So, you know how to fix it now.
Now the issue with ‘SendAs‘ permissions is nearly identical as the one described above but the solution is a little more complicated. As you won’t be able to remove the user on the ECP . You will get an error like above that the ‘object can’t be found‘. If you go to powershell ; you’ll also likely get an error there if you were to use the UPN or PrimarySMTP . What you need to do is go to the mailbox where the permission is applied & run:
Get-Recipientpermission -identity firstname.lastname@example.org |select Trustee,Accessrights
You’ll receive a list of users and find the one with the ‘SendAs‘ rights. it may appear as: EUROPROD5\john541622091
What you’ll notice is the identity for the deleted account has changed as it now references an identity in a soft-deleted db. So,now you have the accounts new identity and then can remove it with everything after the slash:
Remove-Recipientpermission -identity email@example.com -trustee john541622091
This will remove the account from having ‘SendAs‘ permissions & in the future for the same account if the account is recovered.