Category: Intune

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