Can't give 'send-as' permissions in Exchange 2010

Solution 1:

I've finally fixed this.

Interestingly Send-As is an AD permission - not an exchange permission as you might have expected.

Anyway, these are the steps:

Make the target mailbox "shareable" using this command in Powershell on your Exchange Server:

Set-Mailbox user1 -type:shared

If you get this error (same as in my first post):

You will need to find that user in AD and go to the properties >> Security >> Advanced:

You need to ENABLE the option to "Include inheritable permissions from this object's parent":

Once that is done you should be able to complete the folder share script.

Then actually grant the rights using this command:

Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"

Hope that helps others who have the same problem.

Kieran

Solution 2:

Access denied messages usually come from the account running the PowerShell session not having enough permission. I get this all the time when I just launch the Exchange Management Shell instead of doing run as my administrative user account.

Following your update, what I suspect may be happening is that User1 is part of a protected group (Print Operators) so Exchange is not allowing you to grant Send As on User2 because it knows it will only get stripped off in the next hour. It looks like you confirmed that theory by manually adding Send As using ADUC and seeing it taken away a short time later.

On the Domain Controller which runs the PDC Emulator FSMO role, every hour something called the adminSDHolder thread runs. What this does is takes all accounts which are (or have ever been, even if they have subsequently removed) in protected groups (Enterprise Admins, Domain Admins, Account Operators, Print Operators to name a few of the more common ones) and removes all permissions granted on the objects and replaces them with certain explicitly defined permissions. The idea being that a delegated account is not able to wreak havoc and strip a domain admin of their privileges.

I'm not entirely convinced your fix of explicitly granting permission is going to work and won't be reset every hour, but I've been wrong before - so if it does, great! If however the user doesn't need to be in the Print Operators group, I'd recommend you modify their account using ADSI Edit and set the adminCount property to zero. Then enable inheritable permissions on the user object and reset the default permissions. Once you've done that, try your Exchange cmdlet again and with a bit of luck it will work (obviously give enough time for AD replication to occur).

I don't think you'll be able to modify your cmdlet to accommodate for this - like I said, I imagine (not certain though) that it won't let you do it because Exchange knows the permission is only going to get removed shortly afterwards and is trying to save confusion on your part. Under "normal" circumstances (i.e a standard user) the cmdlet should just work without issue because the whole adminSDHolder thread doesn't even come into play.