During many Exchange projects (On-Premises or in the Cloud) we see a lot of situations when organisations create an additional mailbox (secondary mailbox) for some users. Everybody, who works with Exchange environments, knows that a mailbox could have multiple email addresses associated with it. The question is always, why not just define an additional email as an alias to the mailbox? Of course, this scenario could work in some use cases. You probably think, it’s OK…

However, when someone sends an email to the address that defined as an alias, the recipient is not going to easily see to what email address the email was sent (in more details down in this blog post). Also, when we only use aliases, all emails that we send are always seen as if they were sent from the primary email address associated with the mailbox.

We all know that  pictures explain better than 1000 words, so let’s take a look. Because of this, let’s see how to do this On-Premises and in the Cloud (Office 365).

The “Challenge”

The following image illustrates that I have multiple email addresses associated with my mailbox:

Multiple Email Addresses (eMail Aliases)

When someone sends me an email to one of my addresses, let’s say to [email protected] 🙂 , of course it will arrive at my main mailbox.

Email in the mailbox

 

As  you can see, the email arrived. And… do you see the first issue?! At least it bothers me! 🙂 … If I look on the line “To:“, I see that this email was sent to Misha Hanin. When I double-click at the name I see the following screen:

Contact Details

 

Yes, it’s not clear to what address the email was sent! Of course, I can go and check “Internet headers” and I will see something like this:

 

Internet headers

 

I don’t know about you, but for me going and checking headers for all emails, every time when I need to know to what address it was sent to is too much :)!

And, this is only the first part of the problem!  In addition to this, we also have a “challenge” to use “Send As” functionality!

Let’s try to “Send As[email protected]. So, logically, many of us will try to do something like this:

 

5

 

or

 

Send As

 

Now, let’s see how I will see this email when I check my @highclouder.ninja mailbox:

 

Send As - Wrong

 

Seems like, ALL my attempts to send emails as  [email protected] were ignored and as a result, this email looks like it was sent from [email protected] (this is the primary email address of my corporate mailbox)!

Therefore, exactly at this moment, many companies decide to create an additional mailbox (in my case it should be [email protected]) and configure “Send As” permissions.

It’s nothing wrong with this approach, however, as a result of this decision, now you have to manage multiple mailboxes (I even not touching the licensing topic yet!).

HOW EXPERTS WORK WITH MULTIPLE EMAIL ADDRESSES

So, when our clients deal with this “Receive As / Send As” problem, we, at iRangers, do the following:

  1. Create a new Distribution Group. As a Primary Email address for this group we define an address that we want to use as “Receive As / Send As
  2. We add required users to this new Distribution Group. So, in My case, I added myself ([email protected]) to this group. Now, all emails that will arrive to address [email protected] will be forwarded to [email protected]
  3. Assign “Send As” permissions. By doing this, [email protected] will be able to Send As: [email protected]

I hope you know how to do all this by using GUI, therefore let’s see one of the ways how to do this in PowerShell (first of all, If you are in the Hybrid Mode, you will need to do all steps, from On-Premises and Office 365 sections):

On-Premises:

$SendAsRecipient = "[email protected]"
$ForwardToRecipient = "[email protected]"

$ContactsOU = "OU=Contacts,OU=Users,OU=Winnipeg,OU=Canada,OU=iRangers,DC=prv,DC=irangers,DC=com"

New-DistributionGroup -Name $SendAsRecipient -Members $ForwardToRecipient -Alias $SendAsRecipient.Split('@')[0] -PrimarySmtpAddress $SendAsRecipient -OrganizationalUnit $ContactsOU
Set-DistributionGroup $SendAsRecipient -RequireSenderAuthenticationEnabled $False

Add-ADPermission -Identity $SendAsRecipient -User $ForwardToRecipient -AccessRights "ExtendedRight" -ExtendedRights "Send-As"

Also, we can try to allow the Group itself to Sen-As (Sometimes this doesn’t work. So, please consider this command just as a reference):

Add-ADPermission -Identity $SendAsRecipient -User "NT AUTHORITY\SELF" -AccessRights "ExtendedRight" -ExtendedRights "Send-As"

For a validation:

(Get-ADPermission -Identity $SendAsRecipient -User $ForwardToRecipient).ExtendedRights

Office 365:

Before moving forward, be sure that Azure Active Directory Connector (AADC) has already synchronized all data. Of course, you can force the sync by executing the following command from the AADC server:

Enter-pssession IR-SYNC01

(iR-Sync01 is our AADC server. And…., Yes, I am lazy… I am connecting to my AADC server with remote PowerShell… )

& "C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe"

Now, when all objects get synced to the cloud, let’s connect to Office 365 and execute there a few commands. Here is how we connect to the Office 365:

$strUserName = "[email protected]"
$strConnectionURL = "https://outlook.office365.com/powershell-liveid"
$objCredential = Get-Credential -Credential $strUserName

$objPSSession = New-PSSession -ConfigurationName "Microsoft.Exchange" -ConnectionUri $strConnectionURL -Authentication "Basic" -Credential $objCredential -AllowRedirection
Import-PSSession -Session $objPSSession

OK, now as a result of the previous steps, we are inside O365 PowerShell session. Let’s run this commands:

$SendAsRecipient = "[email protected]"
$ForwardToRecipient = "[email protected]"

Get-RecipientPermission -Identity $SendAsRecipient
Add-RecipientPermission -Identity $SendAsRecipient -Trustee $ForwardToRecipient -AccessRights "SendAs" -Confirm:$False

In addition, for a validation purposes:

Get-RecipientPermission $SendAsRecipient | Where { ($_.IsInherited -eq $False) -and -not ($_.Trustee -like "NT AUTHORITY\SELF") } | Select Trustee,AccessControlType,AccessRights

In Conclusion

Now, after all those steps, let’s repeat Receive As and Send As exercise  :). First of all, I will send an email to [email protected]

And… Voila! As a result of all our hard work 🙂  email was automatically forwarded to my primary mailbox: [email protected] and …in the “To” field I see that this email was sent to [email protected]:

 

Recieve As

 

We are almost at the end :). So, I think this is a time for the last test. Now let’s Send as: [email protected]

 

Send As - Working

 

Yes, here is the result we were looking for!

 

Send As / Receive As

 

Finally, I hope you find this blog post informative.

Don’t hesitate to contact me via contact form or be in touch through iRangers.com

Cheers,
Misha

P.S.
Special thanks to Alexander Stankevich and Dima Razbornov (iRangers’ Sr. Solutions Architects), who were actively involved in crafting this blog post!

#

No responses yet

Leave a Reply