Okay let’s face it. The Windows 365 app is just ONE more app to consume our Windows 365 or Cloud PC. But it brings something to the table.
With the Remote Desktop app that we have all learned to connect to our Cloud PCs, AVDs or published apps. And it’s a great app, especially if you work as a consultant like I do and have multiple environments that you connect to, I connect to 2-3 different tenants on a weekly basis. But the Remote Desktop lacks key features when it comes to Windows 365.
If you have ever used Windows 365 through the browser, you know what I’m talking about. There is NO WAY to reboot, restore or troubleshoot a Cloud PC from within the Remote Desktop app, you can simply just connect to your session, and for anymore “advanced” user action you have had to rely on the browser.
Enter the Windows 365 application.
In the Windows 365 app you are able, as in the Remote Desktop app, to connect to your Cloud PCs which are connected to your signed in account. This is the caveat though. Only machines available for the signed in account are displayed, if you are running multiple accounts (like I do) you will have to switch accounts.
However, the features in the Windows 365 app make it worth it, since I can fully control my Cloud PC from within the app, and I don’t have to rely on the website to perform addition actions like I needed previously.
If you have ever used the Windows 365 website to connect to your Cloud PC, you will recognize this experience. The layout is familiar to the web, but you get all the benefits of using the app (like multiple monitors, smart sizing, and Teams optimizations), but you also get the user actions previously exclusive to the web portal.
Working with the Windows 365 app compared to the Remote Desktop app is for me as an end-user not really any different, other the account part mentioned earlier. But if you only use one account, like most are, you will never notice this difference.
You should really check out the new Windows 365 app which is in preview. You can find it on this link or if you search the Microsoft Store for Windows 365. But like always with preview things, be aware that it’s in preview!
So, 2022 was the year Microsoft Ignite was FINALLY a physical event again, and for the first time on Microsoft home turf in Seattle.
Being an ex-Microsoft FTE, this gave me major flashbacks to TechReady, which was an internal training event Microsoft used to host in Seattle. Same location as Ignite, just no hilarious videos with Norm Judah encouraging everyone to fill out the evaluations.
Ignite was different this year since it’s a hybrid event, and the first big such for Microsoft which means that they are still trying out the concept.
Overall, I had a lot of fun. For me, meeting up with peers and having the time to focus on the content is important, if sessions are digital or physical doesn’t really matter. Some sessions made more sense virtually. But in-person sessions are usually the best, and you could really tell that people wanted this. Especially the big keynotes are always more fun in-person.
But I was missing the expo where you can meet vendors or just mingle with Microsoft people, there wasn’t really any space for this, except for an awesome Surface expo.
However, the width that the “old” Ignite had was missing and the break-down sessions were missing. The feeling was that this hybrid thing was more focused on people attending remote, and people on site were more the live audience.
There was a lot of news and I’ve picked out the ones I found most interesting.
Just before Ignite kicked off, there was a Surface event where some news around Windows 11 was released. Check it out here:
This was released a few days prior to Microsoft Ignite, but Microsoft 365 and Windows 365 will be supported on Meta Quest devices, providing a new kind of experience for productivity in the Metaverse.
This means that you will be able to run a fully supported productivity setup in the Metaverse with e.g., Microsoft Teams and Windows 365. Windows 365 is not yet released for Metaverse, but this indicates strongly which direction VR is heading now.
The Remote Desktop app has for long been the go-to application for your VDIs, but now for Windows 365 you can use the brand-new Windows 365 app which is now in public preview. This app aligns more with the Windows 365 features found on the web portal but with the advantages of the desktop app! Read more here:
Getting messages out to end-users is always a struggle within IT. There is a new feature for Windows 11 where you can send organizational messages, natively in Windows, to your users instead of sending them email using Microsoft Intune coming in November to Windows 11 22h2. Read more here:
The brand Microsoft Endpoint Manager or MEM is going away. The new product-family name will be Microsoft Intune where a bunch of things will be included, Configuration Manager amongst others. You can read more about the anoncment here:
Enabling local admin for users on a temporary basis has been a struggle with Intune managed devices. Old solutions relying on attributes in the on-premises AD do not work and there aren’t really any “best practices” established around this yet.
However, Microsoft is looking to solve this with the Endpoint Privilege Management which is in public preview. Read more in the link above.
Automated app patching as add-on
Keeping applications up to date is something that many stuggles with, and there are products around to solve that. Now Microsoft are throwing themselves into this game as well, which makes a lot of sense. This is just briefly mentioned in the “Further value and looking forward” part of the article, but if they are able to deliver on a native Microsoft Intune feature for this, that would simplify things a lot!
Some of you might have seen something called Microsoft Dev Box flash by in your feeds. Something called Dev Box doesn’t really sound like something device-related, it sounds more like something your developers would care about. They probably will, but there is a big reason you should care too.
Microsoft Dev Box is a new tool in the toolbox for you, this time to provide Cloud PCs to your developers or such. There are many similarities between Dev Box and Windows 365, but also Azure Virtual Desktop (AVD). However, your developers can themself deploy computers to your tenant based on a template that you create, which means that a developer could create a new test PC when they need one without really involving you as an admin.
Microsoft Dev Box is not licensed-based like your Windows 365 Cloud PC, instead, it’s consumption-based like an AVD. But you have the simplicity of setting up new computers from Windows 365, so it’s almost like a mix of the two. However, the user target group is different since you can get more powerful machines that are deployed by the user themself.
You can read more about the Microsoft Dev Box here, and what Microsoft calls a “Dev Workstation in the cloud”.
Getting started with Microsoft Dev Box
To get started with Microsoft Dev Box you need the following:
An Azure subscription
Windows licenses (typically as part of your EMS or M365 license)
Setting up the Microsoft Dev box is completely taken care of in the Azure portal, not the Microsoft Endpoint Manager admin center.
To start off, you need to head over to portal.azure.com and make sure you have an active Azure subscription to provision this. Then, search for Microsoft Dev Box.
This is where your different environments will be hosted. You can have multiple Dev Boxes set up for different parts of the organization. In each Dev Box, you can also create different projects. In the real world, you would probably configure this in a landing zone specifically set up for your dev-users who will work on certain projects.
The first step is to create a new Dev-center by pressing “+ Create” in the Microsoft Dev Box pane. Select what subscription and resource group you want to deploy this too and give your Dev-center a name. You will also need to select an Azure region where your machines will be hosted. Since this is a preview, the selection of what Azure data center regions are available is limited. Once you have selected this, press “Review + Create” and create your Dev-center.
Once the Dev-center has successfully deployed, you need to create a Network Connection where you define if your Dev Box PCs should be hybrid-joined or Azure AD joined. Head back to the Microsoft Dev Box pane and select Network Connections (or search Azure for Network Connections).
Select “+ Create” to create a new Network Connection by selecting what subscription and resource group to use. Also, give the network connection a name and select what Azure Vnet you would like to use (if you haven’t created a Vnet already, you will need to do that first). Press “Review + Create” and create your Network Connection.
In this example I’m using Azure AD joined devices as selected as “Domain join type”. If you want to use Hybrid join instead, you will need to add some additional information about your domain.
Once you have created your Network Connection, you will need to create a project. This is where gather each project you would like to use the Dev Box PCs in and define what machines are available by creating Dev Box pools. In the Microsoft Dev Box pane, select Projects.
To create a new Project, click “+ Create” and select what subscription and resource group you want to use. Select which Dev-center you would to use and give your project a name. Press “Review + Create” and create your Project.
Now we need to define what machines are available for our users by creating a Dev box pool. There are a few different “sizes” available, and you can read more about them on Microsoft site about Microsoft Dev Box, where you can find out the pricing for each.
To create a new Dev box definition, navigate to the project you created earlier and select Dev box definition on the bottom of the left-hand menu.
To create a new Dev box definition, select “+ Create“. Give your definition a name and then select a Windows image to use, in this example we will use a Microsoft-provided image, but you could upload your own if you would like. Make the appropriate selections of what size you would like on the machine and click “Create”.
The next step is to create a Dev box pool in your project, do this by navigating to your project you created earlier and selecting Dev box pool.
Create a new Dev box pool by pressing “+ Create” and giving your new pool a name. Select the Dev box definition created earlier and also the network connection. You will also need to confirm that your organization has Azure Hybrid Benefit, you can read more about what that means here.
Once you have filled out this, create the dev box pool by clicking “Create” at the bottom of the page.
The last thing we need to do is to assign users the rights to consume machines and work in our project. Prior to this, it’s a good idea to create an Azure AD group that will contain our users.
To configure the access to our project we will head into “Access control (IAM)” in our project.
To add a new assignment, click “+Add” and select “Add role assignment”. In the list of roles, find and select the “DevCenter Dev Box User” role and press next.
On the next page, add your Azure AD group which contains the users who should have access to the project. Once you have added this group to “Members” press “Review + assign” to finalize your role assignment.
You can verify that the assignment was successful by looking in the list for the role and validating that your group is listed.
And that’s it! You have now successfully prepared your environment to use Microsoft Dev Box!
For users to create new Microsoft Dev Box machines, they will need to access devbox.microsoft.com and sign in with their user account.
Once signed in, the experience is similar to the Windows 365 end-user portal, but there is a new button called “+New Dev box” where users can deploy machines themself.
Once you click that button, a fly-out will appear where you can see the specification on the machine you are allowed to deploy (based on the definition we made earlier) and you are asked to give your machine a name. Once you have given the machine a name, which will be the name displayed to you for your convenience (MEM will show a CPC-xxxxx name), press “Create“.
The creation of a machine will take somewhere around 30-90 minutes. Once the machine is done, it will show in the portal where you are right now but also in the Remote Desktop app where you have all your other Windows 365 machines. A bonus fact is that it will also appear in the Windows 365 portal, marked as Dev box, but you cannot create new machines from there.
Once the machine has been created, you can connect to it and start using it!
One thing you will notice if you are deploying Cloud PCs is that the Enrollment Status Page (ESP) from Windows Autopilot will or might appear when a machine is being set up. I’ve seen numerous instances where the ESP has failed causing the Cloud PC to lock out the user at the initial start. This is usually fixed by reprovisioning, but an unnecessary call to the service desk can cause frustration with your users and your administrators.
The ESP is not an important part of the Windows 365 provisioning in most cases, hence it can be disabled by a custom policy.
Create the policy
To create a custom configuration policy, go to the Microsoft Endpoint Manager admin center (endpoint.microsoft.com) and navigate to Devices > Windows > Configurations Profiles.
Select to create a new profile and select Custom as template.
Give your profile a name based on your naming convention and press Next.
Select to target All devices, but filtered to only target Windows 365 devices. You can read more about how to do that in this blog post about filters.
Finish the wizard by clicking Next until you reach the last step, then click Create.
You have now successfully created a configuration profile that will skip the ESP for all your Cloud PCs.
The ESP is something that in Windows Autopilot is very useful, but for Windows 365 it’s not crucial. This will also reduce the risk of random errors during provisioning.
Applications that are needed before the user starts working can be assigned using the assignments to “All Devices” and filter out your Cloud PCs since this will evaluate a lot faster than Azure AD groups.
As all swedes, summer means well-deserved summer vacation for me. For me personally, this means that I almost completely check out from work stuff for a few weeks.
So playing catch-up with what happened during the summer is always fun! I will cover some of this news in an upcoming post, but I thought I would gather all this for you in one place to start with!
I’ve gathered some of the highlights I’ve found during the summer.
Have I become an MVP!?
So this is kind of a big deal for me, and something I’ve been working towards for a while. I’ve been awarded the MVP titles within Windows and Devices for IT, and I am part of the Windows 365 MVP team!
I’m very happy, honored, and excited to get this award since it’s been something that has been my long-term goal for a while. So this is huge for me personally!
This was something that was announced as a preview this spring and went to general availability during the summer. Windows Autopatch is a way to have Microsoft take care of patching and servicing, making sure your devices are always up to date! I will write a blog post about this in the upcoming weeks, but until then you can read more about it here: What is Windows Autopatch? – Windows Deployment | Microsoft Docs
Ignite is back on and as a hybrid event!
Microsoft announced during the summer that they will host Ignite again where you can attend IN PERSON, but also remotely if you prefer. For me personally, attending Ignite remotely is always a challenge since it’s hard to take the needed time to dedicate to attendance due to your everyday commitments. So being able to attend in person again is great!
Windows Information Protections (WIP) being depricated
With Windows 10, Microsoft introduced Windows Information Protection, WIP, which was formally known as Enterprise Data Protection (EDP). Now WIP is being sunset and transitioned over to Microsoft Purview over time. According to the blog post below things will move gradually over to Microsoft Purview. You can get started today with a free trial. If you are using E3 licenses, there will be an additional license needed but with E5s it is included.
“Beginning with Windows 10, version 21H2, feature updates for Windows 10 release are released annually, in the second half of the calendar year, to the General Availability Channel. They will be serviced with monthly quality updates for 18 or 30 months from the date of the release, depending on the lifecycle policy.” – Windows 10 – release information | Microsoft Docs
News in Microsoft Endpoint Manager
There have been a lot of updates around macOS and Settings Catalog this summer, but also a few updates around Android, iOS, and Windows.
This is a well hidden gem in Microsoft Endpoint Manager (MEM). Filters. I’m not to sure that all of you knows what this is. Maybe you have seen it when setting the assignments for a profile.
Or when going to Tenant Administration.
But what are filters?
Filters in Microsoft Endpoint Manager
Filters in MEM is a way to assign profiles, applications and much more in MEM using the built in “All users”/”All devices” groups or a larger target group, and then filtering out based on specific conditions. You create the filters and set the conditions for the filters.
You can apply filters on
Filters basically singles out users or devices from a larger group of devices, just like filter does. You can re-use the same filter on different assignment groups and get different result for your policy.
The benefits with using filters instead of several dynamic groups is that the filters are evaluated instantly, which makes applying things with them a lot faster then having a dynamic group needing to process which members it should have.
One example could be that you want to be able to single out only Windows 11 computers to apply a specific policy just to them.
Creating a filter
To use a filter, you must first define the conditions of it by going to the MEM admin center (https://endpoint.microsoft.com) and navigate to Tenant administration > Filters.
To create a new filter, press “+ Create” and give your filter a name and select what platform to target. In this example, we will create a filter which will filter out Windows 365 Cloud PCs running Windows 11.
In the next step, you will need to create the conditions for your rule. Since I want to create a filter to single out Windows 365 Cloud PCs running Windows 11, I will add conditions for this by stating that osVersion should start with 10.0.22 (which is the easiest way to identify Windows 11), and that the manufacturer equals Microsoft Corporation, and that model name starts with Cloud PC.
You can also write your own syntax instead of using the built in values.
The easiest way to find the information for your filters is to go to Devices > Windows > Windows devices and search for a device which meets the requirements for your filter. Click the device and select Hardware in the menu, that will show you the information you need.
Once you have configured your rule, you can click the “Preview devices” at the bottom of the filter configuration to validate that your filter is doing what you wanted.
For this filter, I want to be able to select the Cloud PCs running Windows 11, which you can see here that it was able to find.
When you are happy with your filter configuration, click next followed by create.
Using a filter
You can use filters in a lot of different places in MEM. To see what’s currently supported to use filer, have a look at Microsoft Docs. New applications of filters are added constantly.
As of now, I want to deploy and app to only my Cloud PC running Windows 11. I want to make this application available for all my users, but only if they are using a Cloud PC running Windows 11.
The first thing I do, is to add the built in “All users” group to the “Available for enrolled devices” segment under Assignments for the application.
Next, I click on the blue text “None” under Filter mode. To use your filter, you first need to select how you want the filter to behave. You have 3 options.
Do not apply a filter
Include filtered devices in assignment
Exclude filtered devices in assignment
In this case, I want to include my Cloud PCs running Windows 11, so I select the include option. Next step is to select the newly created filter called “Cloud PC Windows 11”. Once I have selected the filter, I press “Select” at the bottom of the screen.
You will now notice that the filter has been applied to our assignment.
Now only my Cloud PCs running Windows 11 will be able to install the application.
Filters are a great addition to MEM and doing assignments, since you can target on a wider group and select just a few devices from that group. You could also make sure that only certain things gets applied to a users device which fulfills your requirements. One such scenario could be that you wish to enforce installation on a users device if the ownership is set to “Corporate” but make it available if ownership is set to “Personal”. There are a lot of different scenarios where this could be super handy!
The best thing is however that applying things using the built in “All devices” and “All users” group are usually a lot faster, and you don’t end up in a scenario where the user or device was not added to the group for a mandatory application. You can then filter out only specific devices from that larger group.
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:
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
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!
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.
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.
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 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!
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 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.
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.
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).
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.