Welcome to the 3rd part of the “Managing Windows 10 through EMM / UEM” series. In my 1st blog I discussed what an EMM / UEM solution is and looks like and in my 2nd blog I talked about how an EMM / UEM fits into the bigger picture and integrates with solutions like Azure AD and Office 365. In this blog I will dive in to the OS provisioning. I will give an overview of what OS provisioning through a UEM looks like and touch on several considerations you have to make when implementing it.
OS provisioning is moving very fast. Microsoft keeps adding new features with each release. New API’s that can be used by EMM to control the provisioning. The OS provisioning with EMM is starting to mature and be a viable option.
With an EMM you are no longer actually deploying an OS like you do with MDT or SCCM. With the current tooling you build the device from the ground up. The device is exactly tailored to your needs. The biggest advantage of the current methods is that it created predictability. You know the OS layer and the generic application layer. On top of this you have complete control over the user experience. You can lock the workplace down, so the user only gets what he really needs through policies and scripts.
The end result is a workplace that is “easy” to maintain because of the predictability and easily repeatable. When there is a new user in the organization you either spin up a VDI or deploy a new device. The downside is flexibility. Every change you would have to consider aspects like cost, development, testing and acceptance… This requires time. Also there is the need for your company’s infrastructure, I discussed this in the first blog of this series.
Provisioning through EMM
With Windows 10 Microsoft has implemented their cloud first, mobile first vision. They have put a lot of thought into enabling organizations to manage their devices through cloud based EMM’s. There is a complication with this however. If a device has to be managed through the cloud, it needs an internet connection in order to get his instructions. To overcome this Microsoft has added the functionality for Windows 10 to contact Microsoft Azure during the out of the box experience when the user chooses to enter his work credentials. I discussed this (partly) in my 2nd blog in the Azure AD chapter. When the device contacts Azure AD, it will install the EMM’s agent and the EMM will take over the provisioning from there.
In short there are 4 ways to provision a Windows 10 OS through an EMM.
- Through Microsoft adding a work account. The user takes his device and starts the enrollment process by taking the required steps. This process is initiated when the user goes to Settings > Accounts > connect to work or school. (Azure AD premium required)
- During the “out of the box experience (OOBE)”. The user has just received his device and turns it on. Windows asks several questions to configure the device, one of which is the users work account. After the user enters his work account the device is enrolled and made compliant to company policies. (Azure AD premium required)
- When downloading the EMM agent manually. The user logs on to the device and downloads an EMM agent app from the Microsoft store or the Internet. Afterwards the device is provisioned.
- When enrolling directly into an EMM during the OOBE. The company has a contract with a hardware manufacturer. The manufacturer changes the OOBE and adds mechanisms to enroll the device directly into an EMM. The EMM vendor has to support this.
What does this difference mean
So what’s the difference with traditional OS deployment? Do you no longer control the OS? It seems as if you only partly control the base layers of the platform. How are you able to handle installed software either installed by the hardware vendor or by users themselves? The hardware vendor may have installed some funny software, the user may have installed a different Java or flash version. Also.. by default, out of the box you get Windows Home editions.
Well these are the places Microsoft has been working hard on to improve, new API’s are continuously being made available. EMM vendors now supply you with various ways to make the devices comply with your companies policies. The way you prepare the devices is up to you. By following this link you get to see the options you have.
- Update level: You have the ability to control the patch level by managing updates
- OS Version: You have the ability to switch OS versions to whatever you need, here you can review which OS versions switches are supported
- Un-enrollment: You can prevent the user from un enrolling the device, making the company the owner
- Apps: You can prevent or enforce the use of app store apps
- Policies: You can configure AV, Firewall, E-mail, Control panel
- User accounts: You can make sure the enrolling user has no administrative privileges on the device.
So yes this means you have the option to fully manage the device like you would through traditional GPO’s.
OS provisioning considerations
There are several deployment scenario’s. The difference is in the vision on the service you are providing. A lot of vendors have an opinion on this, but in the end it comes down to the customers vision. There are decisions to be made early on in the process.
What measures need to be in place in order to allow company data on the device? Where do you set the borders? Do you have requirements for the entire device or do you just wish to control your data?
How will I use the EMM?
EMM does not necessarily need to be used for a BYO scenario. There are plenty of use cases for deploying managed devices through an EMM. You might want to scale down your internal infrastructure. There are also use cases for a specific groups that work a lot from home or in the field. An EMM is designed to give you flexibility in management.
What components are required?
As I stated in the first blog of this series EMM consists of several components MAM (Mobile application management), MDM (Mobile device management) and MIM(mobile application management). The vendors have split off functionalities of their products to fit inside one of these components. Depending on your organizations requirements you could use an individual component or all of them. The way you provision an OS may change based on the components you use. I will give a brief explanation on how each component works.
MDM (Policies) components focus on managing the device. You can deploy policies, install applications. You do not control the flow of the data however.
- Use case: If you opt for managing the entire device and put security measures on Windows 10 (AV, Encryption, Rights management, Firewall etc..), you could opt for an MDM approach.
MAM (Sandbox & App specific VPN) introduces a sandbox on the device. This sandbox makes sure the company data on the device is only opened by authorized applications. This sandbox can be removed when the user leaves the company or when IT believes the device is compromised. For several applications it also allows you to create an app specific VPN only the app can use, allowing the user to work with company data without being inside your network (this only works with the applications a vendor supports).
- Use case: If you want to enable employees to use their own device for work and do not want to scare them with comprehensive policies and requirements, you could consider using the MAM module.
- MIM (Dropbox) brings dropbox like functionality to devices where the user does not get his homedirectory mapped when he logs on. Through a syncing mechanisms it keeps the data up to date. MIM is usually deployed in combination with the other components to control where company data lands.
Here is a visual to get a feeling where each component operates.
Windows as a service considerations
With Windows as a service Microsoft intents to deliver a continuous stream of new feature releases. Every 6 months there will be a major release where Microsoft adds new functionality. These major releases have 18 months of support. The updates may have conflicts with your business applications. I highly recommend putting a lot of time into creating testing procedures for IT and all business critical applications. Microsoft has created useful guides for this.
Using an EMM means you have the ability to support devices everywhere as long as there is an Internet connection. It is good to put some thought in to security.
What requirements do you have to enrolling a device?
If you allow it, users can possibly enroll from any location. Currently the IT admin performs the actions to add a device into the management tooling.
If users are allowed to enroll their devices I highly recommend requiring a 2 factor authentication.
What requirements do you have for a user to log on to a device or access company data?
So now we the user has enrolled his device. What password policy do you require? You might consider the use of Windows Hello.
Considerations for accessing company data
For accessing company data I also recommend using 2 factored authentication. The 1st factor could be the users pin or password and the 2nd could be a certificate on the device itself. Also for allowing company data on the device I recommend enforcing drive encryption and the AV to be up to date.
What permissions does a user have on the device?
If the user is an Administrator on his device, setting restrictions has little use. The user has all the permissions on the device and can change any setting. If the device is owned by the user, you might not have the option to remove administrator permissions from the user. You should then focus your security on the data itself. In my next blog I will discuss this in more details.
OK, so right now I am assuming you are going with a provisioning method that works with Azure AD premium. What does configuring these components look like? Microsoft thoroughly describes the process, but for the sake of seeing it happen I will also quickly run through what needs to be done. In this example I will be using Intune, but you can easily set up other vendors.
Prepare your EMM
Setting up Azure for MDM
Azure is not always required, if you do not wish to use Azure you can consult the EMM vendors for the options they provide. If you use this, Azure AD premium is required.
To set it up, I log into the azure portal and navigate to the Azure Active Directory component. When Azure AD is selected, it show several sub menu’s. 1 of them is “Mobility (MDM and MAM)”. Here I set up a my EMM tooling.
To set them up I klick “Add application” and select the vendor of the EMM tooling. If yours is not in there.. No worries! Just klick on-Premmises and follow your vendors instructions.
After I have set up my MDM, I can select and configure it. There is not much to configure actually, all of them are forwarding URL’s. Microsoft provides API’s for showing the terms of services during enrollment, the enrollment itself and compliance.
The compliance url is usable by users that are denied access to a resource for compliance reasons. They have the ability to review the issues and remediate them. Also you need to set up the users that are allowed access to the resource.
If you use Intune, these addresses get populated automaticly.
Allocate Azure licenses
Aside from allowing access to a specific set or all users to the MDM resource in Azure AD, you also need to allocate the required licenses to the users. This can also be done through the Azure AD component. Select licenses and assign the Azure Active Directory Premium P2 and in case you are using Intune you also assign the Intune license.
Set up terms and conditions
This is where it gets vendor specific. In this case I will be using Microsoft Intune, but this does not have to be the best solution. The terms and conditions will be shown when the user is enrolling. The user has to review them in order to enroll.
In azure I search for the Intune application, when intune is loaded it gives me several options. The 1st thing I want to set up is the device enrollment. I will be going for Device enrollment and then I opt for Terms and Conditions. From here on out it’s a matter of filling out all the required fields and klicking OK and Create.
Afterwards you assigning them to the correct user groups.
Set up enrollment
Like the terms and conditions, the enrollment settings are in the Device enrollment menu. Afterwards I opt for Windows enrollment. Here you can set up your password policies OOBE settings.
In the deployment profile I set up user account type to standard.
Set up policies
Windows 10 offers a large variety of policies. You can set up a set of policies as a profile and layer them on top of each other. I created a base set of policies.
Don’t forget to assign them!
The options above are the basics. With these settings you can allow Windows 10 devices to enroll and apply a set of policies. Additionaly you can apply powershell scripts, baselines and settings for Windows updates. Also you can set up the installation of applications and a sandboxing mechanism, I will talk about this in my next blog.
Laat uw gegevens achter en wij zullen zo snel mogelijk contact met u opnemen om uw vragen te beantwoorden.