From f1dc08ac18601148ee3868db3e1ed3ec42dc5594 Mon Sep 17 00:00:00 2001 From: Prem Kumar <85905240+PremMS-MDE@users.noreply.github.com> Date: Mon, 10 Mar 2025 20:07:56 +0530 Subject: [PATCH 1/2] Update configure-endpoints-vdi.md For all VDI Machines when they onboard for the first time there will be a client delay for 3-4 hours. Receiving few escalations from customer on delayed reporting during initial onboarding. --- defender-endpoint/configure-endpoints-vdi.md | 1 + 1 file changed, 1 insertion(+) diff --git a/defender-endpoint/configure-endpoints-vdi.md b/defender-endpoint/configure-endpoints-vdi.md index f2cbf88ae4..26ec7451f6 100644 --- a/defender-endpoint/configure-endpoints-vdi.md +++ b/defender-endpoint/configure-endpoints-vdi.md @@ -57,6 +57,7 @@ Defender for Endpoint supports non-persistent VDI session onboarding. There migh - Single entry for each VDI instance. If the VDI instance was already onboarded to Microsoft Defender for Endpoint, and at some point deleted, and then recreated with the same host name, a new object representing this VDI instance is NOT be created in the portal. In this case, the *same* device name must be configured when the session is created, for example using an unattended answer file. - Multiple entries for each device - one for each VDI instance. + - For all VDI Machines when they onboard for the first time there will be a client delay for 3-4 hours. > [!IMPORTANT] > If you're deploying non-persistent VDIs through cloning technology, make sure that your internal template VMs are not onboarded to Defender for Endpoint. This recommendation is to avoid cloned VMs from being onboarded with the same senseGuid as your template VMs, which could prevent VMs from showing up as new entries in the Devices list. From 3d08010be9b3c168468c9fdf7b457cadf41b49d3 Mon Sep 17 00:00:00 2001 From: Denise Vangel-MSFT Date: Tue, 11 Mar 2025 09:36:24 -0700 Subject: [PATCH 2/2] Update date and clarify VDI onboarding delay --- defender-endpoint/configure-endpoints-vdi.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/defender-endpoint/configure-endpoints-vdi.md b/defender-endpoint/configure-endpoints-vdi.md index 26ec7451f6..1a11c220c6 100644 --- a/defender-endpoint/configure-endpoints-vdi.md +++ b/defender-endpoint/configure-endpoints-vdi.md @@ -14,7 +14,7 @@ ms.collection: - tier2 ms.custom: admindeeplinkDEFENDER ms.topic: conceptual -ms.date: 03/04/2025 +ms.date: 03/11/2025 ms.subservice: onboard --- @@ -55,9 +55,8 @@ Defender for Endpoint supports non-persistent VDI session onboarding. There migh - In a VDI environment, VDI instances can have short lifespans. VDI devices can appear in the Microsoft Defender portal as either single entries for each VDI instance or multiple entries for each device. - Single entry for each VDI instance. If the VDI instance was already onboarded to Microsoft Defender for Endpoint, and at some point deleted, and then recreated with the same host name, a new object representing this VDI instance is NOT be created in the portal. In this case, the *same* device name must be configured when the session is created, for example using an unattended answer file. - - Multiple entries for each device - one for each VDI instance. - - For all VDI Machines when they onboard for the first time there will be a client delay for 3-4 hours. + - For all VDI machines, when they onboard for the first time, there's a client delay of approximately 3-4 hours. > [!IMPORTANT] > If you're deploying non-persistent VDIs through cloning technology, make sure that your internal template VMs are not onboarded to Defender for Endpoint. This recommendation is to avoid cloned VMs from being onboarded with the same senseGuid as your template VMs, which could prevent VMs from showing up as new entries in the Devices list.