olastrom.com

Tag: intune

  • Intune lab for noobs – part 5 // Android

    This is the fifth part of the series of building your own Microsoft Intune lab. We will take some shortcuts and do some dirty tricks, just to get going. So please don’t use this as an implementation guide in a real environment. We will also skip a lot of fancy steps as getting a real domain name and having an on-premises AD. But if you already have those in your lab, that’s great!

    For Android, there are a handfull of ways we can manage these. In this guide, we will configure Microsoft Intune to manage the method called “Personally owned device with work profile” which is the simplest wat to manage Android devices where we only have control over the corporate data, which is separated from the personal data.

    For Android, we will setup the enrollment method, add a configuration profile, a compliance policy and add an application.

    Configure enrollment

    Navigate to Devices > Android and select Android Enrollment. This will list all available enrollment methods for Android.

    For this lab, we will use the “Personally owned device with work profile” which is the simplest and easiest Android management method to get started with (and it doesn’t require you to reset your device to enroll).

    Click on the box “Personally owned device with work profile“.

    As you will see by the message you are presented with, this is enabled by default. This means that we do not need to make any further configurations.

    Configuration profile

    To create a Configuration Profile navigate to Devices > Android and select Configuration profiles in the left side menu.

    Click on “+ Create profile” to create a new profile. As Platform select “Android Enterprise” and as Profile type select “Device Restrictions” under the “Personally Owned Work Profile” section. Then click Create.

    On the first page, give your profile a name and click Next. I use Android as a prefix to indicate that it’s a profile for Android followed by the PIN Requirements to indicate what the profile does.

    Find and expand the category Device password. Here we will add similar settings as we did with iOS/iPadOS which is to use Numeric Complex password type which blocks simple password (such as 111111 and similar) and we will require the PIN to be at least six digits. Facial recognition or fingerprint sensors will be available to use instead of PIN. When you have added these settings, click Next.

    Assign the profile to your user group and press Next.

    On the last page, review your settings and click Create.

    We have now successfully created a configuration profile which will require a PIN to be set on our enrolled devices.

    Compliance Policy

    As with the iOS/iPadOS configuration, we will create a compliance policy which will audit the device to make sure that the PIN requirements are met.

    Navigate to Device > Android and select Compliance policies and click “+ Create policy“. Select “Android Enterprise” as Platform and “Personally owned device with work profile” as Profile type. Then click Create.

    Give your policy a good name and click Next.

    Find and expand the category System Security and configure the password requirements to mimic the configuration profile. Once you have added this, click Next.

    On the next page, we will leave the default action but we will add the option “Send notification to end user” and leave the schedule to the default value 0 and then click Next.

    On the next page, we will add our user group and click Next.

    On the last page, review your settings and then click Create.

    We have now successfully created a compliance policy which will audit if the user has set a PIN which meets our requirements.

    Applications

    In the iOS guide, we used a Guided scenario to deploy Microsoft Edge to bot iOS, iPadOS and Android. This means that the Microsoft Edge appliucation will be automatically installed on the Android devices as well.

    But we need more than one application, hence we will add one more.

    Navigate to Apps > Android and press “+ Add“. Select “Managed Google Play app” as App type and press Select.

    Search for an application you want to add and select Approve on the application.

    Once the application has been approved, press Sync in the upper left corner of the window. This will take you back to the application list.

    Wait a few minutes and then click Refresh on the app list page in order to display your new applications. You will notice that the Assinged status on all new applications are set to “No” which means that no users has been assigned to the applictiaon yet.

    To assign the application to a group to distribute it to your devices, click on the application and select Properties in the left side menu.

    Click on Edit next to Assignments to add a group to distribute this towards. Add your user group to Available for enrolled devices and click Review + save. Then on the review page click save.

    We have now successfully made the application available to all our enrolled Android devices in the Managed Google Play store.

    Enroll your device

    Now its time to enroll your device and in this scenario it requires the device to be rested to factory default.

    On the first page where you are asked to select language, tap five times fast in order to trigger the QR code scanner.

    Go to Devices > Android > Android enrollment and select the profile you created earlier. Click on Token and scan the QR which is displayed.

    Follow the enrollment guide on your screen (this will vary depending on which version of Android you are running).

    Once enrollment is completed, you can find your device if you go to Devices > Android > Android Devices. Click on your device to show more information and perform remote actions such as wipe or removing the PIN if the user has forgotten it.

    Ending notes…

    There are many ways to manage Android, and in this guide, we went through the simplest one. There is also a method called “Corporate-owned devices with work profile” which is the most powerful method, in my honest opinion. this however requires you to reset your device before enrollment. You will also need to create new Configuration profiles and Compliance policies for this method since it operates a bit different.

    I really encourage you to keep playing around with Intune and try out more stuff. We only scratched the surface in this guide, but you have a good foundation to build upon!

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