Data Loss Prevention in Office 365: Part Four

In part three of this mini series on data loss prevention, we examined a PCI policy’s properties in some detail.  Today, we’ll finish our look at this policy.

When we left off, we were examining the options available via the policy’s “Custom content”  option (see screenshot below) –

screenshot one

The custom content option gives you the ability to determine what properties of the examined message will be sent to the DLP report’s recipient:

screenshot two

As you can see, it can get pretty involved.  This feature is not only useful because of what can be included, but also because of what can be excluded.  For example, the details of a message can be removed to preserve privacy while tracking incidents of your DLP rule being triggered.

Note also that actions can be added to create even more sophisticated, compound logic conditions.

And there can also be exceptions:

screenshot three

These exceptions can be very precise, for example:

screenshot four

The remaining properties are shown in the screenshot below:

screenshot five

You can:

  1. Choose the rule’s priority (this determines the priority it receives relative to other rules.  For example, rules with a priority of 0 are processed first, 1 second and so on).
  2. Choose the rule’s severity level – Low, Medium and High
  3. Choose the rule’s mode – Enforce, Test with Policy Tips, Test without Policy Tips.
  4. Choose a date range for the rule to be in-effect (leave this blank to configure the rule to run without date restrictions).
  5. Choose whether or not to use the “stop processing more rules” option (see this Office 365 community blog post regarding when and how to use this)
  6. Choose what component of the (analyzed) message will be examined for the sender’s address – Header, Envelope or both Header and Envelope
  7. Choose which DLP policy the rule-set will be applied to.


Needless to say, we’ve only scratched this topic’s surface. Hopefully this series of posts has given you a good idea of what’s possible and where to look for more information.

Happy hunting!

Data Loss Prevention in Office 365:

Part One.

Part Two.

Part Three.

Oh and it should also be noted that you can (of course) create and modify DLP Policies using PowerShell’s New-DlpPolicy and Get-DlpPolicy cmdlets.

Data Loss Prevention in Office 365: Part Three


In part two of this mini-series on data loss prevention, I showed you how to create a new policy and explained the link between data loss prevention policies in Office 365 and sensitive information types.

This week, we’ll take a closer look at a policy’s configuration once it’s been created.

Credit Card Policy 4

Note the screenshot above, which shows the main page of the Exchange Admin Center’s data loss prevention section. As you can see, there are two policies in-place, one that tests for the presence of HIPAA information and another which reports the transmission of credit card data (searching for possible PCI violations).

We’re going to focus on the credit card data transmission report.

By clicking on the pencil icon while the policy you want to edit is highlighted, you’ll be brought to the general configuration page:

Credit Card Policy 1

In the general section, we name the policy, enter a description, choose the policy’s state (enabled or disabled) and choose a requirements mode (i.e., whether or not the policy will be enforced, test without policy tips or test with policy tips).

If you’re wondering about policy tips, see this comprehensive overview. The short version is that policy tips can be used to inform your Outlook 2013, OWA and OWA for mobile devices users that the message they’re sending may violate a policy (or at least, is triggering notice).

Once you’ve entered the information and actions you want, click the rules option on the left-hand side of the interface to configure finer-grained actions:

Credit Card Policy 2

In the example, I’ve already configured the sensitive information type used and the policy’s actions.  By clicking the pencil icon, we can take a closer look at what I did:

Credit Card Policy 3

In the name field, I entered the label “PCI DSS…”, the policy’s rule set has been configured to apply if:

  1. The recipient is located outside of the organization
  2. The message contains sensitive information (type: credit card number).

If these conditions are met, the policy will generate an incident report and send it to an internal recipient (email address obscured for this post). The “Custom Content” referenced is the following:

Credit Card Policy 8

And that’s all the time I have for now.  In the next post, we’ll finish our look at this policy and describe some of the other actions you can take.



Data Loss Prevention in Office 365: Part Two


In a previous post, I provided a brief introduction to Office 365’s data loss prevention offering.

This time, we’ll walk through the process of creating a DLP policy from a template.

Before we start, let’s keep three key ideas in mind:

1.) Data Loss Prevention (DLP) policies are intended to prevent the accidental or malicious transmission of sensitive company and/or customer data (for example, emailing a social security number unencrypted to a recipient).

2.) In Office 365, DLP policies are built upon sensitive information types.

3.) Sensitive information types are, as the phrase implies, the confidential or otherwise protected information you want to prevent from being freely transmitted.

This TechNet link provides a listing of the current inventory of sensitive information types that can be used in a DLP policy.

So now let’s walk through the creation of a DLP Policy.

1.) Login to the Exchange Admin Center and choose compliance management and then, data loss prevention (note that in the screenshot, a policy for reporting credit card data is shown):

DLP Walkthrough 1
2.) Click the plus symbol to select New DLP Policy from template option



3.) Now you can browse through the selection of sensitive information types:

DLP Walkthrough 2


4.) Notice that the PCI Data Security Standard (or, PCI DSS) is selected. Click Save to continue.  You’ll be returned to the main screen.

DLP Walkthrough 1


5.) The DLP policy is in-place but its properties – including the actions you’d like it to take – have not been configured. Click the pencil icon to edit the policy.

DLP Walkthrough 3

6.) The general section is where you set the policy’s name, write a description, choose its state and also select whether or not you want the policy to be enforced or act in a testing mode.  Next, click the rules link.

DLP Walkthrough 4

And that’s it for now.  In the next post, we’ll complete the creation of this policy and review some of its finer grained elements.


Data Loss Prevention in Office 365: Part One


As you surely know, email is at the very heart of business communication (as I’ve probably said and/or written about a million times – or perhaps only 10).

Which means that all sorts of information can pass through your messaging system – not all of it desirable; some of it potentially damaging.

For example, let’s say you’re concerned about credit card data being sent to external recipients in potential violation of the Payment card Industry Data Security Standard (PCI DSS), how would you know, and what could you do to prevent it?

The answer is data loss prevention – also known as DLP.

The Wikipedia entry on DLP summarizes:

Data loss/leak prevention solution is a system that is designed to detect potential data breach / data ex-filtration transmissions and prevent them by monitoring, detecting and blocking sensitive data while in-use (endpoint actions), in-motion (network traffic), and at-rest (data storage). In data leakage incidents, sensitive data is disclosed to unauthorized personnel either by malicious intent or inadvertent mistake.

Such sensitive data can come in the form of private or company information, intellectual property (IP), financial or patient information, credit-card data, and other information depending on the business and the industry.

If your email platform is Office 365 (or Exchange 2013 on premise), Microsoft has provided a host of built-in sensitive data type templates you can employ as a part of a DLP strategy.

Although the underlying algorithms are quite complex, the initial workflow is fairly simple to understand so long as you recall that sensitive information types form the foundation of the data loss prevention policy’s actions.

Note the following for example:

The screenshot shows a DLP policy configured to capture potential instances of PCI-DSS violations (in this case, messages sent to external recipients that contain numerical sequences which seem to match the standard credit card format).

Note also that you access the DLP screen from the Exchange Admin Center by selecting the compliance management option.

In the next post, we’ll review in greater detail the process of creating a DLP from a template – or from scratch – including the relationship between sensitive information types and DLP policies.

Until then, check out these links:

Using PowerShell to Remove Specific Emails


Email is at the heart of business communications and so, it shouldn’t come as a surprise when you’re called upon to perform a variety of tasks above and beyond simply keeping messages flowing.

For example, removing emails which, for whatever reason, are considered targets for deletion.

Using PowerShell, it’s possible (on both Office 365 and on-premise Exchange) to remove messages by using a modified application of the search-mailbox cmdlet.

So, to find a message within a user’s mailbox by subject heading, you can issue the following:

Get-Mailbox -Identity | Search-Mailbox -SearchQuery ‘Subject:”your subject”‘ -EstimateResultOnly

And to remove the message found via your search you simply add the -DeleteContent switch:

Get-Mailbox -Identity | Search-Mailbox -SearchQuery ‘Subject:”your subject”‘ -DeleteContent

Note that to perform the basic search, you need the discovery management role and to delete items you need the mailbox import-export role.

Of course, your search parameters aren’t limited to subject line alone but can include date, keywords within a message, target folder and more.

Remote Access to Office 365 Via Powershell

In an on-premise Exchange environment, your PowerShell connection to the server is essentially a remote session (even though it occurs within your Kerberos-enclosed domain).  In an Exchange 2010 environment the EMC (when installed on a Windows desktop) obscures this relationship but it’s there nonetheless.

It’s no different when you connect to Office 365 for PowerShell administration (which is, as I’ve stated before, the best and most powerful way to manage your Exchange tenant).

The how-to is basic and covered well by Microsoft here and at Tom’s IT Pro here.

Briefly, the syntax is very simple:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $UserCredential -Authentication Basic -AllowRedirection
Set-ExecutionPolicy RemoteSigned
Import-PSSession $Session

In which, an object named $UserCredential is created that employs the get-credential cmdlet to gather your, well, credentials and passes that to Office365’s web service (for PowerShell).

The session data is imported so the cmdlet set appropriate for Office365 is imported.  This includes familiar tools such as get-mailbox.

When finished, you end your session by invoking Remove-session $Session which cleans up your PowerShell threads of execution (preventing orphaned sessions).


O365 and OWA: Room Listing Display Limitations



Although quite versatile and feature-rich, Exchange Online does have certain limits that distinguish it from on-premise Exchange.

For example, if you’re accustomed to booking rooms via OWA hosted from an on-premise Exchange organization, you expect to see a list of all available rooms.

In Exchange Online however, there’s a default system setting (which, as of this writing can’t be changed) that limits the number of rooms displayed to 100.  In large enterprises, this can cause some user frustration.

One work-around is to use the scheduling assistant to search for the room you want.  This is helpful, but may not satisfy all users’ needs.

Another method – which I consider to be more elegant – is to create room lists.

Room lists organize room resources into a specific type of distribution group that contains, well, rooms.

This is obviously very useful for large, geographically distributed firms that have many locations and far more than 100 bookable rooms.

So for example, to create a room list for all bookable rooms in the New York office you could issue the following PowerShell command (when connected to your tenant via a remote PowerShell session):

New-DistributionGroup -Name “New York Meeting Rooms” -RoomList

And to add rooms to this room list you’d use the following cmdlet:

Add-DistributionGroupMember -Identity “New York Meeting Rooms” -Member room120

Of course, some amount of planning and thought is needed to organize your rooms into these groups so your users can make sense of it all.  But once you’ve done that background work, room lists will make life much easier for people who access Exchange exclusively through OWA.

Using Role Based Access Control to Securely Manage Exchange Online



Exchange employs a permissions and access control model called Role Based Access Control (or RBAC).

The RBAC security model uses a hierarchy of access, organized into parent objects called ‘Management Role Groups’ and child objects called ‘roles’. Management Role Groups are composed of roles (for example, the Compliance Management role group contains the roles Data Loss Prevention and Information Rights Management – among others – which fall under the umbrella of compliance).
It’s important to note that users can be granted a mixture of rights that fit their job roles (for example, John Smith, who works in legal, can be assigned the ‘Legal Hold’ role from the Compliance Management role group and the ‘Retention Management’ role from the Records Management role group).


The above illustration is an overview of how permissions can be apportioned within Exchange.

Note how for example, administrators (as a category) can be granted rights in several role groups whose component roles – and therefore, role assignments – cross a variety of action areas.

Exchange’s management role groups are as follows:
Compliance Management (manage compliance settings)
Discovery Management (perform mailbox searches)
Help Desk (view and manage recipient configuration)
Hygiene Management (manage Exchange anti-spam features and grant permissions for antivirus products to integrate with Exchange)
Organization Management (manage Exchange objects – system super user)
Recipient Management (create, manage and remove recipient objects)
Records Management (configure retention policy tags, transport rules, etc.)
UM Management (Members of this management role group can manage Unified Messaging organization, server, and recipient configuration)
View-Only Organization Management (view recipient configuration and system properties)

Let’s detail each group’s components.


Compliance Management Role Group

This role group will allow a specified user, responsible for compliance, to properly configure and manage compliance settings within Exchange in accordance with a defined policy.”


Data Loss Prevention (intercepting the transmission of sensitive data types such as credit card, Social Security numbers, etc.)

Information Rights Management (members of this role can configure email encryption settings and related tasks)

Mailbox Import Export (members of this role can export items from and import item into mailboxes)

Retention Management (members of this role can configure mail retention policies)

View-Only Audit Logs (members of this role can search audit logs)

View-Only Configuration (members of this role can view all non-recipient Exchange configuration settings)

View-only Recipient (members of this role can view the configuration of recipients – i.e., mailboxes, mail users, mail contacts and distribution lists)

Discovery Management Role Group

Members of this management role group can perform searches of mailboxes in the Exchange organization for data that meets specific criteria.”


Legal Hold
Mailbox Search


Hygiene Management

Members of this management role group can manage Exchange anti-spam features and grant permissions for antivirus products to integrate with Exchange.”


Transport Hygiene
View-Only Configuration
View-Only Recipients

Help Desk Role Group

Members of this management role group can view and manage the configuration for individual recipients and view recipients in an Exchange organization. Members of this role group can only manage the configuration each user can manage on his or her own mailbox.  Additional permissions can be added by assigning additional management roles to this role group.”


Reset Password
User Options
View-Only Recipients


Organization Management

(note how this management role group forms a set of which the other groups are essentially subsets)…

Members of this management role group have permissions to manage Exchange objects and their properties in the Exchange organization. Members can also delegate role groups and management roles in the organization.”


Audit Logs
Data Loss Prevention
Distribution Groups
Federated Sharing
Information Rights Management
Legal Hold
Mail Enabled Public Folders
Mail Recipient Creation
Mail Recipients
Mail Tips
Message Tracking
Move Mailboxes
Org Custom Apps
Org Marketplace Apps
Organization Client Access
Organization Configuration
Organization Transport Settings
Public Folders
Recipient Policies
Remote and Accepted Domains
Reset Password
Retention Management
Role Management
Security Group Creation and Membership
Team Mailboxes
Transport Hygiene
Transport Rules
UM Mailboxes
UM Prompts
Unified Messaging
User Options
View-Only Audit Logs
View-Only Configuration
View-Only Recipients


Recipient Management

Members of this management role group have rights to create, manage, and remove Exchange recipient objects in the Exchange organization. “

Roles :

Distribution Groups
Mail Enabled Public Folders
Mail Recipient Creation
Mail Recipients
Message Tracking
Move Mailboxes
Public Folders
Recipient Policies
Reset Password
Team Mailboxes


Records Management

Members of this management role group can configure compliance features such as retention policy tags, message classifications, transport rules, and more.

Audit Logs
Message Tracking
Retention Management
Transport Rules


View-Only Organization Management

Members of this management role group can view recipient and configuration objects and their properties in the Exchange organization.


View-Only Configuration
View-Only Recipients



Consider the following example, in which there are four categories of users who interact with Exchange Online:

1.) Administrators – full access (create policies, create recipient objects, create groups and distribution lists, modify critical system settings, delete system and recipient objects, interact with Microsoft engineering at the system level as peer)

2.) Administrators – specialized access (view system configuration, view recipient properties, run system reports, possess super user privileges in one or more management role group but not all)

3.) Help Desk (full access to help desk level activities such as create recipient mailbox, modify mailbox properties, release false positive SPAM from quarantine, view and modify distribution lists and related end-user supportive tasks)

4.) End-users (request modifications, request object creations such as distribution lists, report errors

Within these four main categories, it’s possible to create specific security groupings.

Administrators – full access will have super user privileges within all management role groups:

Compliance Management (manage compliance settings)
Discovery Management (perform mailbox searches)
Help Desk (view and manage recipient configuration)
Organization Management (manage Exchange objects – system super user)
Recipient Management (create, manage and remove recipient objects)
Records Management (configure retention policy tags, transport rules, etc.)
View-Only Organization Management (view recipient configuration and system properties)
Administrators – specialized access will have super user privileges within management role groups that are relevant to their job function. For example, a technical liaison working for Legal would need to possess the ability to place mailboxes on legal hold, search mailbox contents and perform other activities related to gathering information about and from user mailboxes.

So, Administrator – specialized access legal would be granted assignments from following role groups:

Compliance Management
Discovery Management

From the Compliance Management role group, the Administrator – specialized access, legal would obtain the mailbox-import-export role and from Discovery Management, legal hold and mailbox search.

Help Desk – self-explanatory. Help Desk personnel will be granted role assignments from the Help Desk Management Role group. These roles are limited to a subset of the querying and recipient object manipulation capabilities of the more robust admin roles.

The default Help desk roles are:

Reset Password
User Options
View-Only Recipients

Note that it’s possible to add roles from other management role groups to individual Help Desk personnel (for example, Help Desk managers or more senior level Help Desk team members)
End-users – End users are recipients of the policies and configuration changes made by administrators and help desk personnel. End-users are also a source of feedback information about overall system health and performance

As you can see, it’s possible to use the building blocks Role Based Access Control provides to assemble a very granular permissions model for a variety of job assignments which require interaction with Exchange.


Exchange 2013’s Admin Center: A Walk-through


Exchange 2013 introduces administrators to the web-based Exchange Admin Console, a more streamlined, efficient and user-friendly management interface for controlling Exchange.

Of course the best, and most powerful tool for managing Exchange remains the shell but for performing simpler administrative tasks the EAC does quite nicely.  Also, the EAC provides a common control interface for hybrid deployments (i.e., combined deployments of on-premise and Office 365 Exchange).

In this post, we’ll review the EAC’s various feature panes, describing the actions you can take in each.

But before we get to that, let’s take a comparative look at the first level screens of  Exchange 2010’s Management Console and Exchange 2013’s EAC.


First, Exchange 2010’s Management Console (click on the image to enlarge):


In the above, control of various Exchange elements (such as send connectors, CAS configuration and database management) is divided across function areas defined by organization, server and mailbox management sections. It takes a bit of getting used to and can’t be called intuitive.

Now, let’s look at Exchange 2013’s Administration Console (click on the image to enlarge):

Main Page

Here, feature panes are organized according to globally defined tasks, eliminating the sometimes confusing redundancy of the Exchange 2010 Management Console and the need to use many clicks and sub-clicks to accomplish your goal.

Let’s review each feature pane’s details (quotes are from this Technet article about the EAC – and the environment from which the screenshots were taken was built on Amazon Web Services as described by me here).  Click on images to enlarge.

The Recipients Pane:


This is where you’ll manage mailboxes, groups, resource mailboxes, contacts, shared mailboxes, and mailbox migrations and moves.”

The Permissions Pane:


This is where you’ll manage administrator roles, user roles, and Outlook Web App policies.

The Compliance Management Pane:


This is where you’ll manage In-Place eDiscovery, In-Place Hold, auditing, data loss prevention (DLP), retention policies, retention tags, and journal rules.”

The Organization Pane:


This is where you’ll manage the tasks that pertain to your Exchange Organization, including federated sharing, Outlook Apps, and address lists.”

The Protection Pane:


This is where you’ll manage anti-malware protection for your organization.

The Mail Flow Pane:


This is where you’ll manage rules, delivery reports, accepted domains, email address policies, and send and receive connectors.

The Mobile Pane:


This is where you’ll manage the mobile devices that you allow to connect to your organization. You can manage mobile device access and mobile device mailbox policies.”

The Public Folders Pane:

public folders-tab

In Exchange 2010, you had to manage public folders by using the Public Folder Management Console, which was located outside of the EMC in the Toolbox. In Exchange 2013, public folders can be managed from within the public folders feature area.”

The Unified Messaging Pane:

unified messaging-tab

This is where you’ll manage UM dial plans and UM IP gateways.”

The Servers Pane:


This is where you’ll manage your Mailbox and Client Access servers, databases, database availability groups (DAGs), virtual directories, and certificates.”

The Hybrid Pane:


This is where you’ll set up and configure a Hybrid organization.”


Installing Exchange 2013: A Basic Overview



The process of installing Exchange 2013 using the guided GUI is pretty straightforward, provided you’ve taken care of the prerequisites, prepared for gotchas (about which, more later) and planned your deployment carefully.

For the purpose of capturing the process, I created an Amazon Web Services based test environment (similar to the one described here) consisting of a domain controller, an Exchange 2010 server and the server on which Exchange 2013 was installed.

All servers are Windows 2012 R2 and the domain functional level is Windows 2012.

So, the scenario is that you’re installing Exchange 2013 into an existing Exchange 2010 SP3 organization and all roles have been selected.

 Before running Setup.exe on your target host you should make sure the following is true:

1.) Microsoft Office Filter Pack Ver 2.0 is installed

2.) The service pack for the Office Filter Pack is installed

3.) Media Foundation is installed (to support the Unified Communications API) – to install, from a Powershell session run the following as admin: Install-WindowsFeature Server-Media-Foundation (note: a server reboot is required).

4.) Microsoft Unified Communications Managed API 4.0 is installed

5.) Windows 2012’s firewall has been configured to allow all inbound traffic from domain members as described in this blog post (this is done to prevent a known issue in which, after installing Exchange 2013, Remote Desktop connections are denied because of a modification to the firewall rules ).


Once all of the prerequisites have been satisfied, you can run Setup.exe.


The first screen provides an overview of your installation options:



By clicking Next, you’ll be taken to the License Agreement page:



You can choose to either use – or forego – Microsoft’s recommended settings




Next, you’ll choose what server roles to install. In our scenario, all components are selected. Note that in Exchange 2013, server roles have been simplified quite a bit as explained in detail in this Technet article.




As with previous versions of Exchange, you choose the target folder for the application binaries.



One of the new elements of the setup process is choosing whether or not to deploy Exchange 2013’s anti-malware features. In our scenario, we’re choosing to disable this feature (because another product is in-place).



Next, the setup process will verify that the installation prerequisites have been satisfied.



In my installation, I neglected to install the Unified Communications API and received this error message:



Once that was taken care of, clicking “Retry” moved the process along.




Now the setup process begins to make actual progress.



There are 15 steps (details dependent upon the roles selected earlier in the install process).

Note that, as explained in this Technet article, the two building blocks of Exchange 2013 – Mailbox and Client Access – have assumed responsibility for all of the platform’s operational components.  The installation process reveals parts of this design.

1.) Organization Prep

2. – 3.) Copying files

4.) Installing language files

5.) Restoring services (stopped during step one)

6.) Language file installation

7.) Installing Management Tools

8.) Mailbox Role: Transport Service

9.) Mailbox Role: CAS Service

10.) Mailbox Role: Unified Messaging

11.) Mailbox Role: Mailbox Service

12.) CAS Role: Front End Transport Service

13.) CAS Role: Client Access Front End Service

14.) Finalizing Setup

15.) Completion




Once setup is complete and your server has reset, you can begin managing Exchange 2013.


Exchange 2013 introduces admins to the Exchange Admin Center which replaces Exchange 2010’s Exchange Management Console.




The default URL is https://your-exchange2013-server-name/ecp

The first time you logon, you may be redirected to OWA.  To work around this, try the following URL from the console of the Exchange 2013 server:


In a future post, we’ll review navigating the EAC and performing basic administrative tasks, such as migrating users between databases.