Windows Autopilot is a really nice thing, I think you all are familiar with this by now. But the process to add devices, and adding devices without being an administrator, isn’t really that straightforward with exporting CSV’s and such. The way I usually import the hardware IDs is by using the Get-WindowsAutopilotInfo.ps1 PowerShell script.
The built-in roles in Microsoft Endpoint Manager do not give you rights to add or remove devices, you need to create a custom role for this.
There are two options here, you could either duplicate an existing role such as the Help Desk Operator role and add the Enrollment Programs rights which you will need, or you can create a new custom role.
Creating a custom role for this could be very useful if you want to provide the possibility for your e.g. deskside support personal or a hardware coordinator to upload hardware IDs if this was not done by your hardware vendor.
In this example, I’ve created a new role called “Windows Autopilot Operator”.
Create a new role
Head to the Microsoft Endpoint Manager portal and navigate to Tenant Administration > Roles and click “+ Create” (or mark the role you want to duplicate and click the duplicate button).
Give your new role a name such as “Windows Autopilot Operator”.
Click next and find the heading “Enrollment programs” and enable:
Sync device
Delete device
Create device
Read device
Click through the wizard and create the new role.
We now need to assign this to a group of users. When the role is created, click on the role and go to Assignments.
Click “+ Assign” and give your assignment a name, such as Deskside Support or something describing what kind of users will be in this assignment.
Click next and add a group containing your users.
On “Scope groups”, add all users and all devices.
Complete the wizard and you have now created an assignment. If you wish to add more assignments, you can just click the “+ Assign” button again and repeat the steps.
Importing the hardware ID
We can now get started with importing the hardware ID into our tenant! You can do this either from the Out of Box Experiance (OOBE) process or in runtime. Since I think we all know how it works in run time, let’s have a look at what it looks like during OOBE.
In this example I’m using a virtual machine, but you need to have passed the Wi-Fi selection part if you are doing this on Wi-Fi since we need internet connectivity.
During the OOBE process, press SHIFT + F10 (don’t forget FN if you have such keyboard). Type powershell and hit enter.
You have now launched PowerShell in your terminal, and we can get going with executing the following three lines. You will during the have to confirm that you want to install the script, just press “y” and enter when asked to.
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -online
When you run the third line of PowerShell code, you will be prompted to sign in with you account. If this is the first time you are running the online version, you will need to consent the sign in first (it will show up on the screen).
Once signed in, the process will start and the Hardware ID will be harvested and uploaded to your tenant.
This process usually takes a few minutes. Once completed, turn off the computer.
If you have a look in your Windows Autopilot devices list in the Microsoft Endpoint Manager by going to Devices > Windows > Windows Enrollment > Devices you can see that the devices has been uploaded.
Depending on how you are assigning deployment profiles, this will usually be assigned within 15 minutes. Once the profile has been assigned, you can start the computer again and enroll it!
Bonus tip
If you are using group tags to assign profiles like I do in my lab, you can actually do this while running the script by adding “-GroupTag ‘[YourTag]'” at the end of the script.
This will automatically add the group tag to the device entry, and if your automated profiles assignment is depending on this everything will happen automatically!
One question I get a lot from people that are fairly new to Microsoft Endpoint Manager is “which function should I use to reset a Windows device?” and what the different buttons actually do.
So here is a little cheat sheet what the different type of reset of a Windows device does. Some also applies for other platforms, which I will mention below.
One thing you will notice when clicking these options in the portal, you will always have to confirm your selection.
Retire
This is the first option you will glance at when looking at the remote actions available in the ribbon.
Retire is not a Windows unique feature and is maybe mostly used in a BYOD scenario, but could be applicable for some corporate scenarios as well.
Retire means that you will remove the connection to Microsoft Endpoint Manager and at the same time remove all data YOU put there through MEM, such as apps, profiles, policies etc. You could basically call this an “unenrollment” of the device.
A usefull scenario would be when a user is leaving the comapny and is keeping their iPhone which has been been enrolled through a more BYOD scenario. You will only remove corporate data, but leave all the users personal data.
This feature is maybe not that commonly used for Windows since these devices would typically be “locked” to the tenant using Autopilot. But for BYOD scenarios, this could be applicable.
Wipe
Wipe is just what it sounds like. You will wipe all data from the device and put it back to factory defaults. This feature can be used on other platforms too. This is the feature I most frequently use, especially when testing things and needing to enroll things. This is equal to doing a factory reset from within the operating system. This is perfect for when a device is being decomissioned.
For Windows you get a few more options when triggering the option:
Wipe device, but keep enrollment state and associated user
Wipe decice and continue wipe even if device loses power
Typically, you dont need to select any of these but there are some cases where it could be usefull.
The wipe will also remove the device from Microsoft Endpoint Manager, IF not the first option is selected. The Azure AD object will remain and also the Windows Autopilot object, if you are using Windows Autopilot.
The “Wipe device, but keep enrollment state and associated user” will reset wipes all policies, but keeps user accounts and data, but not user files. It will reset user settings back to default. and resets the operating system to its default state and settings. This basically means that the device will be put back into the same state it was when it was first enrolled. If you are using Autopilot, use Autopilot reset instead.
The “Wipe decice and continue wipe even if device loses power” means that the device will continue to try to wipe untill its successfull. This is great for instance if the device is lost and you really want to make sure that the device is wiped for corporate data. This could in worse case leave the device unbootable if something happens. So use it with causion!
Delete
The delete option is exactly what it sounds like, you will delete the device form Microsoft Endpoint Manager. However, this will only remove the link and all data on the device will remain. However, the next time the device connects to Microsoft Endpoint Manager, corporate data will be removed.
This is mostly usefull when cleaning up any stale objects. Cleaning up stale object could with ease however we automated by using the automated clean-up rules in Microsoft Endpoint Manager found in Devices > Device clean-up rules.
Fresh start
Fresh start is a farily unknown feature in Windows which was introduced back in 2017.
What fresh start does is to remove any pre-installed software by the manufacturer (OEM) which is usally there. The computer will then run a more “Vanilla” version of Windows after the Fresh start.
When triggering this reset, there is an option to retain the user data, including enrollment, which would have little to no impact for the user. If this option is not selected, the device will be reseted and start up on the OOBE screen.
This could be usefull for cleaning out devices which has been delivered with an OEM image instead of a pure Windows image, or if the device is not purchased through your regular channels and getting the “wrong” image which includes pre-installed software.
Autopilot reset
Last out is the Autopilot reset, which is a really useful option if you are repurposing a computer from one user to another.
What Autopilot reset does is that it will restore the device back to a business ready state, meaning that all personal data is removed but all corporate settings are re-applied. All management information about the device is kept and so is the Azure AD object with all its device group memeberships. Doing this will also remove the primary user associated with the device.
When the device is handed to a new user, all they need to do is to sign in and the computer will finilize the setup for them. Users will not be able to use the device until the user enrollment parts are finilized, just like with any other Autopilot enrolled device.
Update: Got this pointed out to me by several people so I thought I would add this here as well. Autopilot Reset is NOT supported on Hybrid Azure AD Joined devices.
Key take aways
I hope this brings some clarity to the different remote actions and that you can figure out which to use when.
The ones I most commonly use are:
Wipe when testing things in my lab or completly changing what the device is used for, e.g. assigning a different Deployment Profile to the device.
Delete when I for some reason have ghost/stale objects
Autopilot reset when a device is being repurposed or changing user
The other ones are ofcourse useful, but maybe not something I frequently use.
HoloLens got to be one of the cooler devices out there, but probably also one of the lesser-known devices how to manage.
What is a HoloLens really?
HoloLens is Microsoft’s device aimed for Mixed Reality, but at heart, it’s actually a Windows-based device but done in a more modern way. This means that the support for legacy protocols is limited, but also that the level of built-in security is maybe a bit higher than on your Windows-based PC. You can read more about the HoloLens as a platform here.
Given that it’s a Windows device, we can manage it using basically the same policies in Microsoft Endpoint Manager (MEM) as you would for the rest of your Windows devices. A lot of baseline profiles could be re-used (or duplicated) with ease which simplifies the configuration a bit.
There are a few things to keep in mind when it comes to Microsoft HoloLens 2, which has had an impact on the designs and implementations in my experience.
It doesn’t support EPP/EDR software of any kind
You can only run UWP based applications
You will need additional licenses to run e.g. Remote Assistance
HoloLens 2 as a kiosk
There are a lot of different applications and ways to implement and use a HoloLens 2. In this post, I’ll focus on how to set up the HoloLens 2 as a multi-app kiosk, but with user sign-in, using Microsoft Endpoint Manager.
Importing the device into Windows Autopilot
If your vendor or retailer didn’t import the HoloLens hardware ID for you, you can do this by following these four simple steps:
While the HoloLens 2 device is powered on, press and release the Power and Volume down buttons together to trigger the hardware ID and diagnostic log collection process.
Connect the HoloLens 2 device to a PC using a USB cable so that it shows up in File Explorer.
Browse to Internal Storage > Documents and extract AutopilotDiagnostics.zip. This file/folder will contain a CSV file with a a file name that begins “DeviceHash…”.
Upload the CSV file to the Windows Autopilot service
In order to simplify our management a bit and be able to create a dynamic device group with only HoloLens devices, assign a GroupTag to the device such as “Hololens”.
Creating a device group for HoloLens
Like all things in device management, we are really dependent on groups. In this case, we will use a device group to target only our HoloLens devices.
You can create a new Azure AD group by selecting Groups in the left hand side menu in the MEM portal. Then select “New group“.
Give your group a good name and select “Dynamic Device” as Membership type.
Next, click “Add dynamic query” at the bottom and add the following rule syntax, but replace the word Hololens used here with the name of your GroupTag.
Click Save followed by Create to finish the creating of the group.
Setting up enrollment
First off, we need to create a new Deployment Profile for the HoloLens platform.
You will find the Deployment Profiles by navigating to Devices > Windows > Windows Enrollment and selecting Deployment Profile.
When you have selected the Deployment Profiles card, select “+ Create Profile” and choose HoloLens as the platform.
Give your profile a name in the Basic tab and press next. On the “Out-of-box experience (OOBE)”, you can really only have to change the name template if you are looking to use custom names for your HoloLenses. In my example, I’ve left all values to default. Press next to move to the next tab.
On the Assignment tab, select your HoloLens device group and press next.
Review your settings and hit Create to finish the creating of the deployment profile.
Creating a Filter for HoloLens
To make sure that we only target settings deployed towards users to their HoloLens devices, we need to create a filter we will use later on.
Navigate to Tenant administration > Filter. Create a new filter by clicking “+ Create” in the top ribbon. Give your filter a name, such as HoloLens, and select Windows 10 and later as the platform.
Since filters are kind of like dynamic groups, we need to add a syntax. The easiest way I’ve found to include HoloLens devices is to use our Deployment profile name, the attribute is called EnrollmentProfileName on the device. Enter the name of your Deployment Profile in the Value field.
Click next, then review and create the filter.
Configuring kiosk mode
You could basically already enroll your devices now and be done, but it will be like an unconfigured PC, your end-user will miss vital settings and applications.
Since this is a Windows-based platform, you can reuse or duplicate profiles you already have for Wi-Fi, certificates, and such. Not all profiles make a whole lot of sense to use on the HoloLens (such as settings for the Office suite or Chrome browser to give some examples).
The profile we need to create to set up the Kiosk-mode on HoloLens is a profile based on the Kiosk template.
Go to Devices > Windows > Configuration profiles and create a new profile by pressing “+ Create profile” in the top ribbon. Select Windows 10 and later as platform and Templates as Profile type. Scroll down and find the Kiosk template and click create.
As always, give your profile a name based on your naming convention on the basic tab and press next.
Based on your scenario, select either “Single app, full screen” or “Multi app kiosk” as kiosk mode and select “No” on the question if device is running S mode.
In my scenario, I will configure that users will use the device using their Azure AD accounts. Since I have to specify a group with eligible users, I’ve in my setup used a group containing most of my users meaning that all my users are allowed to sign in to the HoloLens. You can easily assign this to either a group of users or even a specific user. You can also add additional groups and/or users. Depending on your scenario, you can make different choices here.
Next up is to select what applications we will run on the device. This can be done by either selecting built-in applications or applications distributed through MEM. Keep in mind that Win32 applications DO NOT WORK on the HoloLens when selecting applications.
If you want to add built-in or system applications, this is done by adding the AUMID of the application. You can find all the HoloLens 2 applications AUMID on this MSFT Docs site.
In this example, I will add one built-in application and one store app. You add apps by pressing the “Add…” button under the Browser and application section.
When adding a app by using AUMID, you give the application a name (preferably what it’s called in the reference document) and the AUMID for the application.
When adding a store app, MEM will list the apps you have available for distribution. Also, keep in mind that you will need to make sure to target the application distribution towards the HoloLens group.
Leave the rest of the settings to the default value and click Next.
In order for the Kiosk mode to function properly when requiring Azure AD users to sign in, the profile needs to be targeted toward users otherwise nothing will happen in my experience. If you are notdoing personal logins, you can target this towards a device group.
In order to not assign the Kiosk-mode to all the user’s devices, we will need to use a filter to limit what devices the profile is assigned to.
On the Assignment tab, select your group of users who will be allowed to use the HoloLens and then press “Edit filter” next to the group.
Select “Include filtered devices in assignment” and choose your filter then press Select.
Press next and leave the Application Rules to blank and review and create your profile.
Enroll and sign in!
Now it’s time to enroll your device, simply start the device and follow the on-screen instructions.
What I’ve seen is that sometimes, the kiosk mode does not kick in on the first login after enrollment. If this happens, simply sign in and out of the device, this has done the trick for me!
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.
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).
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).
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:
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.
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.
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.
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.
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).
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”.
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.
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!
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.
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.
If we break down the string a bit you can actually filter this based on the specific compliance setting you want to find.
“https://graph.microsoft.com/v1.0/deviceManagement/” – This is the Graph connection string
“deviceCompliancePolicySettingStateSummaries/” – this defines that we want to look at compliance policy setting state
“Windows10CompliancePolicy” – this is the name of my compliance policy, so this will depend on your naming
“.ActiveFirewallRequired/” – this defines which setting we are looking at
“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:
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!
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.
A quite common discussion topic when it comes to mobile device management is the different approaches you can take. Therefore, I’ve written down a little something to try to simplify a little bit.
I’ve intentionally left out any preview features and user enrollment for Apple device to focus on the most common scenarios. I will look to cover that in a separate post.
There are of course more technical aspects to this, but from a high level this is something that is good to keep in mind!
Flow description Android
For Android, there are three different type of management:
Work Profile
Corporate owned fully managed
Corporate owned dedicated device
These are used for three different scenarios which are based on the requirements in the environment. Moving existing devices into Microsoft Intune management also affect which management method which should be used.
Personally owned with work profile
Personally owned with work profile is mostly referred to handle Bring Your Own Device (BYOD) scenarios. This is also often used to transition from either no management or legacy management into a Microsoft Intune enrolled device since it does not require the device to be reset to factory default before getting started.
To register a device using Work Profile, the user will need to download the Company Portal application from the Google Play store. When the application is downloaded and installed, user signs into the Company Portal app using the corporate credentials and follows the on-screen wizard how to enroll.
When the device is enrolled, a corporate container is created on the device where all corporate data is stored separately from the personal data. The user will see a new tab on the application pane called Work and all applications will have a small briefcase on them indicating they are work applications.
The IT department can only manage the Work Profile part but can put some restrictions and requirements on the device regarding e.g., PIN-code and Wi-Fi settings. Limited number of remote actions can also be performed such as PIN recovery or removal of corporate data. Applications in the Work Profile part is managed through a Managed Google Play store which is controlled by the Microsoft Intune administrators. Since the applications in the managed Google Play store are centrally managed and assigned, no corporate Google account is needed for the end-user to download and consume applications in the Work Profile.
The personal part of the phone still functions as expected by the user since data is separated and not allowed to stream between the containers.
Personally owned with work profile
Corporate owned fully managed
A corporate owned fully managed device is used where the company buys the device and there is a 1:1 relationship between device and user. To enroll the device as fully managed, the device needs to be new out of the box or been reset to factory default.
Devices could be pre-registered to the customer by the hardware vendor in Google Zero touch to ease the enrollment procedure for the end-user.
When the user receives the device, and the user follows the on-screen onboarding process for initial setup.
If the device is not pre-registered using Google Zero Touch, the user will be asked to scan a QR code which is unique to each customer and must be made available by the IT department.
During the enrollment, the user will be asked to login using their corporate credentials. The user will also be asked to set a PIN-code. As part of the enrollment in Microsoft Intune, configurations, policies, and applications will be applied to the device which has been assigned to the user and/or device.
When the enrollment has finished, the device is ready to be used by the user.
The fully managed device does not separate corporate and personal data as the Work Profile method does, which means that corporate data and personal data is mixed on the device. On the other hand, since the device is fully managed, the IT department has much more control over the device and applied configurations and policies.
Applications are centrally managed by IT, but the public Google Play Store can be made available for the end user. For applications distributed through Microsoft Intune, no Google account is needed for the end user.
IT can also perform remote actions on the device, such as PIN recovery or data removal.
Corporate owned fully managed
Corporate owned dedicated devices
Corporate-owned dedicated devices are used when there is not a 1:1 relationship between user and device, in a scenario where multiple users use one device. A good example of this is a kiosk device.
Devices could be pre-registered to the customer by the hardware vendor in Google Zero touch to ease the enrollment procedure.
When the user receives the device, and the user follows the on-screen onboarding process for initial setup.
If the device is not pre-registered using Google Zero Touch, the user will be asked to scan a QR code which is unique to each customer and must be made available by the IT department. These QR codes are unique to each enrollment profile and are valid for 90 days.
During the enrollment, no user sign in is required. Device will be automatically enrolled towards Microsoft Intune and no user affinity is applied. PIN-code can be set as part of the enrollment flow.
During the enrollment to Microsoft Intune, configurations, policies, and applications will be applied to the device which has been assigned to the device.
When the enrollment has finished, the device is ready to be used by the user.
Since the device is supposed to be dedicated to a specific task or function, the features in the OS are limited and can be locked by the IT department. Some built in applications can also be removed if needed.
Applications are centrally managed by IT using Microsoft Intune.
IT can also perform remote actions on the device, such as PIN recovery or data removal.
Corporate owned dedicated devices
Flow description IOS and iPadOS
Management of iOS and iPadOS does not have the same number of variations as Android. There is however a difference in how you can handle devices based upon if you use Apple Automated Device Enrollment or not.
For iOS/iPadOS management, there are two different ways of managing the device, personal or shared. Shared device is only applicable to iPadOS.
There are however two different ways of enrollning a device depending on if Apple Automated Device Enrollment is used or not.
Personal iOS/iPadOS devices with Apple Automated Device Enrollment
The default management of iOS/iPadOS devices are personal devices where there is a 1:1 relationship between user and device.
If Apple Automated Device Enrollment is used, the devices are pre-registered by the vendor in Apple Business/School Manager. Apple Automated Device Enrollment is used to simplify the enrollment process for the end-user and provide an additional set of control for IT.
When Apple Automated Device Enrollment is used, IT can control the first run experience for the user to remove unnecessary steps. This control will also ensure that the device will be enrolled. When a user receives the device, they will follow the on-screen wizard to get started and register their device.
During the initial setup, the user will be asked to sign in using the corporate credentials and the device will enroll in Microsoft Intune and received the applicable configuration, polices and applications which has been assigned to the user and/or device. When the setup is done, the device is ready to use.
IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device. If the devices are deployed in Supervised mode, there is also a possibility to trace lost devices and put them in a “lost mode” to prevent a lost device being used by an inappropriate person.
Applications are downloaded through the Apple App Store. For corporate applications and line-of-business applications, the Company Portal is used to initiate the download and the user will not require an Apple ID to download applications. IT can also do required installations of applications.
Personal iOS/iPadOS devices with Apple Automated Device Enrollment
Personal iOS/iPadOS devices without Apple Automated Device Enrollment
The default management of iOS/iPadOS devices are personal devices where there is a 1:1 relationship between user and device.
If Apple Automated Device Enrollment is not used, user will have to download the Company Portal application from the Apple App Store to enroll the device. Users then sign into the application using their corporate credentials and follow the on-screen instructions on how to enroll the device.
IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device.
Applications are downloaded through the Apple App Store. For corporate applications and line-of-business applications, the Company Portal is used to initiate the download and the user will not require an Apple ID to download applications. IT can also do required installations of applications.
Personal iOS/iPadOS devices without Apple Automated Device Enrollment
Shared iPadOS device
Shared iPadOS devices are used when there is not a 1:1 relationship between user and device, in a scenario where multiple users use one device. A good example of this is a kiosk device.
To use the Shared iPadOS scenario, Apple Automated Device Enrollment needs to be used. Devices are registered in the Apple Business/School Manager to connect the device towards the customer.
When a device is to be registered, a user or coordinator starts the device and follows the on-screen instructions. No sign-in is required during this process since the device will not have user affinity.
During the enrollment, the device will receive configurations, policies and applications which has been assigned to the device.
When the registration is completed, the device is ready to use.
IT can manage configuration, policies, and applications centrally and perform some remote actions such as PIN recovery, data removal or resetting the device.
Applications are centrally managed by IT and are installed automatically by assigning them in Microsoft Intune without user interaction.
Shared iPadOS device
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
