Category Archives: Office 365

O365 – Distribution Lists

In our environment, we create the e-mail distribution lists in Active Directory and they are then synchronized to Office 365 Exchange via AAD Connect.  Therefore, management of distribution lists is done in Active Directory (adding/removing members, setting restrictions, etc.)  The exception is that Send As permissions are set in O365 (not Active Directory).

Below are some distribution list configuration examples.

Hide a distribution group from the address list.

  1. In Active Directory, set the msExchHideFromAddressLists attribute on the distribution list object to TRUE.
  2. The box next to Hide this group from address lists will be checked after the next synchronization.

Restrict who can send to a distribution group.

  1. In Active Directory, select the distribution group to which access will be restricted. Populate the dlMemSubmitPerms attribute with the name of the group that will be allowed to send to the distribution group.  (Initially use LDP or PowerShell.  Once the field has been populated, it can be modified via the ADUC.)  Use the authOrig attribute for individual user accounts.
  2. The “allowed” group will be shown on the delivery management page after synchronization.
  3. When a non-allowed internal user tries to send to the distribution group, they will see a note that they do not have permissions to send to the group or will get a bounce-back message.
  4. When a non-allowed external user tried to send to the distribution group, they will get a bounce back message.

Add send as permissions.

  1. In O365, navigate to the Exchange Admin Center.  Select the distribution group, click Edit and select the Group Delegation page.
  2. Click the plus sign (+) and select the user(s) who will have access to send as the group e-mail address.  Click Save.

O365 – Send E-mail as a Shared Mailbox

Sometimes we forget that it’s the simple things our customers (users) need help with.  We have many shared mailboxes in our environment and many users that need to send as the shared mailbox.  It can be confusing for a user to understand how to send with a different mailbox than their own.  So I wrote these simple instructions for how to send e-mail as a shared mailbox to help them along.

  1. From the Outlook client, click New to start a new e-mail.

  1. Click on the Options tab and then click From. This will create the From Field.  (You will only need to do this once.)

  1. Click the drop-down arrow in the From field and select Other E-mail Address. You will need to do this each time you want to send an e-mail as anyone other than yourself.

  1. Enter the first part of the shared mailbox name and click OK.

  1. The sending address will change to the shared mailbox e-mail address. The message will now be sent as the shared mailbox.

O365 – Auto Add Meetings to Calendars

Our marketing manager stopped by one day to discuss the upcoming town hall meeting.  She really wanted to put a meeting invite on everyone’s calendar without them having to accept it.  Sort of like a silent invitation to block the time on their calendars and present a reminder when the time came.  She also wanted the ability to update it silently–to add the WebEx information at a later date.  Then when she was ready to announce the meeting, she could just send a standard e-mail and the date and time would already be scheduled on everyone’s calendar.

I had never done this before, so I did some research.  And sure enough, there is a Direct to Calendar feature in Exchange Online.  Here is how I set it up.  (Click the pictures to make them larger.)

Overview

With the Direct to Calendar feature in Exchange Online, administrators can configure mail flow rules (also known as transport rules) that allow designated users to add meetings to calendars.

The benefits of Direct to Calendar are:

  • The event is automatically added to the recipient’s calendar without any action from them.  If the user received the meeting invitation, it’s on their calendar.
  • The sender doesn’t need to deal with Out of Office or other unwanted response messages that result from sending meeting invitations to a large number of recipients.
  • No meeting-related messages are seen by attendees unless the meeting is cancelled.

Direct to Calendar requires two mail flow rules with specific conditions and actions.

  1. One mail flow rule turns regular meeting invitations into Direct to Calendar meeting invitations.
  2. One mail flow rule prevents Direct to Calendar meeting invitations from appearing in the Inbox of recipients.

Procedure

  1. Open the Exchange Admin Center and go to Mail Flow/Rules.
  1. Click the Plus (+) sign and select Create a new rule.
  1. On the New Rule page, click More Options.
  1. Enter a name for the rule.
  1. Select Apply this rule if > The sender > is this person.  Select the shared mailbox that will send Direct to Calendar meeting invitations.
  1. In Do the following, select Modify the message properties > set a message header. Enter the following values:
  • Set the message header X-MS-Exchange-Organization-CalendarBooking-Response
  • to the value Accept
  1. Click Save.
  1. Back at Mail flow > rules, click New () again, and then select Create a new rule. Click More Options.  Enter a name for the rule.
  1. Select Apply this rule if > The sender > is this personSelect the shared mailbox that will send Direct to Calendar meeting invitations.
  1. Do the following > Modify the message properties > set a message header Enter the following values:
  • Set the message header X-MS-Exchange-Organization-CalendarBooking-TriageAction
  • to the value MoveToDeletedItems
  1. Click Save.
  1. The rules are added.

To validate:

To verify that you have successfully configured Direct to Calendar meeting invitations, use the designated sender mailbox to send a test meeting invitation to a small number of recipients.

Verify that the meeting automatically appears in the calendars of the recipients, and verify there are no meeting-related messages in the Inbox (the second rule should automatically move these messages to the Deleted Items folder).

Ref:  https://technet.microsoft.com/en-us/library/mt800696(v=exchg.150).aspx

O365 – Konica/Equitrac Woes

We use Equitrac on our Konica Minolta Multi-Function Printers for secure print.  Now that we are migrating to Office 365 for our e-mail solution, I needed to determine how to update the mail relay settings on the Konica MFPs for scan-to-e-mail functionality.

Our current hosted Exchange service provides a mail relay server that will send to both internal and external e-mail addresses.  However, the mail relay configurations available in Office 365 are more complex.

The Direct Send option is the simplest—just set up the relay configuration and send–which is similar to our current setup.  However, this option only works for sending internal e-mail.

The options for sending external e-mail via relay are SMTP Client Submission and Office 365 SMTP Relay.

The Office 365 SMTP Relay option requires an on-premises relay server.  Since we are currently hosted and have no e-mail on-premises infrastructure, this was not an option.

We started down the path of the SMTP Client Submission option.  I created a mailbox and set up the mail relay settings accordingly.  Scan-to-e-mail worked for internal recipients, but not for external recipients.

I searched the Internet for solutions, but the articles I found that showed how to configure the Office 365 SMTP relay for a Konica Minolta did not include the Equitrac option and therefore did not apply to us.  I contacted Konica Minolta support and after much research and testing we still could not get the external scan-to-e-mail to work.

I was then escalated to their Equitrac support.  Again, after much research and testing, we still could not get the external scan-to-e-mail to work. We finally escalated to Nuance and they said they would review the request and let us know what could be done.  The next day, they came back with the answer that the Office 365 SMTP Client Submission relay option is not supported in Equitrac.

So much for that.  So we are going with the Direct Send option.  As a workaround, if a user needs to scan to an external e-mail recipient, they will first scan to their own internal e-mail address and then forward the document on to the external recipient.

Why did I write this?  Because I spent a lot of time with Konica and Equitrac support and it might just save someone else a lot of grief.

O365 – Export Licensed Users

While reviewing user account licensing status in my Office 365 tenant, I noticed that there is no Export button when the list is filtered by Licensed Users.  I’m not sure why there would not be a button for exporting the list as filtered because there is an Export button when you filter by Unlicensed Users (see screenshots below).

Active users list filtered by License Users — no Export button!  (Click to enlarge.)Licensed Users FilterActive users list filtered by Unlicensed Users — Export button.  (Click to enlarge.)Unlicensed Users Filter

The fix is to export a list using PowerShell!

Export a List of Licensed Users

Open PowerShell and connect to Office 365/MSOL (see instructions here if you have not done this part before).

Type the following code into PowerShell, changing the output file name and location as needed.

$users = Get-MsolUser -All | Where-Object {$_.IsLicensed -eq "TRUE"}
$users | Export-Csv -Path C:\Scripts\O365\LicensedUsers.csv

That’s all there is to it.  Now you have a list of Office 365 Licensed Users in .csv format.

O365 – How to Connect

Sometimes it’s difficult to find the simplest things because they are buried in other data.  Here are two commands that do just one thing–get you connected to your Office 365 account in the cloud.

Connect to Office 365/MSOL

Prerequisites:

  1. Install the 64-bit version of the Microsoft Online Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
  2. Install the 64-bit version of the Windows Azure Active Directory Module for Windows PowerShell: Windows Azure Active Directory Module for Windows PowerShell (64-bit version).

Open the PowerShell ISE with Run as Administrator on your computer.  Type in the code below.  Run the code and enter your O365 user name and password and you’re connected.

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential
Connect to Office 365/Exchange

Open the PowerShell ISE with Run as Administrator on your computer.  Type in the code below.  Run the code and enter your O365 user name and password.  You will be connected to an Office 365 Exchange session.

$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $Session
Disconnect from Office 365/Exchange

It’s a good practice to remember to disconnect from your O365 Exchange session when you’re done.  Type the code below into your PowerShell session and you will be disconnected.

Remove-PSSession $Session

Now you can add these snippets to any script you create to work in your tenant.  How easy was that?

O365 – Mail Relay

It took some time to gather the settings for mail relay when we implemented Office 365 in our environment.  It’s pretty straightforward, but since I had to research several sites to get the information, I’m writing this article to combine the data for easy reference.

An SMTP relay is required to route e-mails from on-premises applications, scanners (print-to-PDF) or multi-function devices to either internal or external recipients.

Mail Relay Options

Using Exchange Online in Office 365 for mail relay can be accomplished in three ways:

1.    SMTP Client Submission
Here you configure the devices or applications to authenticate with an Office 365 mailbox and use Simple Mail Transfer Protocol (SMTP) client submission.  In this scenario, the device or application uses an e-mail account to send e-mail to recipients, just like an e-mail client.  E-mail can be sent to both external and internal recipients.
2.    Direct Send
With Direct Send you configure your devices or applications to send e-mail directly to recipients in your organization.  This scenario does not support external recipients.  When you set up your device or application, configure it to point to your mailboxes in Office 365 using your mail exchange (MX) endpoint record.
3.    Office 365 SMTP Relay
For this configuration you must configure an Exchange Online connector for your devices or applications to send email to Office 365.  Office 365 can then relay e-mail to both your organization mailboxes and to external recipients.  This requires an on-premises SMTP relay server.

In our environment, we did not have a previous Exchange on-premises setup.  Therefore we were unable to utilize option 3.  However, our programs and devices were able to use options 1 and 2 sufficiently.

Mail Relay Configurations

SMTP Client Submission:
SMTP Server:  smtp.office365.com
Port:  587
SSL/TLS:  required
Authorization:  Exchange Online mailbox credentials
Send Secure:  include Confidential in Subject
Recipients:  Internal/External

Direct Send:
SMTP Server:  <domain>-com.mail.protection.outlook.com
Port: 25
SSL/TLS:  not required
Authorization:  not required
Send Secure:  include Confidential in Subject
Recipients:  Internal only

Sample Mail Relay Send Commands

Replace the domain names with your own.

Send-MailMessage -From "anyone@anyone.com" -To "mailbox@doman.com" -Subject "Test Direct Send E-mail" -Body "Test SMTP Direct Send Relay" -SmtpServer domain-com.mail.protection.outlook.com -Port 25
Send-MailMessage -From "anyone@anyone.com" -To "mailbox@domain.com" -Subject "Confidential Test Direct Send E-mail" -Body "Test SMTP Direct Send Secure Relay" -SmtpServer domain-com.mail.protection.outlook.com -Port 25
$msolcred = mailbox@domain.com
Send-MailMessage -From "mailbox@domain.com" -To "recipient@gmail.com" -Subject "Test E-mail" -Body "Test SMTP Client Submission Relay Service" -SmtpServer smtp.office365.com -Credential $msolcred -UseSsl -Port 587
$msolcred = mailbox@domain.com
Send-MailMessage -From "mailbox@domain.com" -To "recipient@gmail.com" -Subject "Confidential Test E-mail" -Body "Test SMTP Client Submission Relay Service Secure" -SmtpServer smtp.office365.com -Credential $msolcred -UseSsl -Port 587

 

 

O365 – How To Add Proxy Addresses To AD Groups From CSV File With PowerShell

When using Azure AD Connect with Office 365, you will find that many of the mailbox and distribution group attributes cannot be set in the Office 365 portal.  When you try to update the attributes, you will see an error such as the one shown here:Update Error
Since this is an attribute that is synchronized from AD via AAD Connect, it must be updated in Active Directory and the new values will then be synchronized to the Office 365 Portal.

I recently needed to add a second e-mail address alias to a number of distribution groups.  Below are the steps I took using PowerShell to update the groups.

1. Create a CSV file with two columns, Name and ProxyAddresses.  Populate the appropriate cells with the distribution group name and the proxy addresses separated by a semi-colon.  The proxy address with the capitalized SMTP will be the primary e-mail address for the group and will be used as the ‘sent from’ address.  Save the file and note the file location.CSV File

2.  Create a PowerShell script as follows changing the file name and location as needed:

Import-Csv C:\Scripts\DistGroups.csv | ForEach-Object{
  $name = $_.Name
  $proxy = $_.ProxyAddresses -split ';'
  Set-ADGroup -Identity $name -Add @{proxyAddresses= $proxy}
} 

3.  Run the script.  Open a distribution group in AD, navigate to the Attribute Editor tab and scroll down to the proxyAddresses attribute.  Both  e-mail addresses will show.ProxyAddresses

4.  In the O365 Exchange Admin Center, navigate to Recipients > Groups.  Edit the distribution group and select the E-mail Options page to see that both the e-mail addresses are showing.