Your Top 5 Mobility Challenges Solved with Microsoft EMS

Microsoft Enterprise Mobility Suite (EMS) has the capabilities you need to solve your top five mobility challenges in a single vendor, single contract package. In this post I’ll take the top 5 mobility challenge, sourced from you and give you the technical solution to those problems.

For the past couple of months I’ve asked people I meet at conferences, at briefings in Redmond, over twitter and on my blog what their top 5 enterprise mobility challenges are. The responses back have obviously varied but here is the top 5 that I’ve reached:

Almost every response has listed these in roughly this order, sometimes email is number one. Put another way your top enterprise mobility concerns are access to networks, access to email, access to apps, and protection of files. Luckily there is nothing in here that we don’t have a fantastic solution to with enterprise mobility suite! How did I go from four to five? Simple: access to WiFi and VPN are essentially the same thing the only variable is where the user connects from.

Your top enterprise mobility concerns are access to networks, access to email, access to apps, and protection of files

Down to solving these problems, the first three I’ll take you through step by step and, since they are such large topics, I’ll outline App deployment and File protection while providing you some further reading.

Mobility Challenge One: WiFi Access

The most basic thing that most people need from their mobile devices is an ability to connect to the corporate network. In many cases this still requires the user having access to the real corporate network or a (hopefully) isolated network segment – a DMZ – for mobile devices. Access to corporate network resources isn’t always the issue, sometimes it’s just access to the internet to avoid cellular data charges.

Providing access to WiFi networks should be easy, we all have them in our homes now so WiFi is simple…

Not so much. In a corporate environment there is a high chance that you’ve got security governance on the WiFi network. You might only be allowed to use the network if you have a certificate. This was the case in a former employer of mine, for example. Another common approach is to simply hide the SSID of the network making it effectively invisible to users or to place a very complex and long password on the WiFi AP.

When we look at the tools in our EMS toolbox the one to break out for this is Intune, in either stand alone or hybrid configuration. In this case I’m going with the hybrid configuration.

WiFi profiles are a Corporate Resource Access item within the Compliance Settings node of the Assets and Compliance workspace. Create a new WiFi profile from the ribbon to start the process. Then Step by Step you need to:

Specify the network name and the SSID of the network. TIP: Make these the same, some device platforms struggle if they aren’t. Then specify if it’s ok to look for other WiFi networks while connected and if connecting to the WiFi network when the SSID isn’t being broadcast is ok.

Next we specify the security settings for the profile: what type of security is used, what type of encryption and keys are used to ensure encryption. It’s possible to use certificates for the connection and to have Intune configure these for you. For a lot more information check out this area on TechNet and for information on deploying Certificate Profiles through SCCM and Intune look to this article.

On the Advanced page we specify additional settings such as SSO, FIPS compliancy for the network and user or computer authentication.

Next we have the options to configure a Proxy for the network. These settings tend to be especially popular as not all mobile devices (iOS I’m looking at you) are great at detecting a proxy connection.

Finally we select which devices we want to target with this profile, you’ll probably notice iOS and Android are missing. Don’t worry Intune supports them but aren’t surfaced in the wizard yet. Complete the profile setup then go to the properties of your new profile, select the Supported Platforms tab and check the platforms you want to use the profile.

Finally deploy the WiFi profile to your users.

Challenge accepted!

Mobility Challenge Two: Email Access

This is pretty much a joint winner with WiFi profiles for the most request – I think it’s ‘cos email is the onramp to enterprise mobility. The second item on our hit list is Email access, again EMS has you covered in the shape of Intune and SCCM. Just like WiFi profiles, Email profiles appear in the Asset and Compliance workspace under Company Resource Access. In this example I’m going to configure a profile that will automatically add my users Office 365 Exchange account, I’ve already enabled the Email Profiles Extension in the Administration workspace.

Hit Create Exchange Active Sync Profile from the ribbon and give your profile a name and a description.

Next we need to fill out the details of the accounts we’ll be connecting – I hope it’s obvious but we don’t do this for each individual!

First enter the name of the host, for Office 365 this is outlook.office365.com, nice and simple, then give a friendly name for the email for the user, such as Contoso Email .

Now we need to work out where the user’s email address comes from the default is the UPN of the user but the alternative is just the user’s alias.

We need to offer the email address field for the user which will either be the SMTP address attribute in AD or the users UPN.

Then we need to say how we’re going to have the user authenticate, most will just choose the default, Username and Password but for more secure scenarios you might choose certificate. Again you’ll need to deploy the certificate profile first.

Next you get to control how often the device will sync with Exchange and what type of information (Calendar, Email, Tasks, and Contacts) will get Synced.

The last step is specifying the supported platforms for the email profile, note that Android is not currently supported for email provisioning from Intune.

Finally you deploy the policy to your users.

Challenge Accepted!

Mobility Challenge Three: VPN Provisioning

Just like WiFi profiles these are available in Company Resource Access. Before we get into VPNs I just want to make a couple of observations. First you should really be looking at your architecture for mobility overall here – do you REALLY need VPNs? Are there other solutions, such as Web App Proxy or Azure AD App Proxy that can “reverse” proxy resources for external access? They might be a better fit in terms of usability. A device without the cloud is just hot brick in your pocket. They expect the cloud. They expect SaaS based apps. Apps based on this architecture tend to work better in a mobile environment.

A device without the cloud is just hot brick in your pocket. They expect the cloud. They expect SaaS based apps.

Let’s get along now with configuring this.

As always name your profile.

Next we configure its details

Select one of the many supported types of connections.

Next you’ll need to configure the connection and the required details will vary depending upon the type. Typically you’ll be providing the name of the VPN server farm at least.

Then configure split tunnelling and the location of the information to go over the VPN tunnel.

Next configure the authentication method, anything from simple username and password to auth with an RSASecureID if you like extra stuff on your key ring.

Then specify if the VPN launches for specific DNS addresses automatically.

Then finish the wizard and deploy the profile to your users.

Mobility Challenge Four: App Deployment

With regards to deploying apps to mobile platforms the main thing to consider is where the app comes from. The choices for mobile are really

Deeplinked from the app store for that platform

Sideloaded from a file

In the case of Deeplinked apps consider that all you are really doing here is curating apps for the user – you a recommending the best ones for their work to them. The app installs from the store and today the user must accept the license terms and make any payments. As the industry evolves volume arrangements are coming to some stores though. It’s still highly beneficial to do this for your users though since, taking Office apps as an example, if you search any app store for “office” you’ll find lots of apps that aren’t actually Microsoft Office. You also can’t require an app to install on a user’s device from an app store – its’ their choice.

IT’s job is to enable so make MDM enrolment compelling.

You install sidelaoded apps by uploading the package file for the app to Intune and having it distribute the app. Generally the app will must be signed by a trusted source (either your company or the software vendor) and you’ll have to refresh the installation periodically so that the certificates don’t expire (public stores just do this for you).

I’m not going to do a step by step guide here since it would be really long! Intune and Configuration Manager support deployment of apps to Windows, Windows RT, Windows Phone, OSX, iOS and Android in addition to Windows desktops and also to Symbian devices and Windows Mobile devices both of which are commonly used in task worker scenarios. I’ve created lots of app deployment content in the past such as this series on deployment: The Deployment Sessions

Challenge Accepted!

Mobility Challenge Five: File Storage and Protection

Our last challenge is around providing access to or securing files on mobile devices. Most EMM vendors take the approach of creating a secure file container or locker on the device and only allowing the user to store their work files in there. That’s a nice approach but it tends to lead to a degraded user experience: you have a corporate photo, want to apply an Instagram filter but can’t open the file in Instagram because Instagram isn’t on the allow list. Brad Anderson, CVP Enterprise Mobiltiy and Client Management at Microsoft explained our approach in Windows 10 to me in Episode 2 of The Endpoint Zone.

We take a slightly different approach and use Rights Management to secure the files wherever they go. That way the user can put them on a mobile device or store them in any cloud service and organizational protections remain. If the user try’s to open the file in an enlightened app then the app will make a call to the RMS service and allow user the rights they’ve been granted while auditing the access.

The point of encryption and protection with RMS can be: an app, file server, Exchange server or Sharepoint server, on-prem or Office 365 if you’re running in the cloud (SharePoint and OneDrive RMS are coming). For information on configuring the File Server Connector for Azure RMS take a look at this post.

Challenge Accepted!

Five for five. All the top things people tell me they want to do with regard to mobility they can with EMS. One thing that they never actually ask me … but it’s usually a light bulb moment is when I ask them “Why would I want to enrol my device at your company?” After a moment or two they say “to get access to WiFi, Email, Apps and Data”. In the future we will make it so that you to enforce enrolment into MDM management before you can add the Exchange server details but remember this. IT’s job is to enable so make enrolment compelling.

Related

Simon May is an Infrastructure Technology Evangelist at Microsoft concentrating on Devices and Services but with special interests in deployment and device management. Simon is a professional public speaker and the author of several books on Windows. Opinions on this blog are his own.

Yes, I am having the same problem. I am using Intune standalone and have created a wifi profile for iOS as well as Android. But my motive of creating these profile was that ” the users should directly connect to the wifi when its in their range without providing any username and passowrd”. But I am not able to see this as the users have to explicitly give the password to connect to the wifi network.
Any help in this regard would be greatly appreciated.

Ok, so it is possible to do this with Intune stand alone and iOS. Not so much for Android.

You’ll need a Mac, on the Mac you run Apple’s configurator software and create and export an XML that includes the WiFi password. You can then add that as a Custom iOS payload within Intune and deploy it.

You’re probably asking why it’s so hard at this point. It is to protect your WiFi password. You probably wouldn’t like your password saved in plain text, so it would need to be encrypted, doing that is pretty hard (who would have they key, how would it be decrypted on the device etc.) so we take you this route to be really sure about what you’re doing and the potential consequences. Android doesn’t allow us to give it a custom payload today.