Onboarding Defender for Endpoint on Non-Persistent AVD Session Hosts

By David Smith, Founder and CEO, Atlas AVD, 2026-11-11, updated 2026-11-11

To onboard Microsoft Defender for Endpoint on Azure Virtual Desktop (AVD) session hosts that are rebuilt from a golden image, put Microsoft's VDI onboarding scripts in the image as a startup script and use the single-entry-per-device model. Each host then onboards itself at first boot, and a host rebuilt under the same name reuses its record in the Defender portal instead of adding another. Don't onboard the golden image itself, and add the FSLogix antivirus exclusions before users sign in.

The short version: Download the VDI onboarding scripts for non-persistent endpoints package, copy both files into the image's startup scripts folder, and run Onboard-NonPersistentMachine.ps1 as a PowerShell startup script. Keep host names stable so rebuilt hosts map to one record. If your names change on every rebuild, offboard each host before you delete it, then exclude what's left as a duplicate. Add Microsoft's FSLogix exclusions to Defender Antivirus through Intune or Group Policy.

This guide is for pooled host pools whose hosts are replaced or reimaged from an image. It goes with our AVD golden image management guide and the wider AVD security checklist. Microsoft details are from Microsoft Learn as of November 2026, with each source linked.

What "non-persistent" means on AVD

Defender for Endpoint's VDI guidance was written for desktops that are destroyed and recreated all the time. AVD session hosts are ordinary Azure VMs, and Microsoft's AVD onboarding page says Azure Virtual Desktop "doesn't provide non-persistence options". But it also says that provisioning and redeploying hosts from a golden image "increases volatility in the environment and thus impacts what entries are created and maintained in the Microsoft Defender for Endpoint portal" (Onboard Windows devices in Azure Virtual Desktop).

So treat a host pool as non-persistent when its hosts are routinely replaced: a monthly image rollout, a scheduled reimage, or scaling that creates and deletes VMs. Each rebuild is a new Windows installation with a new Defender sensor identity, and without the VDI method each one becomes a new device in the portal.

Personal desktops that live for years are different. Microsoft says to onboard a persistent VDI device the same way as a physical Windows device (Onboard non-persistent VDI devices). Pooled vs personal host pools explains the two models.

Single entry or multiple entries per device

The VDI onboarding package supports two device-entry models. Choose one before you touch the image.

Microsoft's recommendation for AVD is the first column: "Microsoft recommends onboarding Azure Virtual Desktop as a single entry per virtual desktop." It keeps an investigation "in the context of one device based on the machine name", and Microsoft adds that organizations that frequently delete and redeploy AVD hosts "should strongly consider using this method as it prevents multiple objects for the same machine from being created".

Single entry depends on the host name. The record is matched on the device name, so the model only helps when a rebuilt host comes back under the name it had before.

One more thing to expect: Microsoft notes that the first time a VDI device onboards, client reporting "can be delayed by approximately three to four hours". A new host that's missing from the portal ten minutes after it boots isn't necessarily broken.

Step by step: the VDI onboarding script in the golden image

These are Microsoft's steps for the single-entry model (Onboard non-persistent VDI devices), in the order that works for an AVD image build. You need the Security Administrator role (or equivalent access) to download the package, and local administrator rights on the image VM.

1. Download the package. In the Microsoft Defender portal, open Settings → Endpoints → Onboarding (under Device management). Select the Windows 10 and 11 operating system group, not the generic Windows option, which starts the separate Defender deployment tool. For Deployment method, choose VDI onboarding scripts for non-persistent endpoints, then download WindowsDefenderATPOnboardingPackage.zip.
2. Copy both scripts into the image. Extract the package and copy Onboard-NonPersistentMachine.ps1 and WindowsDefenderATPOnboardingScript.cmd to C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup on the image VM. The folder is hidden by default.
3. Register the startup script. Open the Local Group Policy Editor and go to Computer Configuration → Windows Settings → Scripts (Startup/Shutdown) → Startup. On the PowerShell Scripts tab, add Onboard-NonPersistentMachine.ps1. Don't add the .cmd file as well; the PowerShell script calls it.
4. Capture the image without letting the script run on it. Make this the last change before you generalize and capture. A restart of the image VM after step 3 would onboard the image itself, which is the one thing to avoid (see the next section).
5. Test with one host. Deploy a single session host from the new image. Sign in, sign out, and sign in again with a different account. In the Defender portal's Device inventory, search for the host name and confirm there is exactly one entry. Microsoft's detection test confirms the sensor is reporting.
6. Rebuild that host and check again. Reimage or replace it under the same name. There should still be one entry.

Two details from Microsoft's page cause most failed rollouts:

• Timing. Run the script "only after the VM has its final device name and completes its final provisioning restart. Running the script earlier can create duplicate device entries or inconsistent onboarding." If your build renames the VM or joins a domain after first boot, check that the startup script fires after that, not before.
• Script signing. Onboard-NonPersistentMachine.ps1 isn't signed. If your PowerShell execution policy blocks unsigned scripts, the startup script fails silently and no host ever appears.

Other ways to run the onboarding

The golden image is Microsoft's preferred place for the script, because it runs at first boot before the host takes sessions. It isn't the only route.

For the Group Policy task, Microsoft's command is powershell.exe with the arguments -ExecutionPolicy Bypass -command "& \\Path\To\Onboard-NonPersistentMachine.ps1".

Keep the golden image itself out of Defender

Microsoft is direct about this: "Don't onboard the primary image, internal template virtual machines (VMs), or replica VMs. Cloning an onboarded image can duplicate its senseGuid, which can prevent the provisioned VMs from appearing as new device entries in the Defender portal."

That's the failure that looks like "only one of my twenty hosts shows up". Every clone carries the same sensor identity, so Defender sees one device.

If the image VM was onboarded, by a startup script that ran early, by an Intune policy, or by Defender for Servers on the build subscription, clean it before you capture. Microsoft's procedure:

1. Offboard the machine and confirm offboarding finished.
2. Run sc query sense and confirm the sensor service isn't running.
3. Open a SYSTEM command prompt with PsExec and remove the local registration data:

PsExec.exe -s cmd.exe

del "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Cyber\*.*" /f /s /q
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection" /v senseGuid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection" /v senseId /f

Microsoft's page lists four more registry values to delete in the same key. Copy the full block from Update VDI images rather than from here, so you get the current list.

The simplest way to stay out of this situation is to build images in a subscription or resource group that your Defender for Servers and Intune onboarding policies don't target.

Tag the hosts while you're in the image. A device tag makes AVD hosts easy to filter and group in the portal. Set the Group string value under HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging in the image, and every host built from it carries the tag (device tags).

Licensing for multi-session hosts

Microsoft's AVD onboarding page lists two ways to license Defender for Endpoint on Windows Enterprise multi-session:

Check the current list on Microsoft's page before you rely on it. Which option you hold also decides which onboarding route in the table above makes sense.

Duplicate device cleanup

Duplicates are several device records with the same host name, where only one is a VM that still exists. They pile up for four reasons:

• The image uses the multiple-entry model, or the .cmd was registered instead of the .ps1.
• Hosts get a new name on every rebuild, so single entry has nothing to match.
• The onboarding script ran before the VM had its final name.
• Hosts were onboarded by something other than the VDI package (an Intune policy, Defender for Servers, a manual script) that doesn't use the single-entry logic.

What Defender does with a dead host's record. Microsoft's offboarding page gives the timings:

So a deleted host doesn't vanish. Until it ages out it inflates device counts, shows up in vulnerability reports as a machine nobody can patch, and puts two or three identically named devices in front of an analyst during an incident.

How to clean up, in order of preference:

Never exclude a host that's still running. Microsoft's warning is that exclusion "only affects vulnerability management visibility, not actual risk".

The order matters when you automate host replacement: drain the host, offboard it from Defender, then delete the VM. Offboarding after the delete is too late, and that's the step most replacement scripts miss. Our AVD fleet management guide covers the rest of a clean decommission, and replace hosts vs staged rings covers the rollout itself.

FSLogix exclusions for Defender Antivirus

Onboarding connects the host to Defender for Endpoint. It doesn't configure Microsoft Defender Antivirus, and on a host with FSLogix profile containers the antivirus needs exclusions or sign-ins suffer: slow container attaches, sharing violations, temporary profiles and sign-outs that hang.

Two different things are called "FSLogix exclusions". This section is about what the antivirus must not scan. Keeping folders out of the profile container is a separate job, covered in FSLogix exclusions and redirections.xml.

Microsoft publishes the antivirus list in FSLogix prerequisites:

Three points on applying them:

• Use a central policy, not the image alone. An Intune Antivirus policy or the Group Policy setting Windows Components → Microsoft Defender Antivirus → Exclusions reaches every host and survives a rebuild.
• Write per-user paths with a wildcard. Defender Antivirus runs as the system account, so it resolves system environment variables and not each user's (configure exclusions). Write the per-user FSLogix folder as C:\Users\*\AppData\Local\FSLogix.
• Apply them in every layer that scans, as Microsoft puts it: endpoint antivirus, any scanning on the file share, and DLP. Then check they landed with Get-MpPreference on a host.

For the rest of the antivirus configuration, Microsoft's Defender Antivirus on VDI guide recommends, among other settings:

If antivirus is behind a slow sign-in, why AVD logons are slow shows how to find which phase is taking the time, and section 7 of the FSLogix troubleshooting guide covers the antivirus symptoms.

How Atlas AVD handles it

Atlas AVD runs in your own Azure tenant and builds, replaces and deletes session hosts for you, so it sits exactly where duplicates are made.

• Enrollment at provisioning. With Enroll to Defender for Endpoint on for a host pool (it's on by default), Atlas installs Microsoft's MDE.Windows VM extension on each new or reimaged host. That's the Azure integration route from the table above, not the VDI package.
• Your own onboarding script, if you prefer. MDE Auto-Onboarding runs a script you host at an HTTPS address on each new host, as the system account, after the extensions install.
• Offboarding before every delete. Defender Duplicate Cleanup offboards a session host from Defender before Atlas deletes the VM, while its sensor can still take the request. It covers a single VM delete, a host pool delete, scheduled replacements and failed-deployment cleanup, and it works whether Atlas or another tool enrolled the host. If the VM is deallocated, Atlas starts it briefly so the offboard can be delivered.
• Leftovers hidden in Atlas. After the delete, Atlas hides the old record from its own Defender views, so its device counts match the hosts that exist.
• Duplicates counted. With Vulnerability Scanning on the Atlas AVD plan, the Duplicate Devices tile on Security → Threat Protection counts host names enrolled more than once and lists them.

What Atlas doesn't do, so you can plan for it:

• It doesn't run Microsoft's two-file single-entry package for you. If you want that model, put the scripts in the golden image as described above.
• It doesn't exclude or remove records in the Defender portal. Hiding a leftover record affects Atlas' views only; use Defender's Exclude action for the portal.
• It doesn't add the FSLogix exclusions to Defender Antivirus for you. Apply them with your Intune or Group Policy antivirus policy.

See it on your own environment. Start a free 30-day trial, then open Security → Threat Protection to see which session hosts are enrolled in Defender, which aren't reporting, and how many duplicates you already have.

FAQ

How do I onboard AVD session hosts to Defender for Endpoint?

Download the VDI onboarding scripts for non-persistent endpoints from the Defender portal, copy both files into the golden image's startup scripts folder, and register Onboard-NonPersistentMachine.ps1 as a PowerShell startup script. Each host onboards itself at first boot. You can also run the script from domain Group Policy or onboard through Defender for Servers.

Should I use single entry or multiple entries per device on AVD?

Single entry. Microsoft recommends onboarding Azure Virtual Desktop as a single entry per virtual desktop, because a host that's deleted and redeployed under the same name keeps one record in the Defender portal. Multiple entries suits test or non-volatile environments.

Should I onboard the golden image to Defender for Endpoint?

No. Microsoft says not to onboard the primary image, because clones of an onboarded image can share one sensor identity and fail to appear as separate devices. Put the onboarding script in the image so it runs on the hosts built from it, and if the image was onboarded, offboard it and clear its registration data before capture.

Why do I have duplicate devices in Defender for Endpoint after reimaging?

Each rebuild is a new Windows installation with a new sensor identity. Unless the host was onboarded with the single-entry model and came back under the same name, Defender creates a new device record and keeps the old one. The old record's profile stays in the inventory for up to 180 days.

How do I remove old AVD session hosts from Defender for Endpoint?

Offboard each host before you delete its VM, so its status changes to inactive after seven days. For records already left behind, select them in Device inventory and exclude them with the Duplicate device justification, which takes them out of vulnerability management pages and scores. They age out of the inventory within 180 days.

Which FSLogix exclusions does Defender Antivirus need?

The FSLogix processes frxsvc.exe and frxccds.exe, the drivers frxdrv.sys, frxdrvvt.sys and frxccd.sys, the FSLogix program and data folders, temporary VHD and VHDX files, and the VHD and VHDX containers on the profile share with their lock and metadata files. Microsoft lists them in the FSLogix prerequisites.

What license do AVD session hosts need for Defender for Endpoint?

For Windows Enterprise multi-session, either license the VMs through Microsoft Defender for Servers, or license every AVD user with Defender for Endpoint Plan 1 or Plan 2, Windows Enterprise E3 or E5, Microsoft 365 E3 or E5, or Microsoft Defender Suite.

Last updated 11 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: Onboard non-persistent VDI devices, Onboard Windows devices in Azure Virtual Desktop, Offboard devices, Manage device scope and relevance, Prerequisites for FSLogix and Defender Antivirus on VDI. Microsoft changes these pages, so check them before you change an image.