03-11-2020 03:10 PM
03-11-2020 03:10 PM
I just took over as an exchange admin at a company and am trying to perform a relatively simple task. All I need to do is to grant a user "Send As" and "Send on Behalf". Simple huh?
The problem is when I go to that group and open the properties and select Group Delegation, and then click the plus to add a user to Send As I get 500 odd security groups, plus 2 or 3 end users. And that is it. And it's not that the end users are all alphabetically behind the groups so they aren't showing up, it's just that only a few users are in the list.
I've looked at those user's accounts to try to figure out why those show up in the list but not others, and can't see any reason. They are just regular accounts. The owner of the group doesn't even show up in the list so I can't even add that person. I've tried copying and pasting the user's name and email address I want to add the Send As to, but that doesn't work either.
Am I missing something very obvious here? Is there a setting somewhere that prohibits Send As by anything other than a Security group? If there is then I really can't figure out why those 2 or 3 users show up in the list then.
Thanks in advance for any help.
03-12-2020 12:10 AM
The picker controls have limits, and search doesn't always work great there. Just add the permissions via PowerShell?
03-12-2020 08:23 AM
Sorry, no offense to you but I really hate that response. MS codes a crappy interface, so now we are all expected to use the command line for what should be a VERY basic task.
One of my (many) issues with Powershell is that at this company they do that Red Forest(?) architecture. For me to access the Exchange server I have to first RDP to a Jump Station. From there I RDP to the App Tier Jump Station, (using a different ID/PW with VERY complex PW requirements) and do the 2FA. From there I RDP to the Exchange Server. All of these operate on a 10 minute time out so basically I have to redo this entire thing every time I need to do the simplest operation.
Or I can go to the EAC website in Chrome from my desktop, which bypasses all of that, and have Chrome auto remember my super complex PW for me. Since none of the jump stations or exchange servers can access the internet with a web browser, by the time I have typed up this response my RDP sessions will have timed out and I'll have to redo the whole RDP thing again.
UGH. Why can't MS just do a semi decent job of programming the EAC???
03-12-2020 09:51 AM
I'm simply giving you a solution, if you think complaining on a site where no one from Microsoft actually looks is a better one, be my guest :)
03-12-2020 08:16 PM
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.
03-15-2020 06:49 AM
@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.
03-16-2020 03:38 PM - edited 03-28-2020 03:03 PM
@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