Home » Exchange Server » Controlling Microsoft Send App Access with Exchange Web Services

Controlling Microsoft Send App Access with Exchange Web Services

Microsoft has released a new application for Office 365 customers that is designed to be used for short, instant-message style communications via email. The app is named Send and is available in the US and Canadian iTunes App Store, with plans to release it globally in the near future.

Update: In September 2015 the Send app was made available in the UK, Brazil and Denmark, as well as on the Android platform.

While tools like text messaging and IM are great for short messages, you often don’t have your co-worker’s cell phone number or an IM app on your work phone. And we’ve heard loud and clear from people at work, they want all their communications available in Outlook—even if they send them from other apps. This is where Send comes in! Send gives you the simple, quick text message-like experience while allowing you to reach all co-workers and have all of your communications in Outlook for reference later.

I immediately like this app, even though here in Australia I can’t download and use it yet. Having previously worked in large, distributed operations teams I remember how frustrating it was having to manage mobile phone numbers for lots of people in my phone contacts, while also having conversations that were split between text messaging and email.

cropped-Introducing-Send-1

Sure, services like Skype for Business have IM capabilities as well.  But let’s be honest, not every organization that has Office 365 today also has Skype for Business widely deployed and in use for their users (though they should!). And although there are many other chat/IM applications out there today, Send has the advantage of integrating into your actual mailbox as well. For compliance-focused organizations this is a big plus. And for the end users it is very convenient.

I also like that the Microsoft Garage is releasing apps like this and experimenting with ways to improve communications in our lives.

Anyway, when a new email-related application like this is released the first reaction for some people is “how do I block this thing while I evaluate it against our organization’s policies?

Let’s take a look at how Send connects to Exchange Online. From the Send FAQ posted to Yammer:

Send works with the same infrastructure that Office 365 does – Azure AD for authenticating the user, and Exchange to transport and store messages. In addition, Send has a service on Azure that contains our business logic to make sure only messages originated from Send will show up in Send. The Send Azure service connects to Exchange Online through Exchange Web Services managed APIs.

Connecting through Exchange Web Services means Send is not subject to ActiveSync mobile device policies. What about enforcing security features such as device PINs, you ask? Good question.

Currently there is no functionality built within the app that enables an admin to set PIN lock for the app. If your organization has set Exchange ActiveSync policies, then device-level PIN is likely already enforced by the devices main email client (e.g. iOS Email app, or Outlook app). Also, most MDM solutions will let you set a PIN lock for your user’s work device.

So you’re covered if the user’s mobile device is already complying with an ActiveSync or MDM policy that you’ve applied. But what about devices that don’t have an ActiveSync email profile set up, or aren’t enrolled in your MDM?

Well… those devices can connect with Send regardless of their compliance with your organization’s policies.

But that doesn’t leave you with no options. Being an Exchange Web Services application you can still control whether it is allowed to connect or not. In fact, I recently published an excerpt from our eBook “Office 365 for Exchange Professionals” that explains how to manage Exchange Web Services in Office 365.

To apply EWS controls for the Send app you need the user agent string. This string was unfortunately absent from the FAQ when I read it earlier today, but the folks at Microsoft helpfully let me know that the string “MicrosoftSend/*” can be used.

First, connect to Exchange Online with PowerShell.

To block Send for the entire organization, first enable EWS block list enforcement (if it is not already enabled), then add the user agent string to the block list.

That will take effect for the entire org, including any admins or security people who need to evaluate the application.

If you’d prefer to block it for individual mailboxes you can use the same method shown above, but use Set-CASMailbox instead of Set-OrganizationConfig.

You can also disable EWS entirely for a mailbox (without impacting other applications like Outlook), as demonstrated in this article.

If you do choose to block Send for your Office 365 organization I hope you will also plan to properly assess the application with a view to allowing it in future if it is found to comply your organization’s policies. Standing between users and useful communication tools like Send is not a good way for IT departments to add value to a company.

If you plan to block or allow Send please let us know your reasons in the comments below. And if you’re already using it I’d love to hear more about the user experience while I wait for the app to be released here in Australia.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *