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.


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).


Cogmotive: An O365 Business Intelligence Tool

Bogart, Humphrey (Maltese Falcon, The)_02

Cogmotive is a London, UK-based firm focused on providing what is, as far as I know, the only business intelligence tool for managing both the technical and financial (i.e., licensing) aspects of Office 365.

Cogmotive has two advantages over the built-in tools Microsoft offers for Office 365 management:

1.) Cogmotive is built around license management – an area in which Microsoft under-serves its O365 customers.  So, each function, regardless of ostensible technical objective, provides detailed information about the license impact and by extension, cost.

2.) Cogmotive is not a technical resource alone but also (and this is unique for O365) a business intelligence  platform designed to help O365 customers understand how their investment is actually used by employing both exec-friendly visual displays and engineer-friendly, comprehensive reports (downloadable as CSV files).

This is a very basic guide to the Cogmotive product offering.

Let’s start with the main dashboard:


The dashboard provides easy to understand pie-charts showing active vs. inactive mailboxes and devices – a handy display of the tenant’s current state from a licensing point of view.

On the left-hand side of the screen, you see the reporting sections which are as follows:

Find Recipient
General User Reports
• Tenant Reports
Mail Traffic Reports
• Exchange Reports
Lync Reports
Distribution Group Reports
Mobile Device Reports
• Security Reports
License Reports
• SharePoint Reports
• Custom Report
• Saved Reports
• Request Help
• User Management
• Profile and Settings

Skipping around a bit, we can see that the General User Reports, Lync Reports , Exchange Reports and License Reports sections provide high-level information about how user accounts are utilized within the O365 tenant, such as users logged in per day:

general user reports - users logged in per day

Mobile Devices by OS:

mobile devices by OS

Lync session information:

Lync Reports - Lync Sessions Per Day

Subscription usage overview:

subscription overview
Cogmotive offers a powerful and feature-rich toolset – built on PowerShell – for obtaining command and control of the Office 365 environment (key to controlling costs).

Oh and here’s another quite good review of Cogmotive by  And the Cogmotive Reports Blog can be quite informative too.

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.


Office 365 (Cloud-based Exchange): An opportunity, not a threat

Modern Times

As everyone and her grandma knows by now, Microsoft has devoted a lot of time and effort to developing and promoting its software plus service called Office 365.

One of 365’s key services is Exchange Server (which, as of this writing, is at the 2013 level).

When Exchange Online was first introduced several years ago, many Exchange professionals interpreted it as, at best, a kludge and at worst, a threat to their careers. And indeed, it was not uncommon for IT managers and other decision-makers to incorrectly assume that cloud hosted Exchange reduced or eliminated the need for messaging talent.

As the platform has matured however, this perception has faded.  Anyone who has worked with Exchange within Office 365 knows that almost the full range of an engineer’s skills acquired architecting, deploying and managing Exchange (particularly Exchange 2013) can be put to use with Exchange 365.

For example, if you’re familiar with the Exchange Admin Center as implemented on-premise, you have the skills you’ll need to manage the EAC for an Exchange 365 tenant.

Even greater things are possible with a remote PowerShell session to Exchange 365.

Partially (via a hybrid deployment) or entirely moving Exchange to Microsoft’s Office 365 does not diminish an admin’s role, it alters it in new and interesting ways and should be viewed as an opportunity, not a threat.