Forum Discussion
Exchange 2016 - Problem adding users to Send As or Send on Behalf
Are you not able to use the search option to find the appropriate users?
No, for some reason it comes back with nothing found. In the list I have 545 items, (I bumped up the default from 5000 items returned to 1,000), all but 3 or 4 are security groups. For the life of me I can't figure out why there are 3 or 4 users in that list and not any others.
Ted123 are your users in a resource forest? Are the user accounts associated with mailboxes enabled or disabled in AD?
The UI in Exchange and Skype (for that matter) often hide disabled accounts that aren't correctly set to resource accounts.
If you are able to get to the ECP you would likely can connect to the Remote PowerShell endpoint so you can run the commands required without hitting a jump box first.
I have the following script to pull a remote session (save as a .ps1) and replace [Exchange-FQDN] and [@contoso.local]
$account = read-host "What is the userid to use for EMS shell?: (e.g. adm_ntid) "
$accounttouse = $account + "[@contoso.local]"
$Cred = Get-Credential $accounttouse
$ExSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://[ExchangeServer-FQDN]/PowerShell/ -Credential $Cred -Authentication Kerberos
Import-PSSession $ExSessionI have encountered this same issue
FIX : (check your config files in the Pickers dir)
I have a hybrid environment and found that "RemoteUserMailbox" was missing in the string for searches in SendAsPicker.aspx and also SendOnBehalfOfPicker.aspx\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\Pickers\
- Thank you so much! Fix still works for in December 2023!
Ted123 Hi Ted,
Just a thought, but seeing as your environment is so secured (which is good), is it possible some of the AD permissions on certain OU's and/or accounts have been stripped, undoing what is done by the Exchange setup process (i.e. /PrepareAD, /PrepareDomain, etc.)? The logic I am wondering about is that maybe the Exchange Trusted Subsystem group, or Exchange Servers (can't remember if this group is still a thing) have lost their permissions on some OU's due to, for example, permission inheritance being turned off on those OU's.
It could be worth just identifying a user or group that isn't showing up for you, then check that user's account and OU properties for the Security permissions assigned. If you find permission inheritance is turned off, that could be the issue. Re-enabling inheritance might not be allowed, so the solution in that case would be to manually reapply permissions that /PrepareAD would have set. That would be painful, vs enabling inheritance.
