Office 365, EMS, and cmdlets

Tony Redmond

by Tony Redmond on 7/14/2016

Share this:

Article Details

Date Revised:

Applies to:
add-in, Azure Active Directory, Delve Analytics, EMS, Enterprise Mobility and Security, Information Rights Management, Outlook, PowerShell, Secure Islands

A new name for EMS

In early July, Microsoft unveiled a new name for the Enterprise Mobility Suite (EMS) to reemphasize the true value and focus of the suite. Enterprise Mobility and Security is the new moniker and it follows the Office 365 SKU model by being divided into two plans (Figure 1) to give customers the chance to buy what they need. Alternatively, the new arrangement provides Microsoft with even more opportunity to drive additional cloud revenue by selling these plans into the growing Office 365 installed base.

Interestingly, during his keynote at the Windows Partner Conference, Scott Guthrie said that 40% of the Office 365 installed base already use EMS. If only because a lot of Office 365 tenants are in the small-to-medium business category, that figure seems high to me. Perhaps he meant that 40% of all enterprise Office 365 tenants use EMS. In any case, Microsoft is pleased with the process of EMS and is expanding its reach to emphasis the security capabilities available in the suite.

Microsoft renames Enterprise Mobility Suite (EMS) to Enterprise Mobility and Security
Figure 1: The new Enterprise Mobility and Security plans [source: Microsoft]

The existing all-in EMS plan becomes EMS E3 while the new E5 plan will be available in Q4 CY2016 and includes new Identity Management and Privileged Identity Management capabilities. We’ll have to see just how useful the new features are when the E5 plan is available to customers.

From an Office 365 perspective, the most interesting aspect of the announcement was the integration of the capabilities acquired with Secure Islands (November 2015). Office 365 customers are likely to store confidential information in SharePoint Online and OneDrive for Business sites, and it makes perfect sense to protect that information from the start using classifications (for instance “Secret” or “Company Confidential”) that, in turn, ensure that a predetermined information rights management template is applied automatically to documents. Even better, elements of Data Loss Prevention technology are used to ensure that documents that contain sensitive content are automatically protected.

Protection applied through rights management templates is persistent and remain intact even if documents travel outside the tenant. Protected documents are tracked and, if necessary, access to their content can be revoked. Azure Information Protection is now in preview (see this video for more details) and will, I think, be popular with Office 365 tenants, providing Microsoft prices it reasonably (separately or as part of EMS E5).

Renamed cmdlets

Office 365 administrators are probably well aware of the Azure Active Directory for PowerShell because it’s the way to manage Office 365 user accounts and other tenant settings through the command line or scripts. PowerShell isn’t the tool of choice for many administrators and its syntax can be quirky at times, but there’s no denying that Office 365 couldn’t run without PowerShell and tenant operations are easier all round if administrators achieve at least a passing fluency with the cmdlets in the modules for Azure Active Directory, Exchange Online, SharePoint Online, and the Security and Compliance Center.

In any case, the developers who maintain the Azure Active Directory module would like to change the existing cmdlet prefix from “Msol” (standing for Microsoft Online Services) to “AzureAD”. Their wiki explains that they are on the “first step on a journey to renew the existing MSOL PowerShell cmdlets” apparently to achieve “a close alignment of the PowerShell functionality with the Graph API capabilities”.

Sounds good. Until you realize that a by-product of the work will be that common cmdlets that are now used in scripts created to help manage operations inside many tenants will change their name. For instance, the Get-MsolUser cmdlet becomes Get-AzureADUser. The latest version of the Azure Active Directory module is in public preview. Documentation is also available online.

A number of “interesting” differences exist in how replacement cmdlets behave over the current versions. For instance, Get-MsolUser (without any parameters) returns a nice neat list of Azure AD user accounts; Get-ADAzureUser does not. In some cases, the change in cmdlet name is more than in the prefix, as in the case where Get-MsolAccountSku becomes Get-AzureADSubscribedSku. Some cmdlets have been dropped altogether, such as Set-MsolUserPrincipalName, whose role is now performed by specifying the UserPrincipalName parameter for the Set-AzureADUser cmdlet. In other words, replacing the old cmdlet names with the new names in scripts is not just a search and replace exercise. You’ll need to test every call and every response to ensure that everything works as expected.

What we see today is still very much a preview and much can change before a final version is released. I can’t imagine that the engineers who run Office 365 will be pleased at the prospect of having to update and retest all their scripts and perhaps some pressure will be applied on the Azure Active Directory developers to do the right thing and minimize the trauma of the changeover for all concerned.

A refreshed Delve Analytics add-in

On July 9, Microsoft began the process to refresh the Outlook add-in for Delve Analytics to implement a more streamlined and attractive look than the previous iteration. The new version of the software is deployed automatically to tenants who have signed up for Delve Analytics and enabled the add-in for users.

The add-in is designed to provide users with data about how people to whom they send messages deal with that email. For instance, how quickly do people read email? How many ignore messages? Figure 2 shows the general idea. In this case, I can see that a note that I sent out to a group of users is being processed by them reasonably quickly.

Updated Delve Analytics add-in for Outlook
Figure 2: The new version of the Delve Analytics add-in for Outlook

The idea is that you can tune how you send messages to make them more effective using the data revealed by Delve Analytics. Much of what you learn is common sense, such as sending messages to a large distribution list at midnight is probably less effective in terms of communications than sending the same message at 9AM. Delve Analytics is great at analyzing what happens with internal messages but it can’t do anything to understand how messages sent to external recipients are processed. No one has yet managed to master the art of communicating message traffic information across different email servers and it’s doubtful if companies like Google or Yahoo would want to let Microsoft analyze email sent to their domains.

Delve Analytics statistics about communications
Figure 3: Delve Analytics statistics about communications with another user

The add-in also reveals statistics for the volume of email exchanged with other users (Figure 3) and tells you how quickly that person responds to you as compared to how quickly you respond to them. There’s nothing earthshattering here, but I think it is interesting to know who files my email into the “it can wait” category. Those in that category are entered onto my personal brown smell stuff list…

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.

Topic: Security

Sign in with

Or register