olastrom.com

Category: Intune

  • 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.

  • Silent Bitlocker in Windows Autopilot

    When enrolling devices through Windows Autopilot and using Intune enabling Bitlocker without user interaction can be a little bit of a hassle since the default behavior is to ask the end-user to encrypt the device in runtime.

    This pop-up can easily confuse end-users and the device is not really “ready to use” once the Enrollment Status Page (ESP) has closed.

    There are several different solutions for this, where running a PowerShell-scrip as a Win32 app during enrollment is the most common one.

    BUT I’ve found a way to skip this, but it does have some distinct limitations (except for all other Bitlocker requirements):

    • Use Intune for device management
    • Device can only be joined to the Azure AD
    • Running Windows 10 1809 or later
    • No third-party disk encryption services can be used

    So how do you configure this?

    In Microsoft Intune, go to Endpoint Security > Disk encryption and create a new profile:

    Select “Windows 10 and later” as platform and choose the Bitlocker profile, then click create. Give your profile a name based on your naming convention and click next.

    To enforce Bitlocker during enrollment, you need to

    • Set “Enable full disk encryption for OS and fixed drives” to Yes
    • Set “Hide prompt about third-party encryption” to Yes
    • Set “Allow standard users to enable encryption during Autopilot” to Yes

    A heads up on these settings though, if you are using any third-party encryption, you might break the machine and you will have to re-install the machine. So be careful if applying to existing machines.

    Then set your preferred settings for Bitlocker on OS and fixed drives, this is what I am running in this lab setup. One good setting to use is “Require device to back up recovery information to Azure AD” to ensure that you have the recovery information available for the machine. These settings might vary based on your organizational needs and requirements.

    Click next until you end up on “Assignments” and select your targeted device group.

    Click next and review your settings before hitting “Create” on the Review + Create page.

    And that’s it! Your devices will now silently encrypt using Bitlocker during Autopilot enrollment.

  • Why should you care about your phones?

    Why should you care about your phones?

    (Originally published on LinkedIn)

    By now you have gone through several generations of different practices on how and why to manage your computers, through a Microsoft product such as #ConfigMgr or a third-party product like SpecOps. For Windows, managing the device is a standard procedure and most larger organizations have some sort of management.

    But what about your mobile devices such as your iPhones, iPads, and Samsung phones? Are those managed?

    Why should you manage your mobile devices?

    There are a lot of arguments why you should manage your mobile devices such as keeping an inventory, security, and ease of use.

    But why should you care? What’s in it for you?

    Knowing what devices you have in your organisation, who has them and if they are used are a few things that are increasingly important in a cloud-centric world. Devices are no longer only living on the corporate network, and the mobile devices never even made it there.

    Adding management to your mobile devices can provide you with many benefits:

    • You can keep track of what devices are used by whom
    • You can utilize a mobile device as a factor in multi authentication scenarios
    • Ease the access to corporate data for your end-users
    • Distribute software and settings (much like on Windows), making the user experience smoother.
    • Ensure that your corporate data is safe

    There are several other arguments for this as well.

    But to keep it short. You will gain control of what devices are used, by whom, in your organization. These devices are also most likely accessing corporate data, and it’s a clever idea to manage data on these devices (to minimize incidents).

    What’s in it for the user?

    So why would your users care about if their device is managed or not?

    A lot has happened since the iPhone was introduced back in 2007. The services available, the threat level, user behaviour and more. We have also gained a lot of possibilities during the last couple of years when it comes to mobile device management. There are constantly new settings being available to manage to make the end-user onboarding better. We can define email account, deploy corporate Wi-Fi credentials, install business-related apps and much more. But we can also enforce security measurements such as PIN-code and encryption.

    Lately, we are also able to set trust to a device, by registering it in Azure AD and by doing that claiming it to be trusted and not enforcing MFA each time it the end-user is trying to access the corporate sphere. Doing this will increase the user experience and at the same time ensure that you obtain a higher level of security since you know what device your data is accessed from.

    One other important thing in this for the end-user is that you can now remotely assist the user in case they lose their device PIN or need some other help. For some platforms, there are even remote tools through e.g. TeamViewer so that your support team can see what the user is seeing.

    So why should you care?

    Since the behaviour of the workforce is changing. The term “mobile-first” isn’t applicable anymore, but if you look at what devices people are using, they spend a lot of time with their smartphones. So why wouldn’t you secure this device and make it member of your IT environment? There is a lot of hidden potentials here, where you can provide a valuable experience throughout the whole life cycle of the device (from onboarding to decommissioning).

    Especially if you look at the younger generations of your workforce, they are more heavily dependent on their mobile device and if you are not on top of this on an early stage you will have a lot of catching up to do.

    And just to be clear, I’m not suggesting that you manage your mobile devices as you do with your on-prem computers. Adopt to what the mobile device management world looks like and protect the right things (data and identity), having the device locked down and not useful from an end-user point of view will only make your end-users find ways around it and you are back to square one.

    What are your thoughts on this? Leave a comment!