• Tip of the week – Focus mode in Microsoft Word

    Focusing while writing a long Word document can be really hard sometimes with distractions from other applications and windows. Or you just want to focus on the text and not the buttons around it.

    Enter Focus mode. This isn’t a new feature, but I actually just learned about it.

    Enabling focus mode

    To enable focus mode you can either select View in the ribbon and then find Focus.

    Or you can click “Focus” at the bottom of the window and this will also enable Focus mode Word.

    When you enable Focus, Word will automatically go into full-screen mode, but you can still access the ribbon by moving your mouse to the top of the screen.

    To exit out of the focus mode, you simply click the button again or just press the ESC button on your keyboard.

    Changing backgroun color

    When working on a Word document, you typically have some blank space around the document. Your background basically. This is usually white or black, depending on if you use dark mode or not.

    By using Focus mode, you can actually change this color!

    IMPORTANT NOTE: If you change the color of the background this will stick and you can only change it from within focus mode. However, when closing Word this will be reset back to default.

    There are a few different colors to pick from, but they are quite nice!

  • Remove Quick Assist

    Updated on the 29th of September 2022 due to changes in Quick Assist installation.

    Like I mentioned in the blogpost about Remote Help, the build in Quick Assist tool in Windows 10 and Windows 11 is great for supporting friends and family. However, it’s not that great to support an organization since vital features are missing like handling UAC and logging. There is also a lot to wish for when it comes to how accounts are managed and the overall experience in a corporate setup using Quick Assist.

    So, when we have deployed Remote Help to all our users, we want to remove Quick Assist to improve security (so unauthorized people cannot remotely connect) and to ease confusion about what remote support tool to use.

    There are several ways of doing this, but I’m taking the approach that we don’t have a custom image since our devices has been enrolled through Windows Autopilot using vanilla images. So how can we remove the feature, and make sure that the end-user doesn’t get creative with enabling it again?

    The answer to this is using proactive remediations.

    What is proactive remediations?

    Proactive remediations is a part of the Endpoint analytics section of Microsoft Endpoint Manager. You can find it by going to Reports > Endpoint Analytics > Proactive Remediations. By default you will have to script packages published by Microsoft.

    Proactive Remediations is a script package where you can find and fix things on your clients, before this generates a ticket to your help desk.

    However, since these are scripts running, you can do about anything to be honest. Each script package consists of a detection script and a remediation script. The scripts are then deployed to the devices through MEM and will report back. You can find reports on how many times a script has run, and how many times it has fixed an issue. Fixed and issue means that it has run the remediation script. You can read more about how they work and what you can do on e.g. Microsoft Docs.

    One thing you could do is to detect if a Windows component is active, and if found active then disable it.

    How do I remove new Quick Assist?

    Due to an update, Quick Assist have now moved in to the Microsoft Store, meaning that we need a new way to remove the store app. Next chapter will cover the old application which was a Windows Capability.

    There are several ways to remove pre-installed application from Windows, you could either get the application from the Business Store and assign it as “Uninstall” for all devices/users, or you could user PowerShell to remove applications.

    For this, we will use Proactive Remediation to detect if the Quick Assist is installed, and if so we will remove it. This would remove the application even if the user installs it them self. There are other ways to do this as well, like only deploying the removal part and blocking the application with AppLocker.

    I’ve put these scripts in my GitHub repository, for this part use the *_app files.

    First we will do detection:

    WinCap = Get-AppxPackage -name "MicrosoftCorporationII.QuickAssist"
    
    try {
    If ($WinCap.Name -like "*MicrosoftCorporationII.QuickAssist"){
    Write-Warning "Quick Assist installed - running remediation script"
    Exit 1
    }
    Else{
    Write-Host "Quick Assist missing - exiting"
    Exit 0
    }
    }
    catch {
    Write-Host "Quick Assist missing - exiting"
    Exit 0
    }

    If our detection script finds the application, we will run a remediation script to uninstall it, just two lines of simple PowerShell code (thanks @LasseiLarod for the contribution to this).

    $WinCap = Get-AppxPackage -name "MicrosoftCorporationII.QuickAssist"
    Remove-AppxPackage -package $WinCap.PackageFullName

    Now all that we need to do is to make sure that we run the script in User Context, since the application is installed in the user context.

    How do I remove old Quick Assist?

    One way to disable Quick Assist, even if the user enables it again, I have found is to use a proactive remediation which checks if Quick Assist is enabled on the device, and if it finds that it is Quick Assist is disabled.

    Quick Assist isn’t an app installed from the store, it’s a Windows capability which means that we cannot uninstall the app.

    To do this, we firstly need a script which will identify if Quick Assist is enabled. One way of setting that up is like this, a simple PowerShell script that my college helped me create (thank you Daniel).

    I’ve put these scripts in my GitHub repository.

    $WinCap = Get-WindowsCapability -online -name App.Support.QuickAssist*
    
    If ($WinCap.State -match "NotPresent"){
        Write-Warning "Windows Capability - Quick Assist missing - exiting"
        Exit 0
    }
    else {
        Write-Host "Windows Capability - Quick Assist installed, Running Remediation script"
        Exit 1
    }

    This simple script will check if the Windows capability is enabled, if enabled it will run the remediation script which disables Quick Assist. It’s a one-liner:

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

    What could be good to keep in mind is that if the version of Quick Assist changes, this disable-part will stop working. I’ve’ tried using a more generic string, but I couldn’t get it to work. However, my PowerShell skills are quite limited.

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

  • Ignite reflections

    Ignite reflections

    Ignite 2021 Fall edition is over, and I honestly needed some time to process what was announced.

    This year time there was quite a lot of things around device for once, but the general “Teams Teams Teams Teams” was gone and was more “MFA MFA MFA MFA” to quote a former colleague.

    I think one of the bigger things with Ignite this time was not that there were a bunch of new cool things (even though that was awesome). The biggest thing was that you could start to see the synergies and relations between several products that has felt disconnected. It was no longer “yet another collaboration tool” when they announced Microsoft Loop, it integrates to existing things like Outlook or Teams. Microsoft Loops builds on the fluid framework which was introduced a while back and has now become something! That was my biggest take away this time, that now we are starting to see a more connected range of products again. This was referred to during Ignite as digital fabric, so a new cool buzz-word to use!

    There was also some sweet news in the device management area, like a remote assistance tool from Microsoft (finally) and welcomed additions to Windows 365 like Azure AD Join.

    In case you missed it, here is the Book of news containing all new cool things!

    I’ve gathered a list of my highlights down below.

    Device stuff

    My top 5 from a device perspective:

    I’ll also include a link to the summary of all things MEM related, you can find it here!

    Microsoft 365 stuff

    My top 5 from a Microsoft 365 perspective:

    • Microsoft Loop – The fluid framework has gotten a new name and practical application which integrates into other M365 services
    • Teams updates – It’s not Ignite without Teams updates. I think the coolest one was the Mesh support, but also Shared Channels which improved the experience when working with external parties
    • Updates to OneDrive – OneDrive for macOS will get an improved user experience and support for ARM. OneDrive will also get support for Universal Print
    • ClipChamp – Okay, this was a little outside the box, but Microsoft announced ClipChamp which is a new video editing app
    • Microsoft Viva – Microsoft Viva, which I found very interesting after the spring edition of Ignite, has reached General Availablity.

    And of course, the overview for Microsoft 365 which you can find here!

  • CloudLAPS on CloudPC?

    So I’ve been playing around a bit with Windows 365 Enterprise and thinking about “okay, what cool things should we try?”.

    First step is of course to set it up and I thought about writing a guide about that. Halfway through my guide I realised that the one written by Christiaan Brinkhoff was far superior to mine, so go check his guide out!

    One thing came to mind however, could you get CloudLaps to work on a Cloud PC?

    Of course, we needed to try this even though I’m not a 100% sure that you need it.

    What CloudLaps does it that it provides your PCs with a unique, randomized password for the local admin account on the machines which is rotated on a given interval (default is every 3 days). By using this functionality, all your PCs will have unique passwords for their local admin accounts meaning that if this is handed out to an end-user or support personal, the password will stop working when the password is updated.

    The Cloud PC configuration

    If you have not yet implemented CloudLaps, have a look at the guide in the link above, but if you have it in place, you are ready to go.

    Since CloudLaps is built on proactive remediations in Microsoft Intune, you will need to make sure that the Cloud PCs are included in the assignment by using (or adding) a group containing all your Cloud PCs. Windows 365 Enterprise gives you the benefit that Cloud PCs are being automatically enrolled into Microsoft Intune which gives you the possibility to manage them directly without any further actions!

    In this example, all the Cloud PCs are included in the same group as all other PCs since we want all these PCs to have the same settings. This was done by adding an extra rule to our Dynamic Group.

    device.deviceModel -contains "Cloud PC Enterprise"

    No additional configuration needed!

    The outcome

    The outcome of this test was as expected, worked perfectly fine!

    A local admin password is populated in the CloudLaps portal, and I can use it on the machine to elevate my rights on the Cloud PC.

    Since you can use the exact same configuration for Cloud PCs as physical PCs, you will not need to separate how you manage the Cloud PCs. They are just another PC, but in the cloud!

  • Trying to understand Windows 365

    Trying to understand Windows 365

    You know, devices and new stuff are always fun. But what if you would provide a kick-ass, safe, Windows experience on any device without having to invest in infrastructure or administrative work? To semi-quote on of my all-time favourite TV-show: “Haaaave you met W365” (it’s supposed to be Ted, not W365).

    Have You Met Ted GIFs | Tenor

    I remember hearing about the new Windows Virtual Desktop at Ignite 2018 and thinking “Wow, this is sooo cool! Finally, someone simplified the complexity of VDI solutions a little!”

    It was not perfect, but it had potential! Up until then Azure hadn’t really provided any good solutions for Windows 10 based clients. You could run Windows clients if you imported an image, but it was far from great. It was more for playing around with Windows.

    Windows Virtual Desktop later became Azure Virtual Desktop, but it required a decent amount of work to set up initially. Don’t get me wrong, it’s super awesome given the flexibility it provides you could run anything on it. But it comes with a big challenge, especially if you are not familiar with VDIs. It requires a decent amount of configuration before you can get going. The Azure Virtual Desktop is however GREAT for scenarios where users don’t need a dedicated machine, their session can run in a host pool to make the most out of your Azure resources!

    Windows 365 enters the stage

    Microsoft announced Windows 365 during the summer 2021 (I remember noticing it during my summer vacation). I had a really hard time positioning this compared to the AVD solution, when should I pick what?

    But finally, the coin dropped for me. Windows 365 is for when you just need a virtual computer with no super specific needs (since the configurations are a set list). Like for instance you have a consultant working in your company who already has their own device which they can run a Windows 365 machine on, instead of you having to source and ship a physical device.

    Current sizing of Windows 365

    It also has the quite nice feature of being simple to assign and setup since you assign a provisioning policy and a license to the end user, and you are good to go! This is truly VDI made for the masses if you ask me.

    Of course, there are things you need to setup if you are running this in an enterprise, such as the network connectivity and on-premises domain connection (yes you sadly still need an on-premises AD and hybrid join for this in the enterprise setup, but AAD only is coming). You would also need to setup management profiles in Microsoft Intune or just reuse the ones you have for your physical machines. In Microsoft Intune, the Cloud PC is just a computer amongst all the others, but model will be Cloud PC instead of e.g. Surface Laptop.

    Coming from a device management background, I also really love that you manage everything from the Microsoft Endpoint Management portal, no other fancy tools needed or a need to find your way around the Azure portal!

    Who should use a Cloud PC?

    So, who is the Windows 365 Cloud PC for really? Saying everyone is not the wrong answer, but when you face reality and leave the marketing slides behind, you will notice that most of your users don’t need this. But some absolutely do, and those are in this case the interesting users.

    In the perfect of worlds, you could easily “only” have Cloud PCs and let your users use whatever device they want to access those. In an enterprise scenario, with a lot of history, which would not be feasible. At least not for your FTEs to start with unless you provide them with more lightweight devices and provide a beefier Cloud PC to do their work on.

    In the scenarios I mostly have seen and discussed, there is one main use case we are discussing, and that is consultants who already has a computer (or device for that matter) and instead of providing them with a 5-year-old computer which got put in the spare pile you give them a virtual machine which they can access from their PC. This scenario is also valid for providing consultants with a more basic PC and “beef” it up using a powerful Cloud PC.

    One thing I find useful is that you can run either Windows 10 or Windows 11 on it, you select the image yourself. This means that you could potentially have your physical machine on Windows 10 but run your virtual machine with Windows 11. This could be beneficial in a transition period from Windows 10 to 11 if you want to do some application testing without needing to re-install computers.

    I’ll keep exploring Windows 365, and I’m really hoping Ignite will bring more cool stuff around for it!

  • Intune for noobs – Intro

    I’ve been thinking about doing something more educational for a while now and I think this will be a great start to that. Writing a guide on how to setup your own Microsoft Intune lab. We will take shortcuts and do dirty tricks, just to get going. So please don’t use this as an implementation guide in a real environment. We will also skip all 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!

    Here are the links to each part, and they are also published in the blog further down in the feed.

    Sharing is caring, so my idea about this guide is to simply help you get started on your own Microsoft Intune journey and learn what it is and what it can do!

    With this base, you can build further on your lab environment as you grow with the concept!

    Enjoy!

  • Intune lab for noobs – part 1 // Pre reqs

    I’ve been thinking about doing something more educational for a while now and I think this will be a great start to that. Writing a guide on how to setup your own Microsoft Intune lab. We will take shortcuts and do dirty tricks, just to get going. So please don’t use this as an implementation guide in a real environment. We will also skip all 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!

    What do I need?

    There are a few things you will need in order to get started:

    • An Azure AD tenant
    • Microsoft 365 or EMS licenses (E3 or E5)
    • Hyper-V or some other virtualization platform
    • A Windows image
    • A mobile device or two
    • A Google account
    • An Apple ID

    There are more things, but this is a good start.

    Getting a tenant

    This can sound like the most cumbersome and expensive part, but it doesn’t have to be. Depending on your level of commitment, there are different ways to go at this. The Azure AD itself is free of charge, but you will need licenses to run Microsoft Intune. You could either buy these or get a test tenant for free from Microsoft. You can either get a one-month free trial from the Microsoft 365 info page which isn’t persistent if you don’t buy the license once it has expired. You can also sign up for a free trial of Microsoft Intune from Microsoft Docs, then enable a 90-day free trial of Enterprise Mobility + Security E5 if you go to Devices > Enroll Devices > Windows Enrollment > Automatic Enrollment. This will include everything you need to test Intune, but no Microsoft 365 services.

    The best option is to sign up for the Microsoft 365 Developer program and get a tenant and licenses which will be renewed every 90 days if you sign in at least once.

    My recommendation for your lab is to get the later one. You will want something that sticks around for more than 30 or 90 days.

    By using the Microsoft 365 Developer program, you can also get sample data (users, generated emails, SharePoint sites) to make the environment more realistic with minimal effort.

    The setup process is simple, you will need to register with Microsoft and then you will be able to create your tenant. Microsoft has a good step by step guide which you can find here!

    Give your tenant a cool name (or just something you remember) and you are ready to go!

    Once you have your tenant setup, use your admin account to sign in to endpoint.microsoft.com and BAAAM, you are now in the Intune portal!

    Hyper-V or another virtualization platform

    The reason we want a virtualization platform is to spin up some virtual test clients. There are numerous ways of doing this, but for small scale this is the simplest way.

    If you are using a Windows based machine, you can enable in different ways. Easiest way is to simply run the PowerShell console as admin and run the following command (something I learned by writing this post):

    Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

    When the command is successful, reboot the machine.

    If you are not comfortable with PowerShell, you can simply enable it in the “Turn Windows Features on or off” section of Programs and Features in the Settings app.

    We will come back to how to use Hyper-V in a later section were we setup Windows management.

    Getting a Windows image

    There are a lot of different ways of getting a Windows image for testing purposes. If you have an MSDN/Visual Studio subscription, you can download this from your subscription repository of download. But if you don’t have that, the easiest way of getting a Windows image is to simply download it from Microsoft using the Media Creation Tool found here.

    Once you have downloaded and started the tool, you can follow the on-screen wizard to obtain the image.

    First, accept the terms and conditions page, then make sure to select “Create installation media”.

    Select the language you require and make sure you get the 64-bit version (you don’t need 32 bit).

    Select that you want this as an ISO-file

    When you press next, it will ask you where you want to save the file and the download will start.

    Mobile devices

    Depending on what you want to do with your lab, I suggest you get at least one mobile phone. This could be any phone which is fairly up to date (iOS 12 and higher or Android 6.0 or higher).

    For my lab, I’m using a cheap Samsung Galaxy A20 that I got on a sale which is running Android 10 and an iPhone X (which is my primary personal device). However, if possible, I strongly recommend using secondary devices for your lab, at least if you want the wipe features.

    Google Account

    Why do we need a Google account in the Microsoft world? It’s simply to activate and be able to use the Managed Google Play store and activate enterprise features. This can be a regular Google account; I’m using one that I’ve had for ages (in the real world make sure to use a dedicated which is NOT personal). If you already have a Gmail account, that will do just fine!

    If you plan on sharing this environment with more people, use a dedicated account.

    Apple ID

    To enroll Apple devices in Microsoft Intune, we need to obtain a certificate from Apple. For that, we need an Apple ID.

    Same goes here, for your personal lab you can use an already existing Apple ID which is not dedicated for the purpose (for real world use, setup a dedicated account). We will use this account later when we configure iOS/iPadOS management!

    Ending notes…

    And that’s about it for pre-reqs to setup your own Microsoft Intune lab!

    In the next step, we will do some basic configuration of your brand-new Microsoft Intune tenant!