Defender for Server without Azure ARC – “Arc-less”.

Licensing Model Migration Plan

Summary

Organizations can now deploy Endpoint Detection and Response (EDR) without Azure Arc. This option is perfect for customers with mixed and hybrid server environments who want to consolidate protection under the Defender for Servers licensing model. The new “arc-less” capability is a tenant-level setting that automatically switches the licensing model from a billable SKU (Microsoft Defender for Endpoint for Server) to consumption in Azure using Defender for Cloud (either P1 or P2), without additional agent deployments. This means that we can deploy Defender for Endpoint from the Microsoft 365 Defender portal using the onboarding package or script, with billing and licensing being managed through Azure/Defender for Server, and without the need for additional agents, extensions, or products.

Direct onboarding integrates Defender for Endpoint with Defender for Cloud without additional software on your servers. Once enabled, it displays non-Azure server devices in Defender for Cloud under a designated Azure Subscription (for licensing, billing, alerts, and security insights) and in the Microsoft Defender Portal. Note that this “arc-less” mechanism does not include server management capabilities like Azure Policy or Guest configuration. For those additional features, the use of Azure Arc agent is required.

Switching from Direct onboarding to Azure Arc incurs no additional cost (Unless changing from P1 to P2). If you need to collect logs via AMA or use other unsupported features, you can install the Azure Arc agent without offboarding from Defender for Endpoint.

Simplified step-by-step guidance to Transitioning from MDE SKU to Defender for Server P1/P2

  1. Create a new subscription or identify which current subscription will be used for MDE integration.
  2. Enable Defender for Server P1/P2 licenses in the selected subscription
  3. Enabled Direct Onboarding in the subscription
    1. If Defenders for Servers is off for this subscription when Direct Onboarding is Enabled – Defenders for Servers P1 will be enabled for it automatically
  4. Continue onboarding the server to Microsoft Defender for Endpoint using the onboarding script via GPO or SCCM or the current onboarding mechanisms.
  5. All server will be automatically added into the designated subscription only for licensing applications.

How to Enable Defender for Server with Direct Onboarding and a Designated Subscription

  1. Go to Defender for Cloud > Environment Settings > Direct onboarding.
  2. Switch the Direct onboarding toggle to On.
  3. Select the subscription you would like to use for servers onboard directly with Defender for Endpoint.
  4. Select Save.

Enhancing Vulnerability Management with Microsoft Defender for Endpoint (finding the installation path of each software)

In the fast-paced digital world, strong vulnerability management is key to solid cybersecurity. Our goal is to equip organizations with top-notch tools and practices to protect their digital assets. Recently, customers have asked about locating the installation path of their vulnerable software in their setups. Using Microsoft Defender for Endpoint (MDE) and Microsoft Defender for Cloud, we can provide this information.

Installation Path Insights

A crucial part of our vulnerability management is offering detailed insights into software installation paths. Microsoft Defender Vulnerability collects this data, which administrators can access via KQL (Kusto Query Language). For example, KQL queries can efficiently find paths for essential software like Chrome.exe. These queries help create thorough summaries for assessing and managing vulnerabilities.

Unified Data Capture

The insights are derived from data collected across all devices utilizing the existing MDE components implemented by our clients. This integrated method guarantees a consistent and thorough understanding of the software environment, allowing us to detect possible vulnerabilities more efficiently. The collected data is easily accessible for querying, giving our clients the ability to customize their vulnerability management strategies according to their unique requirements.

Defender for Cloud Integration

Besides MDE, all servers using Microsoft Defender for Cloud provide detailed insights in the console. This setup uses the same data and sensors as Defender for Endpoint but presents it in a more user-friendly way, improving clients’ capability to track and manage vulnerabilities across their IT systems.

Conclusion

By leveraging the power of Microsoft Defender for Endpoint and Microsoft Defender for Cloud, we empower our clients to proactively manage vulnerabilities and protect their digital assets.

Managing Duplicate Device Objects in Microsoft Defender for Endpoint (MDE)

When working with Microsoft Defender for Endpoint (MDE), it’s important to understand how certain actions can create duplicate device objects, which can clutter device inventory and hinder management efforts. This issue arises because MDE retains old device entries for 180 days, even when new entries for the same device are created due to changes in its configuration.

Here are the key scenarios where duplicate device entries can occur:

Scenarios That Lead to New Device Entries:

  1. Renaming a Device: Changing the name of a machine will result in a new entry being created in MDE while retaining the old entry.
  2. Workgroup Rename/Change/Join: If a machine moves from one workgroup to another, or is joined to a different workgroup, a new entry will appear.
  3. Domain Join: Joining a domain will trigger the creation of a new device entry.
  4. Changing Primary DNS Suffix: Modifying the DNS suffix also results in a new entry.

Recommendations for Autopilot Machines:

To avoid duplicate entries, it’s critical to reconsider the AutoPilot process for hybrid machines. Specifically, machines should be onboarded to MDE only after they have been renamed and assigned to the end-user. This ensures that the correct name and configuration are reflected in MDE from the start, preventing unnecessary duplicate device objects.

Recommendations for VDI Infrastructure:

In the case of VDI environments, handling duplicates requires different strategies depending on whether your VDI setup is non-persistent or persistent.

  • Non-Persistent VDI: For non-persistent VDIs, it’s essential that the organization follows the appropriate process to include the necessary scripts to prevent new device entries from being created each time a session spins up. Automation can be key here in minimizing duplicates as explain the Microsoft Docs
  • Persistent VDI: Persistent VDIs should be treated like regular machines. Onboarding to MDE should follow the same process as autopilot machines or any other workstation—ensuring they are renamed and assigned before being onboarded. This approach will prevent unnecessary duplicate entries.

Actions That Won’t Create Duplicate Device Entries:

Not all changes result in the creation of a new device object. The following actions are not expected to trigger new entries:

  • Updating the OS version (e.g., upgrading from Windows 10 version 20H1 to 21H2)
  • In-place upgrades (From Win10 to Win11)
  • Updating to the unified agent on older systems like Windows Server 2012r2 or 2016
  • Rolling back updates
  • Offboarding and re-onboarding a device within the 180-day retention period
  • Work or school account logins
  • MAC address changes
  • Restoring devices from snapshots

Conclusion:

By understanding the scenarios that cause duplicate device objects in Microsoft Defender for Endpoint, IT teams can optimize onboarding processes for autopilot and VDI environments. Taking the right steps to ensure machines are properly renamed, assigned, and onboarded after configuration changes will significantly reduce the clutter of duplicate device entries and improve overall device management within MDE.