Category: Intune

  • RBAC in Intune- Who does what at the zoo

    One thing that is important when working with IT infrastructure is to set the right level of permissions for the right people. Principle of least privilege is a good rule of thumb to follow, also in Microsoft Endpoint Manager.

    It’s quite easy to just say that “okay, all admins gets the administrator role” which make everyone equal. But is it a good idea? No.

    Microsoft Endpoint Manager (MEM) has a quite extensive Role Based Access Control (RBAC) function built in, and there are also Azure roles which applies to MEM. There is also the possibility to create your own custom roles if you want to define the roles yourself, or if you want to limit one of the built in.

    Why use RBAC?

    There is a simple answer to this. Improve security. Granting admin permissions to everyone administrating the system isn’t necessary. Your level of permissions should be related to what task you are performing. A Help Desk operator does not have the same needs as a third level support engineer; hence they should not have the same level of access.

    Aiming for the principle of least privilege when looking at how to administrate MEM is important and implementing it at an early stage so that you assign roles accordingly.

    For certain scenarios, there might be a need for users to have additional levels of access, being able to elevate Intune admin for example through Privileged Identity Management (PIM) but having a less privileged access as their normal level. Please note however, that PIM is an Azure AD P2 feature which you will need to make sure you are licensed for (it’s included in EMS and M365 E5 license SKU, but not in the E3 SKU).

    Quick and dirty setup

    So how to get going? One efficient way of doing it, which I like, is to firstly identify what roles you have in your organization and then map out what roles they should have. I prefer doing this in Excel, just listing the roles and then look at what Azure AD roles are related to MEM and then add the built in MEM roles. Then just simply add an X on who should have what roles. As you see in the example down below, some operational roles have several X in their row.

    This should be adopted towards your organization and roles named what you are calling them.

    Update: You can find my example Excel here.

    Can I use PIM?

    Using PIM, especially for admin roles should be a default when you are setting this up. You will need additional licenses, but you will not need this for all users only your admin users.

    For Azure AD you can use PIM without any hassle, it’s easy to setup and you can set it to automatic approvals. Have look at this Microsoft Docs article on how to do it!

    I would suggest having PIM for all roles which are called admin, so for MEM specific roles that is the Intune Administrator role and the Azure AD Joined Device Local Administrator role, but there are additional roles related to this area.

    When it comes to using PIM on MEM specific roles, this isn’t as straight forward. You will need to take a different approach. PIM for Intune roles could be argued how beneficial this is, but it does improve security and resilience. However, you need to use a preview feature for this called Privileged Access Groups which is a part of PIM, and you will need to make sure to enable your Azure AD group for role assignment when creating it (this can’t be added creating the group). The people over at MSEndpointManager.com have create a great guide about how to set this up.

    But in short what you need to do is to create a group which is enabled for Azure AD roles assignment.

    Then enable Privileged Access on the group you created to add it to PIM.

    Then you can assign your role in MEM to this group.

    In this example I’m assigning PIM to my Help Desk Operator role.

    Doing this, you could potentially enable PIM for all your MEM roles. I would however not use PIM for roles which are read only roles.

    Key takeaway

    There are a bunch of built-in roles in MEM which covers most scenarios. However, there might be instances where you need to tweak this a little bit. A good example of this is the Remote Help role which I wrote about in my previous post. Remote Help might be useful for people who are not working in Intune as part of their daily job, this could be application specific support personal for example who don’t need access in MEM but have the need to remotely support their users.

    Getting RBAC in place at an early stage will simplify operations and getting the right permissions for everyone involved down the line, and you will decrease misshappenings. Or just simply shadow IT doing their own thing in your controlled environment without change control or the approvals from the governance forums.

  • Microsoft Remote Help tool

    It finally happened. Microsoft released their own remote assistance tool called Remote Help at Ignite during the fall 2021. It was to be honest one of the things I got most excited about.

    Licenses are still a bit unclear around this, Microsoft says it’s free to use during the preview but will come at an additional fee once GA hits. What this license model will look like, no one seems to really know at this point. So please be aware of that the licensing will change and that this is still public preview before putting this into production.

    But the fact that it´s in public preview means that you can start assessing it and see if it will fulfil your needs!

    The setup

    To get going, you basically sign in to Microsoft Endpoint Manager, navigate to Tenant Administration > Connectors and Tokens > Remote Help and select Enable under the Settings tab.

    And now it’s enabled!

    You will also need to assign the correct rights to your support personal. If you are using the built in roles in Intune for this, this role is enabled by default for:

    • School administrator
    • Help Desk operator
    • Intune admin

    If you want to add this role to a role, or create a specific custom role for Remote Help, you can do so by creating a new role and adding the Remote Help app” rights to that user.

    You can create custom roles by going to Tenant administration > Roles and then select “+ Create“.

    You will then have to assign your new role to an Azure AD group containing the users you want to add this role to by selecting Assignments on your newly created role and then “+ Assign”.

    Give the assignment a name:

    Add the group of users you want to assign this role to:

    On the next blade you can select the scope for your support personal. You could for example only allow this group to remotely support a specific group of devices. But in this setup, I’m using “All devices” as the scope group.

    If you are not using scope tags, just press next and then create your assignment.

    Remote help app

    The other part of this solution is the Remote Help app which you will need to distribute to your users.

    To get the app, you simply download it from Microsoft at aka.ms/downloadremotehelp and you will get the application file.

    Next step is to get this out to your computers through Intune, which means that you would need to package this as an Win32 app in Intune. Best way to do so is by using the IntuneWinAppUtil tool.

    And create a detection rule based on that a file exist.

    Once you have packaged it, uploaded it and distributed it to your clients, you are ready to go!

    The experience

    To connect, the admin or support personal needs to have the Remote Help app installed on their device (which should be deployed from Intune).

    To launch a remote session with a user, there are two ways you can go at it. You as an admin can navigate to the device in the Microsoft Endpoint Management portal and go to Devices > Windows > Windows devices and find the device you want to support. On the device ribbon (where you see “Retire, Wipe, Delete”) find the three dots and select “New remote assistance session” and then click “Launch remote help”. This will open the Remote Help app.
    Update: This being preview and all, it seems like the experience has changed a bit since when I originally started setting this up in my lab. The proper way to initiate a remote session is to go through the app, not Microsoft Intune. Check out the updated Docs for more information.

    To initiate a remote session, launch the Remote Help app from your computer.

    The first time you launch Remote Help, you will be asked to sign in and accept the user agreement.

    Once signed in, you get a similar experience as the Quick Assist app where you can either choose to get or give help.

    To give help, you simply select “Get a security code” which will generate a code that you can provide to the user you are helping.

    When you have generated the code, share it the user you are helping. When the user enters the code in the “Get help” section, the admin will get a prompt showing which user they are trying to connect to, and they can select if they want to take full control or just view the screen.

    Based on the support persons selection, the user will get a prompt showing who is going to help them and to allow or cancel their request to connect.

    As you can see below, Remote Help will prompt if the device you are connecting to is not compliant and you can choose to either accept or leave the session since this could mean an increased risk. This status is also shown in the Microsoft Endpoint Manager portal on the device.

    And now we can see the user’s desktop and perform our remote support tasks!

    One little nice feature I found was that there is some options to do annotations on the users screen if you want to guide them to do something, and there is also a message feature you can send a receive messages in.

    Why use Remote Help

    What sets Remote Help apart from e.g. Quick Assist in Windows is that it’s built for enterprises, not consumer. This means that you have more control and possibilities, such as using corporate credentials and being able to accept UAC prompts with your admin credentials.

    One other major thing here is that logging. You can see who helped whom and when.

    You can also easily monitor how much the remote help is being utilized.

    You can find all these things from Tenant Administration > Connectors and tokens > Remote Help (Preview).

    Additional thoughts

    I’m a huge fan of this new product and I’m really excited to see what this will become once general available.

    One thing that could be a good idea is to remove the Quick Assist app if you have that installed on your device, to reduce confusion but also to improve security a little bit since with the Quick Assist anyone can remote your users’ computers if they are not cautious. This can easily be done by deploying a PowerShell script to the devices.

    Remove-WindowsCapability -online -name App.Support.QuickAssist~~~~0.0.1.0

    Quick Assist isn’t built for enterprise use but is a great tool to support family and loved ones to be honest (I use it often to support family members).

  • Exclude devices from profile

    One of the most common ways to assign Windows Autopilot profiles is to use the wildcard argument for Autopilot devices in an dynamic Azure AD group:

    device.devicePhysicalIds -any (_ -contains "[ZTDId]")

    This is a powerful way of gathering all devices imported to Autopilot into a single group to assign either enrollment profiles, configuration profiles or even applications without the need for any additional work or use of group tags.

    However, this group being powerful makes things a bit harder when it comes to excluding devices that might need a different enrollment profile for testing, different device type or just a different use case.

    There are different ways of doing this, but this is the way I found that works well and it assumes that you have another Azure AD group which you use to assign Enrollment Profiles, dynamic or assigned.

    Let’s say we have two enrollment profiles:

    • Production profile
    • HoloLens profile

    The “Production profile” is assigned using a group called “All Autopilot devices” which gets devices using the “device.devicePhysicalIds -any (_ -contains “[ZTDId]”)” string to gather all devices which are imported to the environment.

    We have also imported the HoloLens devices in to our device list for Autopilot, which we are using a group tag to populate our “HoloLens devices” group with which is then used to assign the HoloLens profile.

    Now comes the tricky part. Since we have the “catch all” group already, that will include the HoloLens’s which means that we will assign configuration profiles and applications that are assigned using that group.

    Since our HoloLens’s are a different type of devices, we want to assign a separate set of configuration profiles and applications towards them, meaning that we need to exclude them from the “All Autopilot devices” group and add them a HoloLens specific group to assign our HoloLens profile.

    Creating out groups

    To add them to the HoloLens deployment profile you can create a dynamic group which is using Group Tags to populate. This will require you to add this group tag to all your HoloLens’s. In this case, we will use the Group Tag “Hololens”.

    (device.devicePhysicalIds -any _ -eq "[OrderID]:Hololens")

    This will assign the HoloLens specific deployment profile to the device.

    However, we also want to make sure that we do not include these devices in the bigger group which is used to assign the “regular” Windows policies. This was a bit trickier than I thought to be honest.

    After playing around with excluding the group tag, which for some reason didn’t work that great, the most effective way was to exclude devices from my big “All Autopilot devices” group by using the fact that it has a deployment profile assigned to it. This value can be used in the rules for the group by saying that we don’t want to include devices having a deployment profiled called “Autopilot HoloLens” assigned to them.

    device.enrollmentProfileName -ne "Autopilot HoloLens"

    The outcome

    By changing the rule to say that in addition to “catch all” also no include anything that has the deployment profile “Autopilot HoloLens” assigned to it, we will now have a group which will exclude all HoloLens devices!

    This can of course be used for other things than HoloLens, it applies for anything that has a deployment profile assigned to it.

    There are other ways to accomplish this, but this is the easiest way I’ve found so far!

  • Get more information on device compliance

    Device compliance is an area which is getting increasingly important and having your devices reporting a “Compliant” status is crucial for Conditional Access to work in a user-friendly way.

    But sometimes you end up with a bunch of devices reporting error on a specific compliance setting. The Intune reporting on Compliance leaves you hanging with either a report on just all your “non-compliant” devices or the count on how many devices have a specific error. Figuring out which devices has a specific error is not an easy task.

    After digging around a bit I stumbled upon this post INTUNE: REPORT ALL DEVICES THAT ARE NON-COMPLIANT BECAUSE THEY ARE INACTIVE – Microsoft Tech Community which explained how to get this data using Graph API. You get a lot of information from this query.

    Since I wasn’t really interested in inactive devices, I needed to tweak the GET query a bit ending up with the following query, since I was looking for devices with a firewall issue.

    https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicySettingStateSummaries/Windows10CompliancePolicy.ActiveFirewallRequired/deviceComplianceSettingStates?$filter=state eq 'nonCompliant'

    If we break down the string a bit you can actually filter this based on the specific compliance setting you want to find.

    1. “https://graph.microsoft.com/v1.0/deviceManagement/” – This is the Graph connection string
    2. “deviceCompliancePolicySettingStateSummaries/” – this defines that we want to look at compliance policy setting state
    3. “Windows10CompliancePolicy” – this is the name of my compliance policy, so this will depend on your naming
    4. “.ActiveFirewallRequired/” – this defines which setting we are looking at
    5. “deviceComplianceSettingStates?$filter=state eq ‘nonCompliant’” – this filters out which state we are looking for. You can change this to “Compliant” to find compliant devices instead

    So, if you want to look at another setting than the firewall as in this example, you simply replace that part in the string with the name of what setting you are looking for. Easiest way to find all the setting names in your tenant is to simply run:

    https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicySettingStateSummaries

    This will list all settings and setting names in your tenant.

    When you have built your own GET string you will be able to pull the data you need and get information about what devices in a simpler way.

    I’m still trying to figure out how to export this in a good way other than the classic copy paste (I’m really bad with PowerShell). Once I figure that out, I’ll post a part two of this! Or if you have a good solution for this, feel free to reuse this or post a link to your solution in the comments!

  • Once you go Mac…

    Once you go Mac…

    I used to be an avid Mac user and major Apple fanboy back in like 2011-2013. Then I joined Microsoft and got to see the other side, the dark side… Somewhere in the hidden corners of the internet, I even have a blog post called “once you go Mac, you never go back” saying I would never use anything else then a Mac.

    Jokes a side. Coming out of a more communications and media technology world from college, Apple and Macs was the best there was. Then the iPhone came along and changed the whole mobile device world.

    I was a Mac user from around 2008 until 2017 even if in the later years I rarely used my personal Mac. Then the Surface Laptop was released and that’s what my personal laptop still is.
    Now that I’m about 10 years older than in 2011 and I have a completely different approach to things. One is not better than the other, it totally depends on who will use it if it’s better or not.

    This post will not cover HOW to configure, more discuss why and what.

    macOS and management

    So, how would you go at this?

    Just like for mobile devices, there are a lot of different tools for managing macOS. As usual, my approach is Microsoft Intune, but for macOS specifically there might be other tools like Jamf Pro which has a lot more features (but also comes with a completely different price tag).

    You know I’m all for making use of what you have and getting the most bang for your buck, so let’s talk about macOS and Microsoft Intune.

    Setting the expectations right

    One thing to keep in mind when it comes to managing macOS. The possibilities are not even close to what you can do on a Windows 10 machine, and what we can control comes down to what APIs Apple allows mobile device management tools to use. Setting up management for macOS and expecting the functionality of a domain joined computer, this is not what you will get.

    The experience is more closely related to how you approach managing mobile device. You put a management layer on top of the experience. There basically three ways to view management of Mac’s:

    • Automated Device Enrollment
    • Device Enrollment
    • User enrolled

    The two first ones are the most common ones while User enrolled is more for BYOD scenarios and gives less functionality and manageability. Both device-based methods are very similar, but the Automate Device Enrollment makes use of the Apple Automated Device Enrollment service, ADE (previously DEP), which will increase the possibilities for management and prohibit the user from removing the enrollment.

    The experience to enroll macOS is more closely related to how you approach managing mobile device. You put a management layer on top of the experience. macOS utilizes what is called “User Approved enrollment” which means that the user must ALLWAYS approve the installation of management profiles, even is automated device enrollment is used. This will add extra steps to the enrollment process compared to mobile or Windows devices where this is automated in a higher degree.

    If you are looking for a more deeply integrated management method, Jamf Pro is more where you need to head, but then we are talking additional licensing.

    What to manage

    Moving on to what you need to manage on the device. This is of course based on your organizational needs, both regarding configurations and security. There are however a few things that might be a good minimum, such as:

    • Wi-Fi settings
    • Encryption and FileVault (macOS equalent to Bitlocker)
    • PIN/Password
    • Endpoint protection
    • Application distribution
    • Compliance settings
    • SSO extension

    There are a lot of more things we could potentially configure, but keeping it to a bare minimum, this is a great start and does not limit us from expanding this down the road.

    One thing to use as a guiding principle is to think about what you NEED to manage and not configure settings just because you can. Is there a need to block let’s say Spotlight suggestions, or could this be useful for the user and resulting in a poorer end-user experience? This is important to keep in mind for all platforms, not only macOS to be honest. Don’t block just because you can, configure based on needs.

    Why manage?

    So why do you want to manage your Mac’s? That is the million-dollar question and something that you need to figure out before even starting. This doesn’t need to be super fancy or technical, just define the goal you have. This might be:

    • Ensure that all devices are secure
    • Get inventory of what devices are used
    • Provide your users with a better experience

    Or you could have more defined demands coming from your organization regarding legal demands or security demands.

    By managing your Mac’s, you will gain a better understanding of what devices are used within your organization and you can ensure that you provide your users with a good and secure platform. By managing the device, you can also provide settings such as Wi-Fi access automatically to the devices without the need for the end-user to know where to find the information. Same would go for applications. You will bring the platform closer to what you know and love when it comes to device management even though the expectations need to be separate from let’s say the Windows platform.

  • What is the difference between management scenarios for mobile devices?

    A quite common discussion topic when it comes to mobile device management is the different approaches you can take. Therefore, I’ve written down a little something to try to simplify a little bit.

    I’ve intentionally left out any preview features and user enrollment for Apple device to focus on the most common scenarios. I will look to cover that in a separate post.

    There are of course more technical aspects to this, but from a high level this is something that is good to keep in mind!

    Flow description Android

    For Android, there are three different type of management:

    • Work Profile
    • Corporate owned fully managed
    • Corporate owned dedicated device

    These are used for three different scenarios which are based on the requirements in the environment. Moving existing devices into Microsoft Intune management also affect which management method which should be used.

    Personally owned with work profile

    Personally owned with work profile is mostly referred to handle Bring Your Own Device (BYOD) scenarios. This is also often used to transition from either no management or legacy management into a Microsoft Intune enrolled device since it does not require the device to be reset to factory default before getting started.

    To register a device using Work Profile, the user will need to download the Company Portal application from the Google Play store. When the application is downloaded and installed, user signs into the Company Portal app using the corporate credentials and follows the on-screen wizard how to enroll.

    When the device is enrolled, a corporate container is created on the device where all corporate data is stored separately from the personal data. The user will see a new tab on the application pane called Work and all applications will have a small briefcase on them indicating they are work applications.

    The IT department can only manage the Work Profile part but can put some restrictions and requirements on the device regarding e.g., PIN-code and Wi-Fi settings. Limited number of remote actions can also be performed such as PIN recovery or removal of corporate data. Applications in the Work Profile part is managed through a Managed Google Play store which is controlled by the Microsoft Intune administrators. Since the applications in the managed Google Play store are centrally managed and assigned, no corporate Google account is needed for the end-user to download and consume applications in the Work Profile.

    The personal part of the phone still functions as expected by the user since data is separated and not allowed to stream between the containers.

    Personally owned with work profile

    Corporate owned fully managed

    A corporate owned fully managed device is used where the company buys the device and there is a 1:1 relationship between device and user. To enroll the device as fully managed, the device needs to be new out of the box or been reset to factory default.

    Devices could be pre-registered to the customer by the hardware vendor in Google Zero touch to ease the enrollment procedure for the end-user.

    When the user receives the device, and the user follows the on-screen onboarding process for initial setup.

    If the device is not pre-registered using Google Zero Touch, the user will be asked to scan a QR code which is unique to each customer and must be made available by the IT department.

    During the enrollment, the user will be asked to login using their corporate credentials. The user will also be asked to set a PIN-code. As part of the enrollment in Microsoft Intune, configurations, policies, and applications will be applied to the device which has been assigned to the user and/or device.

    When the enrollment has finished, the device is ready to be used by the user.

    The fully managed device does not separate corporate and personal data as the Work Profile method does, which means that corporate data and personal data is mixed on the device. On the other hand, since the device is fully managed, the IT department has much more control over the device and applied configurations and policies.

    Applications are centrally managed by IT, but the public Google Play Store can be made available for the end user. For applications distributed through Microsoft Intune, no Google account is needed for the end user.  

    IT can also perform remote actions on the device, such as PIN recovery or data removal.  

    Corporate owned fully managed

    Corporate owned dedicated devices

    Corporate-owned dedicated devices are used when there is not a 1:1 relationship between user and device, in a scenario where multiple users use one device. A good example of this is a kiosk device.

    Devices could be pre-registered to the customer by the hardware vendor in Google Zero touch to ease the enrollment procedure.

    When the user receives the device, and the user follows the on-screen onboarding process for initial setup.

    If the device is not pre-registered using Google Zero Touch, the user will be asked to scan a QR code which is unique to each customer and must be made available by the IT department. These QR codes are unique to each enrollment profile and are valid for 90 days.

    During the enrollment, no user sign in is required. Device will be automatically enrolled towards Microsoft Intune and no user affinity is applied. PIN-code can be set as part of the enrollment flow.

    During the enrollment to Microsoft Intune, configurations, policies, and applications will be applied to the device which has been assigned to the device.

    When the enrollment has finished, the device is ready to be used by the user.

    Since the device is supposed to be dedicated to a specific task or function, the features in the OS are limited and can be locked by the IT department. Some built in applications can also be removed if needed.

    Applications are centrally managed by IT using Microsoft Intune.   

    IT can also perform remote actions on the device, such as PIN recovery or data removal.

    Corporate owned dedicated devices

    Flow description IOS and iPadOS

    Management of iOS and iPadOS does not have the same number of variations as Android. There is however a difference in how you can handle devices based upon if you use Apple Automated Device Enrollment or not.

    For iOS/iPadOS management, there are two different ways of managing the device, personal or shared. Shared device is only applicable to iPadOS.

    There are however two different ways of enrollning a device depending on if Apple Automated Device Enrollment is used or not.

    Personal iOS/iPadOS devices with Apple Automated Device Enrollment

    The default management of iOS/iPadOS devices are personal devices where there is a 1:1 relationship between user and device.

    If Apple Automated Device Enrollment is used, the devices are pre-registered by the vendor in Apple Business/School Manager. Apple Automated Device Enrollment is used to simplify the enrollment process for the end-user and provide an additional set of control for IT.

    When Apple Automated Device Enrollment is used, IT can control the first run experience for the user to remove unnecessary steps. This control will also ensure that the device will be enrolled. When a user receives the device, they will follow the on-screen wizard to get started and register their device.

    During the initial setup, the user will be asked to sign in using the corporate credentials and the device will enroll in Microsoft Intune and received the applicable configuration, polices and applications which has been assigned to the user and/or device. When the setup is done, the device is ready to use.

    IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device. If the devices are deployed in Supervised mode, there is also a possibility to trace lost devices and put them in a “lost mode” to prevent a lost device being used by an inappropriate person.

    Applications are downloaded through the Apple App Store. For corporate applications and line-of-business applications, the Company Portal is used to initiate the download and the user will not require an Apple ID to download applications. IT can also do required installations of applications.

    Personal iOS/iPadOS devices with Apple Automated Device Enrollment

    Personal iOS/iPadOS devices without Apple Automated Device Enrollment

    The default management of iOS/iPadOS devices are personal devices where there is a 1:1 relationship between user and device.

    If Apple Automated Device Enrollment is not used, user will have to download the Company Portal application from the Apple App Store to enroll the device. Users then sign into the application using their corporate credentials and follow the on-screen instructions on how to enroll the device.

    IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device.

    Applications are downloaded through the Apple App Store. For corporate applications and line-of-business applications, the Company Portal is used to initiate the download and the user will not require an Apple ID to download applications. IT can also do required installations of applications.

    Personal iOS/iPadOS devices without Apple Automated Device Enrollment

    Shared iPadOS device

    Shared iPadOS devices are used when there is not a 1:1 relationship between user and device, in a scenario where multiple users use one device. A good example of this is a kiosk device.

    To use the Shared iPadOS scenario, Apple Automated Device Enrollment needs to be used. Devices are registered in the Apple Business/School Manager to connect the device towards the customer.

    When a device is to be registered, a user or coordinator starts the device and follows the on-screen instructions. No sign-in is required during this process since the device will not have user affinity.

    During the enrollment, the device will receive configurations, policies and applications which has been assigned to the device.

    When the registration is completed, the device is ready to use.

    IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device.

    Applications are centrally managed by IT and are installed automatically by assigning them in Microsoft Intune without user interaction.

    Shared iPadOS device
  • Android for task-workers

    Android for task-workers

    Let’s get technical again, it’s been a while.

    Android has some rather good benefits for task-workers/front-line workers, especially if the device is shared. Not only is the price-point of the device better, the user experience is quite simple.

    There are today two ways of doing this, either dedicated device or the newly released dedicated device with Azure AD Shared Device which is still in preview. In this post I will try to cover both, but the device will not be set into kiosk mode.

    How to configure

    Decision points

    Before you start, there are a few things you need to decide upon:

    • What applications do I need?
    • What is allowed on the device?
    • Is it multi app device or not?
    • How will the device be enrolled?

    Using dedicated devices, you can either just enroll the device as a “normal” device but without the user affinity, or you can deploy a single-app or multi-app kiosk where you define what applications can be used. This post will describe how to do the “normal device” setup without user affinity.

    The Intune parts…

    Enable enrollment

    First step is to enable the possibility enable dedicated device enrollment. I’m assuming that you have already setup the Managed Google Play, otherwise you need to do that first by following the wizard.

    In the Microsoft Endpoint Manager admin centre (https://endpoint.microsoft.com), navigate to Devices > Enroll devices > Android and select the “Corporate-owned dedicated devices”

    Click on “Create profile” to create a new profile.

    Give your profile a name and select what token type you want to use. Today, there are two to choose from. The default profile for dedicated devices and the preview profile for Azure AD Shared Devices (which you can read all about here). In this example we will use the preview feature, but you can today just as well use the default if you are not keen on using preview features.

    Enrollment tokens for dedicated devices can only be valid for 90 days, so make a note of the expiration date and create a reminder to renew it. If you miss to do so, you won’t be able to enroll new devices.

    When you are done, hit next two times and then create. Your enrollment token for dedicated devices is now created!

    To view the token, click on it in the list and go to “Token” in the left menu. When you press “Show more” the token will be displayed.

    This will later be used when a device is enrolled.

    Creating a device group

    Now we need a device group to be able to target our settings and applications.

    In the MEM admin centre, go to Groups and select “New group”. Leave the group type to “Security” and give the group a name. Select “Dynamic Device” as membership type.

    Now it’s time to create our very simple membership rule. Set property to “enrollmentProfileName”, operator to “Equals” and the value to the name of the enrollment token we created in the previous step.

    Or you can just use this string and replace the [ENROLLMENT TOKEN NAME] with the name of your token.

    (device.enrollmentProfileName -eq "[ENROLLMENT TOKEN NAME]")

    You can of course build more complex rules if you like, but for the basic setup this is the only thing we need.

    Setting device restrictions

    For shared devices, there are a few settings that might be good to create. In opposite of how I usually create configuration profiles for personal devices, I tend to have one profile containing most settings for share devices, defining that it’s a shared device and doing some minor restrictions.

    When creating a new profile, go to Devices > Android > Configuration Profiles and click “Create profile”. Select Android Enterprise as Platform and make sure use the profile type under “Fully managed, Dedicated, and Corporate-Owned Work Profile” when creating configuration profiles.

    In this example I will only create a simple restriction profile with a few settings.

    Since its a shared device which we don’t really know how it will be used, how updates are applied might be something you need to take in mind. It’s possible to set it to a maintenance windows to adopt to your business.

    This profile will also set a PIN-code which will not be set during the enrollment due to that the general idea with a dedicate device is that it’s a kiosk and does not require a PIN. That is not however what the reality looks like every time.

    If you are creating SCEP profiles, make sure that you create SCEP certificates which are device based and not user based since your device will not have a logged-on user so to speak.

    Assign the profiles you have created to the device group we created earlier.

    Applications

    When it comes to applications, this is where it will vary a lot depending on your needs.

    The important part here is to remember to assign the applications with a device centric approach and not a user centric. Use the group we created earlier or any other device group you have which contains the devices.

    For shared or dedicated devices, you might also want to remove a few applications, not only distribute.

    The easiest way of doing this for Google Play store applications is to simply add it from you Managed Google Play store and assign your dedicated device group to uninstall the application.

    Some vendors, for example Samsung, pre-load their devices with some system applications which for Samsung also includes a separate app store. However, these are usually removed when putting a device into fully managed or dedicated mode, but if you are using e.g. Samsung Knox you will need to look into turning of these applications.

    Enroll the device

    Now it’s time to enroll the device!

    Start up your device and tap the first screen repeatedly to launch the QR scanner.

    Select a Wi-Fi network to connect to if you don’t have a cellular connection on the device. Hit next and the device will start to prepare to enroll. Follow the on-screen wizard to get started with the enrollment.

    If you are using for example Samung Knox, the experiance will be more streamlined and you won’t be asked some of the choices.

    During the enrollment process you will be asked to approve the installation of required applications as a part of the registration process.

    Approve installation of apps
    Register the device as shared

    Once the device is enrolled, you will be presented with the home screen of the device.

    Enrollment is complete

    Some settings and applications might take a few minutes before they apply, so the device might not be ready to send off to the users just yet. To speed this up, you can access the Intune app on the device and press sync. Make sure that all applications and configuration profiles has been applied to the device before shipping it out!

    One thing that is important to keep in mind for this is the licensing. You will most likely require a device license for Intune for these devices since they do not have a user.

    Build further on this

    Now that you have a dedicated device, you can built on this further using depending on your scenario.

    You could for example set up kiosk device, either single- or multi-app using the Managed Home Screen. Using the Managed Home Screen also opens up the possibility to utilize the shared sign in screen mentioned in this post from the Intune team. But I will cover that in a future post instead!

    You can also create different enrollment token based on different purposes, you just repeat this guide and create the ones you need for your organization, make sure to give the tokens and groups unique names which makes sense to you.

  • Recovery in a world without OSD

    Recovery in a world without OSD

    One of the big issues I hear people talk about when it comes to utilizing an image- and OSD less approach is “What if the hard drive breaks and we need to reinstall the machine?”. This is based on that assumption that we need to create a custom image with the drivers and such for recovery purpose. Disks do break, so this is a real problem.

    However…

    You probably bought that computer from one of the big computer manufacturers out there meaning that they thought of this.

    In this article I will post many bold and naive statements, which you might not agree with. I understand that, but we also need to challenge how we have done things for the last 15 years. I’m not saying this is the whole truth, but I want to challenge the way you operate!

    Disk failure

    What happens when a consumer computer breaks down? Your typical home user does not have a Windows Deployment Services server running in their home network.

    Most of the big manufacturers provides you with a new, fresh image created for your computer from their website, often using their recovery tool. The process to obtain the recovery image is a bit different based on which manufacturer, but it’s an uncomplicated way to recover a broken machine without the need to creating custom images.

    Making use of what has already been created (and probably covered by the support commitment) should make sense. If someone else that we know and trust already created this, why shouldn’t we utilize it?

    At least Microsoft, Lenovo, Dell and HP offers this service in one way or another.

    A second option to this, but less ideal, is to use a generic Windows 10 image downloaded from Microsoft (or your Microsoft Volume Licensing Service Centre). The device will be missing all drivers to start with, but that is usually addressed using either the Windows Update feature or the driver update tool for that particular vendor (which you should consider using anyways to keep your drivers up to date on all your machines).

    Resetting the device

    If you for some reason need to reset a computer, there is no need to use an external media source to re-install Windows 10. This is built into the operating system, just like on your phone.

    In Windows 10, instead of injecting your custom image, you simply reset the computer. Depending on where you are coming at it from, you might have to do it in different approaches.

    Microsoft have documented this process very well here, so I won’t dig into it further on a how-to level.

    Conclusion

    I’m going to make a bold statement that many of you might not agree with. But operating systems deployment and creating custom images are a thing of the past. It will still be around for years to come since change does not happen overnight, and most companies have invested heavily in this. But it will start to fade away as more and more companies dare to trust the OEMs that their images are good enough. This will not solve data-loss at all, but it will bring the device back up and running which is often just as important for the user. Creating a custom image is an artform, but soon that artform needs to evolve into something else. There is a shift happening and we need to find other approaches to the old problems when we use new tools.

    Today, this will not fit all scenarios. But if you look at the big picture, this could probably cover 80-90% of your user-base. Heck, you could have your users replace disks them self and then recover the operating system (imagine that!).

    I’ve tried this with several different types of machines and manufacturers, and it works really well. You can even reset a custom image using the built-in reset feature. The result, however, can be a bit strange if you have removed a lot of the built-in apps etc. But the machine will still work and the user might not notice (especially if you make sure to deploy the needed apps to the end-user using Intune).

    Combine this with the power of Office 365 and the cloud for storing your documents and work and you will have a pretty sweet setup where the device isn’t that important anymore.

    Do explore the different possibilities in using standardized recovery media, but I’m not saying it will solve all your problems but it will take away some headache and hours spent on creating and maintaining custom images.

  • Why managed Android matters

    Why managed Android matters

    Looking at the Swedish market, most of the companies I meet are managing their devices. These devices are usually iOS/iPadOS devices since, let’s face it, iOS has been superior in the Mobile Device Management segment throughout the years since they have had more settings exposed to MDM than Android. This has however changed over the years and the difference is not at all the same as of let’s say 3-5 years ago.

    We can always discuss why platform A is better than platform B, but let’s not get into that. Everyone will have a separate opinion on this.

    Looking at where we are today, many companies I meet manage their iPhones and iPads but haven’t really gotten around to Android yet. It’s still in some sense viewed as a secondary platform and not something that is wanted (it’s one more platform to provide end-user support on for one thing).

    I fully respect this. However….

    Looking back at my previous posts about what tools people to expect to use in the workplace, we are seeing a lot of growing demand for Android devices.

    This could be out of personal preferences, the fact that the device is cheaper or the iPhone not being available in the market where the user lives. But this means that dodging the question of Android becomes harder and harder. And the later you get on top of Android, the harder the transition will be since Android is a lot different to manage compared to iOS/iPadOS.

    For Android, you have to options depending on your wants and needs. You have Work Profile and Device Owner.

    Management methods for Android

    You should AT ALL COST avoid using Device Administrator since this is a legacy protocol which will be decommissioned by Google.

    In this post I will not cover the dedicated devices method since this is meant for special adoptions and not regular end-users.

    Work Profile

    Work Profile is the most basic version of Android management and it has the least impact on already existing phones. Your users must download the Company Portal to enroll into Intune. This will create a separate “work sphere” where all corporate data will live.

    This is the easiest form of Android management and you can deploy applications, configurations, and compliance policies. The work data will be separated from the personal data, but there are some limitations around management. This is the easiest way to start managing your Android devices without too much user impact.

    Device Owner

    Device owner or fully managed is the full feathered version of Android management where Intune takes total control of the device. This is more like how the iOS devices would be in a supervised mode. This management method also enabled Google Zero Touch enrollment (or Samsung Knox) for easier user onboarding. But you can of course have your users scan a QR code on first launch.

    A huge benefit with this from a corporate perspective is that the user won’t need a Google account to enroll and download corporate applications. They can add a personal Google account, but it’s not needed to use it as a corporate device. Google accounts can otherwise be a hassle for less experienced user.

    Company-owned work enabled

    This version of Android management is when this blogpost is being written to officially launched, it’s still in preview.

    This is however a combination of Work Profile and Device owner management where you as an organization gains full control over the device (giving you more management capabilities) but corporate data and personal data is separated.

    This requires a device reset, just as device owner, but the user will get one corporate sphere and one personal sphere. The data is managed in the corporate sphere and left to the end users’ privacy in the personal sphere.

    In my view, this will be the more attractive version of Android management overall since you can have a separation between personal and corporate data.

    This method works extra smooth if you combine it with Google Zero Touch or Samsung Knox. If you don’t see a possibility to have this in place, you can of course have your users scan a QR code on first launch.

    Where should you start?

    Start small and start easy. If you have a lot of Android devices today, Work Profile is the best place to start. Having users reset their devices containing photos, apps etc. is not a popular thing to do. You could argue that it’s a corporate device and your users must comply, but this is not an effective way to build trust and getting the devices into management.

    If you have just a few devices and looking to introduce Android into your environment, Device owner or the new Corporate-owned work enabled method is the way to go. You will have fresh devices going in and the need for a reset doesn’t exist. Combine this with Google Zero Touch or Samsung Knox and you will have a killer user on-boarding experience!

    What are your thoughs on Android and where do you stand today? Comment below!

  • What is the difference between a user and a device?

    What is the difference between a user and a device?

    As I’m browsing through the Microsoft Q&A forum for Intune related question, there is one thing that I see which seems to be a quite common misconception. That misconception is the difference between what a user is and what a device is.

    It’s not that people don’t know the physical difference between what a user (a person) and a device (an object) is, it’s in the sense of how they differ in Intune management and the cloud world.

    Let’s try to sort this out, shall we?

    Definitions:
    • User noun – “A person who uses or operates something.”
    • Device noun – “A thing made or adapted for a particular purpose, especially a piece of mechanical or electronic equipment”

    Disclaimer: I’m trying to wright this extremely simple and basically assuming that the term user and device is not known.

    Who is the user?

    The user is the person who in your organization is consuming the services and using devices. Users are usually a 1:1 scenario, but you might also have service users and group users. Behind a user there is in most cases ONE person (the Microsoft license structure kind of assumes this as well).

    In an Intune context, the user is the person who uses the device. The user is in a the most common context tied to a specific device where the user is the primary user and owner of the device.

    A user might have multiple devices such as a computer, a phone, and a tablet.

    An Azure AD user

    What is the device?

    The device is the piece hardware which the services are consumed on. This can be a computer, tablet, or phone. The device must, in an Intune context, run any of the supported operating systems:

    • iOS
    • iPadOS
    • macOS
    • Windows 10
    • Android

    The device usually has one main user and owner, which is the one tied to the device in Intune and Azure AD.

    An Intune enrolled device

    What is the difference and why does it matter?

    But why does this all matter?

    The reason this is important is in how you in Intune would distribute configurations, compliance policies, applications and so on.

    When you distribute any of these in Intune, you get to select whether you want to assign this to users or devices. Without knowing the difference, knowing which option to select is hard.

    However, the item itself is never applied to the user. It is ALWAYS applied to the device. The assignment only decides on what devices to apply the item in question.

    If you assign to a device

    If you assign your e.g. configuration with a device centric approach, this means that the configuration will only follow that device. If the user uses another device, the configuration will not be present on the second device.

    If you assign to a user

    If you assign your e.g. configuration with a user centric approach, this means that the configuration will follow the user. If the user uses another device, the configuration will apply also to that device (given it’s applicable for the device type).

    The key take away

    It pretty much defines how your configurations, policies and applications are distributed and utilized.

    The conclusion of this is that, depending on what scenario you want to fulfill, you might have to assign things in different ways. There are also a few things that might make more sense in distributing in one way or another.

    One thing that is important to keep in mind around applications is however the fun topic of licensing. Depending on how you have licensed an application, you might have to distribute in a certain way. So that is something that is important to think about when purchasing applications.