It’s been over a year since Microsoft started previewing the “PST Import Service” which allowed administrators to import PSTs into Exchange Online mailboxes. The blog post I wrote (“Office 365 – Using the New PST Import Service“) about the service back in May 2015 has been incredibly popular which tells me there’s a high amount of interest with this service.
For the most part, the PST Import Service is pretty good but there are a few restrictions; specifically, there is minimal flexibility in regards to the import options. While the “New-MailboxImportRequest” cmdlet is used behind the scenes, the PST Import Service doesn’t expose many of the parameters of that cmdlet such as the ability to exclude certain folders.
Below is a more flexible way to handle PST imports using PowerShell…

PST Import Service

The service provided by Microsoft is probably where you should start, it will handle most scenarios. The process is pretty well documented and not very difficult to execute. Additionally, one advantage of this approach is that Microsoft provides you the Azure Blog Storage to upload your PSTs to. However, as mentioned above, all you can do is import the PST and provide a destination, you can’t use all the parameters available natively to the “New-MailboxImportRequest” cmdlet.
Note: Something to be aware of, which is sort of hidden in the documentation, is that using the PST Import Service puts the mailbox on “Retention Hold” indefinitely. The idea is that if you have Retention Policies that delete or archive data older than X days, you don’t want those policies processing the newly imported data. So if you choose to use the PST Import Service, make sure to take the mailbox off Retention Hold when appropriate.

Advantages of Using PowerShell

You may find that you don’t want to import everything in a PST. Calendar entries in particular can be a problem; you may find that they create a storm of calendar alarms that no “Dismiss All” seems to fix. The “BadItemLimit” and “ConflictResolutionOption” parameters are other options that may be of use; the PST Import Service defaults “BadItemLimit” to “Unlimited” instead of the normal default of “0”.

Prerequisites

While Microsoft provides Azure Blob Storage with the PST Import Service, it appears that the SAS token that they provide only allows read and list access to the folder. You can upload PSTs to the folder using the token but you cannot download or read them. In order to use PowerShell for our imports, we’ll need to provision our own Azure Blob Storage with a SAS token that can read the uploaded files. There is of course a cost for this storage but it’s pretty minimal, a month of 1 TB of storage is less than $30 USD and you won’t even need the data for that long; check out the pricing matrix or pricing calculator to estimate your costs. You can also sign up for a free trial that gives you $200 in credits which is about 8 TB of data.

Setting Up Azure Blog Storage

Once you have an Azure account, you’ll want to install the Azure PowerShell module. You can then provision a storage account and storage container for the PSTs.
The commands below create a storage account called “iwitl” in the “West US” region using an Azure subscription called “Visual Studio Professional with MSDN”, you will need to select your own unique name and enter your subscription name (“Get-AzureSubscription | select SubscriptionName”). Also, the SAS token is set to expire 2016-12-31, you will want to adjust this accordingly.

Add-AzureAccount
$sta = "iwitl"
$stc = "pstupload"
$loc = "West US"
$sub = "Visual Studio Professional with MSDN"
$exp = "2016-12-31"
Select-AzureSubscription -SubscriptionName $sub
New-AzureStorageAccount -StorageAccountName $sta -Location $loc -Type "Standard_LRS"
Set-AzureSubscription -CurrentStorageAccountName $sta -SubscriptionName $sub
New-AzureStorageContainer -Name $stc -Permission Off
$token = New-AzureStorageContainerSASToken -Name $stc -Permission rwl -ExpiryTime $exp
Write-Host "`nStorage Account URI`n-------------------`nhttps://$sta.blob.core.windows.net/$stc`n`n"`
"SAS Token`n---------`n$token`n`n"`
"SAS URI`n-------`nhttps://$sta.blob.core.windows.net/$stc$token`n"

After provisioning, you’ll see the following output:

You now have your storage provisioned and can test connectivity. You’ll want to download the “Azure Storage Explorer” utility and you should be able to successfully connect using the “SAS URI” value in the PowerShell output.

Uploading PSTs into Azure Blob Storage

There are two options for getting the files into Azure Blog Storage. You can use the same PowerShell upload process as used by the PST Import Service using the “Azure AzCopy” tool. Otherwise, if you prefer a GUI interface, you can also use the recently installed “Azure Storage Explorer” utility to upload the PSTs.

How to Import PSTs Using PowerShell

Now that the PSTs are uploaded and you have your SAS token, you can use the “New-MailboxImportRequest” cmdlet in Exchange Online to kick off the import.
The following command imports the specified PST into a folder called “Imported PSTs”, excludes the Calendar from the import and allows for up to 25 bad items:

New-MailboxImportRequest -Name "mailbox_import_testuser" -Mailbox "test.user@iwitl.com" -TargetRootFolder "Imported PSTs" -ExcludeFolders "#Calendar#/*" -BadItemLimit 25 -AzureBlobStorageAccountUri "https://iwitl.blob.core.windows.net/pstupload/test.pst" -AzureSharedAccessSignatureToken "?sv=2015-04-05&sr=c&sig=Lo6%2B6IeNTSn%2Bbro5Xyytmu65PB0%2FyvGioHrKCFfzfLo%3D&se=2016-12-31T05%3A00%3A00Z&sp=rwl"

The “AzureBlobStorageAccountUri” is the “Storage Account URI” value from the previous PowerShell output along with the PST file name and the “AzureSharedAccessSignatureToken” is the “SAS Token” from that PowerShell output.

Once the import is started, you can use the “Get-MailboxImportRequest” and “Get-MailboxImportRequestStatistics” cmdlets to monitor the progress.
Once the process is completed, don’t forget to remove your PSTs from the Azure storage so you do not continue paying for them.
Tip: If you have Retention Policies in place, you may want to use the “Set-Mailbox -RetentionHoldEnabled $True” command to pause those policies before importing the PST. You will need to use “Set-Mailbox -RetentionHoldEnabled $False” in the future to apply the policies again.

Summary

The PST Import Service is a convenient way to import PSTs into Exchange Online mailboxes. However, this service has some limitations and may not meet the needs of every import project. Azure Blob Storage and PowerShell can be used to import PSTs in a similar manner but with the full flexibility of all the cmdlet parameters available.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Anyone who works with Office 365 knows that there is no shortage of new features rolling out, the pace at which new functionality is made available definitely keeps you on your toes.
Part of what inspired me to develop www.roadmapwatch.com is that I wanted to know more about when features progressed through the various stages on the official Office 365 Roadmap. Even with that tight watch of the roadmap, there are 164 features currently in some sort of “in progress” state and it’s hard to track them all.
On top of the features documented on the roadmap, there are occasionally small items that either slip through the cracks or aren’t worthy of a roadmap mention. One of those features is the “Common Attachment Blocking” feature in EOP that was introduced some time in the last month or so.
Below is a summary of what “Common Attachment Blocking” is all about…

The Timeline

Chatter about “Common Attachment Blocking (CAB)” started on one of the EOP blogs back around August 2015. In January of this year, there was a mention on a different EOP blog and on the Office blog that the feature would be coming in “the next quarter”. And then… Well, that was it. I never saw another mention of the feature or it’s rollout status.
It turns out that the feature was released in the last couple months and you’ll likely find it available in your tenant right now.

A “New” Feature?

There’s always been a way to block attachments by extension in EOP via a transport rule. However, using a transport rule gave you somewhat limited options when it came to the user experience. You could reject or delete a message with an attachment but there wasn’t a clean way to just strip the attachment and send the message along to the end user.

Using “Common Attachment Blocking”

You’ll find CAB buried in the Anti-Malware Filter Policy in EOP. From the Exchange Admin Center, if you navigate to “Protection” and then “Malware Filter”, you’ll see your default policy. On the “Settings” tab is the option to enable CAB; despite being “recommended”, it will be disabled by default in your policy.

Once enabled, there is a default list of 10 file extensions that Microsoft has selected and you can add more from a pre-defined list of 96 file extensions. All your favorites such as .exe, .com and .vbs are there.

TIP: While you cannot add custom extensions via the portal, it does appear that you can use the “-FileTypes” switch on the “Set-MalwareFilterPolicy” cmdlet to add extensions not in the list of 96.

User Experience

Any attachment file extension that you’ve selected will trigger the “Malware Detection Response” in your policy. You have the option to delete the message in it’s entirety or you can replace the attachment with a text file containing a notification.
The default notification looks like this:

Otherwise you can provide custom text in the notification.

Testing It Out

You can easily test out the feature by creating a second anti-malware policy (you’ll find CAB enabled by default on it) and applying it to only a subset of users via the options on the “Applied To” tab of the policy.

Give it a try! Let me know what you think in the comments below.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

One of the common limitations that organizations discover when deploying Exchange Online is the inability of users to “self-manage” distribution groups that are synchronized.
I’ve written about this in the past including putting together a workaround for environments that have Exchange 2013 on-premises. However, if you want users to be able to do what they’ve always done and manage Distribution Groups via Outlook, those groups will need to be moved to the cloud.
Below is a script that helps automate the process of moving the groups.

Quick Overview

The limitation is essentially that objects that are synced from on-premises can only be modified in the on-premises AD. When a user tries to modify a Distribution Group via Outlook, it is trying to modify the object in the cloud Global Address List (GAL) and not the on-premises one. As a result, the operation fails.
Moving the Distribution Group involves recreating the group in the cloud GAL however there are some attributes such as the email addresses that cannot be duplicated. This means you need to export out the existing groups configuration, remove the old group and then create the new group.

Assumption

The assumption is that you have no on-premises mailboxes at this point or people in the on-premises environment do not need the Distribution Group in their GAL. If users still need to see the object, you could do something where you create a mail contact on-premises that points to the Distribution Group in the cloud and exclude that mail contact from the sync scope so there is not a conflict on the address.

My Process

There are a number of ways this can be done, this process has worked for me and provides some ability to validate your changes before removing the old group completely.
At a high level, the process is as follows:

• Create a “placeholder group” in the cloud with all attributes populated except the email addresses
• Export out the current email addresses to a CSV
• Remove the on-premises by filtering it from the sync scope
• Finalize the placeholder group by changing it’s name to the proper name and importing in the email addressees
• Permanently remove the on-premises group by deleting it

Running the Script

To create the placeholder group and export the CSV, you’re going to run the following command:

.\Recreate-DistributionGroup.ps1 -Group "DL-Marketing" -CreatePlaceHolder

This will create a group in the cloud with the name “Cloud-PreviousDisplayName” and hide it from the GAL.
After the placeholder group is created, you will want to validate the new group. You can then delete the old group from the cloud by removing it from the sync scope. For current versions of AAD Connect, this can be done by populating the “adminDescription” attribute with the value “Group_NoSync”. See “Office 365 – The (Previously) Undocumented AAD Connect Filter” for more information on this attribute.
Once your sync cycle completes, you can run the following command to make the final cutover:

.\Recreate-DistributionGroup.ps1 -Group "DL-Marketing" -Finalize

Assuming everything looks good with the new cloud group, you can delete the on-premises one and setup a mail contact if desired.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Recreate-DistributionGroup.ps1
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

It’s been about 18 months since Microsoft announced the “Clutter” feature in Exchange Online. In that time, the default nature of Clutter has changed and it seems that many either love or hate the feature.
I recently had to dig into the details around “Clutter” for a client as some of the specifics around the behavior of the feature are not well documented.
Below are a few things you may not have known…

Quick Overview

The idea of the Clutter feature is to take “low-priority” emails and automatically move them out of your inbox into another folder. The thought is if there is a particular type of email you rarely read, but isn’t junk/spam, the message will be filed away into a folder where you can review it later. In order to achieve this goal, Exchange Online needs to be able to watch your behavior for a period of time before it can be “trained” on what to identify as clutter.

What Is / Isn’t Considered “Clutter”?

There are some emails that will never be identified as clutter. Some of these include:

• Messages where you are the sender
• Messages from anyone in your management chain
• Messages from your direct reports

Based on these items, you may find additional reason to populate org information in Active Directory if you’re not doing so today.

Is It Enabled?

When the feature was initially released, it was “opt-in” in that you had to explicitly enable it on a per-mailbox basis. Microsoft has since made a change so that Clutter is now enabled by default for all mailboxes. There are, however, some reasons why you may not see Clutter enabled instantly on a mailbox.
The Clutter feature will be automatically enabled after the user has received roughly 1,000 emails. My experience is that it is not instantly at 1,000 messages but can take a week or two before it is enabled. When enabled, the user will receive a “What is Clutter?” email in their “Clutter” folder welcoming them to the feature; the email also contains a link to the options page that allows the user to disable the feature.

Another reason you may find that Clutter is never enabled is if you have disabled OWA for a user. Since the Clutter feature is managed in OWA, Microsoft will not enable it if the user does not have access to the management interface.

How Can It Be Disabled?

Users can disable Clutter themselves via “Options” within OWA. Otherwise, administrators can disable Clutter via PowerShell with the “Set-Clutter” cmdlet. For organizations that want to disable the feature across their entire tenant, there is unfortunately not a single setting to make this change; each mailbox will need to have “Set-Clutter” run against it.

Controlling “Clutter” Behavior

The Clutter feature is intended to be managed by the user in that they can “train” it by moving messages in or out of the “Clutter” folder. You can either drag emails between folder or use the “Move to Clutter” option in Outlook and OWA to help with the sorting logic.
Administrators can block emails from being filed as clutter through the use of an Exchange Transport Rule that sets the “X-MS-Exchange-Organization-BypassClutter” header.

PowerShell Nuances

As mentioned above, Clutter is automatically enabled after certain behavior metrics are met. When a mailbox is first migrated or provisioned in Office 365, the “Get-Clutter” cmdlet will show “IsEnabled” as “False”. Once a user reaches the metrics for being enabled, “IsEnabled” logically changes to “True”.
Unfortunately, there seems to be nothing exposed to admins that shows the difference between a user that has not yet met the metrics vs a user that has explicitly had Clutter disabled. So if you have a new mailbox that you want to have Clutter disabled on, you need to run “Set-Clutter” and set “IsEnabled” to “False” even if it’s already set to that value.
This is something that is a bit confusing and I would like to see updated.

Personal Notes

I’ve had some clients that specifically state they do not want Clutter enabled for their users; others allow the feature to be used as Microsoft intends in that they leave it up to the user to follow the prompts and disable if they choose so. Personally, I have Clutter enabled on both my work and personal mailbox. My work mailbox receives very little into the Clutter folder, mostly notifications from Yammer. My personal mailbox, however, does a pretty good job of sorting bulk mailings such as sale notifications or other items that might be of interest to me but I probably don’t make a priority to read.
Could Clutter result in a user missing an email? It could, especially if the user is a heavy mobile user. The word “missing” here probably needs some definition as the email is obviously still in the mailbox, just in the “Clutter” folder as opposed to the inbox. Additionally, as Clutter catches new emails, it will place a message in the inbox stating what new types of emails were filed away.
Email usage is something that is very individual for each person. You have the “pilers” with thousands of messages in their inbox and the “filers” with hundreds of folders. Everyone uses it differently and “Clutter” is just another option that will appeal to some but not all users.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

While Office 365 offers an ever-expanding amount of insight of logging and health information, there are still operational tasks behind the scene that organizations do not have insight into. In many situations, you don’t necessarily care either; take for instance a failure of a database or server, the service has redundancy in place such that this type of issues goes largely unnoticed.
There is, however, one situation that can be hiding in the shadows that can be disruptive and a bit difficult to diagnose. The situation I’m referencing is one where all indicators on your end show that directory synchronization is healthy yet you have recipients missing from your Exchange Online Global Address List (GAL).
Below are some details on this situation, how you can identify it and how to get resolution through Microsoft support.

Directory Sync Process

It will help to start by explaining the sync process. When you’ve implemented directory synchronization, you’re using AAD Connect or one of its predecessors to sync on-premises Active Directory objects to an “Azure Active Directory” instance in the cloud.
What you may not know is that there is an additional sync process that occurs that you cannot see; Microsoft will often refer to this as the “forward sync” process. It is the “forward sync” process that actually populates the Exchange Online GAL from the Azure AD information; this generally occurs within a couple minutes or less from the initial Azure AD provisioning.

Possible Issues You May Encounter

Although rare, there are situations where you’ll find that there is an issue with that “forward sync” process. Some of the symptoms can be user objects that appear in Azure AD (“Get-MsolUser”) but not in the Exchange Online GAL (“Get-Recipient”) or issues with group members not being consistent when looking at Azure AD (“Get-MsolGroupMember”) vs Exchange Online (“Get-DistributionGroupMember”).
I’ve worked with several hundred Office 365 tenants since the inception of the service and the number of times I’ve uncovered “forward sync” issues is probably less than 10. That said, it’s very possible that others have gone unnoticed as identifying the issue can be difficult especially in large tenants.

Identifying The Issues

I was recently working with some on-premises mailboxes that were not showing up in the Exchange Online GAL as “Mail Enabled Users” as you would expect.
Taking a closer look at the sync process and these broken objects, I determined the following:

• Upon first sync, Azure AD will set “MSExchRecipientTypeDetails” to “1” on the user object and “CloudExchangeRecipientDisplayType” to “null”
• After the “forward sync” completes and the “Mail Enabled User” appears, you will see “CloudExchangeRecipientDisplayType” in Azure AD get set to “-2147483642” for user mailboxes.

For my objects that were not appearing the in the GAL, “CloudExchangeRecipientDisplayType” on the Azure AD object remained “null”.
So with the following PowerShell command run in Azure AD, I was able to identify all of the problem objects (7 in total):

Get-MsolUser -All | where {$_.MSExchRecipientTypeDetails -eq "1" -and $_.CloudExchangeRecipientDisplayType -eq $null}

The above command is searching for on-premises user mailboxes that are not appearing the Exchange Online GAL; if you’re looking for something else such as a resource mailbox, you will need to change the value specified in “MSExchRecipientTypeDetails”. You could also likely just look for MSExchRecipientTypeDetails values greater than or equal to “1”.

Resolution

Unfortunately there doesn’t seem to be much that you can do to resolve the issue on your own. In each case, I’ve needed to escalate to Microsoft and ask them to force the “forward sync” process. It can be challenging at times trying to explain what the issue is to some of the lower tier support specialists.
However, armed with the information above, you should be able to clearly show differences between Azure AD and Exchange Online queries and some potential attributes to key in on.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
 
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

While the Office 365 Roadmap is the authoritative source for features being added to the service, many features seem to receive a sort of “official announcement” via blog post or otherwise before they appear on the roadmap.
Before the feature announcement, one would assume that Microsoft has made a fair amount of progress of integrating components of the new feature into the service. Occasionally, some of these components become visible long before public announcement of the feature.
A bit of a different type of blog post today, one based on pure speculation resulting from a few recent observations.
Could these be signs of future functionality to come?

Undocumented Cmdlets

Through some keyboard fumbling, I recently stumbled across these two cmdlets:

• Get-MailboxLocation
• Get-MailboxPreferredLocation

The cmdlets quickly caught my attention as I had recently put together a script called “Get-MailboxLocations.ps1” that provides feedback on the various datacenters where your mailboxes are stored. Neither of these cmdlets seem to have any public documentation.

Get-MailboxLocation

This command returns a couple interesting attributes: “IsMigratedConsumerMailbox” and “IsPremiumConsumerMailbox“.

There’s also a “SiloName” attribute which I honestly have no clue about.

Speculation

These attributes lead me to believe they’re related to the recently announced “Outlook Premium” pilot and potentially a merging of the “Outlook.com” consumer service with Office 365. They certainly seem to indicate that Office 365 will be hosting “consumer” mailboxes in the future.

Get-MailboxPreferredLocation

There has been a long-standing request from international organizations to have “geo-tenants” or tenants where data can be distributed globally as opposed to being restricted to a single region. While I haven’t read anything “official”, I suspect we’ll eventually have that functionality in one form or another.
Looking at the attributes, “Get-MailboxPreferredLocation” provides a few interesting values:

Based on a cursory check of a few mailboxes, the “MailboxPreferredLocation” seems to reference the region from which the mailbox owner is accessing the mailbox. For my test mailbox, this is “NamNorth” which is the same as what I resolve “outlook.office365.com” to.
The “MailboxAlternatePreferences” seems to list out the various datacenter locations that I noted in my “Get-MailboxLocations.ps1” script. This list of datacenter codes seems to include 9 more entries than other lists that I’ve seen so it may represent new capacity (Canada?) or locations I just have not come across previously.

Speculation

These attributes could be for a couple things: Microsoft could be looking to optimize the traffic on their network by placing the mailbox in the location closest to the point from which the user accesses it. In addition to creating better user performance (although possibly unnoticed), it would in theory reduce traffic between datacenters. For the list of datacenters, is the list potentially a lead into “geo-tenants” where your data could be spread across a list of regions?

What Do You Think?

Let me know what you think about the above in the comments and what your thoughts are about what they might be for.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Just a quick post today on something that doesn’t seem to be well documented and could be helpful…
AAD Connect is basically Microsoft’s third version of their Directory Synchronization tool for Office 365. While AAD Connect includes more of a “wizard-type” interface for configuration of components such as AD FS, it’s also the current Directory Sync tool.
With each iteration of the Directory Sync tool has come changes; the method of forcing a sync has changed in each version and in the latest version of AAD Connect, we have a new set of default filters.
Below is a summary of the default AAD Connect filters along with two somewhat undocumented filters that could be used to your advantage.

How To See The Filters

You can see the filters by launching the “Synchronization Rules Editor” (“C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe”). At a high-level, you should understand that are basically two types of rules: “Inbound” and “Outbound”. The rules dictate the attribute flow in relation to the AAD Connect metaverse; so “Inbound” rules cover data going into the metaverse and “Outbound” rules cover data coming out of the metaverse.

Default Filters

Most of the default rules are pretty well documented on this page: Azure AD Connect sync: Understanding the default configuration.
As a summary, the default rules will not sync users…

• without a source anchor
• without sAMAccountName populated
• with the sAMAccountName of “SUPPORT_388945a0”
• with a mailNickname that begins with “SystemMailbox{”
• with a sAMAccountName that begins with “AAD_”
• with a mailNickname that begins with “CAS_” and contains “}”
• with a sAMAAccountName that begins with “MSOL_”

The rules will also not sync:

• Mail-enabled Public Folders
• System Attendant Mailboxes
• System Mailboxes
• Discovery Mailboxes
• Exchange Role Groups
• Conflict Objects (DN begins with “\\0ACNF:”)
• Dynamic Distribution Groups

The Not-So-Documented Filters

If you’ve used the “Synchronization Rules Editor” to peek at the default rules, you’ll see there are two filters that can be helpful when needing to exclude adhoc objects.
The inbound rules for users and groups both contain a filter that use the “adminDescription” attribute. If a user has this attribute populated with a value that begins with “User_” or a group has the attribute populated with “Group_”, it will not be synced into the metaverse.
So if you have objects that you don’t want to sync that are buried within an OU in your sync scope, you can use this attribute to filter out these individual objects. Populating the “adminDescription” attribute with the value “User_NoO365Sync” or “Group_NoO365Sync” (depending on the object type) will allow you to easily filter these objects.
There are a couple advantages of using “adminDescription” over a custom filter that sets “cloudFiltered” to “True”. First of all, the filter is already there in the base set so there’s no additional configuration needed in AAD Connect. The second advantage is the object is not pulled into the metaverse like it is with “cloudFiltered”. You’ll occasionally encounter scenarios where you need to purge an object from the metaverse to resolve the issue and just setting “cloudFiltered” will not do this for you.
 
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

It seems like every week I see a new phishing story coming through my social media feeds. The stories are all basically the same, someone with access to financials in an organization receives an email from “an executive” and follows instructions to wire thousands, hundreds of thousands or millions of dollars overseas.
While I’m admittedly surprised that large sums of money are transferred based on emails without any type of validation, it apparently is not uncommon. The email turns out to be, of course, not from an “executive” and the money is in most cases is long gone.
The other attack that seems to be making the news quite a bit these days is the distribution of “ransomware” via email. In particular, it seems like the healthcare industry is targeted with these types of attacks. A user opens an email attachment and suddenly they’ve encrypted whatever files they have access to; short of restoring the data from backups, the only answer is to pay a ransom in Bitcoins.
Proper security includes depth in defense and in some cases your users are the final layer of protection. Below are a few things that can be implemented at virtually no cost that could help protect your organization.

Notable Attacks

If you’re asking “does this really happen”, here are a few recent examples for you:

• Omaha’s Scoular Co. loses $17 million after spearphishing attack
• Ubiquiti Networks Says It Was Victim of $47 Million Cyber Scam
• Mattel fought elusive cyber-thieves to get $3M out of China

So now that we’ve established that the threat is real (and costly), how does this happen?

How It Happens

Short of a compromise of your internal systems, there’s basically two ways that these emails trick your users:

Microsoft Fights Back

Microsoft is implementing a few things to help defend against these types of attacks. One of these features is “Safety Tips” which is a visual indication in OWA around how safe an email is. Unfortunately this feature is only rolling out to OWA today although I wouldn’t be surprised to see it make its way into Outlook in the future. Another feature, related to HTML links and attachments, is “Advanced Threat Protection” which is part of the E5 license or available separately as an add-on.

What You Can Do

First of all, if you don’t have a proper SPF published today, you should start there. After that, implementing DKIM and DMARC can help protect against “insider phishing” emails. Even if you implement DMARC with an action of “none”, you can use a transport rule to protect your own users from “insider phishing” emails. For more details on this setup, see “Office 365 – SPF, DKIM and DMARC in Exchange Online“. Another option is to modify inbound emails and provide “visual cues” to your users about the source of the email.

Providing Visual Cues

I have somewhat mixed feeling on this type of action. I’ve seen it implemented at a few clients and while I’m not a fan of modifying the content of the email, it could prove helpful. The effectiveness will certainly depend on the percentage of external vs internal emails that a person receives; at some point I’m sure there’s a subconscious habit to ignore any warnings.
The idea here is to modify the either the subject line or body of an email such that a user has additional information about it. While messaging admins might look at the message headers, it’s unreasonable to think that your average user is going to think about that. You can easily use transport rules to give users a little more insight as to whether an email is safe or not. In the earlier stated phishing examples, one would hope that it would at least cause the recipient to ask a few more questions before wiring millions of dollars overseas.
As an example, you might force all external email to show the following:

And if a message fails SPF because a company has failed to properly configure it, you might modify the email as such:

Configuration

The setup here is not that difficult. Basically it’s two transport rules that use the “prepend disclaimer” function to modify inbound emails. If you have emails that are known to be spoofed (e.g. external applications) then you may need to add some exceptions.

New-TransportRule -Name "Visual Cue - External to Organization" -Priority 0`
-FromScope "NotInOrganization"`
-ApplyHtmlDisclaimerLocation "Prepend"`
-ApplyHtmlDisclaimerText "<div style=""background-color:#FFEB9C; width:100%; border-style: solid; border-color:#9C6500; border-width:1pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;""><span style=""color:#9C6500; font-weight:bold;"">CAUTION:</span> This email originated from outside of the organization.  Do not click links or open attachments unless you recognize the sender and know the content is safe.</div><br>"

New-TransportRule -Name "Visual Cue - No SPF Validation" -Priority 1`
-HeaderContainsMessageHeader "Authentication-Results"`
-HeaderContainsWords "spf=TempError","spf=PermError","spf=None","spf=Neutral","spf=SoftFail","spf=Fail"`
-ApplyHtmlDisclaimerLocation "Prepend"`
-ApplyHtmlDisclaimerText "
WARNING: The sender of this email could not be validated and may not match the person in the ""From"" field.
"

Limitations

Again, this is not a perfect solution and Microsoft is likely to eventually bring features like “Safety Tips” to Outlook and the mobile platform. If the email is sent as “plain text”, the appended warnings lose some of their visibility as the warning is also in plain text without any color.
Additionally, the scenario I really wish we could account for here is when the message is sent with a similar domain and the P1 and P2 don’t match. Unfortunately, there is not an X-header that indicates this even though it seems like it would be relatively easy to identify. Also, if an email is received with a similar domain where the P1 and P2 do match, it’s going to be difficult to catch. With both of these scenarios, you can only hope that the notification of it being an “external email” is enough.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Just a quick post today on a recent script I had to put together.
The message trace feature within Exchange Online works pretty well but can be a challenge if you want to search based on a particular email subject. In a scenario where you want to know who received an email or a set of emails, you have to employ some tricks to be able to query large amounts of logs.
The script below allows you to search on a subject or variants of a subject going back X number of days. The output is logged to a CSV file showing the details of the trace log entry.

Some Influences…

Some of the code in this script was inspired by the example at “Praveen’s Blog“.

Using The Script

The script takes three command line switches and all are mandatory. The parameters are as follows:

In the scenario where you’re looking for something like a phishing campaign, you might know that the emails all come through with a unique but patterned subject. So you may have subjects like “Invoice TUINV65988 from Tip Top Delivery” and “Invoice HXINV44152 from Tip Top Delivery” where the only difference is the “invoice” number. Using the asterisk in your subject line will allow you to search for variants.
So using the following would search 5 days back for an email with the subject “*Invoice*Tip Top*” and save the results in c:\scripts\output.csv:

.\Get-MessageTraceBySubject.ps1 -Days 5 -Subject "*Invoice*Tip Top*"

During the query, which can take an extended amount of time, you can see in the progress bar what date range is currently being evaluated. Messages are evaluated in batches of 5,000 per query.

Limitations

The Get-MessageTrace cmdlet only returns a maximum of 5,000 results per query unless you use paging and then you can return up to 1,000 pages. So the theoretical limit on this query is 5,000,000 entries.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Get-MessageTraceBySubject.ps1

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Despite all the new features that Microsoft has introduced around Retention Policies and Archiving, some clients that I work with still long for the day of “Managed Folders”.
The “Managed Folders” feature left us with Exchange 2010 and the replacement, “Retention Policies” and “Retention Tags”, can be a difficult to adopt for some organizations.
In many cases, I’m working with clients that were previously allowing users to “archive” emails to PSTs so the users are familiar with a “drag and drop” approach to storing away messages. Tagging individual emails with a “Personal Tag” and leaving it in place can be a training struggle that the organization is not ready to take on.
Below is a script I developed for recreating some of the “Managed Folders” functionality that existed in earlier versions of Exchange.

The Use Case

This is by no means a perfect solution, ideally your organization should embrace Retention Policies and Retention Tags. However, there are times where the textbook “right” solution is not the best fit for an organization and this can get you somewhere in the middle. At a high level, we’re basically talking about automating the creation of a folder in a user’s mailbox and assigning it a Personal Tag that does not delete the folder contents.
Here are a couple of use cases:

Some Influences…

Some of the code in this script was inspired by examples from Glen Scales. That should be the standard disclaimer on all things related to EWS as any research in this space seems to lead back to Glen’s site.

Prerequisites

This script uses version 2.2 of the EWS Managed API. If you don’t have it installed, you can download it from Microsoft: Microsoft Exchange Web Services Managed API 2.2. The API should install in a default folder of “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”, if you install it in a different location you will want to modify the script or use the command line parameter to specify the alternate location.
You will also need an account that is setup for Impersonation. If you don’t have an account with this role, you can easily set it up with these instructions: “How To: Configure Impersonation“.

Using The Script

The script takes up to seven command line switches although you can specify as few as three. The parameters are as follows:

So using the following would create a folder called “Archived Emails” in the mailbox and assign it a Personal Tag labeled “Never Delete”:

.\Create-ManagedFolder.ps1 -TargetMailbox test.user@iwitl.com -FolderName "Archived Emails" -RetentionTag "Never Delete"

When executing the script, you’ll be prompted for the credentials of the account that has the Impersonation role.

User Experience

Your user, or entire organization, now has a folder where they can “drag and drop” emails so they are protected from a Default Policy Tag that may archive or delete items.

Limitations

It should be noted that the user, as the owner of the mailbox, can still manage the folder you create including changing the assigned Personal Tag or even deleting the folder. Also, during creation of the folder, if the folder is found to exist, the script will just log a message to the console and not touch the existing folder.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Create-ManagedFolder.ps1

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Earlier this month, I published some notes (“Office 365 – Have You Evaluated These Exchange Online Features?“) on features within Exchange Online that deserve a bit of scrutiny.
One of these features is the “Default Role Assignment Policy” which, by its name, is assigned by default to every mailbox.
What does this policy contain?
Are there any permissions that may not align with your organization’s policies?
Below is a deeper look at this policy and some settings you might want to dig into.

What Is It?

The “Default Role Assignment Policy” is assigned to every mailbox and “grants end users the permission to set their options in Outlook on the web and perform other self-administration tasks“. You’ll find the policy in the Exchange Admin Center under “Permissions” and “User Roles”.

What Does It Allow?

The policy contains 13 roles for “commonly used permissions” as defined by Microsoft, all of which are enabled out of the box.
These roles are:

Evaluating the Roles

Requirements will vary by organization and some may not even be relevant in your environment.
For the “MyContactInformation” and “MyProfileInformation” roles, they will not work if you are using Directory Synchronization as any changes need to be made in the on-premises Active Directory. So it might be worthwhile to disable it just to avoid any confusion. If you’re not using Directory Synchronization, do you want users to be able to change their own name in the directory? It’s not a common operation that I see delegated out to users and is likely to cause more issues than it solves. Consider disabling these. The one exception is that “MyPersonalInformation” under “MyContactInformation” is what allows you to change your pictures via OWA. Leave that role enabled if you want to allow users to update their pictures; if you don’t, you’ll need to modify the “OwaMailboxPolicy-Default” as well and set “SetPhotoEnabled” to “$False”.
The “MyDistributionGroups” role is the one I most often recommend disabling. Do you want your users to be able to create their own distribution groups in the directory? Generally not. If you don’t disable this one, at least consider creating a “Distribution Group Naming Policy“.
“MyDistributionGroupMembership” is another role that if you’re using Directory Synchronization, it may not apply to you. Unless you’ve migrated your distribution groups to the cloud, they would need to be modified in the on-premises Active Directory. If you want to actually use this feature, you need to dig really deep into OWA. Go to “Settings” | “Mail” | “Other” and then click the link to “Go to an earlier version” and then you’ll finally be presented with the “Groups” button. Completely intuitive! Hopefully this is eventually pulled a little higher into the options menu.
The “MyRetentionPolicies” is a little confusing in that is allows users to add “Personal Tags” that are not part of their assigned Retention Policy. Not sure I understand the use case for this and would generally recommend that you disable it.
I believe that “MyMailSubscriptions” role is part of the “Connected Accounts” feature in OWA but there is very little documentation on it. The cmdlets that it includes (“New-SyncRequest” along with Get- Set- and Resume-) aren’t even documented on TechNet. This one can likely can be disabled.
The “My Marketplace Apps”, “My ReadWriteMailbox Apps” and “My Custom Apps” roles pertain to the Office Apps. I find a number of these helpful but some organizations want to restrict their users from using them.
The rest of the roles are pretty innocuous. The “MyTextMessaging” role is pretty legacy where you could setup the ability to receive a text message when you had a meeting or received an email. Limited to certain locations and providers, it’s basically pre-smartphone era and can be disabled.

Digging Deeper

Still want to know more about the roles and what specific cmdlets/parameters they allow?
You can see the cmdlets behind each role by running the following in PowerShell:

(Get-ManagementRole {RoleName}).RoleEntries

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Office 365 Roadmap is a bit like Christmas twice a month or so; you never know what might pop up as an “In Development” feature.
The March additions included four new Outlook features that should prove to be interesting the in weeks / months to come.
Below are the latest additions to prepare for as they make their way through the development cycle and onto your desktop.

All of the features below are in a status of “In Development” at the time of this post.

#1 – One-Click Archive

I fear that this one will be a little confusing for users, especially in organizations with Retention Policies or Archive Mailboxes in use. Basically the user is presented with a button called “Archive” that does nothing more than allows the user to move a message to a folder they designate. The action has no bearing on the actual retention of that item, it’s just a shortcut for dragging the item into a folder. In Outlook for Windows and Mac, you’ll see a similar button added for this action on the Delete pane.

#2 – Focused Inbox for Outlook for Windows, Mac and Web

As long as this feature is an opt-in and not enabled by default (like “Conversation View” is), I’m indifferent on this one. I don’t find “Focused View” very helpful in the iOS application and have it disabled.
Everyone uses their mailbox differently so it’s fine to add this feature to the desktop client as it seems to be popular but lets hope it’s disabled by default. Given that “Clutter” is enabled by default and then we have “Junk E-Mail”, I think we may be giving users a few too many options on where we send their mail.

#3 – Outlook 2016 for Mac Two Step Authentication

If you’re running an “Office Insider” build of Office for Mac, you likely saw this already.
The Outlook client is being converted over to support “Modern Authentication” which provides for more of a single sign-on experience and allows for true Multi-Factor Authentication (MFA). We have more and more clients asking about MFA so this will be a welcome addition. This feature will be dependent upon the service being enabled for Modern Authentication. For more details, check out “Office 365 – Getting Closer To “True” Single Sign-On For Outlook“.

#4 – Upload Local Outlook Attachment to OneDrive & OneDrive for Business

This will be great for organizations using OneDrive for Business and allow external sharing. Basically the same “Cloud Attachments” feature that exists in OWA today is being added to Outlook. Perhaps soon we’ll stop the sending of 30+ MB files around via email.

How To Keep Track Of These Changes

The Office 365 Roadmap is the authoritative source for all these updates but if you want more detail on the changes or would like to be notified when the roadmap is updated, check out the RSS feed I created over at Office 365 Roadmap Watch. You can subscribe to the RSS feed via Outlook or IFTT and get notified when changes occur.

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.