For regular Microsoft 365 groups, you can go to the Exchange dashboard, open the group, switch to the Settings tab and click the Edit delivery management link under the Delivery Management section.

Then select any senders who are granted to send emails to the group.

Pretty straightforward, until you want to change a group that is managed by your on-premise Active Directory.

Now what to do? You do that from Active Directory users & groups, obviously.

First, make sure you have Advanced Features checked under the View menu. Then, open up the distribution group’s properties, and go to the Attribute Editor tab.

And here is the list of attributes you can update to meet your needs.

• authOrig – only these users can send to the distribution group
• unauthOrig – anyone but these users can send to the distribution group
• dLMemRejctPerms – anyone but members of these distribution groups can send to this distribution group
• dLmemSubmitPerms – no one but members of these distribution groups can send to this distribution group

Sounds awesome, but the trick is, these are Exchange-specific attributes, meaning that if you don’t or never had an Exchange server installed in the same Active Directory domain, you most likely will get an error message like this when you try to update one of these attributes.

The solution is, according to this Microsoft post, to install the Exchange schema extension on the on-premise AD server. And you will need to obtain a copy of the Exchange Server 2010 DVD to do so.

Well, that’s a bit too much. At this point, I’d take a different route, changing these distribution groups from AD-synced to Microsoft 365 native. Easier to handle without worrying about the other side effects.

A much better option is to use PowerShell and let the server do all the work. And one cmdlet that just does the job is Search-Mailbox.

Here is how it goes.

First of all, connect to Exchange Online.

Connect-ExchangeOnline

An Office 365 login window pops up, sign in with an account that is a member of the Discovery Management role. You can log in as a Global Admin and go to Exchange > Permissions to edit the Discovery Management role.

Then, to move all emails from one mailbox to another,

Search-Mailbox $sourcemailbox -TagertMailbox $targetmailbox -TargetFolderName $targetfoldername

All three parameters are required. Messages will be copied to the target mailbox under the specified folder name. The structure goes like this:

TargetFolderName\Date of the search\Primary Mailbox\Inbox

It works like a charm. However, there is one limitation. It only returns 10,000 results per mailbox. So, for a larger mailbox or a larger amount of messages to move around, use the New-ComplianceSearch instead, which is a lot more complex.

If you want to see how big the mailbox is you are dealing with, use the -EstimateResultOnly switch.

Search-Mailbox $sourcemailbox -EstimateResultOnly

You can also use the -SearchQuery switch to narrow down the messages that you want to migrate, such as subject line, To or From.

Search-Mailbox $sourcemailbox -SearchQuery "Subject: Away Today"

And if you need to do a dry run, use -LogOnly.

Need very detailed log for the operation? -LogLevel Full is your friend.

Lastly, to make this all happen, you need to be part of the Discovery Management role in Office 365.

Sign into Microsoft 365 Portal and go to Exchange Admin Center.

Click Mail Flow on the left-side pane, and click the little + icon to add a new rule.

Name the Rule, select the following rule as the condition,

Any attachment's file extension matches...'html' or 'htm'

Pick on the following actions as it fits your goal.

• Forward the message for approval
• Redirect the message to
• Block the message
• ect.

If you only want to apply the rule to incoming messages, you can add an exception to allow outgoing emails with the same attachment.

Here is one example of the rule I set in place.

If you are using the Approval approach, you will get emails containing any HTML files for you to approve, like below.

As you can tell, it’s already caught one.

So how can I do that? Turns out, it’s pretty easy and straightforward.

Open Active Directory Users and Computers on your computer, make sure Advanced Features is checked under View tab.

Find the account, double-click it, and go to the Attribute Editor tab. Scroll down until you find one attribute called msExchHideFromAddressLists. Double-click it and set the value as True.

And then wait until the next sync cycle finishes before seeing the group or user disappearing from the list.

You can also accomplish the same with PowerShell, which is my preferred way to change settings like this these days.

First, as always, let’s connect to the Exchange Online,

$username = 'email-address'
$pwd = ConvertTo-SecureString 'password' -asplaintext -force;
$cred = New-Object -TypeName PSCredential -argumentlist $username, $pwd

$getsessions = Get-PSSession | Where-Object {$_.State -eq 'Opened'}

if (!$getsessions){
    Connect-ExchangeOnline -Credential $cred
}

Then, use the Add-MailboxFolderPermission to assign access rights.

$user1 = 'emailaddress1:\calendar'
$user2 = 'emailaddress2'
Add-MailboxFolderPermission -Identify $user1 -User $user2 -AccessRights Editor -SharingPermissionFlags Delegate,CanViewPrivateItems -SendNotificationToUser $false

That will give the $user2 the Editor access to $user1’s calendar with the privilege to view Private items as well.

Guess what? Out of the 6 policies I put in, only one of them gets pushed out. None of the other ones got applied.

The gpresult command line that checks the resulting set of policy settings enforced on the computer tells me all of them are pushed out from the Active Directory as they are supposed to. But why my Office 365 apps take none of them?

Turns out, something has changed since the release of Office 2013. All group policy settings pushed out from AD will be ignored on retail version of Office, including Microsoft 365 Business subscription. If you need a version that supports GPO, you need to get the volume license editions, or Microsoft 365 Business Premium, which is equivalent to Office 365 ProPlus. Essentially, you will need to pay more, a lot more, to get the functionality again.

I don’t find any official documents that state this requirement but I do tend to agree with this, as it’s exactly what happened in my case.

Workaround? Use Registry settings instead, not the ones under Policies key because those ones are already existed but are ignored, but the real ones under HKCU.

For example, if I need to Allow Trusted Locations on my network, I can open GPO editor on a specified GPO and go to

User Configuration > Preferences > Windows Settings > Registry 

Right-click on the empty area at the right pane, choose New > Registry Item.

Select Create as Action, HKEY_CURRENT_USER as the Hive, with the following Key Path:

SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Locations

Set a Value name as AllowNetworkLocation with a value data as 1 in REG_DWORD type.

You may also need to copy/paste to another item and change the action to Update to make sure the setting you put in is always intact.

It’s not as perfect as the ones pushed out via GPO but it works. If it gets changed during one session, it will get reset via next login.

If you are using a package deployment tool such as PDF Deploy, following the right way is the best approach. When setting up right, deploying the Office 365 apps on a bunch of computers is a breeze of air that you will enjoy. It uninstalls whatever the version of Office you have installed and installs the Office 365 apps right after. All process could be finished within minutes, believe it or not.

Here is the simplified version of the process.

Step 1 – generating the Office 365 config file

Go to Office Customization Tool and click Create button to start creating a new configuration.

Finish every section carefully, especially the following sections

• Select proper Products and the right Update channel. Semi-Annual is my go-to channel. Anything less is too frequent to me to manage.
• Unselect the apps that you don’t want install, such as Skype for Business.
• Select Local source with a specified network path as the Installation options.
• Make sure Uninstall any previous version option is checked.
• Select a Product activation method, either User based or Shared.

And export the configuration file in XML format once done.

Step 2 – downloading the Office 365 installation source files

Easy-peasy once you have the configuration file ready. Run the following in the command prompt window.

.\setup.exe /download ./configuration.xml

If everything goes as planned, you will see an Office folder shows up with all the source files needed for the installation.

Step 3 – building the deploy package

For example, here is what to do in PDQ Deploy:

1. Set the install file to setup.exe.
2. Add the parameter “/configure configuration.xml”.
3. Add the configuration.xml file as an Additional File.

And that’s it.

I also should mention that doing so via PDQ Deploy is completely free.

It typically works like this:

• Email gets automatically forwarded from me@mydomain.com to your Gmail account.
• When you reply to emails sent me@mydomain.com you are using me@mydomain.com instead of your Gmail address.
• When you send a new email in Gmail, you have the options to choose which email address to use as the sender.

To set it up, you basically go to the Gmail Accounts setting page, click Add another email address in the Send mail as section, and follow the instruction on the screen.

If you are adding a Microsoft 365 email account as another sender in Gmail, there are two main hurdles to overcome.

Microsoft 365 email auto-forward

The email auto-forwarding to an external email address used to be working out of the box, whether it’s set in the Outlook app level or the mail account level. But things have changed lately.

Now, external forwarding is disabled by default in Office 365. While usually it’s a good practice in general, it doesn’t help in this case. However, Microsoft still leaves a door open so you can change that if you need to, given that you understand the danger of it.

So, to re-enable external forwarding, go to the Anti-spam policy page on Microsoft 365 security page, and turn on Automatica forwarding under Outbound spam filter policy.

Enable SMTP Client Authentication

Again, Microsoft doesn’t mess around. The SMTP Authentication is disabled by default in Microsoft 365.

To disable, we need the help from PowerShell.

First, install ExchangePowerShell module if you haven’t done so.

Install-Module ExchangePowerShell

Then, connect to Exchange Online using

Connect-ExchangeOnline

And then, to enable SMTP client authentication, you need to enable it at organization level,

Set-TransportConfig -SmtpClientAuthenticationDisabled $false

as well as at the mailbox level,

Set-CASMailbox <MailboxIdentity> -SmtpClientAuthenticationDisabled $false

Once these two hurdles are solved, you can then move on to finish setting it up.

First, install the module if you haven’t done, and connect to Azure AD with your Office 365 subscription.

Install-Module msonline
Connect-MsolServie

To list of the licensing plans available in my tenant:

Get-MsolAccountsku

To view a full list of licensed accounts:

Get-MsolUser | Where {$_.IsLicensed}

How many of my users are licensed in Premium?

Get-MsolUser | Where {($_.Licenses).AccountSkuID -eq $accountskuid}

Where $accountskuid can be found in the cmdlet Get-MsolAccountsku described above.

Need to export the result in CSV for reporting purpose?

Get-MsolUser | Where {($_.Licenses).AccountSkuID -eq $accountskuid} | Export-CSV "path\csvname"

First, verify the ownership of the domain and get all the mailboxes ready in Office 365.

Then, prepare a CSV file in the following format:

EmailAddress,UserName,Password
terrya@contoso.edu,contoso\terry.admin,password12345

The first row is the header, obviously. And each row under the header represents one user, which is the EmailAddress registered in Office 365, and the IMAP credential that will be used to migrate that user’s mailbox.

Now, create a migration endpoint for the migration. Go to Recipients in Exchange admin center. Switch to migration tab, click the … and choose migration endpoints.

Click + sign, select IMAP and fill in the IMAP server info to create a migration point for import.

Once done, it’s ready to create a new import job to use that newly created migration endpoint. Click the + sign in migration and choose Migrate to Exchange Online.

Select IMAP migration, choose the CSV file prepared earlier, and off you go.

The actual process could take quite some time to finish. Meanwhile, you can check the status of the process at any time by highlighting the job and clicking the View details on the right.

Finally, you can flip the switch and change the MX records to finally redirect the mail to Office 365.