Microsoft officially retired Classic Teams on July 1, 2025, and the client is no longer functional. Despite this, many organizations still have remnants of Classic Teams scattered across their Windows device estate. This is not just a cosmetic issue. Classic Teams no longer receives security updates, the per-user installation model wastes disk space, leftover shortcuts confuse users, and end-of-life software can put you out of compliance. If you have been putting off the cleanup, now is the time to remove Classic Teams from your environment.
In this post I am sharing three PowerShell scripts that handle different scenarios, from a one-off standalone removal to a fully automated Intune Proactive Remediations approach.
Why You Need to Remove Classic Teams
Even though Classic Teams stopped working months ago, there are real reasons to actively remove it rather than just leaving it behind:
Security – Classic Teams no longer receives security updates, leaving a potential attack surface on your endpoints
Disk space – The per-user installation model means Classic Teams can consume hundreds of megabytes per user profile on a device
User confusion – Leftover shortcuts and autorun entries can confuse users, especially when New Teams is already deployed
Compliance – Many organizations have policies requiring the removal of end-of-life software from managed devices
Clean device state – Leftover registry entries and autorun configurations can interfere with New Teams or cause unexpected behavior
What Gets Removed
All three scripts target the same Classic Teams components:
Teams Machine-Wide Installer – The MSI-based installer typically deployed via SCCM, GPO, or during OS deployment
Per-user Teams installations – Classic Teams installed itself per-user under %LocalAppData%\Microsoft\Teams for each profile on the device
Autorun registry entries – Both HKLM and per-user Run keys that launch Classic Teams at logon
Desktop and Start Menu shortcuts – Leftover .lnk files pointing to the old Teams client
Teams Installer folder – The C:\Program Files (x86)\Teams Installer directory
Option 1: Remove Classic Teams with a Standalone Script
If you need to remove Classic Teams from a smaller number of devices, or want to run the cleanup through SCCM, ConfigMgr, GPO, or manually, use the standalone removal script. It handles the complete removal process in a single run: stops Teams processes, uninstalls the Machine-Wide Installer via msiexec, iterates through all user profiles to remove per-user installations, cleans up registry entries and shortcuts, and validates the result.
The script creates a log file at C:\Windows\Logs\Remove-ClassicTeams.log for troubleshooting.
Option 2: Remove Classic Teams with Intune Proactive Remediations
For organizations managing devices through Microsoft Intune, the preferred approach is to use Proactive Remediations (now called Remediations in the Intune admin center). This gives you a detection script that identifies non-compliant devices and a remediation script that automatically cleans them up.
Detection Script
The detection script checks whether you still need to remove Classic Teams by scanning all common locations. If any remnant is found, it exits with code 1 (non-compliant), which triggers the remediation script. If the device is clean, it exits with code 0 (compliant).
Teams Machine-Wide Installer in both 32-bit and 64-bit uninstall registry keys
Classic Teams folder, Teams.exe, and Update.exe in each user profile
Teams desktop shortcuts across all profiles
HKLM Run entry for Teams
Remediation Script
When the detection script flags a device as non-compliant, the remediation script will remove Classic Teams and perform the full cleanup. It goes further than the standalone script by also cleaning Start Menu and Startup folder shortcuts, loading offline user registry hives to remove per-user Run entries, and removing the Teams Installer folder from Program Files.
After remediation, the script runs its own validation. If all remnants are successfully removed, it exits with code 0. If anything remains, it exits with code 1, which Intune will flag for review.
Give it a name, for example: Remove Classic Microsoft Teams
Upload Detect-ClassicTeams.ps1 as the detection script
Upload Remediate-ClassicTeams.ps1 as the remediation script
Set Run this script using the logged-on credentials to No (runs as SYSTEM)
Set Run script in 64-bit PowerShell to Yes
Assign the remediation to a device group – start with a pilot group before targeting all devices
Set the schedule – daily is recommended until the bulk of devices are cleaned up, then reduce to weekly
Logging
All three scripts write detailed logs to C:\Windows\Logs:
Remove-ClassicTeams.log
Detect-ClassicTeams.log
Remediate-ClassicTeams.log
Each log entry includes a timestamp, severity level (INFO, WARN, ERROR), and a descriptive message, making it easy to verify that the scripts successfully remove Classic Teams. This makes it straightforward to troubleshoot any issues through Intune device diagnostics or by reviewing the log files directly.
Summary: Remove Classic Teams the Right Way
Cleaning up Classic Microsoft Teams is a necessary task for any organization that has migrated to New Teams. Whether you run the standalone script through your existing deployment tools or leverage Intune Proactive Remediations for automated, ongoing compliance, these scripts give you a reliable way to get it done.
If you manage Windows devices in any kind of enterprise environment, the Secure Boot certificate expiry is a deadline you really do not want to sleep on. The Microsoft certificates that have been the foundation of UEFI Secure Boot since Windows 8 are reaching the end of their lifetime in 2026, and the clock is ticking. The first wave of expirations begins in June 2026, and if your fleet is not ready by then, devices will start losing the ability to receive boot-level security updates and to trust software signed with new certificates.
The reason this matters is not just calendar housekeeping. The whole reason we are rotating these certificates in the first place is the BlackLotus UEFI bootkit (CVE-2023-24932), a piece of malware that can survive an OS reinstall and even bypass Secure Boot itself. The 2023 certificate set is the long term answer, and you need every Windows device in your environment trusting it before the old certificates roll off.
In this post I want to walk through what BlackLotus actually is, what is happening with the Secure Boot certificates, how the two are connected (but not the same thing), and what you can practically do about it today using Intune, PowerShell, and the great work that several Microsoft MVPs have already shared with the community.
A Quick Refresher on BlackLotus
BlackLotus is a UEFI bootkit that exploits CVE-2023-24932, a vulnerability in the Windows boot manager. What makes it particularly nasty is that it loads before Windows does, which means it sits underneath every traditional security control you have in the operating system. Antivirus, EDR, even a clean reinstall of Windows will not necessarily get rid of it, because the malicious code lives in the boot path that Secure Boot is supposed to protect.
Microsoft addressed CVE-2023-24932 with a multi-phase rollout that started back in 2023 and is still in progress today. The fix is not just a patch you install. It involves updating the bootloader, revoking the trust of the vulnerable boot manager, and ultimately replacing the certificates that Secure Boot uses to decide what is allowed to run. That last part is the piece we are dealing with right now.
The Secure Boot Certificate Expiry: What Is Actually Going Away in 2026
There are three Microsoft certificates from 2011 that are baked into firmware on basically every Windows device shipped in the last decade. Here is the short version of what is going away and when:
Microsoft Corporation KEK CA 2011 – the Key Enrollment Key authority. Expires June 2026.
Microsoft Corporation UEFI CA 2011 – signs third party UEFI components and option ROMs. Expires June 2026.
Microsoft Windows Production PCA 2011 – signs the Windows boot manager itself. Expires October 2026.
The replacements are the 2023 certificate set: Microsoft Corporation KEK CA 2023, Microsoft UEFI CA 2023, and Windows UEFI CA 2023. These are the certificates Microsoft is using going forward to sign boot components, and they are also the ones that carry the BlackLotus mitigations.
How BlackLotus and the Certificate Expiry Are Connected, but Not the Same Thing
This is the part I see people mixing up the most, so it is worth being precise. BlackLotus and the certificate expiry are two different problems that share a single solution.
BlackLotus (CVE-2023-24932) is a security vulnerability. It exists because the old boot manager can be tricked into running malicious code. The fix is to revoke trust in the vulnerable boot manager and replace it with a new one signed by a new certificate.
The 2026 certificate expiry is a lifecycle event. The 2011 certificates were always going to expire eventually. June 2026 is simply when their validity runs out.
Where they meet is the 2023 certificate set. Microsoft is using this rotation as the opportunity to also roll out the BlackLotus mitigations at the same time. So when you update a device to trust the 2023 certificates, you are doing two things in one go: you are getting it ready for life after the 2011 certificates expire, and you are closing the BlackLotus attack path.
If you do nothing, the consequences are not the same on both sides either. A device that never gets the 2023 certificates will still boot after June 2026. It just will not be able to install future Secure Boot updates, will not trust new third party UEFI components, and will remain exposed to BlackLotus style attacks. That is not a place you want to be.
How to Fix It
The good news is that the actual remediation is mostly registry plumbing. Microsoft ships the certificate update logic inside the cumulative update, and you opt a device in to receiving the new certificates by setting a value under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot. Specifically, the AvailableUpdates DWORD controls which steps are applied. The current recommended value is 0x5944, which performs the full sequence: it adds the 2023 KEK to KEK, adds the 2023 DB entries, updates the boot manager, and updates DBX. After the registry value is set, the Microsoft\Windows\PI\Secure-Boot-Update scheduled task is what actually does the work, usually across one or more reboots.
At a high level the process for any device looks like this:
Make sure the device is fully patched. Anything earlier than the July 2024 cumulative update is not going to do you any favors.
Confirm that diagnostic data is set to at least Required, because the certificate update flow uses it.
Set AvailableUpdates to 0x5944 under the Secureboot key.
Trigger the Secure-Boot-Update scheduled task (or wait for it to run on schedule).
Reboot. Sometimes more than once. Verify by checking the UEFICA2023Status registry value, which should eventually read Updated.
Validate by querying the actual Secure Boot databases with PowerShell to confirm the 2023 certificates are present.
The cleanest way to do this at scale is with Intune Remediations. You build a detection script that reports back whether a device already has the 2023 certificates installed, and a remediation script that sets the registry values and kicks off the scheduled task. That gives you a single dashboard view of your whole fleet and lets you target the long tail of devices that need a nudge.
Things That Will Trip You Up
OEM firmware. Some older devices will need a UEFI/BIOS update from the manufacturer before they can accept the 2023 certificates. If you have a fleet that is more than four or five years old, plan on doing a firmware audit as part of this project.
Diagnostic data. If telemetry is set to Off (Security on Enterprise), the certificate update flow will not run. You need at least Required.
Dual boot and custom signed bootloaders. If you are running anything that depends on the 2011 UEFI CA (some Linux distributions, some hardware vendors’ utilities), test before you push the update broadly.
Virtual machines. Hyper-V Generation 2 VMs and Azure VMs are also affected. Do not forget the server side of the house.
Monitor first, remediate second. Microsoft’s recommended approach is to start with a monitor-only Intune Remediation that just reports status, so you understand the scope of the problem before you start changing anything.
Reference Articles From the Community
I am far from the first person to write about this, and several Microsoft MVPs have already done excellent deep dives that are well worth your time. If you are about to start this project, read these first:
If you would rather start from working code than write your own from scratch, several community members have published their detection and remediation scripts on GitHub. Always read through any script before deploying it in your environment, but these are good starting points:
ThomasMarcussen/SecureBoot_2026_UpdateScripts_v1.0 – my own toolkit. Four scripts: a readiness detection script, a remediation script that applies the registry and telemetry settings, a CSV reporting script, and an OEM firmware readiness check. Designed to be deployed via Intune Remediations or Configuration Manager.
markorr321/Secure-Boot – Detection, remediation, and throttle bypass scripts for Intune, with a focus on enterprise wide compliance and the BlackLotus mitigation.
The 2026 Secure Boot certificate rotation is one of those rare projects that touches every Windows device in your environment, including the ones nobody has thought about in years. It is also one of those projects that is going to be infinitely easier if you start now than if you wait until May 2026 and try to do it under pressure. The combination of Intune Remediations, the registry-based opt-in flow, and the great scripts already shared by the community means there is no real reason to put it off.
Start with monitoring so you know what you are dealing with, fix any firmware and telemetry prerequisites, and then roll out the remediation in waves. Closing the door on BlackLotus is a nice bonus on top of staying ahead of the certificate expiry, and your future self (and your security team) will thank you.
If you’ve been following the passwordless journey in Microsoft Entra ID, you already know passkeys have been around for a while. But until now, FIDO2 in Entra essentially meant hardware security keys – practical for your admins, not so much for 5,000 end-users who lose USB dongles faster than you can ship them.
With the March 2026 update, that changes. Synced passkeys are now GA.
Synced vs. Device-Bound – What’s the Difference?
Type
Stored On
Survives Device Loss
Use Case
Device-bound passkey
Single device or security key
No
Privileged accounts, high-security roles
Synced passkey
Cloud-synced provider (iCloud Keychain, Google Password Manager, 1Password, etc.)
Yes
Broad workforce rollout
Synced passkeys are still FIDO2-based and still phishing-resistant. The difference is they follow the user across devices. Lost your laptop? Your passkey is already on your phone.
What Shipped Alongside It
This wasn’t a standalone release. Microsoft also GA’d passkey profiles, which let you define multiple FIDO2 policies targeting different user groups. That means you can enforce device-bound passkeys for Global Admins while allowing synced passkeys for standard users – same authentication methods policy, different profiles.
On top of that, the Conditional Access Optimization Agent (public preview) now supports automated passkey adoption campaigns. It assesses readiness, generates rollout plans, and creates policies in report-only mode before enforcement. And no – it doesn’t flip switches without your approval.
Getting Started
Navigate to Entra admin center > Authentication methods > Passkeys (FIDO2)
Monitor adoption through the authentication methods activity report
For bulk FIDO2 provisioning, check out MichaelGrafnetter/webauthn-interop – a .NET library with a PowerShell module for registering passkeys on behalf of users via Graph API.
Synced passkeys remove the hardware logistics barrier that kept phishing-resistant MFA out of reach for most organizations. Combined with passkey profiles and the new CA optimization agent, you now have the tooling to roll this out at scale – without shipping a single USB key. If you’ve been waiting for the right moment to push passwordless beyond your admin accounts, this is it.
When we talk about Windows 365, there are many things that come to mind. Accessibility from anywhere, flexibility, data security, and scalability are some of the most common benefits you’ll get when you sign up for Windows 365.
Together with the many others I haven’t mentioned, these benefits can significantly improve how your organization operates and can get your productivity levels trending upwards. But, as with any solution, the key to getting the most from your investment is fully understanding the features that Cloud PCs offer and how you can leverage them to enhance your operations.
Establishing a Windows 365 Environment
There are many steps to consider before administrators start providing end users with functional Cloud PCs. In a previous blog, I did a deep dive into how your organization can provision your Cloud PCs.
All of this begins with researching Windows 365, defining SMART (Specific, Measurable, Attainable, Relevant, and Time) objectives, considering the various Cloud PC provisioning scenarios, and then creating the provisioning policy.
Provisioning policies are the elements necessary for creating and assigning Cloud PCs to their users. They determine which operating system version will be used. They’ll also decide other key things, such as join type, language, and region. Once you create the provisioning policy, it will handle all the provisioning necessary to automatically get licensed users their Cloud PCs.
What if Provisioning Fails?
As with any tech solution, sometimes things go wrong and the installation process fails to deliver the expected result. When this happens with Cloud PC provisioning, Windows 365 will automatically retry the provisioning process a further 2 times. And if after these 3 attempts the provisioning still fails then:
The provisioning process stops.
The Cloud PC will mark as Failed.
An error message will display.
At this point, the administrator needs to figure out the cause of the failure before they can proceed. Finding the reason for this failure requires a detailed analysis of the specific error messages within the Microsoft Intune admin center as well as checking underlying dependencies.
Once admins identify the error message, they can then investigate common areas. These might include ANC failures, AD domain join failures, licensing and policy issues, Microsoft Entra Hybrid Join failures, and IP address exhaustion. After admins determine the root cause, they can manually trigger a retry of the provisioning process by pressing the Retry button in the error dialog.
Resizing a Cloud PC
Certain situations may present themselves where end users may require:
More RAM and vCPU cores to run CPU-intensive applications.
An increase in disk space for file storage.
Or, less RAM and vCPU cores to run their current workload applications.
In these scenarios, Windows 365 allows you to resize your Cloud PCs without compromising user and disk data. Moreover, the resizing can be performed without having to reprovision the affected Cloud PCs. Admins should be aware that although resizing won’t support GPU Cloud PCs, it does support the following:
Direct and group-based licenses.
Paid, preview, and trial licenses.
Bulk and single device operations.
The key to carrying out a successful resizing operation while minimizing the risk of potential issues is communicating and coordinating with the concerned end users. Because the resizing operation disconnects end users from their sessions, it’s best to choose a pre-agreed time that is convenient for all parties. And do so when there is no unsaved work that could be lost. To perform the resizing of Cloud PCs, you follow the steps below:
Start by checking to see if you have the appropriate license for the new Cloud PC size in your environment.
Start the resizing process from the Intune console. (Note: Before proceeding any further, you should know that if you remove the license before resizing, the device will be put in a grace period. And this in turn will prevent you from resizing.)
Navigate to the Intune portal and search for the device.
Click on Resize.
If the appropriate license is available, you can proceed with the new Cloud PC.
After starting the process, expect the Cloud PC to swiftly shut down and begin resizing. This process will take about 15 to 20 minutes, after which the end user can regain access to their device.
Reprovisioning A Cloud PC
Windows 365 makes it possible to modify provisioning policies if the need arises. But any changes made to a provisioning policy won’t apply to previously provisioned Cloud PCs. Not unless you first reprovision those virtual machines. Basically, the reprovisioning action is a feature that can prove particularly useful if:
You need to test different Cloud PC configurations.
You are having issues with a previously provisioned Cloud PC.
The end user requests a new Cloud PC.
In addition to the above scenarios, reprovisioning can also be the solution for Cloud PCs in a Failed provisioning state in the Windows 365 provisioning node. Simply put, you can think of the reprovisioning action as functioning in a similar manner to how one would reset a physical device.
Once reprovisioning is complete, the current Cloud PC is deleted, and a new one is recreated. This new Cloud PC won’t contain any of the previous user data, applications, and customizations, as they will have been deleted.
Instead, this new device is reprovisioned using the current configured settings in the provisioning policy that’s assigned to the user’s Microsoft Entra group. So, if an admin makes changes to a provisioning policy, such as changing the image referenced by the policy or any other modifications, these new configurations will be applied to the reprovisioned Cloud PC. And to simplify reprovisioning for Frontline Cloud PCs in shared mode, Windows 365 allows you to bulk reprovision all the Cloud PCs in a provisioning policy.
How To Restore A Cloud PC
The ability to revert a Windows 365 Cloud PC to a previous state gives users a great solution for when disruptive events occur. When restoring the Cloud PC to a selected restore point, issues like critical system failures, the need to reverse unfavorable changes, malware, and data recovery, among others, can be addressed. Reverting a Cloud PC to a previous point in time prevents having to completely wipe the device.
However, the process will still permanently delete data saved to the Cloud PC and any apps installed between the restore point and now. Before proceeding, be advised that the Cloud PC will not be available for the duration of the restoration. This action cannot be reversed. If you decide to proceed, you can follow the steps below:
Find your Cloud PC and select the gear icon (Settings).
Select Restore.
From the drop-down menu that appears, choose the restore point that you would like to use.
Check the appropriate box and select Restore.
Admins can also initiate the restoration process for their end users by:
Going to the Intune Admin Center and signing in.
Head over to Devices > Windows 365 > All Cloud PCs, then choose the Cloud PC to restore.
Select Restore.
Choose the restore point that you want to use.
Check the appropriate box and select Restore.
How To Deprovision A Cloud PC
Every now and then, admins will face a situation requiring them to deprovision one or more of their organization’s Cloud PCs. This can happen when employees leave or change roles, or when the organization needs to reclaim unused licenses. It also happens when persistent technical issues need resolution, etc. Regardless of the reason, when it comes to the actual deprovisioning of a Cloud PC, there are a couple of ways to do it.
Method 1
Start by selecting the Cloud PC that you want to deprovision and then remove the Windows 365 license from that user. Doing this will move that Cloud PC into a 7-day Grace Period. Windows 365 has designed it this way so that Cloud PCs aren’t deleted accidentally.
This is a great setup to have because if an admin accidentally removes licenses from users whose Cloud PCs aren’t targeted for deprovisioning, those devices won’t immediately delete.
During those 7 days, an admin can still re-assign the license and manually end the Grace Period. It should also be noted that transferring the license to another user won’t end the Grace Period. This is because Cloud PCs cannot be moved from one user to another without provisioning a fresh Cloud PC.
Method 2
With this method, admins can deprovision Cloud PCs by removing the concerned users from the Group which is targeted by the Provisioning Policy which was used to provision the Cloud PC or Remove the Group from the Provisioning Policy Assignment. And similar to the first method, there will also be a 7-day Grace Period.
This gives you the option of keeping those Cloud PCs if you add the user back to the group or re-assign the group to the provisioning policy before the 7 days have elapsed.
Furthermore, Windows 365 gives you the choice to end the Grace Period early if you don’t want to wait 7 days to deprovision a Cloud PC. You can do so by clicking on the “In Grace Period” state and selecting End Grace Period. Having done this, the status of the Cloud PC is then changed to “Deprovisioning” while the Cloud PC is being deleted.
Unfortunately, this is not something you can do as a bulk action in the MEM console, meaning that you can only end the grace period one Cloud PC at a time. But admins who want to bulk deprovision multiple Cloud PCs simultaneously can still do so by leveraging PowerShell scripts.
Cleaning Up
After a Cloud PC provisioning failure or after a Cloud PC is deleted once the Grace Period has expired, the Windows 365 service will clean up all objects created during the provisioning process. You should typically expect the cleanup to occur around 3 hours after the failure. The following objects will clean up:
Intune Object
Microsoft Entra device objects
Azure vNIC
The cleanup won’t affect network security groups created for Cloud PCs because other objects may also be reliant on those groups. In addition, Windows 365 isn’t going to delete on-premises Microsoft Entra computer accounts joined to the domain during provisioning.
Redundant computer objects only disable because Windows 365 doesn’t have the necessary permissions to delete on-premises computer objects. With that in mind, a common recommendation is that businesses use their regular maintenance processes to clean up these disabled computer objects.
Evaluating Cloud PC Usage
Once all provisioning steps are complete and end users’ needs are being met, it’s important to monitor usage in your Cloud PC environment. To help you with this task, Windows 365 provides you with a utilization report that plays a vital role in monitoring and optimizing Cloud PC usage in your organization. Admins can use it to view information such as the amount of time end users are spending on their Cloud PCs, as well as when they last used them. Reviewing this data enables admins to:
Evaluate the underutilized Cloud PCs with the goal of possibly reassigning those licenses to end-users with a greater need for them.
Identify Cloud PCs that have remained inactive for extended periods of time. By targeting these devices for deprovisioning, admins can help cut costs for their organizations.
The Cloud PC utilization report is accessible by signing in to the Microsoft Intune Admin center and selecting Devices > Cloud PC performance > Cloud PC utilization.
Cloud PC utilization report page (tenant data)
This report displays the following tenant data aggregated for the chosen timespan (28, 60, or 90 days):
This histogram shows the number of Cloud PCs connected for each range:
High time connected – More than 80 hours. Average time connected – 40-80 hours. Low time connected – Less than 40 hours.
None – Zero hours.
List of individual Cloud PCs with the following columns:
Device nameUser UPN – user’s identifier in Active Directory in the form of an email address.PC typeTime connected – total hours spent connected to the Cloud PC over the last 4 weeks. Date last connected – date last connected to Cloud PC within the last 60 days. If currently connected, you’ll see the most recent connection time.
And if not, the last sign-out time will display.
Date created – date the Cloud PC was created.
Device type – Cloud PC type based on the offering (Enterprise, Frontline dedicated, Frontline shared).
Scaling Your Cloud PC Environment
Undoubtedly, one of the most attractive features of Windows 365 is that it allows organizations to scale their Cloud PC environments up or down according to need. This type of flexibility is perfect for the business environment because it gives you access to the resources you need when you need them. As a result, you can better manage IT expenditure and potentially reduce costs.
Scaling Up
Organizations can easily scale up their Cloud PC environments by purchasing more Windows 365 licenses. After procuring these additional licenses, you can assign them to the end users who need them.
At this point, you’ll need to assess your provisioning policies before deciding whether or not any modifications are necessary. And if you have new user groups that require different configurations, admins will have to make changes to their provisioning policies.
Additionally, carry out a careful evaluation of your network capacity to check if the increased load is manageable without issue.
Scaling Down
In like manner, scaling down is just as easy. It’s not a particularly complicated process. A detailed assessment of your environment will give you information about end users who no longer require Cloud PCs thus allowing you to remove their licenses.
Once done, the affected Cloud PCs move into a 7-day Grace Period before they deprovision. Admins can also start modifying or unassigning user groups from provisioning policies, depending on the gathered information.
Furthermore, it’s critically important that admins make sure that licenses are reclaimed and made available for reallocation.
Conclusion
Windows 365 delivers powerful virtual machines to businesses that help them improve operations and boost productivity. These Cloud PCs, which are accessible from anywhere using any device, provide users with a great degree of working flexibility.
Not only that, but the robust identity and access management protocols ensure a high level of network security, thereby alleviating the security concerns that often plague virtual computing solutions. And when you add the features discussed in this blog, as well as others not mentioned, businesses will have access to wonderful tools that can ease the management of Windows 365.
Before an organization can deploy Windows 365, it needs to conduct research to gather the information needed to develop an execution plan. You need to look at your current IT setup so you can determine where your greatest need is and how Windows 365 Cloud PCs will integrate into your IT operations. And after looking at all of that, you also need to carefully consider how to set up a Cloud PC environment that will serve you well.
As discussed in the previous blog, part of those considerations should focus on how to properly create provisioning policies. In this second blog, we’ll be continuing with looking at how best to manage your provisioning policies so that you end up with Cloud PCs that function just as you envision.
The Provisioning Process
In the first blog, I went over the importance of provisioning policies and how they are responsible for creating, configuring, and deploying Windows 365 Cloud PCs. I talked about how you’ll first have to sign in to the Microsoft Intune admin center and provide some general information, including the experience and license type you want.
Subsequently, I provided information on the use of Azure Network Connections (ANCs) and how to go about selecting an image for a Cloud PC. Having understood these steps, let’s now take a look at configurations.
Determine Your Configurations
Start by going over to the Configurations page and selecting a Language & Region under the Windows Settings. The selected language will install on Cloud PCs provisioned with the policy that you’re creating.
This next step is not mandatory. It involves selecting a Apply device name template to create a Cloud PC naming template to use when naming all Cloud PCs provisioned with this policy. Admins should note that although the naming template will update the NETBIOS name, it won’t affect the display name of the Cloud PC. Additionally, there are certain rules to follow when creating the template:
Enterprise and Frontline dedicated mode:
Names should be between 5 and 15 characters.
Names can contain letters, numbers, and hyphens.
No blank spaces or underscores can appear in the names.
Use the %USERNAME:X% macro to add the first X letters of the username. (This is optional)
Use the %RAND:Y% macro to add a random string of characters, where Y equals the number of characters to add. Y must be 5 or more. Names must contain a randomized string. (This is a requirement)
Frontline shared mode:
Names must have exactly 15 characters.
Names can contain letters, numbers, and hyphens.
No blank spaces or underscores can appear in the names.
Prefix should contain 7 characters or less.
Use the %RAND:Y% macro to add a random string of characters, where Y equals the number of characters to add. Y must be 8 or more. Names must contain a randomized string. (This is a requirement).
ADDITIONAL SERVICES
This next step is also optional. Head over to Additional services and select a service to install on Cloud PCs provisioned with this policy:
Windows Autopatch is a cloud service that automates Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams updates to improve security and productivity across your organization. The service works on both physical and virtual devices. Admins should note that the Windows Autopatch option isn’t available for Frontline in shared mode.
Those who already have Windows Autopatch configured to manage their Cloud PCs need to know that this option replaces the existing policy. Consequently, they should be aware that the replacement could potentially disrupt any dynamic distribution that is already configured in Autopatch.
When you select Windows Autopatch, the system assigns devices to a new ring as the last ring of the Autopatch group.
You can manually enable dynamic distribution for your Cloud PCs by changing the Autopatch Groups dynamic distribution list to include the Entra ID group to which your Cloud PCs are being added.
None. Manage and update Cloud PCs manually.
Although Autopatch is not available for Frontline devices in shared mode. It still remains possible for these devices to enroll in Autopatch and receive Windows update policies.
Windows Autopilot is a collection of technologies to set up and pre-configure new devices, getting them ready for productive use. It helps ensure that Intune applications and scripts are installed during initial enrollment and setup. And with all the features it has, the main selling point for this service is how it simplifies the Windows device lifecycle. It does so for both IT and end users, from initial deployment to end of life.
User Experience Sync is a cloud-native solution that delivers a seamless and consistent experience for users across Cloud PC and Cloud App sessions. It is a feature that is available for Windows 365 Frontline Cloud PCs in shared mode. If you choose to enable it, Windows 365 will store user-specific Windows and app experience data in central cloud storage and reconnect it whenever the user signs in to the Cloud PC in this provisioning policy.
By preserving Windows personalization, users will benefit from a consistent, productive experience every time they sign in to their Cloud PC or Cloud App. User storage limits depend on the Frontline license type and are pooled across all assigned users.
When everything’s done, click Next.
Scope Tags
If you want, Windows 365 gives you the option to create scope tags for your provisioning policy. Scope tags are particularly important for ensuring that Admins’ access and visibility tie to what they expect to manage. Limiting access in this manner serves to enhance overall security for your organization.
Only admins assigned the Microsoft Entra Intune Administrator role can create, update, or delete scope tags. This means that admins with scope tags in their role assignments can’t update or delete the scope tag from the master list of scope tags. To create a scope tag:
Go to the Microsoft Intune Admin center and select Tenant administration > Roles > Scope (Tags) > Create.
On the Basics page, provide a Name and Description(optional). Choose Next.
Now you go to the Assignments page and select the groups containing the devices that you want to assign this scope tag. Click Next.
On the Review + create page, choose Create.
Creating Assignments
Navigate to the Assignments page, choose Select groups > choose the groups you want this policy assigned to > Select. Nested groups aren’t currently supported.
A Cloud PC size for each group in the policy will need to be selected for Windows 365 Frontline in dedicated mode.
Choose Select one > select a size under Available sizes > Select.
This step is optional. You can create an assignment to reserve licenses for the group members by following the steps given below:
Navigate to Assignment and type in an Assignment name.
Under Number of licenses, type in the number of licenses that you would like to reserve for the group. You can also see the number of unassigned licenses.
When it comes to Windows 365 Frontline in shared mode, you will need to:
Choose Select one > select a size under Available sizes > Select.
Now you need to enter a Friendly name > select a Cloud PC number > Next. This Friendly name will be visible in the end user’s Windows app.
Click Next.
Review and Create
Once you have completed all the steps that I have gone over and you’ve checked that everything is as it should be, you can now head over to the Review + create page and select Create. Those who use Microsoft Entra hybrid join as the join type should be prepared to wait for up to an hour for the policy creation process to complete.
Ultimately, how much time it takes will depend on when the Microsoft Entra Connect sync last happened. And then, following the creation and assignment of the provisioning policy, Windows 365 will automatically begin the process of provisioning Cloud PCs.
Making Changes to Provisioning Policies
In some instances, you may find yourself needing to make changes to your provisioning policies so that you can change assignments or key attributes, like image and network connection. To do so, you’ll need to:
Navigate to the Microsoft Intune Admin center and sign in. Then, select Devices > Windows 365 (under Provisioning) > Provisioning policies > select a policy.
Next, if you go to the policy page, you can make changes to the General information, Image, and Assignments by selecting Edit next to each header. Admins should note that no modifications take effect for previously provisioned Cloud PCs. This includes if the network, image, region, or single sign-on configuration in a provisioning policy is edited.
The changes that you are making to the provisioning policy will apply to newly provisioned or reprovisioned Cloud PCs. Therefore, if you want to change the image of your previously provisioned Cloud PCs to match the new image, then you will have to reprovision these Cloud PCs. And if you want the network, region, or single sign-on of previously provisioned Cloud PCs to adopt the new changes, you’ll need to apply the current configuration.
Name changing
Changing the name of the provisioning policy in the General information will result in the following modifications:
Any Cloud PC in the All Cloud PCs node applies the new policy name updated in the Provisioning policy column.
All new Cloud PCs resulting from the provisioning policy will apply the new name registered as the device’s enrollmentProfileName in Microsoft Entra ID and Microsoft Intune. Note that the enrollmentProfileName property for Cloud PCs applies only during initial enrollment. Admins must remember to edit any dynamic device group rules that use the enrollmentProfileName property if they decide to change the name of a provisioning policy. Doing so allows the rules to continue to include the correct Cloud PCs.
Property = enrollmentProfileName
Operator = Equals
Value = <New name for provisioning policy>
The provisioning process proceeds automatically when new users with valid Cloud PC licenses are assigned to the provisioning policy. On the other hand, if users are removed from the provisioning policy assignment:
The grace period triggers for Enterprise Cloud PCs.
Frontline Cloud PCs in dedicated mode are immediately deprovisioned, but those in shared mode remain unaffected.
Applying the Current Configuration for Enterprise and Frontline in Dedicated Mode
Applying a configuration change to existing Cloud PCs is easy. Just modify and then save the changes to an existing provisioning policy. After which, you go to the policy page and select Apply this configuration. With that done, you can now proceed to choose the configuration change to apply to existing Cloud PCs from the list provided, which includes region and single sign-on. Click Apply.
Applying the Current Configuration for Frontline in Shared Mode
Apply a configuration change to existing Cloud PCs by modifying and then saving the changes to an existing provisioning policy. After which, you go to the policy page and select Reprovision. Once you’ve done that, you’ll now need to decide on the percentage of Cloud PCs that you want to make sure is available for user connections. Then, select Continue.
Getting Started
After successfully completing the creation of a provisioning policy, the new Windows 365 policy will be deployed. A bit of patience is required because, as mentioned above, completing the policy creation process can take up to 60 minutes. Admins can keep an eye on the status of the policy deployment via the Intune portal.
When the process is complete, admins can then check if the provisioned Cloud PC is accessible. The verification happens using the Windows App or any web browser. And if the authentication succeeds, then the newly provisioned Cloud PC will appear as ready for use. End users can access their Cloud PCs according to the information in the table below.
Windows 365 Edition
Windows App
windows.clous.microsoftweb client
Microsoft Remote Desktop
LG Web OS
Windows 365 Business
X
X
X
X
Windows 365 Enterprise
X
X
X
X
Windows 365 Frontline
X
X
Windows 365 Government
X
X
Note: Microsoft Remote Desktop support will end in March 2026. Furthermore, the Remote Desktop Connection client (mstsc.exe) is not a supported connection method for Windows 365 users. So, even though you may successfully use it for troubleshooting, you should not be reliant on it for daily access. Instead, use a supported client, such as the Windows App or the Microsoft Remote Desktop app.
Access Options
WINDOWS APP
Windows App connects remotely to your Windows devices and apps from Azure Virtual Desktop, Windows 365 Cloud PCs, Microsoft Dev Box, Remote Desktop Services, and PCs, securely connecting you to Windows devices and apps. It can be used on any device and is thus the recommended application to connect to Windows 365 Cloud PCs.
Users connecting using a web browser on a desktop or laptop will be able to do so without needing to download and install any software. Not only that, but Windows App is available for Windows, macOS, iOS/iPadOS, Android, Chrome OS, web browsers, as well as Meta Quest VR headset.
Windows 365 web site
Alternatively, users can access their Cloud PCs using the Windows 365 web site (windows.cloud.microsoft). However, for one to access their Cloud PC from this web site, they will need a device that runs a supported operating system such as Windows, macOS, ChromeOS, or Linux. Additionally, a modern browser like Microsoft Edge, Google Chrome, Safari, Mozilla Firefox (v55.0 and later), or LG webOS 23 will also be a requirement.
Home Page
After getting access to their Windows 365 home pages, users can see the Cloud PCs they have access to in the Your Cloud PCs section. On this page, users find 2 options for connecting to their Cloud PCs:
Open in browser – enables you to open your Cloud PC in the web client. This option is not available to mobile devices.
Open in Remote Desktop app – enables you to open your Cloud PC in Remote Desktop.
Conclusion
Adding Windows 365 Cloud PCs to your operations does not need to be an overly complicated process. Microsoft has designed Windows 365 with a vision of making it a platform that is easy to deploy, use, and maintain. But, as with any endeavor, careful planning can make all the difference. Hence, the reason behind this two-part blog. By going over all the steps involved in creating a provisioning policy, admins will have a much easier time setting up their Cloud PC environments.
The importance of virtual machines to businesses continues to grow as the technology itself has constantly improved. Services like Windows 365 can become integral to an organization’s IT operations by providing highly secure, efficient, and scalable Cloud PCs.
As hybrid work environments grow even more popular among remote-capable employees, businesses need to take advantage of tested solutions such as Windows 365. Once you have made your decision, it’s also vital to provision your Cloud PCs correctly so your IT environment operates seamlessly.
Flexibility – one of the best features of Windows 365 is that it is accessible from anywhere using any device. This gives remote employees a great degree of convenience, too. This is because, in addition to accessing their desktops from anywhere. It’s equally convenient that the Cloud PC allows them to do so on any device they have on hand.
Scalability – unsurprisingly, this one is very popular with a lot of businesses. As a service that caters to both small and large enterprises, Windows 365 offers a range of solutions to meet each client’s specific needs. By providing flexible configurations, each organization receives a service plan that adequately meets its performance requirements while remaining cost-efficient. As the business evolves, computing resources can scale to meet usage needs.
Security – security concerns are often the primary reason organizations turn aways cloud-based services. Fortunately, Windows 365 addresses those concerns with security features such as Microsoft Defender and Zero Trust principles, among others. Such features play a major role in keeping your organization’s data extremely secure at all times.
Significance of Provisioning Policies
Provisioning policies are the elements necessary for creating and assigning Cloud PCs to their users. They will determine which operating system version to use, as well as join type, language, and region.
By using critical provisioning rules and settings, these policies will facilitate the building and configuring of Cloud PCs before availing them to end users. Once you create and assign a provisioning policy to the Microsoft Entra user security groups or Microsoft 365 Groups, the Windows 365 service will verify licensing and configure the Cloud PC.
KEY INFORMATION
Before proceeding with the creation of provisioning policies, IT professionals should take note of the following information:
Windows 365 Enterprise – Windows 365 does not provision Cloud PCs for users in an assigned group who don’t have Cloud PC licenses assigned. Furthermore, each Cloud PC license assigned to a user will use only one provisioning policy to set up and configure the Cloud PC. A Cloud PC will always provision using the first assigned policy.
Windows 365 Frontline in dedicated mode – you should prepare for some users to not get their Cloud PCs. This occurs if there are more users in your Microsoft Entra user group than the number of Cloud PCs available for the selected size. And if any users are removed from the Microsoft Entra user group, the respective Cloud PCs automatically move into a grace period.
Windows 365 Frontline in shared mode – in this instance, users removed from your Microsoft Entra user group will lose access to their Cloud PCs. And if the Microsoft Entra user group is removed from the assignment, the Cloud PCs are automatically deprovisioned with no grace period.
Windows 365 Reserve – Cloud PCs will not automatically provision when creating the provisioning policy. Instead, provisioning will require the “Provision” device action. Additionally, some users might not receive their license assignment. For example, you may have more users in your Microsoft Entra user group than the number of licenses available in the tenant. Each Cloud PC license assigned to a user will have only one provisioning policy used to set up and configure the Cloud PC. And as before, Cloud PC provisioning always uses the first assigned policy.
Creating a Provisioning Policy
To create a provisioning policy, you will need to first provide some general information:
Start by navigating to the Microsoft Intune Admin center and signing in. With that done, select Devices > Windows 365 (under Device onboarding) > Provisioning policies > Create policy.
Next, you’ll need to provide a Name for the new policy on the General page. You can also provide a description (optional).
There are 2 experience types you can choose from. The first option gives you access to a full Cloud PC desktop and is available for all Windows 365 license types. This means that end users can connect to a full Windows desktop experience. The second option is only available for Windows 365 Frontline in shared mode and allows end users to only access apps that run on a Cloud PC.
At this juncture, you’ll need to choose a license type, which can be Enterprise, Frontline, or Reserve. However, those who select Frontline will require Windows 365 Frontline licenses to create a provisioning policy for Frontline Cloud PCs. Additionally, if you choose Frontline, you need to choose between Dedicated and Shared.
Deciding on a Join Type
If you choose to go with either Enterprise or Frontline, then you will need to pick a Join Type.
MICROSOFT ENTRA JOIN
Opting for Microsoft Entra Join has several advantages, such as streamlined device management and configuration, which helps to simplify IT operations. Combined with the excellent security measures and reduced delays in provisioning, there are plenty of reasons to make this option very attractive. To set up Entra Joined Windows 365 Cloud PCs, here are some of the requirements to consider:
You need an Intune and a Microsoft Entra tenant.
You also need to have Intune default device type enrollment restrictions set to Allow Windows (MDM) platform for corporate enrollment.
With Intune as the primary device management, an Intune license will be necessary.
Enterprise users need licenses for Windows E3, Intune, Microsoft Entra ID P1, and Windows 365 to use their Cloud PC. On the other hand, Frontline users need licenses for Windows E3, Intune, and Microsoft Entra ID P1. They will be added to the Microsoft Entra security group in the provisioning policy to use their Cloud PC.
Microsoft hosted network – you start by choosing the Geography where you want your Cloud PCs provisioned. With that done, you can pick a Region from the following:
[Recommended] All default regions within the geography (not supported for Frontline in shared mode) – enables you to maximize resiliency and provisioning success. This is the recommended option because it allows Cloud PCs to distribute across the maximum number of regions with a similar latency experience.
A single region group – for those who want all their Cloud PCs to be in one specific country or region group, it will be ideal to choose only that region group. By doing so, Cloud PCs will then distribute across its regions. This delivers maximum resiliency at the region-group level.
A specific region – this is your best option if you want to ensure that all your Cloud PC provisioning occurs in the specific region that you chose. Additionally, you can also choose regions across multiple region groups.
Auto opt-in – there is also an auto opt-in checkbox available that, if you enable, will automatically include any future regions or region groups as they become available. This gives you the convenience of benefiting from the latest Azure expansion without the need for manual updates.
Azure network connection – for this policy, you need to select an Azure network connection (ANC).
HYBRID MICROSOFT ENTRA JOIN
Hybrid Microsoft Entra Join also has its advantages, especially for businesses that want to tap into the benefits of cloud-based solutions while still using on-premises applications and servers. This works well because these types of devices enable a seamless operation for both systems. However, you need to be aware that you cannot use this policy without selecting an ANC.
Choosing an Azure Network Connection
An ANC is required for your provisioning policy if you have chosen either of the options below:
Join type – Hybrid Microsoft Entra Join
Join type – Microsoft Entra Join and
Network – Azure network connection
The steps below will guide you through the selection of an ANC:
Pick one or more ANCs on the General page for Azure Network Connection.
Those who select more than a single ANC can set the priority order for those ANCs. Doing so is a simple process that requires you to hover over an ANC before selecting and dragging on the three dots. After doing that, you can then drag the ANC to a different position in the list.
If the first ANC in the list has no issues, it will always be used to provision Cloud PCs under this policy. However, in the event that something is wrong, then the policy will use the ANC that is next on the list, provided that it’s healthy.
Using Alternate ANCs
Having alternate Azure Network Connections is a great option to have that helps minimize delays during provisioning. Without alternate ANCs, the Cloud PC provisioning process for policies that use an unhealthy ANC is blocked. As one can imagine, this would be extremely frustrating.
It’s this kind of scenario that gave rise to the alternate ANC, a great feature enabling you to define more than one ANC within a provisioning policy. Admins can add several alternate ANCs listed according to priority.
As mentioned earlier, if the highest-priority ANC fails, the next one on the list will be used. If the primary ANC recovers, it will automatically be used for new Cloud PCs being provisioned.
USE CONSIDERATIONS
Below are some of the considerations that businesses should look at before adding additional ANCs.
Alternate ANC use is optional. A provisioning policy only requires a single ANC, and adding alternate ANCs is not mandatory. This simply means that those with a single ANC and who see no reason to change will not be required to modify their existing configurations.
Alternate ANC selection is automatic. The choice of which ANC to use is automatic and follows the priority order list. Therefore, admins don’t need to manually make changes if the primary ANC becomes unhealthy. If a failure occurs, the next healthy ANC on the list will be the default. Admins should also be aware that they should not add an alternate ANC if they don’t want to provision into an alternate region.
Alternate ANCs should use the same domain. The alternate ANCs that you add to your provisioning policy should match the domain you use as your primary ANC if you are using a Hybrid Microsoft Entra Join ANC. If you don’t ensure this match, you can easily end up with some Cloud PCs joined to the primary ANC domain. Additionally, others may join the alternate ANC domain.
Alternate ANCs should be geographically appropriate. This is because the alternate ANCs will be substitutes if the primary ANC becomes faulty. You need to carefully consider the Azure regions in which these ANCs are created. You want to avoid having regions geographically far apart, as well. In this scenario, Cloud PCs in those regions are not suitable for the users you intend to provision.
Monitor your ANC health. Admins should be meticulous about regularly checking the health of primary ANCs. Otherwise, you could find yourself constantly dealing with a primary ANC that is frequently unhealthy. This results in more alternate ANC usage than you anticipated. You can avoid this by ensuring your primary ANC is always healthy, thereby reducing the need for the alternate ANC. An alternate ANC should be a fallback. And you should not add one unless you fully comprehend the consequences that come with provisioning Cloud PCs in a different ANC.
You can have Alternate ANCs in the same region. They don’t necessarily need to be located in a different region. There may be situations where alternate ANCs in the same region provide value.
Image Selection
Windows 365 enables the use of both default and custom operating system images to automatically create Cloud PCs. Microsoft Intune provides users with a gallery containing default images. These can be used when creating provisioning policies for Cloud PCs.
In this gallery, users will find a more than adequate list of regularly updated images available for use. But, if you decide against this, you also get the option to upload your own custom images. However, regardless of whether you prefer default or custom, all images must meet the following requirements:
Supported versions of Windows 10 or Windows 11 Enterprise.
Generation 2 images.
Generalized VM image.
Single Session VM images.
No recovery partition.
The image must never have been Active Directory, Microsoft Entra ID joined, Intune-enrolled, or enrolled for co-management.
In addition to the above, custom images should also exist in an Azure subscription. They should also be stored as a managed image in Azure.
To select an image, head over to the Image page and for Image type, pick one of the following options:
Gallery image – Choose Select > select an image from the gallery > Select. (Note: For Reserve, the default gallery image is Automatic, where Windows 365 selects the latest image.)
Custom image: Choose Select > select an image from the list > Select.
Optional – If you chose Access only apps for Experience in the previous steps, then you can view applications discovered in the image. You will also be available to publish as Cloud Apps after creating the provisioning policy.
Once you’re done with your selection, click Next.
Wrap Up
Windows 365 Cloud PCs provide many benefits that can help businesses enhance their IT operations. End users get to access their desktops remotely and remain productive without having to worry about data security. Businesses can scale their resources up or down depending on their specific needs.
And just as importantly, Windows 365 is designed to be easy to set up by simplifying processes such as the creation of provisioning policies. As we’ve seen in part I of this blog, the process is not complicated, and we’ll be continuing our look into provisioning policies in the second part of this blog.
The Intune Connector for Active Directory, also referred to as the Offline Domain Join (ODJ) Connector, is responsible for joining computers to an on-premises domain during the Windows Autopilot process.
This Intune Connector for Active Directory will create computer objects in a specified Organizational Unit (OU) in Active Directory during the domain join process. Unfortunately for Microsoft, it appears as though there have been some issues with setting up the connector with build 6.2501.2000.5.
Common Issues with the Intune Connector for AD version 6.2501.2000.5
According to the feedback that Microsoft received, here are some of the more common challenges that customers run into.
Issue
Details
Error “MSA account <accountName> is not valid” when signing in.
This happens when the connector successfully creates the MSA but fails to retrieve the data from the domain controller. Several things could cause this, including replication delays between domain controllers in a single domain, or when the user account exists in a different domain to the connector machine. Fortunately, this issue is resolved in build 6.2504.2001.8.
Error “Failed to create a managed service account – Element not found.”
Error “Cannot start service ODJConnectorSvc on computer ‘.’. —> System.ComponentModel.Win32Exception: The service did not start due to a logon failure” after the MSA is created.
This has been observed when the service can’t run as the MSA. Several issues can cause the service to not be able to run as the MSA, including group or local policy restricting Log on as a service privileges.
Error “System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred.”
New and Improved Build
In light of everything, Microsoft released an update and build that intends to address the recent challenges. This update specifically resolves come of the client feedback and it also improves overall functionality. Users can download this new build 6.2504.2001.8 from Microsoft Intune. From this improved version, you can expect:
A new sign in page in the wizard that now uses WebView2, lives on Microsoft Edge, instead of the previously used WebBrowser.
There is resolution to the error “MSA account <accountName> is not valid” that some clients were seeing.
The error “Cannot start service ODJConnectorSvc on computer” is available for mitigation.
The error “System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred” is also available for troubleshooting and mitigation.
Updated Intune Connector
Windows Autopilot continues to use the Intune Connector for Active Directory to deploy hybrid joined Microsoft Entra devices. Going forward, Intune is looking to enhance security. It does so by updating the connector to use a Managed Service Account (MSA) instead of a SYSTEM account.
Customers will find the updated Connector available for download from within Intune. And although the legacy connector may still be available for download, it will no longer have support in late June 2025. So, before that happens, you need to plan to update the connector because this won’t happen automatically.
Updated Troubleshooting Guide
Problem
Solution
Why is the Intune Connector for Active Directory not logging in Event Viewer even though logging is enabled?
The connector originally logged in the Event Viewer directly under Applications and Services Logs in a log called ODJ Connector Service. But, going forward, logging for the connector has been moved to the path Applications and Services Logs > Microsoft > Intune > ODJConnectorService. This means that users who find the ODJ Connector Service log at the original location empty or not updating should check the new path location.
Why does uninstalling the Intune Connector for Active Directory through the Settings app not fully remove the application?
Uninstalling the connector requires you to use both the Settings app and the Intune Connector for Active Directory installed executable ODJConnectorBoostrapper.exe. To uninstall the connector, run ODJConnectorBoostrapper.exe and select the Uninstall option. Make sure that the ODJConnectorBoostrapper.exe installer version matches the version of the connector you’re uninstalling.
Why is the error “The MSA account couldn’t be granted permission to create computer objects in the following OUs” occurring when installing the Intune Connector for Active Directory?
Different types of failures can cause this error including: The admin installing and configuring the connector not having the required permissions. The OU specified in the Intune Connector for Active Directory ODJConnectorEnrollmentWiazard.exe.config XML configuration file doesn’t exist. To view more information on the error and what caused it, see the ODJConnectorUI.log normally located in the following folder: C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard
Why is the error “Cannot start service ODJConnectorSvc on computer ‘.'” occurring when setting up the Intune Connector for Active Directory?
A few reasons could cause this error including the following: The domain has more than one domain controller with a replication latency policy. The MSA was created in one of the domain controllers but the search happened against another domain controller. Wait until replication completes in accordance with your policy or manually sync. Once the replication is complete, then open the connector and choose Configure MSA.A group policy is configured that doesn’t allow services to start as a non-privileged account. Check that the MSA account has Log on as a service privileges granted.
Why is the error “Microsoft Edge can’t read and write to its data directory” occurring?
This error shows that the user needs read/write permissions to the listed directory.
Why did enrollments start failing when using the Intune Connector for Active Directory?
Verify that the Intune Connector for Active Directory is updated to version 6.2501.2000.5 or later and that the legacy version isn’t still being used.
Why are the errors “Navigation to the webpage was canceled” or “Can’t connect securely to this page” occurring while setting up the Intune Connector for Active Directory?
Different types of issues can cause this error including: The server where the admin has chosen to install and configure the Intune Connector for Active Directory lacks the required internet access or required Intune URLs aren’t allowed. The server is sending network requests via TLS 1.0 or 1.1 because PKCS Cryptography is disabled. You can fix this on the server hosting the Intune Connector for Active Directory by deleting the registry key value specified in the following command by running the command from an elevated command prompt: reg.exe delete “HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS” /v Enabled /f
Pre-installation Requirements for Intune Connector
Before carrying out the installation, you need to verify that you meet all the requirements for the Intune Connector for Active Directory:
The connector will work best when installed on a computer running Windows Server 2016 or later with .NET Framework version 4.7.2 or later.
The server hosting the Intune Connector for Active Directory must have access to the Internet and Active Directory.
Multiple connectors can install in a domain, as this will increase scale and availability. Each connector must be able to create computer objects in the domain that it supports.
The administrator carrying out the installation must be a local administrator on the server where the Intune Connector for Active Directory is installing.
For the updated Connector, installation will require an account with the following domain rights:
Required – Create msDs-ManagedServiceAccount objects in the Managed Service Accounts container
Optional – Modify permissions in OUs in Active Directory – if the administrator installing the updated Intune Connector for Active Directory doesn’t have this right, additional configuration steps by an administrator who has these rights may be essential.
Installation Process
Internet Explorer Enhanced Security Configuration
The change to using WebView2 that comes with build 6.2504.2001.8 means that turning off the Internet Explorer Enhanced Security Configuration setting in Windows Server is no longer necessary. So, as long as you have version 6.2504.2001.8 or later of the connector installed, you should not run into problems with the Internet Explorer Enhanced Security Configuration setting.
DOWNLOADING THE CONNECTOR
To install the new connector in your environment, you can download it from the Intune admin center as follows:
Sign into the Intune admin center on the server where you want to install the connector.
Select Devices in the Home screen.
Select Windows in the Devices | Overview screen, under By platform.
Select Enrollment in the Windows | Windows devices screen, under Device onboarding.
Select Intune Connector for Active Directory in the Windows | Windows enrollment screen, under Windows Autopilot.
Select Add in the Intune Connector for Active Directory screen.
In the Add connector window that opens, under Configuring the Intune Connector for Active Directory, select Download the on-premises Intune Connector for Active Directory. The link downloads a file called “ODJConnectorBootstrapper.exe.”
INSTALLING THE CONNECTOR ON THE SERVER
Sign into the the server where you want to install the connector using an account that has local administrator rights.
Before you can install the updated Intune Connector for Active Directory, you need to first uninstall the legacy connector.
Open the downloaded “ODJConnectorBootstrapper.exe.” file to launch the Intune Connector for Active Directory Setup install.
Go through the Intune Connector for Active Directory Setup install.
When installation is complete, tick the checkbox Launch Intune Connector for Active Directory.
SIGNING IN With Intune Connector
Select Sign In in the Intune Connector for Active Directory window, under the Enrollment tab.
Sign in with the Microsoft Entra ID credentials of an Intune admin role under the Sign In tab. Also note that the user account needs to have an assigned Intune license.
With the sign in process done:
A “The Intune Connector for Active Directory successfully enrolled” confirmation window appears. Click OK to close the window.
An “A Managed Service Account with name “<MSA_name>” was successfully set up” confirmation window appears. The name of the MSA has the format “msaODJ#####” with the ##### representing 5 random characters. Notate the name of the MSA created, and then click OK to close the window.
The Enrollment tab shows Intune Connector for Active Directory as officially “enrolled.” The Sign In button will also be gray and Configure Managed Service Account will show as enabled.
Close the Intune Connector for Active Directory window.
VERIFICATION
Once authentication finishes, the Intune Connector for Active Directory will finish installation. After the completion of installation, you can verify that the connector is active by following the steps below:
Head over to the Microsoft Intune admin center if it’s still open. From there, close the Add connector window if it’s still there. Alternatively, if the Microsoft Intune admin center isn’t still open:
Sign into the Intune admin center.
Select Devices in the Home screen.
Select Windows in the Devices | Overview screen, under By platform.
Select Enrollment in the Windows | Windows devices screen, under Device onboarding.
Select Intune Connector for Active Directory in the Windows | Windows enrollment screen, under Windows Autopilot.
In the Intune Connector for Active Directory page:
Confirm that the server displays under Connector name and shows as Active under Status.
Don’t forget to verify that the version is greater than or equal to 6.2501.2000.5 for the updated Connector.
If you don’t see the server displayed, select Refresh or head away from the page before going back to the Intune Connector for Active Directory page. Once the connector installs, it will start logging in the Event Viewer under the path Applications and Services Logs > Microsoft > Intune > ODJConnectorService.
Wrap Up
The previous version of the Microsoft Intune Connector for Active Directory presented several issues for many customers. And as one would expect, these issues reduced the efficiency of the connector and negatively impacted functionality.
Fortunately, with build 6.2504.2001.8, Microsoft is taking heed of the feedback from its clients to make the necessary adjustments. Going forward, clients can look forward to leveraging a connector with better functionality and significantly less issues. And if you do run into any problems, Microsoft provides updates the troubleshooting guide.
Microsoft products and services have been widely used across the globe for decades now. From office environments and universities to people’s homes, Microsoft has consistently provided invaluable service.
As technology has evolved, one of the things that has been at the forefront of a lot of the change that we have witnessed is the issue of access. Considering the popularity of services such as Windows 365 Cloud PC, Azure Virtual Desktop, and Microsoft 365, Microsoft wants its clients to have easy access to devices and applications. Hence the development of the Windows App Portal.
Introducing the Windows App
Windows App is a service that will remotely connect to your Windows devices and apps from Azure Virtual Desktop, Windows 365 Cloud PCs, Microsoft Dev Box, Remote Desktop Services, and PCs. It aims to guarantee you a secure connection to Windows devices and apps. Windows App comes with a lot of flexibility thus allowing you to use it with various types of devices on different platforms and form factors. The service is available for Windows, macOS, Android, Chrome OS, web browsers, meta quest VR headset, and iOS/iPadOS.
Owing to this flexibility, clients can use their desktops, laptops, tablets, or smartphones. Additionally, individuals that will be using a web browser on a desktop or a laptop won’t need to download and install any software. Below are the services and products you can connect to from different platforms:
Connect To
Windows
macOS
iOS / iPadOS
Android /Chrome OS
Web Browser
Meta Quest
Azure Virtual Desktop
Yes
Yes
Yes
Yes
Yes
Yes
Windows 365
Yes
Yes
Yes
Yes
Yes
Yes
Microsoft Dev Box
Yes
Yes
Yes
Yes
Yes
Yes
Remote Desktop Services
No
Yes
Yes
Yes
No
Yes
Remote PC
No
Yes
Yes
Yes
No
Yes
Benefits of Windows App
Windows App aims to provide organizations with a consistent, reliable experience for all devices, enabling secure access from any location. Whether your platform of choice is Azure Virtual Desktop, Windows 365, Remote Desktop, or any of the others, the goal with Windows App is to ensure that the process is easier thereby enabling you to manage and utilize these resources from a single, intuitive app.
In addition, this service is not uniquely for IT admins only. End-users can also take advantage of the many features to tailor their experience to fit their personal workflows. On the other hand, admins will find great value in the added security as well as streamlined management. Other exciting features that businesses can look forward to include:
Unified access – manage and access multiple Windows services, including cloud PCs, virtual desktops, and local PCs, from a single, streamlined interface.
Customizable experience – end-users get the option of personalizing their interfaces thanks to the customizable home screens, multimonitor support, and dynamic display resolutions.
Enhanced experience – take advantage of great features including device redirection, Microsoft Teams optimizations, and easy account switching for an efficient remote working experience.
Prerequisites
WINDOWS
There are a few requirements that you need to meet before you can download Windows App and connect to your Cloud PC from Windows:
As one would expect, you need an internet connection before you can download Windows App from the Microsoft Store and connect to Windows 365. Most people should have no issues here but if you happen to be on a network that blocks internet access then you’ll have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator. Users can also sign in with multiple accounts and switch between them when necessary. A personal Microsoft account can’t be used to sign in.
Your device must be running a supported version of Windows 11 or Windows 10 (21H2 and later including LTSC and IoT Enterprise). If you are running a version of Windows 10 that no longer has mainstream support, you must have your device enrolled in the Extended Security Updates (ESU) program.
MACOS
Before you can download Windows App and connect to your Cloud PC from macOS, you’ll need to meet the following requirements:
An internet connection will be required before you can download Windows App from the Mac App Store and connect to Windows 365. Again, the majority of users won’t have problems here but those using networks that block internet access will have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator. Users can also sign in with multiple accounts and switch between them when necessary. A personal Microsoft account can’t be used to sign in.
Your device must be running macOS 12.0 or later.
iOS/iPadOS
Before you can download Windows App and connect to your Cloud PC from iOS or iPadOS, you need to verify the requirements below:
An internet connection is a requirement before you can download Windows App from the App Store and connect to Windows 365. Most users won’t encounter any challenges during this process but those working on networks that block internet access will have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator. Users can also sign in with multiple accounts and switch between them when necessary. A personal Microsoft account can’t be used to sign in.
Your device must be running iOS or iPadOS 16.0 or later.
ANDROID/CHROME OS
There are a few requirements that you need to meet before you can download Windows App and connect to your Cloud PC from Android or Chrome OS:
An internet connection will be required before you can download Windows App from the Google Play Store and connect to Windows 365. The majority won’t encounter any challenges during this process but those working on networks that block internet access will have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator. Users can also sign in with multiple accounts and switch between them when necessary. A personal Microsoft account can’t be used to sign in.
Your device must be running Android 10 or later and Chrome 126 or later.
WEB BROWSER
You need to meet the requirements listed below before you can download Windows App and connect to your Cloud PC from a web browser:
You must have an internet connection to connect to Windows 365. Most people should have no issues here but if you happen to be on a network that blocks internet access then you’ll have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator.
Additionally, you should ensure that your web browser is supported. Unfortunately, Windows App won’t support mobile web browsers. Supported browsers must also:
Be less than 12 months old on a rolling basis.
Support the AVC codec, which fortunately has support by default on most desktops and laptops.
Have WebGL enabled which you will also find enabled by default on most recent browser versions.
The table below contains information about the web browsers that you can use.
Web Browser
Supported Platforms
Notes
Microsoft Edge
Windows, macOS, Linux, Chrome OS
Version 79 or later
Google Chrome
Windows, macOS, Linux, Chrome OS
Version 57 or later
Apple Safari
macOS
Version 11 or later
Mozilla Firefox
Windows, macOS, Linux
Version 55 or later
META QUEST
You need to meet the requirements listed below before you can download Windows App and connect to your Cloud PC from Meta Quest:
Users will need to have an internet connection to download Windows App from the Meta Store and connect to Windows 365. In most cases, end-users won’t run into problems, but for those using networks that block internet access, they will have to allow access to the list at Required FQDNs and endpoints.
Your user account for Windows 365, and you’re assigned a Cloud PC by your administrator.
Connect To Your Cloud PC
To connect to your Cloud PC on Windows, you should start by downloading and installing Windows App from the Microsoft Store. Once installation is complete, open Windows App. Windows App for Windows may also download as a standalone outside of the Microsoft Store as a .msix file. The download links can be found here.
Next, you need to select Sign in and sign in with your user account for Windows 365. End-users will be signed in automatically if they’re already signed in to a local Windows device with a work or school account on a managed device.
During the first time using Windows App, you can navigate through the tour to learn more about Windows App, then select Done. Alternatively, you can simply select Skip.
Once signed in, select Devices to show your Cloud PC and any other services you have access to. If you don’t see a Cloud PC, contact your administrator.
A search box and filters are available to help you find the Cloud PC that you want to connect to.
Select Connect on a Cloud PC to connect. Once the connection to your Cloud PC is complete, you’re ready to start using it. End-users can benefit from quick access by adding their favorite Cloud PCs to Task view in Windows 11 or the Favorites tab of Windows App.
The process for connecting to a Cloud PC on macOS, iOS/iPadOS, Android/Chrome OS, web browser, and Meta Quest are similar to this one. The specifics for each process are in this article.
End-users should expect to find a customizable home screen that should be perfectly adaptable to one’s workflow needs. As mentioned earlier, flexibility is one of the key aspects of Windows App and this will allow end-users Windows access across multiple different services and remote PCs from a single place.
Features
Not only that, but end-users can also pin the favorites they access most. And for those with multiple accounts, the account switching feature makes switching between accounts a simple, seamless process. End-users will get several other features to enhance the remote experience and these include:
Multiple monitor support – end-users get the option to use multiple monitors thereby enabling them to work more efficiently.
Custom display resolutions – the display resolution of a Cloud PC or remote app is customizable so that it fits the unique needs of the user.
Dynamic display resolutions and scaling – to perfectly match your device, Windows App will automatically adjust the display resolution and scaling of your Cloud PC or remote app.
Device redirection, such as webcams, audio, storage devices, and printers – devices can redirect to a Cloud PC or remote app.
Microsoft Teams optimizations – Windows App is optimized for Microsoft Teams thus ensuring a great user experience.
Sign in with multiple accounts and easily switch between them.
Wrap Up
Microsoft has made the transition from the Remote Desktop app to Windows App to provide businesses with a portal that delivers a better experience. End-users will benefit from unified access to multiple Windows services as well as customizable home screens, multimonitor support, and dynamic display resolutions. All of these are crucial to giving Windows 365 Cloud PC users a more seamless experience. And as Cloud PC users move away from windows365.microsoft.com, they will benefit from the enhanced workflows that the versatile Windows App will provide.
The Download-OD4BAccount.ps1 script just got another major update – and this one takes it to a whole new level.
Following the September refresh that added full pagination and improved reliability for large OneDrive libraries, this new release focuses on smarter downloads, better handling of OneDrive “shortcuts,” and a cleaner, dependency-free approach to working with the Microsoft Graph API.
And once again – a big thank-you to Gary Chamryk and others in the community for their real-world feedback, testing, and suggestions that made this update possible.
Why Another Update?
After the last version went live, several users (including Gary) noticed edge cases where certain file types or OneDrive “shortcut” folders didn’t export correctly.
Digging into the logs revealed that the Microsoft Graph PowerShell SDK’s @microsoft.graph.downloadUrl property can occasionally fail or behave inconsistently when handling shortcuts to remote drives or shared folders.
That’s where this new iteration comes in – with a cleaner, more reliable download engine built entirely on direct /content requests via the Graph API. The script now uses: Invoke-MgGraphRequest -OutputFilePath
to stream file content directly from Graph to disk – no longer relying on @microsoft.graph.downloadUrl. This eliminates transient URL expiration issues and improves consistency across large multi-user exports.
Full OneDrive Shortcut (remoteItem) Support
OneDrive “shortcuts” (also known as remoteItems) are now fully supported. The script automatically follows the referenced driveId and itemId, so both files and folders linked from other OneDrives or SharePoint document libraries are downloaded seamlessly.
Paths That Match the Real OneDrive View
Exported folder structures now reflect the actual visible OneDrive hierarchy, including shortcut names. That means what you see in your OneDrive web UI is exactly what you’ll get on disk — no more confusing “shortcut_12345” placeholders.
Multi-Threaded Downloads, Inside Worker Runspaces
The existing multi-threaded model remains, but now imports the Microsoft Graph authentication module inside each worker runspace. This ensures every parallel job runs independently with full Graph context, even in long-running sessions or constrained environments.
Original CSV Reports Intact
Reporting hasn’t changed – the familiar CSV export for file listings and results is preserved, ensuring backward compatibility for scripts or processes that rely on it.
he script still requires Microsoft Graph PowerShell and admin consent for:
Organization.Read.All
User.Read.All
Directory.Read.All
Files.Read.All
When to Use This Version
Offboarding or Archival – Export full OneDrive content (including shared shortcuts) for departing users.
Legal or Compliance Holds – Capture exact user views of OneDrive, including remote shared content.
Tenant-to-Tenant Migrations – Seamlessly move data structures between organizations without breaking links.
Community-Driven Evolution
This update wouldn’t exist without direct input from the field. Gary Chamryk and others in the community helped identify the gaps, test fixes, and validate the new approach.
The best part of open tooling is that it keeps evolving with real-world usage — and this release is proof of that.
Get the Latest Version
🔗 Download the updated script:Download-OD4BAccount.ps1 (available on the same GitHub repository as before)
If you’re already using the script, I strongly recommend upgrading – especially if you’re exporting libraries that include OneDrive shortcuts or shared content.
As always, feedback and PRs are welcome. These scripts only get better because of the community behind them.
