When it comes to Windows 365 Cloud PC, there are different options available to cater to the different needs of various businesses. As one can imagine, a massive corporation operating in countless countries across different continents will have significantly different needs to those of a smaller organization with a handful of offices.
However, the need for Cloud PC Usage insights is something that all these businesses have in common. It’s important to have up-to-date information regarding usage patterns of Cloud PCs, how many Cloud PCs are required, correct size of Cloud PCs, and more. Having this data can help businesses operate much more efficiently.
Utilization Report
With the Cloud PC Utilization Report, Microsoft is offering clients a tool that will help them monitor and optimize Cloud PC usage. The data available shows you not only the amount of time that users are spending on their Cloud PCs but when they were last connected as well.
After noting Cloud PCs with low usage, businesses can then reduce operating costs by reassigning under-used Cloud PC licenses to other users who might use them more often. Another cost-cutting measure that organizations can implement is to identify and deprovision Cloud PCs that remain inactive for extended periods of time. To access this Cloud PC Utilization Report, you need to sign in to the Microsoft Intune admin center, select Devices > Cloud PC performance > Cloud PC utilization.
Tenant Data
On the Cloud PC Utilization Report page, you’ll find information with tenant data aggregated for the chosen timespan (28, 60, or 90 days):
This histogram gives you 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 name
User UPN: The user’s identifier in Active Directory in the form of an email address.
PC type
Time connected: The total hours that the user has been connected to the Cloud PC over the last four weeks.
Date last connected: The date when the user most recently connected to their Cloud PC (within the last 60 days). If the user isn’t currently connected to the Cloud PC, this date is the sign out time. If the user is connected to the Cloud PC, this date is the most recent connection time.
Date created: The date the Cloud PC was created.
Device type: The type of Cloud PC based on the offering (Enterprise, Frontline dedicated, Frontline shared).
FILTERS
Clients will also have access to an Add filters option that enables them to filter the table by PC type,time connected, and date last connected. Filters can be a key tool that organizations can leverage to have a better understanding of usage patterns. By analyzing this information, decisions about whether to deprovision or downgrade underused Cloud PCs become much easier to make.
Device Level Data
If you want to see the same usage data but on a per Cloud PC basis, you can:
Sign in to the Microsoft Intune admin center, select Reports > Cloud PC overview > Cloud PC utilization.
Select a device and then select Performance (preview).
The Time connected section shows usage data for this Cloud PC. For more detail, in this section, select View report.
Recommendations
Organizations using Windows 365 Cloud PCs will not only get usage insights but Cloud PC recommendations as well. The objective, in this case, is to provide businesses with an AI-powered tool that helps admins with determining the correct size of Cloud PC. This feature is designed to assess end-user Cloud PC usage patterns, platform level resource utilization data, and performance needs to help businesses come up with the optimal configuration for their Cloud PCs.
An evolving model will then analyze the data provided to find out how an organization’s Cloud PCs are working. It can also determine correct size and utilization capabilities. To access this Cloud PC Recommendations Report, you need to sign in to Microsoft Intune admin center, select Reports > Cloud PC Overview > Cloud PC recommendations.
OVERVIEW TAB
Cloud PC Insights
Details
Rightsized
These are Cloud PCs that are used regularly and whose size correctly matches the workload that they are being used for.
Undersized
These are Cloud PCs that are not powerful enough for the workload they are dealing with. As a result, end-users are probably getting a poor experience and need to increase the device’s resources by re-sizing to a larger SKU.
Oversized
In this, the Cloud PCs have far too much power for the workload they are supporting. End-users can still get the same quality experience with fewer resources. Businesses can free up resources by re-sizing these Cloud PCs to a smaller SKU.
Underutilized
These Cloud PCs are used infrequently or not at all. Businesses should consider them as potentially not needed. Any Cloud PC with less than 40 hours of active connected time over a 28 day period falls into this category.
Wrap Up
Windows 365 Cloud PCs offer businesses a powerful virtualization service that empowers employees to work from anywhere. Being able to access one’s desktop using multiple devices, regardless of location, can be a massive benefit for productivity. Not to mention the fact that Cloud PCs can provide significant computing resources.
With all this in mind, however, organizations need accurate usage insights to ensure that the resources they are paying for match their needs. And this is precisely what they get with the Cloud PC Utilization Report.
This feature enables administrators to have a clearer picture of the resources at their disposal along with usage. Having this up-to-date data will help businesses better manage their costs by increasing or decreasing Cloud PC resources as necessary.
Introduction: The Challenge of Managing Microsoft Teams Rooms
Microsoft Teams Rooms (MTR) are purpose-built devices that bring seamless Teams meetings into physical conference rooms. However, if you’re an IT admin or consultant trying to manage these devices with Microsoft Intune, you may have already hit a major wall: you can’t deploy standard applications like Win32 or MSI packages.
In this post, I’ll walk you through:
Why app deployment fails on MTRs
How to use Intune Proactive Remediation Scripts to install apps anyway
A real-world script-based workaround you can implement today
This article is especially useful for IT administrators, Microsoft 365 consultants, and organizations managing MTR on Windows devices using Microsoft Intune.
What Are Microsoft Teams Rooms (MTR) Devices?
Microsoft Teams Rooms are specialized endpoints running Windows or Android, designed to facilitate video conferencing in meeting spaces.
This article focuses on MTR on Windows, which:
Boots into a kiosk-like shell
Uses a locked-down local user account (usually “Skype”)
Automatically launches the Teams Rooms app
Is managed differently from typical Windows endpoints
Why Are MTRs So Locked Down?
Because they’re designed to do one thing very well: run meetings reliably and securely. That means:
Minimal background processes
No user distractions
Reduced vulnerability footprint
Unfortunately, this also means limited support for app deployment using traditional Microsoft Intune methods.
Why Standard App Deployment Doesn’t Work on MTR
Let’s quickly review how app deployment in Intune normally works:
You upload a Win32 or MSI app
Intune pushes it to the device
The app installs silently in the background
But MTRs are a special case:
Issue
Description
Kiosk Shell
MTR devices run a locked-down shell that prevents user interaction.
Limited Admin Access
The logged-in “Skype” user doesn’t have full local admin rights.
Silent Installs Often Fail
Even SYSTEM-context installs can hang or fail silently.
Win32 App Deployment Not Supported
MTRs are excluded from full app deployment via Intune.
TL;DR: Intune treats MTRs like they’re manageable—but for apps, they’re basically off-limits.
What Can You Manage on MTR with Intune?
Feature
MTR Support?
Enroll in Intune
✅ Yes
Configuration Profiles (Wi-Fi, Certificates)
✅ Yes
Compliance Policies
✅ Yes
PowerShell Scripts
⚠️ Limited
Win32/MSI App Deployment
❌ Not Supported
Store App Deployment
❌ Not Supported
Remediation Scripts
✅ Yes — this is our workaround!
The Workaround: Use Proactive Remediation Scripts
What Are Proactive Remediations in Intune?
Proactive Remediations are part of Endpoint Analytics in Microsoft Intune. They allow you to:
Detect issues on endpoints (e.g., missing apps or settings)
Run scripts in the SYSTEM context to remediate them
And because these scripts run as SYSTEM, they can bypass the user restrictions imposed by the MTR shell. That’s the secret sauce here.
Step-by-Step: Deploy Apps to MTR Devices Using Remediation Scripts
Step 1: Choose an Application
Pick an application with a silent installer. Examples include:
Zoom Rooms Plugin
Custom certificate tools
Remote support agents
Pro tip: Avoid apps that require UI interaction or restart the system.
Step 2: Host the Installer
Since you can’t upload Win32 apps, host the installer externally:
Azure Blob Storage with SAS token
SharePoint Online
A secure HTTPS server
Step 3: Write the Detection Script
This script checks whether the app is already installed.
For complex applications, consider a manual install window, or coordinate with the OEM.
Alternatives to Intune Remediation Scripts
Method
Notes
Manual Deployment
Good for one-off fixes
OEM Management Tools
Logitech Sync, Poly Lens, etc.
Group Policy
Works for Hybrid AAD Join MTRs
Teams Pro Management
Useful for Teams config, not apps
Conclusion: MTR App Deployment is Possible—With the Right Tools
Deploying applications to Microsoft Teams Rooms using Intune isn’t supported natively—but that doesn’t mean it’s impossible. With a bit of scripting and smart use of Proactive Remediation, you can achieve automated, scalable, and relatively safe application installs.
This method:
Uses supported Intune features (Endpoint Analytics)
Microsoft is offering clients an updated Intune Connector for Active Directory and this connector is what Intune will be using starting from Intune 2501. This connector uses Windows Autopilot to deploy devices that are Microsoft Entra hybrid joined.
The updated version of the connector aims to enhance security and will be using a Managed Service Account (MSA) instead of a SYSTEM account. Customers currently using the old version of the Intune Connector for Active Directory (that uses the local SYSTEM account) should know that this connector will no longer have support, starting in late June 2025.
Therefore, it’s important to start planning for the update because once support ends, enrollments from the old connector build will no longer be acceptable.
Key Features of the Intune Connector
The main role of the Intune Connector for Active Directory is to join computers to an on-premises domain and add them to an organizational unit (OU) allowing for central management and policies.
The Intune Connector also places joined computers within a specific OU, something that helps establish granular control over device configurations and settings. Furthermore, customers will also benefit from hybrid enrollment of devices which offers the convenience of device management by both on-premises AD and Intune.
The Intune Connector plays a key role in leveraging Windows Autopilot to set up and deploy devices. And for all those already using Autopilot, they will know that this feature will have a huge impact in making life easier for customers by simplifying deployment processes.
In addition to all the above, the Intune Connector ensures that the policies defined in both AD and Intune continue to enforce, thus offering compliance and consistency.
Why Switch to Managed Service Accounts?
As the new version of the Intune Connector for Active Directory makes the change to using Managed Service Accounts, it’s important to understand why they are important. The use of MSAs will enable the new connector to follow least privilege principles and thereby strengthen security.
With MSAs, clients enjoy managed domain accounts that have automatic password management. They are also generally permissible with privileges to perform their duties. With such measures in place, there is a reduction in the risk of compromise, intentional or otherwise.
You can only use standalone MSAs on one domain-joined machine and can thus only access resources within that domain. MSAs can easily and securely run services on a computer while simultaneously maintaining the capability to connect to network resources as a specific user principal. When taking all of this into account, it’s not difficult to see why Microsoft views the use of MSAs as better for the Intune Connector moving forward.
Securing The Future
The security update to the Intune Connector for Active Directory fits in seamlessly with Microsoft’s Secure Future Initiative. Microsoft is uniquely ideal within the tech industry to play a key role in safeguarding the future for all its clients.
As such, the tech giant is taking a comprehensive approach to cybersecurity with a key focus on certain areas that are critical to enhancing security across the board. There continues to be substantial progress in these areas:
identity and secret protection
Updates to Entra ID and Microsoft Account (MSA) are live for both public and U.S government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service.
Microsoft has continued to drive broad adoption of its standard identity SDKs, which provide consistent validation of security tokens. As a result, we now see this standardized validation covering more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications.
Tenant Protection and Isolation of Production Systems
A full iteration of app lifecycle management for all production and productivity tenants has been performed. This has resulted in the elimination of 730,000 unused apps. Additionally, because of the elimination of 5.75 million inactive tenants, the potential cyberattack surface has become significantly smaller.
Not only that, but a new system to streamline the creation of testing and experimentation tenants with secure defaults is available. It also enforces a strict lifetime management.
Protect networks
More than 99% of physical assets on the production network record in a central inventory system. This enriches asset inventory with ownership and firmware compliance tracking. Virtual networks with backend connectivity are isolated from the Microsoft corporate network, as well. They are additionally subject to complete security reviews to reduce lateral movement.
With the expansion of platform capabilities such as Admin Rules to ease the network isolation of platform as a service (PaaS) resources such as Azure Storage, SQL, Cosmos DB, and Key Vault, Microsoft has made it easier for customers to secure their own deployments.
Protection of engineering systems
We are now experiencing more consistent, efficient, and trustworthy deployments because 85% of production build pipelines for the commercial cloud are now using centrally governed pipeline templates.
Other notable changes include shortening the lifespan of Personal Access Tokens to seven days, disabling Secure Shell (SSH) protocol access for all Microsoft internal engineering repos, and massively reducing the number of elevated roles with access to engineering systems.
Moreover, proof of presence checks for critical chokepoints in software development code flow are now available.
THREAT DETECTION AND MONITORING
A lot of progress continues toward the goal of pushing all Microsoft production infrastructure and services to adopt standard libraries for security audit logs. Additional efforts include those to emit relevant telemetry and to retain logs for a minimum of two years.
A good example is the establishment of central management and a two-year retention period for identity infrastructure security audit logs, including all security audit events throughout the lifecycle of current signing keys. Add to this the fact, that no less than 99% of network devices now have enablement with centralized security log collection and retention.
Accelerate response and remediation
We can now observe improved time to mitigate for critical cloud vulnerabilities because of the recent process updates across Microsoft. Customers will also appreciate the greater transparency provided by the publishing of critical cloud vulnerabilities as common vulnerability and exposures (CVEs). This is especially helpful even when there are no direct customer action requirements.
In addition to this, the establishment of the Customer Security Management Office (CSMO) will go a long way to improve public messaging and customer engagement for security incidents.
Required Permissions
As we look at the new version of the Intune Connector for Active Directory, one of the key areas that can help us distinguish this new connector from its previous version is doing a comparison of account permissions:
Create Computer Object Rights (required for hybrid Autopilot scenario)
Unlimited if connector is on the same machine as domain controller. Delegation is required if connector is not on the domain controller.
Explicit delegation required
Pre-requisites
As with any product or application, there are certain requirements that all customers intending to use the Intune Connector for Active Directory will need to meet. So, before proceeding with the set up of the new Intune Connector, you need to verify that you can meet all the pre-requisites. These requirements include:
The computer you’re installing Intune Connector for Active Directory to must be running Windows Server 2016 or later.
You should also verify that you have .NET Framework version 4.7.2 or later installed.
To facilitate communication with Microsoft’s Intune service, the server hosting the Intune Connector should have internet access.
The Intune Connector will need standard domain client access to domain controllers.
Customers must verify that they have a Microsoft Entra account with Intune Service Administrator permissions, as this is a requirement to download and manage the connector.
Also needed will be a domain account with local administrator privileges and the ability to create msDS-ManagedServiceAccount objects.
Verify that the Windows Server configuration aligns with the Desktop Experience and, for versions 2019 or earlier, install the Microsoft Edge browser manually before connector setup.
The Microsoft Entra account should have an Intune license assigned to it.
For those that will be using Hybrid Azure AD Join, they should check that it’s configured via Azure AD Connect tool.
Lastly, the Intune Connector machine must have the appropriate delegated permissions to create computer objects in the target OU.
Setting Up The Connector
To setup the new Intune Connector for Active Directory, you need to start by uninstalling the existing connector. You can do this by uninstalling from the Settings app on Windows and then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). With that done, you can download the connector build from Intune and then perform the installation (as described in detail in my previous blog).
Configuring organizational units (OUs) for domain join
Customers should be aware that by default MSAs won’t have access to create computer objects in any Organizational Unit (OU). Thus, if you intend to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. Fortunately, this is something you can do before or after connector enrollment:
Update ODJConnectorEnrollmentWizard.exe.config:
Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard”
Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin
OU name should be the distinguished name.
You need to be aware that the MSA is only granted access to the OUs configured in this file (and the default Computer’s container). This means that if any OUs are removed from this list, completing the rest of the steps will revoke access.
Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button.
If successful, a pop up will appear showing success.
Using the Intune Connector with multiple domains
For those who are already using the connector with more than one domain, they will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain.
Configuring the connector
Customers should install the Intune Connector for Active Directory on each of the domains that they want to use for domain join. In case a second account redundancy is required, customers must install the connector on a different server (in the same domain).
Go through the connector configuration steps meticulously and verify that everything has been done correctly. Also check that the MSA has the appropriate permissions on the desired OUs.
Verify that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5.
Configure Domain Join profile
Follow the steps given below.
Start by creating a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot.
Target the domain join profile to the appropriate device groups.
Wrap Up
The Intune Connector for Active Directory provides an essential tool for managing hybrid devices in an Intune environment. With its many available features, customers will get centralized management capabilities for their environments thus allowing businesses to operate more efficiently.
But, with security having been a big concern for many, Microsoft has made the switch to using a Managed Service Account instead of a SYSTEM account. This action has effectively tightened security in customers’ environments. Going forward, the previous version of the Intune Connector will no longer be supported. Therefore, if you are yet to download and set up the new Intune Connector for Active Directory, the sooner you do the better.
Troubleshooting Errors Like 0x80180014 and Navigating Device Records in the Admin Portals
Introduction
Managing devices in a modern enterprise requires a clear understanding of how devices enroll into your organization’s management ecosystem, particularly in Microsoft Intune and Microsoft Entra ID (formerly Azure Active Directory). With the increasing adoption of mobile device management (MDM) and the demand for secure cloud identity integration, IT administrators frequently encounter various behaviors—and sometimes, errors—that can be confusing.
One of the more common challenges occurs when a device fails to enroll correctly, presenting cryptic error codes such as 0x80180014. This blog post provides a deep dive into how device registration and visibility work across Microsoft Intune and Entra ID. We’ll also unpack typical issues, explain where devices appear in each admin center, and how to cleanly troubleshoot enrollment errors.
This issue was thoroughly explored during a troubleshooting session with Carsten Lund Meilbak, the go-to expert for everything Microsoft Teams and Teams Meeting Room environments, where we investigated problems with a Microsoft Teams Room (MTR) device. During the session, we discovered how certain Autopilot scenarios could result in orphaned device records in Entra ID, preventing re-enrollment.
What Is Microsoft Intune?
Microsoft Intune is a cloud-based endpoint management solution that helps organizations manage user access, enforce compliance, and deploy apps and configurations to devices. Whether the devices are Windows, Android, iOS, or macOS, Intune serves as the command center for policy enforcement and inventory tracking.
What Is Microsoft Entra ID?
Microsoft Entra ID (previously known as Azure Active Directory) is Microsoft’s cloud-based identity and access management service. Devices can be registered, joined, or hybrid joined to Entra ID, and the identity status of these devices is critical for secure access, Conditional Access policies, and MDM enrollment flows.
Section 1: Device Lifecycle – From Registration to Management
Step 1: Device Registration in Entra ID
When a device first connects with a corporate identity, it can take one of several paths:
Azure AD Registered (Workplace Join):
Typical for BYOD (Bring Your Own Device).
Appears under the user’s profile in Entra ID.
Usually paired with manual or conditional enrollment in Intune.
Azure AD Joined:
Common for corporate-owned devices.
Full control over the device by the organization.
Required for Autopilot provisioning and device-based Conditional Access.
Hybrid Azure AD Joined:
Devices are joined to on-prem Active Directory and then synced to Entra ID via Azure AD Connect.
Offers compatibility for legacy environments still using GPOs or SCCM.
Step 2: Device Enrollment in Intune
After a device is registered in Entra ID, it may also become enrolled in Intune:
Automatic Enrollment via group policies or Autopilot.
Manual Enrollment by end-users through “Access Work or School” in Windows settings.
Co-management Scenarios where both Intune and ConfigMgr (SCCM) share responsibilities.
This enrollment is what allows policies, apps, and configurations to be deployed to the device.
Microsoft Entra Admin Center → Devices → All Devices
Here, you’ll see all devices that are registered or joined to your Entra tenant.
Each record provides the following key information:
Device Name
Join Type (Azure AD Registered, Azure AD Joined, or Hybrid)
OS Type and Version
MDM Enrolled (Yes/No)
Compliant (Yes/No)
Owner (User Principal Name)
If a device shows up here but not in Intune, it might not be enrolled in MDM. You can confirm this via the MDM Enrolled column or by selecting the device and checking details.
This view shows all devices that are successfully enrolled in Intune, either through automatic enrollment or manual addition.
Important fields include:
Compliance Status
Enrollment Type (Corporate, BYOD, Autopilot)
Primary User
Managed By
Last Check-In
Device Category
If a device is listed here but shows a warning or non-compliance, the issue often relates to Conditional Access, configuration profiles, or missing required apps.
Cross-Referencing Between Portals
It’s not uncommon for admins to find a device in one portal and not the other. Here’s what it typically means:
Found in Entra Only
Found in Intune Only
Found in Both
Device is only registered, not MDM-enrolled.
Rare; usually due to stale objects or migration.
Device is properly joined and managed.
A properly managed device should show up in both portals, and any inconsistency is a sign of an enrollment issue.
Section 3: Common Error – 0x80180014
What Does 0x80180014 Mean?
This error appears most often during the enrollment phase of a Windows 10/11 device. It typically means:
“The device is already enrolled.”
In other words, Windows believes the device is already managed, either because of a previous enrollment or residual data from a prior configuration.
Resolution Steps
Check Admin Portals: Remove the device from both Intune and Entra if it still exists.
Remove MDM Profile: Disconnect the work or school account in Settings.
Use PowerShell: Run dsregcmd /leave to unjoin from Entra ID.
Retry Enrollment: After cleanup, re-enroll the device manually or through Autopilot.
Section 4: Unable to Delete Device from Entra ID
If the device does not appear in Intune but is still stuck in Entra ID and can’t be deleted, follow these steps:
Step 1: Confirm Your Permissions
Ensure your account has one of the following roles:
# Replace 'DEVICE-NAME' with the actual name
$device = Get-MgDevice -Filter "displayName eq 'DEVICE-NAME'"
Remove-MgDevice -DeviceId $device.Id
If you already have the Object ID, skip the lookup and run:
Remove-MgDevice -DeviceId "<device-object-id>"
Note on Autopilot Devices
In some scenarios, Autopilot devices can lose their connection to the Entra device object, especially if the device has been reset outside of Autopilot flows (e.g., manually or using third-party imaging). This causes:
The Autopilot object to remain in the Autopilot portal
The Entra ID device to become orphaned
Intune showing no matching device
This was exactly the case during a troubleshooting session with Carsten Lund Meilbak, where we were diagnosing an enrollment failure on a Microsoft Teams Room (MTR) device. The Entra ID device had become orphaned, preventing the MTR from successfully enrolling. Manual deletion of the Entra device object was required to resolve the issue.
In these cases, the orphaned Entra ID device must be deleted manually as described above.
Conclusion
Understanding how devices register and appear in Microsoft Intune and Entra ID is crucial for device management. Cross-portal visibility, proper cleanup, and the ability to handle errors like 0x80180014 efficiently ensure a secure and manageable environment for both users and administrators.
If device records are left stale or orphaned, they can interfere with future enrollment attempts, Autopilot deployments, and compliance policies. Always keep your portals clean and verify device join and MDM status regularly.
As hackers get more daring and attacks more sophisticated, organizations need to continuously look at how they can enhance their security protocols. Concerning statistics show that the cost of cybercrime, already well into the trillions, could surpass $23 trillion by 2027.
Faced with the reality that cybercrime is unquestionably on the rise, a proactive approach is now necessary to lessen the risk of attack. One of the best ways to achieve that is by utilizing the indicators that Microsoft Defender for Endpoint has.
By using these, IT admins can preemptively block malicious entities and prevent them from accessing the organization’s resources. With this in mind, the focus for this blog will be to provide you with detailed information concerning indicators.
Explaining Microsoft Defender for EndpointIndicators
Indicators provide IT administrators with certain data that can help identify individuals with nefarious intentions. This data can enable organizations to pinpoint malicious IP addresses, untrusted certificates, suspicious URLs, and more. Moreover, an organization can then set up its indicators accordingly thereby enabling a proactive approach to dealing with threats.
In Microsoft Defender for Endpoint, the indicators operate by applying specific rules to endpoint devices. These rules will use predetermined criteria to govern whether or not devices allow or block certain types of activity. A good example of this would be blocking all traffic to and from IP addresses that have been determined to be carrying out malicious activities.
Importance of Indicators
Indicators play a major role in improving organizational security by enabling businesses to take a proactive approach and block malicious actors before they can do any damage. And if an incident does occur, indicators will help you to quickly identify threats and implement a swift response. Additionally, using indicators allows you to customize your security to effectively meet the specific needs of your organization.
These tools are invaluable for intercepting attacks. Once it has been determined that an attack is ongoing, the malicious entities can be immediately blocked therefore limiting the impact from affecting the entire organization.
Types of Indicators with Microsoft Defender for Endpoint
In this section, we’re going to look at four types of indicators that Microsoft Defender for Endpoint supports. These indicators are essential for responding to different threats.
IP ADDRESS INDICATORS
This type is used for preventing access to IP addresses suspected of malicious activities. Once a specific IP address has been determined, an action is implemented that blocks all devices within an organization from connecting to that IP address. To do this, you need to navigate to Microsoft 365 Defender portal > Settings > Indicators. Next, you’ll need to add a new indicator and then select IP Address. With this done, you can now set up the action as Block and specify devices affected.
URL AND DOMAIN INDICATORS
These indicators are used to block access to malicious domains and phishing sites. After you’ve specified the URL concerned, you can then implement an action blocking all devices within your organization from connecting to that particular URL. Microsoft Defender for DNS is recommended if you want to have DNS-level protection.
FILE HASH INDICATORS
These will enable you to block access to known malicious files based on their hash (MD5, SHA-1, or SHA-256). You can use Advanced Hunting in Microsoft Defender or third-party threat intelligence sources to get the necessary file hashes.
CERTIFICATE INDICATORS
With this fourth type, you can block executables signed by untrusted certificates.
How to Set Up Microsoft Defender for Endpoint Indicators
The process of setting up indicators is not an overly complicated one. You start by navigating to the Microsoft 365 Defender portal where you need to sign in with your administrator account. Following this, you can then begin creating an indicator.
CREATION PROCESS
Head over to Settings > Indicators.
Click on Add Indicator.
Select the type of indicator required.
Provide the necessary information:
Indicator Type: IP Address, URL, File Hash, or Certificate.
Action: Block or Allow
Scope: Specify which devices/groups will be affected by the action to be performed.
Expiration Date: Provide an expiration date for temporary indicators (this is optional).
Description: For documentation purposes, a description will be required.
COMPLETING THE PROCESS
After you’ve completed the creation process, you can click Create to save the indicator. You’ll also have the capability to monitor the indicator’s impact by taking advantage of Reports and Advanced Hunting. Advanced Hunting offers a powerful, query-based tool that helps you track threats and evaluate how effectively the indicators are working. Hunting works best if you use filters to get more specific results, as well as if you save and reuse queries during the monitoring processes.
Using Indicators Effectively
Like most other apps and services, you can’t set up indicators once and forget about them. You need to constantly review them and update them when necessary so your security remains strong.
As already mentioned, some indicators are temporary and so you need to remember to set expiration dates for these so that you avoid cluttering your environment. Not only that, but you should ensure that indicators are targeting the specific devices or groups they are created for.
Furthermore, IT admins should continuously evaluate the information obtained from Advanced Hunting and reports so that they are always aware of whether or not the indicators are performing to expectations. And then to enhance your security posture even more, you can combine indicators with Conditional Access policies for better results.
Wrap up
The staggering figures that we hear being thrown around when discussing cybercrime are almost beyond belief. But, the reports about cybercrime provide a lot of insights that enable organizations to take the necessary steps to improve their security. Leveraging the indicators available in Microsoft Defender for Endpoint goes a long way in securing your network and reducing the risk of attack. If applied correctly and used as recommended, indicators can be some of the best tools in an organization’s cybersecurity arsenal.
Upgrading to Microsoft Configuration Manager (ConfigMgr) version 2503 is a critical step for IT administrators aiming to leverage the latest security enhancements and bug fixes. However, many have encountered a recurring issue during the prerequisite check
This error often appears even when the ODBC Driver 18 is already installed. This article delves into the root cause of this problem and provides a comprehensive solution.
Understanding the Issue
The Configuration Manager 2503 prerequisite checker mandates the installation of the Microsoft ODBC Driver 18 for SQL Server. However, the link provided in the error message (https://go.microsoft.com/fwlink/?linkid=2220989) directs users to an outdated version of the driver. Consequently, even if a version of the driver is installed, the prerequisite check may fail if it’s not the expected version.
Administrators have reported that installing the driver from the provided link results in a message indicating that a newer version is already present, yet the prerequisite check continues to fail. This inconsistency stems from the prerequisite checker not recognizing newer versions of the driver – Reddit – System Center Dudes
Recommended Solution
To resolve this issue, it’s essential to ensure that the correct version of the Microsoft ODBC Driver 18 for SQL Server is installed. The recommended version is 18.5.1.1 or later.
Choose the appropriate installer based on your system architecture (e.g., x64).
Step 3: Re-run the Prerequisite Check
After installing the correct version:
Open the Configuration Manager Console.
Navigate to Administration > Updates and Servicing.
Right-click on the Configuration Manager 2503 update and select Run prerequisite check.
The check should now pass without errors related to the ODBC driver.
Additional Considerations
Multiple ODBC Versions: Some administrators have multiple versions of the ODBC driver installed (e.g., versions 17, 18, and 19). While multiple versions can coexist, ensure that version 18.5.1.1 or later is present, as it’s the one recognized by the prerequisite checker.
Silent Installation: For automated deployments, the ODBC driver can be installed silently using the following command: bashCopyEditmsiexec /i msodbcsql18.msi /quiet /norestart
Replace msodbcsql18.msi with the actual filename of the downloaded installer.
Verify Installation: After installation, verify the driver version:
Open ODBC Data Source Administrator.
Navigate to the Drivers tab.
Ensure that ODBC Driver 18 for SQL Server is listed with version 18.5.1.1 or later.
Conclusion
The prerequisite check failure during the Configuration Manager 2503 upgrade, related to the Microsoft ODBC Driver 18 for SQL Server, is primarily due to version discrepancies. By uninstalling outdated versions and installing the recommended version 18.5.1.1 or later, administrators can ensure a smooth upgrade process.
Since its launch in 2021, Windows 365 has benefited from countless new features and updates that have enhanced the Cloud PC experience. And 2024 has not been an exception. But, arguably the biggest Windows 365 announcement comes right as the year is coming to an end. Microsoft is introducing a purpose-built device that has been specifically designed to enable users to quickly and securely connect to their Windows 365 Cloud PCs. As the first Cloud PC device, Windows 365 Link is generating a lot of interest. And it’s looking to be the the high-fidelity experience Microsoft promises.
Unboxing
Once you receive your Windows 365 Link device, you can expect to find the following:
Hardware
Windows 365 Link device.Power adaptor.Quick start guide.
Ports
On the front panel, you’ll find a USB-A port, a 3.5 mm audio jack, as well as a power button and LED indicator. On the back panel, you’ll find 2 USB-A ports, 1 USB-C port, 1 Display Port, 1 ethernet port, 1 HDMI port, and the power supply port.
Side Panel
The side panel has a Kensington lock to physically secure the device.
Monitor Support
Both the HDMI and Display Port support one monitor each, up to 4k in resolution.
Peripheral Support
Users will get USB and Bluetooth support for their keyboards, mice, headphones, and cameras.
Software
The device comes pre-installed with a small, Windows-based OS called Windows CPC. To add to the convenience, updates are downloaded in the background and then installed during off hours. However, to ensure these updates occur, verify that the device is plugged in and powered on (in standby or sleep mode).
Wireless Support
Here you get Wi-Fi 6E as well as Bluetooth 5.3.
Why would I need this?
Understandably, whenever a new device comes on the market, businesses want to know how purchasing the product can benefit them. After all, the Windows 365 Link device will set you back US$349.
According to Microsoft, this new device aims to resolve some of the problems that Cloud PC users encounter. These include, but are not limited to, latency issues, security challenges, and complicated sign in processes. From what we’ve heard so far, the biggest positives of using the Link device will be:
CLOUD-POWERED PERFORMANCE
Users can harness the full power of the cloud to increase their efficiency and enjoy a more seamless experience. With the ability to connect to their Windows 365 Cloud PCs in seconds, users can maximize productivity. This ensures that businesses get full value for their investment. Additionally, users will benefit from responsive, high-fidelity experiences with access to all their favorite Microsoft 365 productivity apps.
SECURE BY DESIGN
The Windows 365 Link devices comes with security measures that will address the concerns about endpoint vulnerability that IT professionals have raised. Because of these concerns, the Link device has a locked-down operating system with no local data or apps, and no local admin users. By designing it this way, Microsoft has significantly reduced the potential attack surface thus making the task of compromising devices much harder.
Furthermore, the availability of passwordless authentication using Microsoft Entra ID means that users can sign in with MFA using the Microsoft Authenticator app, a cross-device passkey using a QR code, or a FIDO USB security key. Consequently, the use of all these security measures will serve to improve overall device protection.
SIMPLIFY IT MANAGEMENT
Another key issue that Windows 365 Link wants to resolve is complex management. I’m sure that we’ve all at one point or another been frustrated about just not seeming to have enough time to complete all the tasks at hand.
Fortunately, Windows 365 Link gives us a possible solution by enabling admins to configure and manage devices using Intune. By allowing admins to leverage the knowledge and policies they already have, the Link device helps improve IT management efficiency.
ALIGNMENT WITH SUSTAINABILITY GOALS
Many organizations are looking for ways that can help them make a positive environmental impact while simultaneously enhancing business operations. With this in mind, Microsoft has built the Windows 365 Link device to be a sustainable product.
The device is built with 90% post-consumer recycled aluminum alloy in its top shield, 100% pre-consumer recycled aluminum alloy in its bottom plate, and its motherboard contains 100% recycled copper and 96% recycled tin solder.
In addition, when in operation, Windows 365 Link consumes less energy than your average desktop with external monitors and peripherals connecting to Windows 365. And as a device that has been designed to have a long life, the lack of moving parts means that frequent replacements will not be an issue with this gadget.
Get an early look
As mentioned before, Windows 365 will become generally available as of April 2025. In the interim, those who want to get an early look may be able to participate in the public preview.
Anyone interested in getting Windows 365 Link devices for their organization should get in touch with their Microsoft account team. Additionally, you could also join the Customer Connections Program and Office hours for the latest updates as part of your participation.
Wrap up
The new purpose-built device that Microsoft is introducing will make accessing Cloud PCs much simpler for users. With the ability to wake quickly and connect you to your Cloud PC in seconds, this device has the potential to be an excellent productivity tool. Announced at Microsoft’s Ignite 2024 tech conference in Chicago, Windows 365 Link will provide users with a high-fidelity experience with access to all the familiar Microsoft 365 apps.
The public preview period should provide us with a lot more information in the coming months. But, as something that Microsoft hopes will bring positive change to the future of virtualization, the lightweight Link device will have a lot riding on its petite frame.
Flow dynamics calibration is critical to achieving high-quality 3D prints, especially when using the Bambu Lab X1 Carbon (X1C). Proper calibration ensures precise material extrusion, improved surface quality, and optimal dimensional accuracy. In this detailed guide, we’ll dive into everything you need to know about flow dynamics calibration for the X1C, including why it’s important, when you should do it, how the printer handles calibration, and how to perform and save a manual calibration properly.
1. Understanding Flow Dynamics Calibration
Flow dynamics calibration is the process of tuning how the printer compensates for the behavior of melted filament as it moves through the nozzle and onto the print bed. Factors such as filament type, viscosity, print speed, and temperature all impact flow characteristics.
Flow dynamics calibration helps determine the optimal “pressure advance” (K value), which corrects for the lag between extrusion start/stop and nozzle pressure buildup/release.
Without proper calibration, you might experience issues like:
Over-extrusion at corners
Blobs and zits on surfaces
Inconsistent line widths
Dimensional inaccuracies
Thus, a good flow dynamics calibration is essential for high-fidelity prints.
2. How Bambu Lab X1C Handles Flow Dynamics Calibration
The X1C offers two primary ways to calibrate flow dynamics:
2.1 Automatic Flow Dynamics Calibration Before a Print
When you enable “Flow Dynamics Calibration” in the print settings before a print, the printer will perform a calibration sequence. However:
The result is used only for that specific print.
It is not saved to any filament profile or memory for future prints.
This method is quick and convenient but not optimal for consistent results across multiple prints.
2.2 Manual Calibration via Bambu Studio
Performing a manual calibration through Bambu Studio allows you to:
Calibrate flow dynamics accurately
Save the resulting K value directly into a filament profile
Apply this calibration automatically every time you use the filament
This ensures consistent quality without the need to recalibrate every print.
3. When Should You Perform Flow Dynamics Calibration?
Calibration isn’t necessary before every single print, but there are several situations where you should perform it manually:
Using a new brand or type of filament (e.g., switching from PLA to PETG)
Changing nozzle sizes (e.g., from 0.4mm to 0.6mm)
After significant nozzle wear
Changing maximum volumetric speeds
Noticing under- or over-extrusion artifacts
Filament moisture exposure
Remember: better calibration means fewer failed prints and higher part quality.
4. How to Manually Calibrate Flow Dynamics (and Save It)
Let’s walk through the manual calibration process in detail.
4.1 Preparation
Before you begin, make sure:
Your printer is clean and the nozzle is not partially clogged.
Tip: If you’re unsure about the nozzle size, you can find it in your printer’s configuration or by physical inspection.
Step 4: Start the Calibration Process
Click Start Calibration.
The printer will print a special pattern designed to measure pressure advance.
This process usually takes around 5-10 minutes.
Step 5: Analyze Results
Once the test print is complete:
Bambu Studio will automatically analyze the printed lines.
It will suggest an optimal K value.
Accept the suggested value if it looks good, or manually adjust based on visual inspection.
Step 6: Save the Calibration
After accepting the K value:
Save it directly into the filament profile.
The K value will now automatically apply every time you use this filament with this profile.
Congratulations! You’ve now successfully saved your flow dynamics calibration for ongoing use.
5. Important Tips for Successful Calibration
Calibrate at typical print temperatures: If you normally print PETG at 240°C, calibrate at that temperature.
Use default speed settings: Don’t alter speed drastically during calibration unless necessary.
Keep environmental factors constant: Big changes in ambient temperature (cold garage vs warm room) can affect extrusion behavior.
Dry your filament: Especially important for hygroscopic materials like nylon and PETG.
6. Troubleshooting Calibration Problems
Problem 1: Inconsistent calibration results
Check nozzle for partial clogging.
Make sure filament is dry.
Problem 2: K value seems too high or too low
Double-check filament diameter consistency.
Look for under/over-extrusion or strange surface artifacts.
Problem 3: Calibration pattern looks messy
Level your bed.
Ensure proper first layer adhesion before starting.
7. Expert Tips for Advanced Users
Tune Flow Rate Afterwards: After setting pressure advance, consider tuning “flow rate” or “extrusion multiplier” for perfect walls.
Multiple Calibrations: Some experts recommend doing calibration at both slow and fast speeds and averaging the K value.
Custom G-code Scripts: Advanced users can embed calibration K values into startup G-code scripts if they want different K values for different speeds automatically.
8. FAQs About Flow Dynamics Calibration on Bambu Lab X1CQ1: Can I use the same calibration across different filament colors?
Sometimes yes, but darker pigments (like black) and translucent filaments often behave slightly differently.
Q2: Do I need to recalibrate if I switch from PLA to PLA+?
It’s recommended, because even minor changes in formulation affect flow.
Q3: Will nozzle wear affect calibration?
Definitely. A worn-out nozzle has larger internal diameter, affecting pressure buildup and release.
Q4: What’s the default K value if I never calibrate?
Bambu Lab sets conservative defaults, but they’re not optimized for every filament.
Q5: Can I copy calibration profiles between filaments?
You can, but performance may degrade. It’s better to calibrate each filament.
9. Conclusion
Flow dynamics calibration is a cornerstone of achieving professional-level results with your Bambu Lab X1 Carbon. While the automatic on-the-fly calibration is convenient for quick prints, for serious or repeatable results, manual calibration is the way to go.
By taking the time to manually calibrate and save your pressure advance values into filament profiles, you’ll:
Save time on reprints
Improve surface finishes
Ensure accurate dimensions
Reduce mechanical stresses in parts
Remember, every filament is unique. Treat your printer and materials with care, and they will reward you with stunning prints every time.
When I think back to how my 3D printing journey started, it all began with a big box of parts and a manual that felt like it was translated by an AI still in beta. That was the Anet A8 Plus—my very first printer. It was as DIY as it gets. You didn’t just build the prints—you practically built the printer itself.
The A8 Plus was a fantastic learning tool. I learned what a stepper driver was, how to flash firmware, how to fix a failed thermistor, and that fire hazards were very real if you weren’t careful with your wiring.
Later, I upgraded to the Creality Ender-5 Pro, which felt like a huge step up. It was sturdier, more consistent, and less prone to spontaneous meltdowns. But even that required regular tinkering—manual bed leveling, frequent nozzle changes, and more “printer babysitting” than I liked to admit.
Then came the Bambu Lab X1 Carbon.
If the A8 Plus was the equivalent of building your own race car and the Ender-5 Pro was a dependable but clunky commuter, the X1C is a Tesla Model S of printers: sleek, fast, nearly autonomous, and kind of magical.
The Evolution of Setup: Screws, Springs, and… Silence?
The Anet A8 Plus was where I learned patience. Assembly took hours. Wiring felt like a bomb defusal mission. Firmware? Let’s just say I bricked it once and learned to never skip backups again.
The Ender-5 Pro was pre-assembled to an extent, but still required manual leveling and tuning. Every time I moved the printer, I had to redo everything. Good prints were possible—but they weren’t guaranteed.
Then the Bambu Lab X1C showed up.
Fully assembled. No Z-bracing hacks needed. No fiddling with springs and wheels. It booted up with a clean interface, and after a few taps on the touchscreen, that was easly mounted, it auto-calibrated everything from bed leveling to flow rate compensation.
It felt like jumping into a self-driving car after years of clutch-kicking old stick shifts.
Unboxing: From Cardboard Chaos to Premium Packaging
The Ender-5 Pro came in a box filled with foam blocks, mystery screws, and semi-labeled bags. Not quite chaos, but you definitely needed a good table and some spare time.
Unboxing the Bambu Lab X1 Carbon was a totally different experience. Think “Apple product”. Everything was labeled, secured, and neatly packed. The AMS (Automatic Material System) had its own box, clearly organized with guides and quick-start instructions.
In 20 minutes, I had it powered on and connected to Wi-Fi. No zip ties. No half-translated instructions. Just plug-and-play. And it felt luxurious.
First Print: A Benchmark Benchy, But Make it Beautiful
We all do it. The first print is always a Benchy. But with the X1C, it wasn’t just to test the printer—it was to witness what modern hardware could do with zero tinkering.
This Benchy came out faster, cleaner, and more detailed than any print I’d ever done on my Ender-5 Pro or Anet A8 Plus. The hull was smooth, the portholes were crisp, and the layers? Practically invisible.
No first layer anxiety. No extrusion hiccups. Just hit “print” and watch it go.
AMS: The Game-Changer I Didn’t Know I Needed
Back on the A8 and Ender, multi-color printing was a manual mess. Pause the print, swap the filament, purge, hope the printer doesn’t blob up the nozzle, and repeat.
With the AMS, that whole drama vanished. I loaded four filaments, selected colors in Bambu Studio, and let it run. The AMS handled filament switching, detection, and purging all on its own.
Watching it print a multicolor model—with seamless transitions—felt like magic.
Speed and Precision: CoreXY Muscle
On the Ender-5 Pro, I had to balance speed with quality. Push too fast, and the prints got sloppy. Stick to 50mm/s and you’d wait overnight.
The X1C prints at up to 500mm/s thanks to its CoreXY motion system. That’s not a typo. And somehow, it doesn’t shake, doesn’t wobble, and doesn’t lose accuracy.
A model that took 7 hours on the Ender now finishes in under 3. And with better quality.
Noise and Smell: Office Friendly at Last
Both the Anet and Ender were noisy. Stepper motor whine, fans, open-frame echoing… not something you want running next to your desk.
The X1C is enclosed and well-insulated. The AMS adds some clicking during filament changes, but overall it’s just a soft hum. No PLA smell. No ABS fumes. Finally, a printer that doesn’t dominate the room it’s in.
Slicer Experience: From Cura Tuning to Bambu Smoothness
Cura served me well, especially on the Ender. But getting prints dialed in took work—adjusting profiles, testing retraction, tuning speeds.
Bambu Studio is built for the X1C. It has presets that just work, but also allows deep customization. It connects directly to the printer, offers real-time monitoring, and even supports remote starts.
I send models from my laptop and start prints from my phone. No SD card shuffle. No hassle.
Downsides? A Few.
Cost: It’s a premium machine, and the AMS adds to the price. Not for budget tinkerers.
Filament Drying: AMS isn’t a dryer. You still need dry storage for hygroscopic filaments.
Ecosystem Lock-In: It works best with Bambu gear and software. You can go open-source, but it takes more effort.
Still, these are minor trade-offs compared to the value and time it saves.
What I Still Use the Ender For
Believe it or not, the Ender-5 Pro still gets some use. It’s great for rough prototypes, quick PETG brackets, or experimental filaments I don’t want to risk clogging the AMS.
The A8 Plus? It retired with honors. It taught me everything I needed to know about 3D printing—the hard way.
Final Thoughts: Worth the Hype
The Bambu Lab X1 Carbon changed how I think about 3D printing. It’s no longer a technical project—it’s a creative tool. It’s fast, reliable, versatile, and smart.
For anyone coming from the tinker-heavy days of Anet or Creality machines, the X1C feels like stepping into the future.
Would I recommend it? 100%. If you want to focus on printing instead of troubleshooting, the X1C is the printer you’ve been waiting for.
Windows Autopilot is a set of technologies that is built to simplify the process of deploying, setting up, and configuring new devices. By using this technology, users can avoid going through the traditional imaging process and save countless productive hours.
However, Autopilot is not without its faults. One of the more common instances of running into problems occurs when using Managed Installer policies with Win32 app deployment during the Autopilot device preparation phase. As an issue that can cause quite a headache, this blog will help you better understand this problem as well as provide you with solutions for addressing it.
Windows Autopilot Explained
Windows Autopilot gives organizations a solution that eliminates the challenges that come with building, maintaining, and generally applying custom images. IT admins can use this service to set up new desktops to join pre-existing configuration groups and apply profiles to the desktops. What this does is give users the opportunity to access fully functional desktops from their first login.
Importance of Managed Installer Policies
Managed Installer policies are useful for dictating which applications can be installed on your organization’s devices. Once enabled, Managed Installer uses a special rule collection in AppLocker to designate binaries. These are trusted by your organization as an authorized source for application installation.
The problem IT admins will run into is that currently Windows Autopilot device preparation doesn’t guarantee the delivery of the Managed Installer policy before trying to install Win32 apps. Because of this, you may end up with deployment failures during the App Installation phase of Autopilot.
INVESTIGATING THE PROBLEM
A regular deployment scenario follows a series of steps that begins with the launch of the Autopilot Device Preparation process. Following this, Win32 apps are then scheduled for installation as part of the device preparation policy.
At this point, the Managed Installer policy won’t yet have been installed. The reason why you may see the Win32 app installations failing is because the policy is set up to block apps from unverified sources.
WHAT TO EXPECT With Windows Autopilot
One of the things you can expect to see because of this issue is the Autopilot deployment process stopping at the app installation phase. You will also get error messages showing application deployment failures. Another thing to expect is that deployment reports will show failed Win32 app installations. Lastly, end-users may receive incomplete or improperly configured devices.
How has Microsoft addressed the issue?
Microsoft is fully aware of the issue at hand and has offered some recommendations that provide a temporary solution. IT admins can start by removing Win32 apps from all Autopilot device preparation policies.
Also, devices should be left to complete Autopilot and reach the desktop. Furthermore, Win32 apps and Managed Installer policies need to be applied after the user gets to the desktop.
In October 2024, Microsoft announced service release 2410 that introduced some new changes that will see Win32 and Microsoft Store apps being automatically skipped during device preparation and instead continuing to the desktop. To implement these solutions, you’ll need to follow the steps below:
AUDIT YOUR EXISTING Windows AUTOPILOT DEVICE PREPARATION POLICIES
For this process, organizations need to identify all device preparation policies configured in Intune. You’ll also need to verify any Win32 apps included in these policies. With all this done, make sure to document these apps as well as their purpose.
REMOVE WIN32 APPS FROM DEVICE PREPARATION POLICIES
Navigate to Microsoft Intune and edit your existing device preparation policies. Then, proceed to remove all Win32 apps from these policies. Once these tasks are complete, save and apply the updated policies.
MONITOR DEPLOYMENT STATUS
Use the updated policies to deploy your devices. You can track the progress of this process using the Autopilot Deployment Report. Make sure that you check that devices reach the desktop without app installation failures.
DEPLOY WIN32 APPS POST-ENROLLMENT
Once a device has reached the desktop, you can reassign your Win32 apps to deploy. You’ll need to use Required or Available for enrolled devices deployment settings in Intune. The success of app installation can be monitored using Intune’s reporting tools.
Alternative Options
In addition to the recommendations by Microsoft, there are other options that organizations can consider to address the above-mentioned issue. These include:
PRE-STAGE CRITICAL APPLICATIONS
One thing that organizations can consider doing is pre-staging key apps that are required to be on the device at deployment. This can be done using offline methods such as:
Injecting apps into the Windows image using tools like OSDCloud or Configuration Manager.
App deployment using PowerShell scripts post-Autopilot.
CONDITIONAL ACCESS AND APP PROTECTION POLICIES
If your organization is worried about security, then using Conditional Access policies will help block access to corporate resources until the necessary apps have been installed. An example of this would be enforcing Conditional Access policies to ensure that non-compliant devices are prevented from accessing the organization’s resources.
Optimize Enrollment Status Page (ESP) Configuration
The Enrollment Status Page plays a key role in controlling app deployment during Windows Autopilot. This is done by dividing the deployment into several stages, thus allowing you to prioritize the apps you consider more important.
USER VS DEVICE ASSIGNMENTS
With device-based deployments, there is a greater likelihood of encountering problems with Managed Installer policies. Because of this, it’s worth considering changing your app deployment from device-based to user-based assignments.
PILOT AND TEST NEW CONFIGURATIONS
Before rolling out new deployment configurations to the entire organization, it’s always wise to test them on a small pilot group. Doing it this way gives you the opportunity to identify problems and address them early.
Monitoring and Troubleshooting
The availability of Autopilot Deployment Reports in Microsoft will provide organizations with key information concerning the deployment process. This allows them to evaluate skipped apps, failed deployments, and device readiness status.
Additionally, organizations should also use Intune Diagnostics and Event Viewer to analyze deployment logs. By evaluating these logs, IT admins can pinpoint specific app failures and then determine whether they’re related to the Managed Installer policy.
If all else fails and your deployment issues are still yet to be resolved, you’ll have the option of reaching out to Microsoft Support for any help you need. Alternatively, engaging with the Intune community on X may yield assistance from those who have dealt with the issues you may be confronting.
Wrap Up
Windows Autopilot offers organizations a powerful tool to help simplify the process of deploying and setting up devices. Processes are made simpler and faster, thus helping businesses operate more efficiently. And although there may be issues with Wind32 app deployment during device preparation, there are ways to deal with it.
But, in addition to the workaround, we can look forward to Microsoft developing a more permanent solution to this challenge. Updates are sure to be forthcoming and we will be keeping an eye on what Autopilot will bring us next.
