Author: Jens Du Four

  • Cloud PKI in the Intune Suite: The Future Is Now

    The Prelude: What Is Microsoft Intune?

    Microsoft Intune isn’t just a buzzword—it’s a cloud-based symphony of endpoint management and security. Imagine a conductor orchestrating a harmonious blend of user access, app management, and device wizardry across a cosmic array of gadgets. We’re talking mobile devices, desktops, and even those elusive virtual endpoints (dare me to talk about Windows 365).

    Now, imagine all these superpowers bundled into one cosmic cape—the Microsoft Intune Suite. It’s like assembling the Avengers, but for IT management.

    1. Remote Help: Imagine a digital lifeline connecting IT professionals to users in distress. With Intune’s Remote Help, troubleshoot issues, provide expert guidance, and rescue devices from the abyss.
    2. Endpoint Privilege Management: Picture a backstage pass at the nightclub. Endpoint Privilege Management ensures that only authorized users waltz through the VIP door. No more unauthorized gatecrashers.
    3. Advanced Analytics: Behold the crystal ball of data insights! Advanced Analytics peers into the mists, revealing patterns, anomalies, and hidden truths. It’s like having a detective on your team.
    4. Enterprise Application Management: Ever juggled a circus of apps? Fear not! Intune’s Enterprise Application Management tames the app menagerie. Deploy, update, and manage apps with finesse.
    5. Cloud PKI: Ah, our star of the show! Cloud PKI dances with digital certificates, whispering secrets of security and authentication. It’s the custodian of trust, and today, we’re shining a spotlight on it. 

    Overview

    Cloud PKI is your ticket to hassle-free certificate lifecycle management within the Microsoft Intune ecosystem. Imagine a world where you can create, revoke, and manage certificates without the burden of maintaining on-premises PKI infrastructure. Sounds like a dream, right? Well, it’s real, and it’s here to revolutionize your certificate game.

    What Is Cloud PKI, Anyway?

    Before we dive into the nitty-gritty, let’s demystify PKI. Public Key Infrastructure (PKI) is the backbone of secure communication. It uses digital certificates to authenticate and encrypt data between devices and services. Think VPNs, Wi-Fi, email, web traffic, and device identity—all powered by PKI magic.

    However, managing PKI can be like herding digital cats. It’s complex, costly, and time-consuming, especially for organizations juggling multiple devices and users. That’s where Microsoft Cloud PKI swoops in like a caped crusader.

    The Marvels of Microsoft Cloud PKI

    1. No On-Premises Servers Required: Say goodbye to racks of servers and tangled cables. Cloud PKI provides a dedicated PKI infrastructure without any on-premises fuss. No more late-night server patching—just pure cloud goodness.
    2. Certificate Lifecycle Made Easy: With Cloud PKI, issuing, renewing, and revoking certificates becomes a breeze. It’s like having a digital butler that handles all your certificate needs. Your Intune-managed devices will thank you.
    3. Accelerate Your Cloud Transformation: Cloud PKI aligns perfectly with your cloud-first strategy. It’s the turbo boost your organization needs to embrace the cloud without tripping over PKI hurdles.
    4. BYOCA (Bring Your Own CA): Got an existing PKI infrastructure? No problem! Anchor your Intune Issuing CA to your private CA through Active Directory Certificate Services or any non-Microsoft certificate service. It’s like merging the best of both worlds.
    5. Certificate Management with Finesse: Create a CA per Intune tenant, set up a 2-tier PKI hierarchy, and wield RBAC permissions like a pro. Plus, scope tags keep things organized—no more certificate chaos

    Crafting a 2-Tier Cloud PKI Hierarchy

    Creating the Root CA

    Our journey begins with the Root Certificate Authority (CA). Think of it as the foundation—the bedrock of trust. Here’s how you lay the groundwork:

    • You can find the dashboard under “Tenant administration” -> “Cloud PKI”
    • After selecting the “create”-option, you give the new Root CA a name.
    • First option that we should verify is the “Validity period” of your CA.
    • Afterwards, we will select the EKU. Be aware that the “any” configuration is not supported, this is also not possible as a “Custom” EKU.
    • After filling in all the attributes, we have to select our key size and algorithm.

    Creating the Intermediate CA

    Now, let’s build an Intermediate CA. It’s like a bridge between the Root CA and the real world:

    • Repeat the same steps as above, where you start with naming the intermediate CA.
    • After selecting the Issuing CA, it is important to choose your Root CA source. It is possible to use the Intune Root CA, which we created, or to use a “Bring your own root CA”.
    • Be aware that when selecting the period this will be equal or less than the Root CA validity period.

    Take note that the EKU of the Issuing CA is a subset of the Root CA EKU. This is the same with the key size and algorithm.

    Enjoy the fruits of your labor

    Now that we’ve established the necessary infrastructure in Intune, let’s explore how Certificate-Based Authentication (CBA) can enhance security and streamline user access.

    Leveraging the CA for Certificate-Based Authentication

    Adding the Root CA in Microsoft Entra ID

    After surfing to “entra.microsoft.com”, you should navigate to “Protection” -> “Security Center”. Here you can find the “Certificate authorities”.

    Through the upload button we will add both the Root and Intermediate CA to Microsoft Entra. Be aware to switch the “Is root certificate” flag and add the “Certificate Revocation List URL” which we found in the dashboard.

    Afterwards, we should navigate to “Protection” -> “Authentication methods”, where we can configure

    Trusting the CA through Microsoft Intune

    Selecting “Certificate-based authentication” lets you configure this method for all users or a subset of users.

    Under “Configure” you can change the protection level and add your Root CA as a “Certificate issuer”. Here you can also bind the certificate field to the user attribute for authentication.

    Deploying the Certificates using Microsoft Intune

    Now that we have successfully configured the Cloud PKI infrastructure and have added this to Microsoft Entra ID, we have to make sure that the certificates get pushed towards our endpoints.

    For this we will be using Microsoft Intune. The process is fairly easy as we will be creating two configuration profiles:

    • One to add the Root CA as a trusted certificate
    • One to issue a certificate using SCEP (Simple Certificate Enrollment Protocol)
    • Create a profile for your relevant OS and use the templates. Select “Trusted certificate” and click “Create”.
    • Give the configuration policy a name.
    • Select your Root CA certificate which you can download from the Root CA dashboard in Cloud PKI. You can repeat this process for the intermediate CA.
    • After adding the trusted certificate for both the Root and Intermediate CA, we will publish the certificate to the endpoint.
    • Create a profile for your relevant OS and use the templates. Select “SCEP certificate” and click “Create”.
    • Give the configuration policy a name.

    We will create a user certificate where the subject name format will be the username and the SAN attribute contains the “UserPrincipalName”. This will be used for the authentication. Make sure to select your preferred validity period, KSP, usages, key size and hash algorithms.

    Finally, we will select the Root CA we added as a “Trusted certificate” above. As EKU, we will use “Client Authentication” as we are configuring CBA. At the bottom, we fill in the SCEP Server URL.

    When all this is configured the Root and Intermediate CA should be trusted on the endpoint. Using SCEP, the endpoint will get a certificate issued to it. We can manage this certificate again through the Cloud PKI dashboard in Microsoft Intune.

    The Practical Outcome of Cloud PKI

    Your 2-tier PKI hierarchy is now operational—a bridge between trust and secure authentication. Devices wield certificates like digital passports, and users journey through gateways with confidence.

    On the endpoint you can see if the certificates are present in the “Manage computer certificates” Control panel.

    • The Root CA can be found in the “Trusted Root Certification Authority” folder.
    • The Issuing CA can be found in the “Trusted Intermediate Certification Authority” folder.
    • The user certificate can be found in the “certmgr” under “Personal”.

    When trying to authenticate on Office.com, we notice that the browser asks us to select the relevant certificate for CBA.

    In the end, the user is logged in using the certificate.

    Conclusion

    I give Cloud PKI two enthusiastic 👍👍. It’s a game-changer for organizations seeking simplicity, security, and scalability. So go forth, my fellow tech adventurers, and explore the cloud-kissed realms of Microsoft Cloud PKI!

    For more details, check out the official documentation.

  • Entra ID: The Magic Wand for Ubuntu 23.04 Authentication

    Introduction

    Welcome to this article about Entra ID authentication for Ubuntu devices. Entra ID authentication is a powerful way to authenticate on your devices. Additionally, you will learn how to enroll your Ubuntu device in Intune, a cloud-based service that helps you manage and secure your devices. By the end of this article, you will be able to use your Entra ID credentials to log in to your Ubuntu device. You will need some basic knowledge of Ubuntu, Microsoft Entra, and Microsoft Intune to follow along. I hope you enjoy this article and find it useful. Let’s get started!

    Setting up an Entra ID Application

    We start with the beginning! Using the Entra ID authentication with Ubuntu requires the creation of a Microsoft Entra application. This application needs to be able to retrieve the tenant ID and application ID required for the authentication.

    Creating an Entra ID Application

    We will create the application through the Entra portal. Going through the “Identity > Applications > App registrations” where we will select “New registration”. We will name the application “Ubuntu Entra ID Authentication”, so the purpose of the application within our tenant is clear. The remaining options you can leave as default and click “Register” at the bottom of the page. This will give you the “Application ID”. Together with the “Tenant ID” this forms the basis for the Entra ID authentication.

    Using a Script to Get the Ubuntu Device to Use Entra ID Authentication

    The first thing we got to do before enrolling the device to Microsoft Intune is to enable the authentication with Microsoft Entra ID. Unfortunately, this is something we still have to do manually, as for today there is no zero-touch provisioning with Microsoft Intune for Linux nor Ubuntu devices. However, as any good system administrator would do, we put this in a script.

    Using a script to enable the authentication

    Although support for Linux is still fairly limited at this point in time, we can already use the script we created to prepare everything for the Entra ID authentication.

    The script can be seen below in its entirety. Make sure to adapt the Tenant ID and App ID.

    #!/bin/bash
    
    # Replace these two variables with your relevant Tenant ID and Client Secret Value
    tenant_id="<tenant-id>"
    app_id="<app-id>"
    
    # Check if the script has already run
    if [ -f /var/run/aad_ubuntu.lock ]; then
        echo "Script has already run. Exiting..."
        exit 0
    fi
    
    # Create lock file to indicate that the script has run
    sudo touch /var/run/aad_ubuntu.lock
    
    # Check Ubuntu version
    if [[ $(lsb_release -sr 2>/dev/null) == "23.04" || $(lsb_release -sr 2>/dev/null) == "23.10" ]]; then
        echo "Ubuntu version is supported."
    else
        echo "Unsupported Ubuntu version."
        exit 1
    fi
    
    # Install required packages
    sudo apt-get update
    sudo apt-get install -y libpam-aad libnss-aad aad-cli
    
    # Configure Azure Active Directory Authentication
    echo "auth [success=1 default=ignore] pam_aad.so" | sudo tee -a /etc/pam.d/common-auth
    
    # Enable home directory creation on login
    sudo pam-auth-update --enable mkhomedir
    
    # Add your tenant details to the configuration file
    sudo truncate -s 0 /etc/aad.conf
    echo "tenant_id = $tenant_id" | sudo tee -a /etc/aad.conf
    echo "app_id = $app_id" | sudo tee -a /etc/aad.conf
    echo "[cetsjdf.be]" | sudo tee -a /etc/aad.conf
    echo "offline_credentials_expiration = 30" | sudo tee -a /etc/aad.conf
    echo "homedir = /home/cetsjdf.be/%u" | sudo tee -a /etc/aad.conf
    echo "shell = /bin/zsh" | sudo tee -a /etc/aad.conf
    
    # Restart services
    sudo systemctl restart systemd-logind.service
    echo "Entra ID Authentication setup complete."
    exit 0
    

    After getting the successful prompt “Entra ID Authentication setup complete”, we can be certain that it is enabled. Or can we, as you can see below, we try to login with a user before enrolling the device, as that user in Microsoft Intune. This will be vital to further manage the device.

    Testing the Entra ID Authentication

    We are at the end of our journey! Great! But for the most important part, will it work? Testing it is easy, after rebooting the Ubuntu device, try to login with any user from your Entra ID tenant. If everything goes well, it should look something like below.

    Enrolling an Ubuntu Device in Intune

    The main question you can ask yourself here is “Why should we enroll a device to Microsoft Intune?”. Fairly simple, we will use Intune to further configure the device so that the local account created during the installation of Ubuntu is no longer to be used. Now there are a couple of things we have to do beforehand, which you can find in the prerequisites below.

    Prerequisites

    First of all, your device should be at least Ubuntu 22.04 or 20.04 LTS, with the GNOME graphical desktop environment. Be aware that all Ubuntu devices enrolled with Intune are considered corporate-owned devices.

    Furthermore, the Microsoft Edge browser and Microsoft Intune app should be installed to the device. This you can do yourself or you can utilize the script that I have created below. All these scripts can also be found on my Github.

    #!/bin/bash
    
    # Check if the script has already run
    if [ -f /var/run/aad_ubuntu_prereq.lock ]; then
        echo "Script has already run. Exiting..."
        exit 0
    fi
    
    # Create lock file to indicate that the script has run
    sudo touch /var/run/aad_ubuntu_prereq.lock
    
    # Check Ubuntu version
    if [[ $(lsb_release -sr 2>/dev/null) == "23.04" || $(lsb_release -sr 2>/dev/null) == "23.10" ]]; then
        echo "Ubuntu version is supported."
    else
        echo "Unsupported Ubuntu version."
        exit 1
    fi
    
    # Install the Microsoft GPG key
    wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
    sudo install -o root -g root -m 644 microsoft.gpg /usr/share/keyrings/
    sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/ubuntu/22.04/prod jammy main" > /etc/apt/sources.list.d/microsoft-ubuntu-jammy-prod.list'
    sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge.list'
    sudo rm microsoft.gpg
    sudo apt update
    
    # Update Java for Microsoft Intune
    sudo apt install -y openjdk-11-jre
    
    # Install Microsoft Edge
    sudo apt install -y microsoft-edge-stable
    
    # Install Microsoft Intune
    sudo apt install -y intune-portal
    
    echo "Installation complete."

    It might be useful to know that I always include lock files in my scripts to make sure I don’t run them twice. This is not always necessary but is a precaution I take myself. You should end up with an “Installation complete.”-message, as you can see.

    Enrolling the device in Microsoft Intune

    This is a process we call user-driven enrollment into Microsoft Intune. The process is fairly simple, once the prerequisites are implemented. We will begin by opening Microsoft Edge and logging in.

    It is easier to start with logging into Microsoft Edge, this is not a requirement, but it makes our lives easier in the long run.

    Afterwards, we continue with the Intune enrollment. The user will need to sign-in and afterwards there will be an additional authentication prompt to apply the configuration.

    Conclusion

    In this post, I showed you how to set up Entra ID authentication for your Ubuntu 23.04 device, and how to enroll it in Microsoft Intune for further management. Entra ID is a powerful and secure way to authenticate your Linux device with your Microsoft account, and Intune is a cloud-based service that allows you to configure and monitor your device remotely.

    By following the steps in this post, you can leverage the benefits of both Entra ID and Intune for your Ubuntu device.

    If you have any questions or feedback, please leave a comment below. And if you found this post helpful, don’t forget to share it with your friends and colleagues who might be interested in Entra ID authentication for Ubuntu. Thank you for reading!

  • Windows 365: Zero to Cloud in 1 hour!

    This blog article is throwback to the session I did at the MCT Summit in The Hague. The Windows 365 session was an eye-opener for organizations of all sizes and setups. It demonstrated how easy it is to implement Windows 365 and how it can benefit any organization. In this write-up, we will cover the basics of Windows 365 and the easy setup process.

    Gone are the days when Windows was consumed solely from a native PC. I still remember the day when the first PC arrived at our home. I finally got my hands on the glory of Windows XP.

    The first step towards virtualization was evolutionary. We introduced system administrators to the flexibility and control of their environment beyond the physical. Azure Virtual Desktop, formerly known as Windows Virtual Desktop, was a gamechanger.

    Today, a whole new option presents itself: Windows 365, or the Cloud PC. This option has a specific focus on experience, more importantly end-user experience. It takes into account that the end-user of this solution is not solely the consumer. The system administrator that needs to configure and maintain it, also plays a big part.

    How do I integrate this with my current environment?

    One of the most frequently asked questions I receive is “How can we integrate this into our existing environment?”. The answer is simple: How are you doing this today? Depending on your current environment, there are three main architectures you can use.

    The first option is to host the full solution in the Microsoft subscription and utilize the Microsoft Hosted Network. The option to connect to on-premises resources with something like a split-tunnel VPN is still valid.

    The second option utilizes something we call an Azure Network Connection. It basically allows you to connect your Cloud PC to a vNET that exists within your Azure subscription. You can connect this vNET through a site-to-site VPN or even an ExpressRoute.

    For our third option, we take it one step further. You can create a computer object in your AD and manage it as if it were an on-premises device. This allows for SCCM to perform the device management. This requires a line-of-sight from your vNET, that we specified in the ANC (Azure Network Connection), to your domain controller. You need to specify some additional information to allow the computer object to be created in the relevant organizational unit.

    The provisioning policy

    If you want to set up a Cloud PC, you need to create a provisioning policy first. This policy defines everything about your Cloud PC, such as its name, description, and features. One of the most important choices you have to make is whether to use Enterprise or Frontline.
    How do you decide? Well, it depends on how many Cloud PCs you and concurrent sessions you need. The Frontline license gives you three Cloud PCs for the price of one, but only one session at a time.
    For example, you have 300 workers who need a Cloud PCs. But only 100 of them will use it at the same time. This allows you to save money by choosing 100 Windows 365 Frontline licenses.

    Another important choice in the provisioning policy is your “Join type details”. This refers to the network architecture you want to use: Microsoft Hosted Network, Microsoft Entra Join with your own vNET, or Hybrid Microsoft Entra Join. I have explained these options above. You can enable the single sign-on checkbox if you use the Microsoft Entra Join or if you have a Cloud Kerberos Trust with the Hybrid Microsoft Entra Join.

    After clicking next, you get the option to choose a gallery image or a custom image. It is always recommended to go with the gallery images. These are created and maintained by Microsoft. Providing you with optimized images for the Cloud PC.

    The final step before applying the provisioning policy is to configure some settings. You can choose the language and region for the Cloud PC, create a naming template, and opt to enroll the device in Windows Autopatch. This is a service that I will cover in a future blog post.

    Easy-peazy!

    That’s it! Were done! The provisioning policy will check if the assigned group has some licenses. Afterwards, it will start spinning up the relevant Cloud PC. As you see, the entire process is as easy as one-two-three!

  • Adding a language pack using Proactive remediations

    One of the features of Intune is Proactive Remediation. This allows administrators to create scripts that automatically fix issues on devices before users even notice them. Adding a language pack using Proactive Remediation script is a straightforward process. I will guide you through the steps in this article.

    I have been using this method to add additional language packs to my Windows 365 deployments. This is from great use to organizations that are multi-geographical.

    Creating the scripts

    First, we will create a language pack installation script. This is split into two parts. One should be designed to detect the language currently in use on the device. The other installs the appropriate language pack.

    The first script here uses some basic PowerShell to detect what languages are installed on a system and verifies if the one required is installed.

    $OSInfo = Get-WmiObject -Class Win32_OperatingSystem
    $languagePacks = $OSInfo.MUILanguages
    
    if ($languagePacks -contains "de-DE")
        {
        write-output "Installed"
         Exit 0
        }
        else
        {
        write-output "Not installed"
         Exit 1
        }

    We will leverage the LanguagePackManagement Module to install the required languages. This downloads and installs the language components for the specified language.

    Install-Language de-DE

    Additionally, you have the option to directly enable the new language pack by using the following command:

    Install-Language de-DE -CopyToSettings
    

    Warning! Please verify that these scripts we created earlier are saved in UTF-8 encoding.

    Creating the script package

    After we created the language pack installation script , we should create the Proactive Remediation script in Microsoft Intune. To do this, log in to the Intune portal and navigate to Reports. Click on “Endpoint Analytics” and select “Proactive remediations”.

    After clicking on “Create script package”, give the script a name and a description and Publisher.

    The next step is to select the installation script that we created in the initial step. We do this for both the “Detection script file” and the “Remediation script file”.

    Make sure to set the slider for “Run script in 64-bit PowerShell” to “Yes”.

    Finally, we should assign the policy. To do this, navigate to the Assignments section of the policy and select the group that the policy should apply to.

    Additionally, you can also change the schedule and filter for specific devices.

    Conclusion

    Adding a language pack using a Proactive Remediation script is a straightforward process that can save administrators time and ensure that devices are always running in the correct language.

    By following the steps outlined in this article, administrators can easily create a language pack installation script and create a Proactive Remediation script to automate the installation process.

  • Enroll an Android device in Microsoft Intune

    The newly created AVD, from our last post, should be managed within Microsoft Intune. Microsoft Intune provides a range of options for managing and securing Android devices. Some of the key features include:

    • Device enrollment: Allows users to easily enroll their Android devices in Microsoft Intune and access corporate data.
    • Policy management: Enables administrators to configure policies that control how devices can be used. E.g. password policies and enforcing encryption.
    • Compliance monitoring: Provides the ability to monitor compliance with corporate policies and take action if any devices are not compliant.
    • Mobile application management: Allows organizations to securely distribute and manage corporate apps on Android devices.
    • Remote actions: Provides the ability to remotely wipe data from a device or perform other actions if necessary.

    There will be more in-depth guides on the capabilities of Microsoft Intune. In this article we will keep it simple and start with how to enroll an Android device.

    Android Device Management

    Enrolling an Android device into Microsoft Intune is a simple process. This will directly enable you to manage and secure mobile devices.
    There are three main methods of enrolling a device:

    • Android Enterprise (AE): Most up-to-date and secure method
    • Android Device Administrator (DA): It is encouraged to migrate to AE
    • AOSP: Method for devices that aren’t integrated with Google Mobile services

    The focus here will be on Android Enterprise. Because this is the most versatile method with applications for BYOD, personal- and corporate-owned devices.

    Android Enterprise

    Android Enterprise is a set of features and services provided by Google. This will enable organizations to manage and secure Android devices used by their employees. This can include features such as the ability to remotely lock or wipe a device, enforce password policies, or restrict access to certain apps or data. With Intune, you can take advantage of these features to manage and secure their Android devices. Additionally, you ensure that they are used in a way that aligns with the security and compliance policies. This can help organizations protect their data and prevent unauthorized access to sensitive information. Next to this, it allows employees to use their own Android devices for work purposes. When using Android Enterprise, there are two main modes of deployment: fully managed devices and work profiles.

    Fully Managed

    This method allows users to enroll their Android device as a fully managed device. This gives the organization complete control over the device and access to all of its features and functions.

    Fully managed devices are completely owned and controlled by the organization. This means that the organization can install any app, configure any settings, and enforce any policies on the device. This is typically used for devices that are provided by the organization and used exclusively for work purposes.

    Work Profile

    A work profile is a separate, secure profile on the device used for work purposes. In this mode, the employee still has their own personal space on the device. The organization can only manage and control the work profile. It cannot access or modify the personal space on the device. This is typically used for employee-owned devices. Enabling them to use their own device for both work and personal purposes.

    The main difference between the two modes is the level of control the organization has over the device. With fully managed devices, the organization has complete control over the device. With a work profile, the organization only has control over the work profile. Allowing employees to maintain their privacy on their own devices. In the meantime, still allowing the organization to manage and secure their work data.

    Microsoft Intune

    Android Enterprise

    Prerequisites

    Before starting with an enrollment profile, you must link a “Managed Google Play” account to Microsoft Intune. For this, you must have set up a managed Google Play account.

    Afterwards, you can use Intune to manage and distribute apps from Managed Google Play to your Android devices.

    Enrollment Profiles

    By default the “Personally-owned devices with work profile”-option is enabled. We need no additional configuration for this.

    Android Device Enrollment

    User-Drive Enrollment

    To enroll an Android device using the Intune Company Portal app, users simply need to download the app from the Google Play Store and sign in with their organizational credentials. Once logged in, the app will guide users through the enrollment process. Afterwards, allowing them to enroll their device in a matter of minutes.

    Automated Enrollment

    Zero-touch enrollment is a method of automated enrollment that allows organizations to enroll Android devices in Intune directly from the manufacturer or reseller. In this method, the organization provides the manufacturer or reseller with their enrollment configuration. You can automatically enroll devices in your mobile device management (MDM) solution when shipped to the user. This pre-configures the devices with their desired settings and policies. This ensures that they are ready for use as soon as received.

    In conclusion, enrolling an Android device into Microsoft Intune is a simple process. It can be done using user-driven or automated enrollment. Each of these methods provides organizations with the ability to manage and secure their mobile devices. Ensuring that sensitive data is protected and that employees have access to the tools they need to be productive.

  • Creating an Android Virtual Devices (AVD)

    I am a fond believer of the concept “Seeing is believing”. Does that mean that I will test everything? No, probably not. But I will at least try to! Today the goal is to be creating an Android Virtual Device (AVD).
    Further down the road, we will enroll these in Microsoft Intune.

    For those of you that don’t know Microsoft Intune yet, it is a cloud-based unified endpoint management solution. Intune provides a central console for monitoring, configuring, and managing mobile devices and applications across multiple platforms, including iOS, Android, Linux, Chrome OS and Windows. It also provides a comprehensive set of tools for managing mobile applications, such as managing the distribution, installation, and usage of apps. All of this helps to improve productivity and reduce costs.

    Creating an Android Virtual Device (AVD)

    First of all, we will be creating an Android Virtual Device (AVD). AVD is an emulator that is part of the Android Studio. It is a great tool for developers to test their apps on different versions of Android. With AVD different versions of Android and different hardware configurations can be simulated.

    However, that is not how we are intending to use it. In this article we will create an Android Virtual Device. This is helpful for those who don’t have access to physical Android devices. The AVD can be used to test out Intune policies and apps.

    Creating an Android Virtual Device (AVD)

    The process of creating an AVD is fairly straightforward within Android Studio. In addition, this software is freely available and has the following pre-requisites:

    • 16GB RAM
    • 64-bit Windows, macOS, Linux, or Chrome OS operating system
    • 16GB disk space

    After installing and verifying the prerequisite, we will be configuring the AVD in Android Studio:

    • Open Android Studio and select “Virtual Device Manager” from the “More Actions” drop-down menu.
    • Click the “Create device” button
    • Select a device definition, with or without Play Store
    • Select the system image for the preferred Android version
    • Configure the AVD hardware settings.
    • Click the “Finish” button to create the AVD.

    Select the AVD you created and click the “Start” button to launch the AVD.

    Configure hardware acceleration in Windows


    Lastly, some configuration changes should be made to Windows. This will enable hardware acceleration of the emulator. However, this is an optional step, you can still use the emulator without it, but it will be slower and may not perform as well.

    First, you must ensure that your computer has a processor that supports virtualization and that the feature is enabled in the BIOS. Then, you can follow these steps:

    1. Open the Start menu and type “Turn Windows features on or off” into the search box.
    2. Click on the “Turn Windows features on or off” option that appears in the search results.
    3. In the Windows Features window, scroll down and check the box next to “Hyper-V”.
    4. Click on the “OK” button to enable Hyper-V on your computer.

    This will enable Hyper-V acceleration for the Android emulator, which can improve its performance. Make sure that the AVD you are creating is using an x86_64 or x86-based system image.

    In conclusion, we are left with an Android Virtual Device (AVD) on Windows with all the necessities in-place to have hardware acceleration and still be able to use Hyper-V.
    Our next step will be to enroll this device in Microsoft Intune, just as described in my next post.

  • Hello world!

    Hello all, hello world! Today, the first of December, marks the beginning of a new journey for me as I start this personal blog. This will be a way to reflect on my thoughts and experiences. This blog will serve as a public journal where I can share my thoughts on various topics. It will hold myself accountable for my actions and decisions.

    I don’t have any specific expectations for this blog. I won’t be monitoring the number of readers I get or providing guidance on how to handle your own situation. I’ll probably make some mistakes along the way, but I’m excited to see where this journey takes me.

    If you happen to stumble upon this website, I would love to hear from you. Whether you have questions, suggestions for topics, or just want to say hello, please don’t hesitate to reach out to me.

    Finally, what is my goal here? What will I be focusing on?

    Modern Work

    One of the main subjects I plan to focus on in this blog is modern work. This term can mean many different things. To me it encompasses the ways in which technology and the changing nature of the workforce are impacting the way we do our jobs. From remote work and flexible schedules to the rise of artificial intelligence and automation, the world of work is undergoing a major transformation.

    I want to explore the concept of organizations that enable digital collaboration. Organizations that see IT as a tool to help employees achieve their goals, rather than a burden to be managed. I believe that IT has the potential to be a powerful enabler for modern organizations. I hope to share some of my thoughts and experiences on this topic in this blog.

    Overall, my goal for this blog is to explore how organizations can adapt and thrive in this rapidly changing world. I’m looking forward to sharing my journey with you and learning from your own experiences as well.

    P.S. Feel free to check out my first post on how to create an Android Virtual Device!

    Cheers

    Jens