BlackLotus and the 2026 Secure Boot Certificate Expiry: What It Means and How to Fix It

Posted on April 8, 2026 by Thomas.Marcussen

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:

Torbjörn “Mr T-Bone” Granheden (MVP, Enterprise Mobility) – Update Secure Boot Certificate by using Intune Remediation, Take 2. T-Bone has been iterating on his detection and remediation scripts as Microsoft has refined the recommended registry values, and his “Take 2” post is the most current version of his approach. This is the article I would point any Intune admin to first.
Richard M. Hicks (MVP) – Windows Secure Boot UEFI Certificates Expiring June 2026. Richard provides a clean walkthrough of the problem and includes a handy Get-UEFICertificate PowerShell function for inspecting the current state of Secure Boot on a device.
Microsoft Windows IT Pro Blog – Act now: Secure Boot certificates expire in June 2026. The official call to action from Microsoft, with the timeline and the high level guidance.
Microsoft – Secure Boot playbook for certificates expiring in 2026. The detailed playbook, including the registry values, the scheduled task, and the recommended sequence of operations.
Microsoft Support – Secure Boot certificate updates: Guidance for IT professionals and organizations. The canonical reference for what each registry value does and what state to expect at each step.
4sysops – Monitoring Secure Boot certificate installation status with Intune and PowerShell. A practical write up of the monitor-first approach using Intune Remediations.

GitHub Scripts You Can Use Today

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.
calibur/SecureBoot-ManagedOptIn-Intune-Remediation – A minimal Intune remediation that opts a device in to fully managed Microsoft handling of the DB and KEK updates.
SimoneTermine/MicrosoftIntune – SecureBoot_UpdateCerts – Detection and remediation scripts using the AvailableUpdates=0x5944 registry trigger.

Conclusion

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.

Synced Passkeys in Microsoft Entra ID – Now Generally Available

Posted on April 2, 2026 by Thomas.Marcussen

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)
Create a passkey profile for your target group
Allow synced passkey providers (iCloud Keychain, Google, third-party)
Assign the profile to a security group
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.

Wrap Up

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.

Key Features For Managing Windows 365 Cloud PCs

Posted on March 31, 2026 by Thomas.Marcussen

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:

Navigate to https://windows365.microsoft.com and sign in.
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.
- 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.

Fix Microsoft Teams Dial Pad Not Working

Posted on February 19, 2026 by Thomas.Marcussen

If you’ve ever had a user say:

“The dial pad is there, but I can’t click it.”
“Join meeting does nothing.”
“Teams opens, but it’s just broken.”

You already know what’s coming.

And no – it’s usually not licensing.

In many cases, it’s a corrupted local Teams client.

In this article, I’ll show you:

Why Microsoft Teams breaks like this
Which common error codes this reset resolves
When the issue is client-side vs policy-side
And a full PowerShell script to fix it properly

The Real Problem: Teams Is a Web App in Disguise

Microsoft Teams (especially New Teams) is essentially:

WebView2
Cached profile data
AAD token storage
Local state
MSIX container

When something corrupts:

WebView2 rendering
Authentication tokens
Local Teams cache
SSO credentials
Proxy configuration

The result is classic:

Dial pad visible but not clickable
Join meeting button does nothing
Blank white screen
Endless loading spinner
Random sign-in prompts

Common Microsoft Teams Error Codes This Script Fixes

This reset script resolves a large number of client-side errors, including:

Authentication Errors

CAA50021
CAA50024
CAA20002
0xCAA70004
0xCAA82EE2
0x80048823
0x800704CF

Meeting Join / UI Errors

Join button unresponsive
Dial pad not clickable
Blank calendar view
“We couldn’t connect you” error
“Something went wrong” generic UI errors

WebView2 / Rendering Issues

White screen on launch
UI elements missing
Buttons visible but not interactive

0x80072EFD
0x80072EE7
0x801901F7

If Teams Web works but the desktop client does not -> this script is almost always the fix.

When This Script Will NOT Help

If the dial pad is greyed out, the problem is not the client.

It’s usually:

No Teams Phone license
No OnlineVoiceRoutingPolicy
No Calling Policy
Enterprise Voice not enabled

Client reset won’t fix licensing.

Clickable but broken = client
Greyed out = policy

Important distinction.

What the Script Actually Does

This is not just a “delete cache” script.

It performs a full user-context reset:

Stops all Teams-related processes
Removes Classic Teams folders
Removes New Teams MSIX profile folders
Clears WebView2 cache
Optionally removes stored AAD/Office credentials
Optionally resets WinHTTP proxy
Relaunches Teams cleanly

It does NOT:

Uninstall Teams
Change licensing
Affect other users
Modify tenant configuration

Safe for enterprise usage.

Reset-TeamsClient.ps1 – https://github.com/ThomasMarcussen/assortedScripts/blob/master/Reset-TeamsClient.ps1

Simplifying The Creation of Windows 365 Provisioning Policies (part II)

Posted on February 12, 2026 by Thomas.Marcussen

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.microsoft web 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.

Simplifying The Creation of Windows 365 Provisioning Policies (part I)

Posted on February 2, 2026 by Thomas.Marcussen

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.

Why Choose Windows 365?

A simple web search will probably show you several options that your business has when trying to pick a virtual machine solution. So, here are a few reasons why the Windows 365 Cloud PC may be the ideal solution for your organization:

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.
You need to have an administrator role. This can be either an Intune Administrator in Microsoft Entra ID or a Windows 365 Administrator if you want to provision Cloud PCs.

Entra Join comes with three options for network:

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.

Microsoft Intune Connector for Active Directory – Updated and Improved

Posted on December 16, 2025 by Thomas.Marcussen

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.

Say Goodbye To windows365.microsoft.com – Welcome The Windows App Portal

Posted on November 6, 2025 by Thomas.Marcussen

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:

A Meta Quest 3 or Quest 3S headset.
Users must also have a Meta Quest for Business subscription installed on their headsets to connect to Windows 365.
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.

New Release: Full OneDrive Shortcut Support, Smarter Downloads, and Enhanced Reporting for Download-OD4BAccount.ps1

Posted on October 28, 2025 by Thomas.Marcussen

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.

Quick Start

The syntax remains simple and consistent:

.\Download-OD4BAccount.ps1 -Username [email protected] `
                           -Destination "D:\OD4B" `
                           -ThreadCount 3 -Verbose

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.

New and Improved: Download All OneDrive Files for a User with PowerShell – Updated Script

Posted on September 22, 2025 by Thomas.Marcussen

Back in early 2023 I published a post:
PowerShell script to download a user’s OneDrive content

That original script – Download-OD4BAccount.ps1 – quickly became one of my go-to tools for off-boarding and archiving user data. It let administrators export an entire OneDrive for Business library directly to on-premises storage without paying Microsoft to keep the data around.

Since then, the script has seen heavy real-world usage, and thanks to some great community feedback it just got a serious upgrade.

Why the Update

A reader recently reached out after running the script against a very large OneDrive.
They noticed that not every file was exported.

After some digging, we discovered the root cause:

The Microsoft Graph PowerShell cmdlets Get-MgUserDriveRootChild and Get-MgUserDriveItemChild now page their results by default.
Without explicit pagination, large folders could quietly drop files from the export.

This was a subtle but critical issue – your export might look fine at first glance, but some files would never make it to disk.

What’s New in the Updated Script

The refreshed script keeps the original simplicity and speed but addresses these limitations and more.

– Full Pagination Support

Both Get-MgUserDriveRootChild and Get-MgUserDriveItemChild now run with the -All switch, ensuring every item – even in massive libraries – is fetched.

– Reliable Folder Traversal

Recursive folder expansion now preserves the full path, so deep folder hierarchies are exported exactly as they appear in OneDrive.

– Broader Microsoft Graph Scopes

The connection now requests:

Files.Read.All, User.Read.All, Directory.Read.All

These scopes ensure cross-user OneDrive exports work reliably across tenants and admin scenarios.

– Cleaner Reports

Removed an undefined $Job field from the file report, preventing runtime errors.

– More Robust Downloads

The script now checks and creates destination directories before writing each file, so missing folder paths won’t break the download process.

– Improved Batching and Multi-Threading

Thread batching logic is more resilient when splitting large file lists, while keeping the same multi-threaded performance boost that made the original so fast.

Quick Start

The usage remains the same:

.\Download-OD4BAccount.ps1 -Username [email protected] `
                           -Destination "D:\OD4B" `
                           -ThreadCount 3 -Verbose

Prerequisites

Microsoft Graph PowerShell Module (the script will auto-install if missing).
Azure AD user with admin consent to approve:
- Organization.Read.All
- User.Read.All
- Directory.Read.All
- Files.Read.All (new requirement)

When to Use This Script

Off-boarding – export a departing employee’s OneDrive to a secure archive before disabling their account.

Legal hold or compliance – capture a one-to-one copy of a user’s OneDrive library for audit purposes.
Bulk migration scenarios – move large OneDrive libraries to on-prem or a different tenant without relying on paid retention.

Community-Driven Improvement

This update wouldn’t have happened without feedback from the community.
Real-world use exposed a change in the Microsoft Graph SDK behaviour, and the fix – adding -All – was simple but critical.

If you’ve used the original version, I highly recommend updating your copy with the new script to guarantee complete and reliable exports.

Download the updated script: Download-OD4BAccount.ps1

Feel free to share feedback or improvements. Real-world input keeps these tools evolving and useful for everyone.

A Quick Refresher on BlackLotus

The Secure Boot Certificate Expiry: What Is Actually Going Away in 2026

How BlackLotus and the Certificate Expiry Are Connected, but Not the Same Thing

How to Fix It

Things That Will Trip You Up

Reference Articles From the Community

GitHub Scripts You Can Use Today

Conclusion

Synced vs. Device-Bound – What’s the Difference?

What Shipped Alongside It

Getting Started

Further Reading

Wrap Up

Establishing a Windows 365 Environment

What if Provisioning Fails?

Resizing a Cloud PC

Reprovisioning A Cloud PC

How To Restore A Cloud PC

How To Deprovision A Cloud PC

Method 1

Method 2

Cleaning Up

Evaluating Cloud PC Usage

Cloud PC utilization report page (tenant data)

Scaling Your Cloud PC Environment

Scaling Up

Scaling Down

Conclusion

The Real Problem: Teams Is a Web App in Disguise

Common Microsoft Teams Error Codes This Script Fixes

Authentication Errors

Meeting Join / UI Errors

WebView2 / Rendering Issues

Network / Proxy Related

When This Script Will NOT Help

What the Script Actually Does

The Provisioning Process

Determine Your Configurations

ADDITIONAL SERVICES

Scope Tags

Creating Assignments

Review and Create

Making Changes to Provisioning Policies

Name changing

Applying the Current Configuration for Enterprise and Frontline in Dedicated Mode

Applying the Current Configuration for Frontline in Shared Mode

Getting Started

Access Options

Home Page

Conclusion

Why Choose Windows 365?

Significance of Provisioning Policies

KEY INFORMATION

Creating a Provisioning Policy

Deciding on a Join Type

MICROSOFT ENTRA JOIN

Entra Join comes with three options for network:

HYBRID MICROSOFT ENTRA JOIN

Choosing an Azure Network Connection

Using Alternate ANCs

USE CONSIDERATIONS

Image Selection

Wrap Up

Common Issues with the Intune Connector for AD version 6.2501.2000.5

New and Improved Build

Updated Intune Connector

Updated Troubleshooting Guide

Pre-installation Requirements for Intune Connector

Installation Process

DOWNLOADING THE CONNECTOR

INSTALLING THE CONNECTOR ON THE SERVER

SIGNING IN With Intune Connector

VERIFICATION

Wrap Up

Introducing the Windows App

Benefits of Windows App

Prerequisites

WINDOWS

MACOS

iOS/iPadOS