Since we now have successfully set up and provisioned Windows 365 Frontline in our environment, we need to add some additional layers of configuration to make operations as smooth as possible, and especially to make sure that we use the licenses in the best way possible.
With Windows 365 Frontline, each license is reserved as long as the user has the session running. This means that users could potentially have active sessions but are idle which would result in them locking one license.
Since users might forget to end the session, you can configure a policy that will end idle sessions for the end-user.
Create the policy
To create the policy, head over to Intune (https://intune.microsoft.com) and navigate to Devices > Windows > Configuration profiles and select “+ Create profile“.
Select the profile type to be Settings catalog and press Create.
Give your profile a name that makes sense to you and your organisation, I will go with something that follow my name standard for my environment that indicates it’s for Windows 365 Frontline and what the profiles does. When you have given the profile a name, press Next.
Select “+ Add setting” to open the settings picker.
In the settings picker, search for session time limits and select the category for Session Time Limits.
In the settings name section, check the box for “End session when time limits are reached“ and “Set time limit for active but idle Remote Desktop Services sessions“, and your setting will appear in the policy. Once you have selected the setting name, close the fly-out settings picker.
Enable the settings and choose the time limit that matches your needs and corporate policies. In this example I’ve selected 1 hour, which is good value to start with. Once you have enabled these settings, press Next.
Unless you use Scope tags you can skip this section and move right to Assignments where we will deploy this towards all our Windows 365 Frontline devices. I’m doing this by assigning the policy to the built in All devices group and applying a filter I’ve created for Windows 365 Frontline.
The rule syntax you want to use when creating a filter for Windows 365 Frontline machines is at least this one, but it can of course have additional lines depending on your needs:
(device. Model -startsWith "Cloud PC Frontline")
Once you have made the assignments as needed, press Next and then Create.
Your policy will now assigned to all your Windows 365 Frontline Cloud PCs and you can track the progress in Intune by looking at the policy.
Microsoft finally released the long-awaited Intune Suite, or as it is called in Intune “add-ons”.
But what is the Intune Suite and why should I even care? That’s what I’m set out to cover in this blog post, and we will take a look at what there is right now and what’s to come.
One major change happened when this was introduced, and that is how Intune is licensed. Or at least it got some new names. Microsoft Intune Plan 1 is what previously was just called Intune and is included in the Microsoft 365 and EMS plans. This will give you the core Intune features as you have been using them today (with some exceptions).
Then we have Microsoft Intune Plan 2 which are some add-ons to plan 1 including Microsoft Intune Tunnel for Mobile Application Management, which will give you an option to use Intune Tunnel together with your MAM enabled applications. And then we also have Microsoft Intune management of specialty devices, which enables you to manage specialty devices in Intune such as AR/VR devices, conference room meeting devices and large smart screen devices.
For Plan 1, there is also a possibility to buy Remote Help, Endpoint Privilege Management, Advanced Endpoint Analtics and the other upcoming features as standalone services to your Plan 1.
Intune Suite – premium features for Intune
The Intune Suite is a packaged deal which includes all the bells and whistles. You get Plan 1 and Plan 2, but also all the nice extra add-ons. Today, this list is quite limited since it will only get you Plan 2, MS Intune Tunnel for MAM and Remote Help on-top of your Plan 1 licens (which you got from your M365 license anyway). BUT, and this is the selling point, you will get all the upcoming features once they are released.
The two already released premium features (if we disregard the Plan 2 features), are by them self really good products. I’ve previously covered the Remote Help app which since then has been refined even further.
Microsoft has further announced that they will release Endpoint Privilege Management (which is currently in public preview) and Advanced Endpoint Analytics as a start, but there are more things coming which will make this suite even better!
Why should I consider this?
Should you consider the Microsoft Intune suite? Well, that depends on your needs. For some, it certanly makes sense to consider it given that they are interested in a lot of the listed features. For others, maybe just one is interesting which then makes more sense to buy as add-ons on it’s on rather than buying the whole suite.
I think, as of right now, Remote Help and the upcoming Endpoint Privilege Management is what will be most useful for many companies as it solves two major headaches: A remote support tool integrated to Intune and a first party solution to manage local administrator. There are a lot of other good tools out there to manage both remote support and local administrator but having a first party tool comes with advantages such as good integrations to Intune for e.g. reporting.
I will in feature post dig in more to the features of the Intune Suite, but for now we have set the scene!
Once every now and then you get one of those weird and maybe a bad ideas and ask yourself:
“What if I have a Windows 10 computer which cannot run Windows 11, but I really want to run Windows 11 on it in a supported way?“
That was what I asked myself when realizing my old Surface Laptop (first generation) does not support Windows 11.
Putting this in maybe a more real-life like scenario “we have some old hardware and Windows 365. We want to keep using the hardware for a few more years but run Windows 11” or something like that.
This gave me an idea. Can we create a kiosk that runs the Windows 365 app only on a managed Windows 10 computer? And to make it more special, let’s make it as a shared device so that I get MY Cloud PC and you get YOUR Cloud PC! 😊
Since Windows 365 Boot is not coming to Windows 10, we need another solution. This solution could be using kiosk mode and shared mode for Windows.
Pre-reqs
What do we need for this to work?
Intune managed Windows 10 computer
Computer registered for Windows Autopilot
Self-deploying deployment profile for Windows Autopilot
Shared device policy
Windows 365 license of some sort
All other licenses required to use Intune
The Remote Desktop application installed on a device
An Azure AD group containing out kiosk PCs
And that is about it.
My thought is to use the old school ShellLauncher method for this, not the fancy assigned app setup since we can make this more dynamic if we want to re-purpose this for another application. This means that we could also use Win32 applications and not only UWP apps.
Using the ShellLauncher method in Intune has gotten really easy, it’s just one custom policy and we are set.
Creating the ShellLauncher script
When looking around for a good source, and inspiration, for this setup I came across this post by Michael Niehaus which is really good and even provides a sample script we can use (why re-invent the wheel?).
Using the script example in the blog above, I came up with this script which you can download from my Github repo.
Basically, what you need to update, is the <Shell> section of this part to the path for your application (Win32) or the AUMID (UWP). In this case, the Windows 365 app for Windows 10 which is a UWP app (as stated in the V2:AppType attribute).
If the remote desktop session is closed, the application will restart.
Creating the ShellLauncher policy
For this, we need to create a custom policy in Intune.
First step is to go to Intune (https://endpoint.microsoft.com) and navigate to Devices > Windows > Configuration profiles and select “+ Create profile“. Select Windows 10 and later as platform, Template as profile type and then the Custom template.
Next, we will give our profile a good name so that we know what the profile does. This should be based on your name standard and naming convention for policies. Then hit next at the bottom of the window.
On the “Configuration settings” tab, select “Add” and give the configuration a name (e.g., ShellLauncher V2). As OMA-URI, enter:
./Device/Vendor/MSFT/AssignedAccess/ShellLauncher
As data type, select “String (XML file)” and upload your XML file. When this is completed, press Save at the bottom of the screen.
You will now see that your setting has been added as a row to this configuration setting and you can press Next at the bottom of the screen.
On the Assignment tab, select the group where you have put you targeted kiosk devices and press Next at the bottom of the screen.
You can skip the “Applicability rules” tab and jump straight to the “Review + create” tab to view a summary of your configuration.
Once you have reviewed your settings, you can press Create and your profile will be created.
Shared device policy
The other profile we need to create is a profile for Shared device. This is done by going to Devices > Windows > Configuration profiles and select “+ Create profile“. Select “Windows 10 and later” as platform, “Templates” as Profile type and find and select “Shared multi-user device” and click create.
Give your profile a name, I will call mine “Win365 Shared Kiosk“. When you have given your profile a name, press next.
On the Configuration settings tab, enable the Shared PC mode and add the settings you need based on your requirements. I will use Domain as Guest account type to ensure that only users from my organization will be allowed to sign in. I will also add some additional settings as you can see from the screen. When you have added your settings, hit next.
Assign your policy to the group you created and used for the ShellLauncher policy and press next.
On the last step, review your settings and click create!
Self-deploying enrollment profile
To have this as a zero-touch installation, which would require zero input from an IT person, we can use the self-deploying deployment profile in Windows Autopilot, which means that we need to create a new profile.
In Intune, head to Devices > Windows > Windows Enrollment > Deployment profiles and select “+ Create profile” and select Windows PC.
First step is as always to give you profile a name, I will call mine “Self deployed Kiosk” and then press next.
On the next tab, select “Self-Deploying (preview)” as Deployment mode. You will then see that almost all fields are grayed out. You can leave all values as default, or choose to change the Language, if keyboard should be automatically configured and if a name template should be used.
Notice: If you are to use this on a virtual machine, you will need to use the user-driver deployment mode since self-deploying requires physical hardware.
For this demo, I will leave everything set to default and press next.
The next step is to set assignments, we will select the Azure AD group we created for the policy for this, but you could also use another group. The important part is that the device is in this group.
Press next and you will end up on the review + create tab where you can review your settings before pressing create.
Once the profile is created, it will take around 15 minutes or so for the enrollment profile to be applied to your device, given that it’s not already included in another active assignment. If that is the case, you need to either add an exclusion group or remove it from the other group before the profile will be assigned.
If you navigate to Devices > Windows > Windows Enrollment > Devices you can look at your device and make sure the correct enrollment profile is assigned.
Deploying our kiosk
This is where the fun begins. Let’s deploy our kiosk to our device!
My device needed to be reset, since it’s already managed by Intune, I can simply just use the wipe command and the device will reset. Since I’ve already added it to the target group for my deployment profile, the enrollment will kick off automatically once the device has been reset. However, if you are connecting using Wi-Fi, you will need to select region, keyboard and Wi-Fi network.
Once the Windows Autopilot enrollment process has completed, my Windows 365 kiosk device is ready, and I can now only run the Windows 365 app on my device.
NOTICE!
There is a big flaw in this design at the moment, and that is the fact that we cannot deploy the W365 application during the ESP at this stage, this means that we need to ensure that the application is installed BEFORE we apply the kiosk profile. If and when we can install the application from the “new store” during ESP, this will not be an issue.
This means that we currently need to wait until the W365 app has been deployed before we assign our kiosk profile.
Windows 365 and Cloud PCs are as you know PCs running in Azure somewhere. But what if you want to control this “somewhere” and pinpoint the region they are running in? You might have noticed that spinning up a Cloud PC in e.g., Western Europe gives you Google and all web-based things in Dutch. This isn’t too convenient for the end-users who doesn’t speak Dutch. So, let’s try to address that and give a more “local” experience.
I’m thinking of putting users in a Windows 365 region as close as possible to them, hopefully even within the same country. And to top it off, let’s provide them with a Windows experience in their local language, just for the sake of it.
How can we achieve this?
Well, we need two things, we need a provisioning profile per country and an Azure AD group which has been populated with users for each country. The region selected in the network for Windows 365 decides in which region the Cloud PC is hosted.
Setting up Azure AD groups
There are as many ways to do this as there are IT pros, but I decided to make this easy and just look at three things for my groups, attributes that I know all my users have.
What I decided to look at is that:
The account is enabled
Usage location for the user is set to Sweden
And the country for the user is set to Sweden
That got me the following query for my dynamic group.
(user.accountEnabled -eq True) and (user.usageLocation -eq "SE") and (user. Country -eq "Sweden")
To create a new group, head to Groups in the Intune portal and create a new group by pressing “New group“.
Give your group a name, in my case I’ve called it “All users Sweden” since we will gather all Swedish users in this group. Also make sure to set “Membership type” to Dynamic User so that we can create a query to automatically populate the group based on user attributes.
Add your query to your group by pressing “Add dynamic query” and enter your rule. You can take my example and modify it if you like, copy the rule syntax above and press “Edit” on the rule syntax windows and paste it there. This will populate the fields for you, and you can modify them to suit your needs. Or create your own! Keep in mind that the usage location uses the two-letter country code e.g., Sweden is SE, Norway is NO, Netherlands is NL, USA is US.
Press Save when you have created, and validated, your rule and press Create.
We have now successfully created a dynamic group which will be populated with all active accounts which has their country and usage location set to Sweden.
Creating provisioning policies
Now that we have our groups, we want to put them to effective use. Let’s head into the Windows 365 pane in Microsoft Intune by navigating to Devices > Windows 365 and selecting the “Provisioning policies” tab. To create a new policy, click the “+ Create policy” button on the ribbon.
First off, as always, we will give our policy a name, in my case I’m giving it a name indicating that this is a Windows 11 image, Azure AD joined and running on Microsoft hosted network. And this is for my Swedish users.
The next step is to select what kind of join type you will use and which network. In this example, I will use Azure AD join and using the Microsoft hosted network. The dreadful thing about using Sweden as an example here is that we don’t have Windows 365 in Sweden Central, so we will use the next best thing. Norway East!
You can do this for Azure v-nets, but then you need to set the region stuff when setting up the Azure v-net. There is a limit to the amount of how many Azure Network Connections (ANC) you can define per tenant, you can find out more here. If you know that you have multiple locations and want to put the service as close as possible to the end-user, it’s much easier to use the Microsoft hosted network.
The next step is to select an image, I will go with a gallery Windows 11 image since this will reduce the amount of maintenance I need to do since Microsoft is curating the image. Press next when you have selected your image.
Next, we will configure language and region settings. Like I said, the ambition here is to provide the Windows 365 experience in the user’s local language. So, for this I will select Swedish for this policy.
In this section, you can also choose to opt-in to Windows Autopatch straight away if you have this enabled in your tenant. If you do not wish to do so, just leave it to the default value. But since I have it activated in my tenant, I will add this as well and then press next.
The next step is to assign this policy to our group created in the first part. If you wish, you can add multiple groups to the same provisioning profile. But I only have one which will be used for this one, so I will select my group with all Swedish users and press next.
Final step is to review the settings we have selected and then press “Create“.
Conclusion
Now when a Windows 365 license is assigned to a user, their Cloud PC will be provisioned in the region based on which provisioning policy they are assigned to using our dynamic Azure AD group.
The groups don’t need to be dynamic and you could just as easily accomplish this using assigned groups. Also, you could utilize this setup to also include e.g., your developers who need access to a specific Azure v-net for example. In this case you would have provisioning profiles connected to those networks instead of the Microsoft hosted network, giving those users access to that network.
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.
Windows
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!
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.
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.
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).
You know, devices and new stuff are always fun. But what if you would provide a kick-ass, safe, Windows experience on any device without having to invest in infrastructure or administrative work? To semi-quote on of my all-time favourite TV-show: “Haaaave you met W365” (it’s supposed to be Ted, not W365).
I remember hearing about the new Windows Virtual Desktop at Ignite 2018 and thinking “Wow, this is sooo cool! Finally, someone simplified the complexity of VDI solutions a little!”
It was not perfect, but it had potential! Up until then Azure hadn’t really provided any good solutions for Windows 10 based clients. You could run Windows clients if you imported an image, but it was far from great. It was more for playing around with Windows.
Windows Virtual Desktop later became Azure Virtual Desktop, but it required a decent amount of work to set up initially. Don’t get me wrong, it’s super awesome given the flexibility it provides you could run anything on it. But it comes with a big challenge, especially if you are not familiar with VDIs. It requires a decent amount of configuration before you can get going. The Azure Virtual Desktop is however GREAT for scenarios where users don’t need a dedicated machine, their session can run in a host pool to make the most out of your Azure resources!
Windows 365 enters the stage
Microsoft announced Windows 365 during the summer 2021 (I remember noticing it during my summer vacation). I had a really hard time positioning this compared to the AVD solution, when should I pick what?
But finally, the coin dropped for me. Windows 365 is for when you just need a virtual computer with no super specific needs (since the configurations are a set list). Like for instance you have a consultant working in your company who already has their own device which they can run a Windows 365 machine on, instead of you having to source and ship a physical device.
Current sizing of Windows 365
It also has the quite nice feature of being simple to assign and setup since you assign a provisioning policy and a license to the end user, and you are good to go! This is truly VDI made for the masses if you ask me.
Of course, there are things you need to setup if you are running this in an enterprise, such as the network connectivity and on-premises domain connection (yes you sadly still need an on-premises AD and hybrid join for this in the enterprise setup, but AAD only is coming). You would also need to setup management profiles in Microsoft Intune or just reuse the ones you have for your physical machines. In Microsoft Intune, the Cloud PC is just a computer amongst all the others, but model will be Cloud PC instead of e.g. Surface Laptop.
Coming from a device management background, I also really love that you manage everything from the Microsoft Endpoint Management portal, no other fancy tools needed or a need to find your way around the Azure portal!
Who should use a Cloud PC?
So, who is the Windows 365 Cloud PC for really? Saying everyone is not the wrong answer, but when you face reality and leave the marketing slides behind, you will notice that most of your users don’t need this. But some absolutely do, and those are in this case the interesting users.
In the perfect of worlds, you could easily “only” have Cloud PCs and let your users use whatever device they want to access those. In an enterprise scenario, with a lot of history, which would not be feasible. At least not for your FTEs to start with unless you provide them with more lightweight devices and provide a beefier Cloud PC to do their work on.
In the scenarios I mostly have seen and discussed, there is one main use case we are discussing, and that is consultants who already has a computer (or device for that matter) and instead of providing them with a 5-year-old computer which got put in the spare pile you give them a virtual machine which they can access from their PC. This scenario is also valid for providing consultants with a more basic PC and “beef” it up using a powerful Cloud PC.
One thing I find useful is that you can run either Windows 10 or Windows 11 on it, you select the image yourself. This means that you could potentially have your physical machine on Windows 10 but run your virtual machine with Windows 11. This could be beneficial in a transition period from Windows 10 to 11 if you want to do some application testing without needing to re-install computers.
I’ll keep exploring Windows 365, and I’m really hoping Ignite will bring more cool stuff around for it!
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.
