I actually ran into this working with a customer. We had setup the Cloud PCs using an Azure Vnet in connected to the wrong landing zone (test environment) and we had 100+ Cloud PCs up and running and there was no possibility due to internal processes to move that network to the production environment.
This could also be relevant if you want to move a provisioning policy from one Microsoft hosted network region to another.
In this post we will cover how this looks when using Microsoft hosted networks, but they could just as well be Azure Network Connections. The beauty is that we don’t need to re-provision them, we can just update the provisioning policy!
Update provisning profile
Since we are moving from one Microsoft hosted network to another, we won’t need to do any updates outside the provisioning policy. If we are moving to another Azure Network Connection, we need to first create a new connector for our new network. This could be in the same subscription but be another subnet for example. Once you have created this, you can move on to updating the provisning policy.
So, the first step is to head into our provisioning policy. In this example we are updating our policy which is currently set up to use US East as a the region, but we want to move this to Europe instead.
What we need to do here is to update the geography and region in our policy, and of course also the name since I have the region in my policy.
Once I’ve done my updates to the region, I simply click next to the bottom of the screen, and I end up on the summary page where I as always get an overview of my policy. When I’m done reviewing this, I click Update.
But we are not done yet. We also need to apply this update to our machines, unless we do that this only applies to newly provisioned Cloud PCs, and we want to move all of them to the EU.
When we are back on the overview blade for our policy, there is a action at the top called “Apply current configuration”.
When we click on this text, we get prompted whit this pop-up asking us if we want to apply the region change or the SSO change. Since we didn’t make any SSO changes in this policy, things would happen, but this is a fantastic way to enable SSO for all your Cloud PCs without having to redeploy them. But let’s select the “Apply region change” and hit Apply.
Once you have applied the change, your Cloud PCs will start updating.
During the update, the Cloud PC will not be available since work is being done in the back end.
Once the move has been completed, which took about 10-15 minutes for me, you can sign back into the Cloud PC and keep using it in the new region!
Like the swede I am, I’ve been off work for the last 4 weeks to get my summer vacation. I’ve actually done my best to try to stay away from IT stuff this summer, to disconnect and focus on other things (like golf and getting our house in order).
But the world of IT does not slow down just because of summer, so here is a summary of some of the highlights that I missed during my time off!
I got renewed as MVP
Okay, this I already knew before the summer. But I was awarded for my 2nd year as an MVP within Windows and Devices for IT. I’m truly honored to be awarded for yet another year and being part of such a cool community of awesome people!
I will do one session about Windows 365 networks and one about how to do better deployments of Windows 365.
I’m really looking forward to this and I hope to see you all there!
Windows 365 Switch in public preview
At Microsoft Ignite 2022, Microsoft introduced three big new features coming to Windows 365. In May, Windows 365 Boot reached public preview as the first of the three. Now in August, the second and maybe my favorite, Windows 365 Switch reached public preview!
Windows 365 Switch lets you switch between your physical PC and your Cloud PC through the task viewer, just like the other desktops you can have. It’s a really cool feature and I will cover this in a blogpost the upcoming weeks!
This was actually announced before I left for summer vacation, but Windows 365 Frontline finally reached general availability!
For those of you not familiar with this concept, this is a different licensing modell designed for scenarios where the users are not using their device all the time, user who work in shift where you have users coming an going. The concept is that you buy one license, but you get three Cloud PCs but only one can be used at the time.
It sounds a little bit tricky, I know, but I covered this in an earlier blog post which you can have a look at.
Microsoft released new information about the Windows 11 23h2 update coming later this year. It is currently scheduled to be released in Q4 and will be released as an enablement package. This means that there are no big changes coming to the code base of Windows 11, and you can keep doing you testing on Windows 11 22h2 if you are still transitioning over to Windows 11.
Microsoft also mentions a Windows 11 LTSC version in this update, which means that if you are waiting for that release, you can start preparing.
As per usual, Microsoft Intune has gotten it’s weekly updates during the summer. I think the most impactful update was the fact that uninstalling applications as an end-user in Company Portal is FINNALLY available! I know this has been something a lot of IT Pros has been waiting for. There are also a lot of new stuff in the 2307 Service release.
Uninstall Win32 and Microsoft store apps using the Windows Company Portal
Use the Turn off the Store application setting to disable end user access to Store apps, and allow managed Intune Store apps
New BitLocker profile for Intune’s endpoint security Disk encryption policy
Intune supports new Google Play Android Management API
Change to default settings when adding Windows PowerShell scripts
New settings available for the iOS/iPadOS web clip app type
Settings insight within Intune Security Baselines is generally available
Tamper protection support for Windows on Azure Virtual Desktop
Endpoint Privilege Management support to manage elevation rules for child processes
During the summer Microsoft updated how you can enable screen captrue protection and watermarks for Windows 365 (and Azure Virtual Desktop).
Previously, you had to upload a custom ADMX template to enable these settings (or GPO), but they have now been made available in the built-in ADMX profile in Intune, making this setting much more accessible.
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.
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:
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.
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.
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.