Onboard and configure Defender for Endpoint for non-persistent VDI environments

Microsoft supports multiple onboardings methods for Defender for Endpoint. For non-persistent VDI’s there is always a challenge since non-persistent VDI’s are working differently in comparison with typical endpoints. For Defender for Endpoint, there is a challenge during the onboarding and configuration of Defender Antivirus. Non-persistent requires additional design decisions around the signature update process/ AV configuration and onboarding of Defender for Endpoint to avoid double objects or increasing temp storages/ CPU load for the signature/ platform update process.

Blog information: Blog published: August 8, 2023 Blog latest updated: August 8, 2023

What is persistent vs non-persistent?

First, let me explain the difference between persistent and non-persistent. Persistent and non-persistent Virtual Desktop Infrastructure (VDI) are two different approaches to managing virtual desktop environments in a centralized computing setup.

Persistent: Something persistent retains its state, data, or existence even after the process or system that created it has ended or been shut down. While persistent, the user can repeatedly access their uniquely Virtual Desktop without loss of previously stored data. Every time you log into the system, you can access their last-saved data and settings. Persistent can be handled the same way you would onboard a physical machine (MECM/ Intune/ GPO etc..)

Non-persistent: Something non-persistent does not retain its state, data, or existence after the process or system that created it has ended or been shut down. Every time a user logs into the system, a fresh virtual desktops awaits. It will revert to its original configuration after each session termination.

The challenge with non-persistent and Defender for Endpoint

For Defender for Endpoint, there is a challenge during the onboarding and configuration of Defender Antivirus. Non-persistent requires additional design decisions around the signature update process/ AV configuration and onboarding of Defender for Endpoint to avoid double objects or increasing temp storages/ CPU load for the signature/ platform update process. In general, the following challenges are actual when onboarding Defender for Endpoint:

• Short-lived session
• Device name reused for new sessions
• Signature updates are generating load on the servers
• The machine is not directly up-to-date/ onboarded to Defender for Endpoint, no time to sync settings via Intune or other tools

Time for some more in-depth deep-dives and an explanation of how we can manage non-persistent VDIs in combination with Defender for Endpoint.

---

Non-persistent VDI in Defender for Endpoint

In most of the situations, the non-persistent VDI environment is provided with a golden/master image. The golden/ master image is used as a refresh when the session is terminated or created. The Gold/master image must not be HAADJ or onboarded to Defender for Endpoint since this gives conflicts with the same sense GUID as in the template VMs. which could prevent VMs from showing up as new entries in the device view. From my learning the following is important:

• Do not onboard your master/golden image to MDE. It is possible, personally see no reason to make this process more complicated. It is way easier to onboard via GPO or custom scripts during the provisioning of the machine
• Add some of the settings in the image itself, since some of the Defender settings require a reboot before the settings are configured/ added on the machine itself.
• Update signatures via the file share (Fileshare source), when using MicrosoftUpdate it generates more load during the unpacking process.
• Tweak/tune some settings for improving the performance and disk cache logging (to avoid filled disk drives with cach files)

Signature updates

When using the online MicrosoftUpdate/ MMPC source for signature updates it will download and extract the security intelligence updates on the non-persistent VDI machines – this will generate more CPU/ disk and memory resources on the disk. Since the non-persistent VDI machines are most of the time really small in disk size; this gives issues around the storage of temp files.

For this, we need to load pre-extracted security intelligence updates directly from the UNC share. With the use of the UNC share the signature update is extracted onto a host machine, which saves resources on the non-persistent VDI machines.

The method is part of the following setting Define security intelligence location for VDI clients setting. This setting offloads the extraction and disabled all other forms of security intelligence updates on the machine. This setting can be configured via PowerShell or the local group policy editor.

Create file share

The first step in the preparation is the creation of a file share. The file share is hosted on a single server or machine and can fetch the updates at a configured interval.

We need two directories:

1. Location of the script
2. Location for the updates

Create a directory for the Powershell script. This location will be used for the automatic task to download signature updates:

• C:\tool\PS-Scripts\

Create a directory on your file server with subdirectories for the different CPU architectures (for example; x64, x86)

• C:\SignatureUpdatesMDAV\x64
• C:\SignatureUpdatesMDAV\x86

Download the following PowerShell script from the PowerShell gallery. Copy the downloaded file to the created folder: C:\tool\PS-Scripts\ and run the script with the following parameters:

Delta signature updates (x64)

.\SignatureDownloadCustomTask.ps1 -action create -arch x64 -isDelta $true -destDir C:\SignatureUpdatesMDAV\x64 -scriptPath C:\Tool\PS-Scripts\SignatureDownloadCustomTask.ps1 -daysInterval 1

Full signature updates (x64)

.\SignatureDownloadCustomTask.ps1 -action create -arch x64 -isDelta $false -destDir C:\SignatureUpdatesMDAV\x64 -scriptPath C:\Tool\PS-Scripts\SignatureDownloadCustomTask.ps1 -daysInterval 1

The PowerShell script will add the task for both Delta and Signature updates in the task. scheduler. We can confirm this in the Task Scheduler GUI by navigating to Microsoft\Windows\Windows Defender. By default, the rules are with a daily interval, which can be changed to any preferred frequency (recommended is 4 or 8 hours for VDI)

The folders are still empty. So right-click -> run for initiating both rules. This will result in a download and file creation in the earlier created C:\SignatureUpdatesMDAV\x64 folder.

Reviewing the output. When correct the following files are downloaded and available in the x64 folder. (mpam-d.exe, mpam-fe.exe, and nis_full.exe)

Share and rights

Now it is time to map the created folder C:\SignatureUpdatesMDAV to a share. Example \\server\mdav-updates. This share will be used in the local policies.

Share permission: Authenticated Users: Read

Folder Permission: Authenticated Users: Read/Execute | SYSTEM: Read/Write

---

Configuration of the master image

Since non-persistent VDI relies on several local policies we need to add the policies directly in the image to make sure the settings are directly available at the next boot. Some of the settings require a reboot; which makes it important to add the updates in the local group policy of the master image, when not added the updates via file share will never work, since it is looping on the reboot component.

The following settings must be configured in the local policy of the master image since some of the settings require a reboot:

Microsoft Defender Antivirus

Location: Computer configuration -> Administrative templates -> Windows Components -> Microsoft Defender Antivirus

Setting	Value	Explanation
Turn off Microsoft Defender Antivirus	Disabled	When disabled Defender Antivirus will run in active mode. When there is a local policy set for the disablement it will keep running.

Security intelligence updates

Location: Computer configuration -> Administrative templates -> Windows Components -> Microsoft Defender Antivirus -> Security Intelligence updates

Setting	Value	Explanation
Define security intelligence location for VDI clients	Enabled \\server\mdav-updates	Configured VDI File share for downloading the security intelligence updates
Define file shares for downloading security intelligence updates	Enabled \\server\mdav-updates	Configured File share for downloading the security intelligence updates
Define the order of resources for downloading security intelligence updates	Fileshares | MMPC	The order of resources for downloading security intelligence updates. MMPC as a second source is optional and depends on the caching size.
Check for the latest virus and spyware security intelligence on startup	Enabled	During the startup, the VDI instance will check the security intelligence updates

Define the order of resources for downloading security intelligence updates, which is where you’re setting the update source. If you use ‘Fileshares | MMPC’, you’re telling the VDI to use your file share first, when the file share is not available from the VDI it will download the updates directly from MMPC. MMPC gives a bit of overhead in CPU/ Memory – since the signature file is locally extracted.

Install the latest patches/ full scans and signatures

When Defender is never used/ enabled make sure the image is fully up to date with the latest updates/ Defender product version/ engine version and the latest package of signatures. When Defender AV is never activated it is possible that Defender is disabled or included with a really old definition/production version.

When the version is old; it takes a lot of time before the Defender agent is up-to-date, since there is no additional reboot we need to make sure the update is frequently updated.

In general, I recommended taking the following steps when closing the golden image build. Can be automated via a task sequence or building process to make this process automated when new golden/ master images are created.

1. Update the image and include the latest Windows Updates
2. Install the latest Defender product version
3. Install the latest available signatures
4. Initiate full-scan part of Defender AV

I recommend updating the master image frequently to make sure the difference between the image and the actual VDI is not too big. For 2012R2/ 2016 make sure to install the unified agent, install the agent without onboarding the machine to Defender for Endpoint.

---

Configuration of the centralized GPO

Defender AV and Defender for Endpoint require a proper configuration to make sure Defender is working correctly and can use the full benefit of additional protection capabilities (Tamper Protection/ Disable local admin merge) and more.

With the use of a GPO/ PowerShell it is the most stable way to push settings to the machines. Avoid the usage of MDE security settings management since this requires objects in Intune/ AzureAD. For non-persistent sessions, this will make a complete mess of duplicate names for short-lived sessions. Configuration management tools such as Microsoft Endpoint Manager/ Intune are typically not used on non-persistent VDI machines, mostly because anything that is installed or done to the machine with a configuration management solution is lost when the machine is deleted/de-provisioned

My recommendation; make it easy and use GPO or PowerShell scripts as part of the launch.

Important: Don’t include the 5 settings that were added in the local group policy of the machine – since this gives conflicts with the centralized GPO for settings.

The below policies are common; of course – the configured settings depend on the environment and require fine-tuning. I always go live with MAPS/ Cloud Protection/ Network Protection. Consider adding more hardening settings in the image (SmartScreen/ AV/ Firewall and Windows hardening) – since this blog is scoped only for Defender for Endpoint/ Defender AV.

Defender AV

Setting	Value	Explanation
Configure the local administrator merge behavior for lists	Enabled	Only exclusion items defined by GPO will be used in the effective policy.
Configure whether or not exclusions are visible to Local Admins	Enabled	Local exclusions are not visible to Local Admins.
Randomize scheduled task times	Enabled	Schedule tasks will begin at a random time within 4 hours after the time specified. This prevents high CPU usage for the VDI cluster.
Configure detection for potentially unwanted applications	Enabled (block)	With the value block it will prevent the run of potentially unwanted software.

Maps

Setting	Value	Explanation
Configure the local ‘block at first sight’ feature	Enabled	Block at first sight feature enabled
Join Microsoft MAPS	Enabled – advanced	Maps enabled with the advanced time
Send file samples when further analysis is required	Send safe/ or send all	Send safe or send all for the file sample submission. Use one of the two; other configurations are not configured.

Microsoft Defender Exploit Guard – Attack Surface Reduction

For ASR add a similar approach as used for endpoints. Ideally, start in audit mode for all rules and collect events. When possible configure ASR rules with the value block, since this adds more prevention.

Start at least with enabling all of the rules in audit mode and the following rule in block:

9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2/ Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Microsoft Defender Exploit Guard – Network Protection

Setting	Value	Explanation
Prevent users and apps from accessing dangerous websites	Enabled (block)	PUA enabled in block mode. Always check in audit first

MpEngine

Setting	Value	Explanation
Configure extended cloud check	50 seconds	An extended timeout of 50 is recommended. From my experience, this works fine together with VDIs.
Select cloud protection level	Enabled (high or High+)	High or High+ is both fine. Use High+ for higher protection. In my experience, both levels are working fine when the image is used with Microsoft software.

Real-Time Protection

Setting	Value	Explanation
Turn off real-time protection	Disabled	Real-time protection enabled
Turn on behavior monitoring	Enabled	Behavior monitoring enabled
Scan all downloaded files and attachments	Enabled	Scan downloaded files and attachments as part of the real-time scanning component.
Monitor file and program activity on your computer	Enabled	Monitoring of file and program activity
Turn on script scanning	Enabled	Script scanning enabled.

Security intelligence updates

Setting	Value	Explanation
Specify the interval to check for security intelligence updates	4 or 8	The interval for the signatures is for VDI endpoints recommended with the value 4 or 8.

Scan

Setting	Value	Explanation
Specify the time for a daily quick scan	(configure time)	A quick scan is recommended. Configure the quick scan time which is sufficient for the environment
Specify the maximum percentage of CPU utilization during a scan	25	25 max CPU utilization during a scan.
Allow users to pause scan	Disabled	Pauze of the scan is disabled by the user

Threats

Setting	Value	Explanation
Specify threat alert levels at which default actions should not be taken when detected	All levels (1-5) configured with action 2 (quarantined)	All threat alert levels will be quarantined – this is the default action

For more information and an in-depth explanation of the settings see the following MDE blog series. MDE Series |Jeffreyappel.nl

When needed review of exclusions is needed – each known VDI vendor recommends a set of exclusions; my preferred way is to always start with a minimal set of exclusions. Use the available performance toolings to check if exclusions are needed. See: Microsoft Defender for Endpoint series – Validate Defender protection and additional troubleshooting – Part6

Of course; Defender AV requires additional tweaking and configuration. Based on experience above configuration sets works well for VDI machines; all it depends on the used VDI techniques

---

Onboarding of Defender for Endpoint

The final step is the onboarding of Defender for Endpoint itself. Do not onboard your master/golden image to MDE. It is possible, personally see no reason to make this process more complicated. It is way easier to onboard via GPO or custom scripts during the provisioning of the machine.

In general, there are two ways:

• Use GPO for onboarding the VDI machines
• Local startup script via group policy

The main goal; onboard VDI machines to Defender for Endpoint at first boot as soon as they are created. For VDI machines there is a specific VDI onboarding script available.

I use always the GPO method – with this method, the onboarding script is pushed by the GPO and there is no onboarding on the master images. When there is no GPO available – there is always the option to use local startup scripts as part of the startup scripts. When using this method – avoid that the master image is onboarded using the script after a reboot.

Download script

First, we need to download the onboarding package from the Microsoft 365 Defender portal. Select Settings > Endpoints > Device management > Onboarding and download the VDI onboarding scripts for non-persistent endpoints script for the specific OS.

Results in two files:

• Onboard-NonPersistentMachine.ps1
• WindowsDefenderATPonboardingScript.cmd

There are two different ways of configuring the startup script for the VDI onboarding:

• A single entry for each machine
• Multiple entries for each machine.

The .ps1 is generating a unique value for the senseGuid based on OganizationID and computer name. Part of the script is a write-back to the Windows Advanced Threat Protection registry location. With the use of the WindowsDefenderATPOnboardingScript.cmd the machine is onboarded using the earlier created senseGuid.

The senseGuid value produced by the .ps1 in the registry on the machine ensures the same machineID is used as long as the machine DNS name stays the same.

When only running the WindowsDefenderATPonboardingscript.cmd the machine is creating a single entry for each machine. I prefer to use the PowerShell script for non-persistent VDIs.

In short:

1. If you are implementing multiple entries for each device – one for each session, use WindowsDefenderATPOnboardingScript.cmd during the startup
2. If you’re implementing a single entry for each device, copy both Onboard-NonPersistentMachine.ps1 during the startup. (cmd file must be available since there is a reference in the ps1 file and this file is needed for completing the onboarding)

Now you can make the decision to use the local startup script method via C:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup & Computer Configuration > Windows Settings > Scripts > Startup or run it centralized via GPO during the startup scripts. Both ways are fine, ensure the master/golden image is not onboarded to Defender for Endpoint and that the files are available during the provisioning process.

---

Conclusion

There is no “best practice guidance” for VDI deployment and depends on the used components as part of the VDI infrastructure. I hope my blog gives some impression of the configuration methods and why it is different for non-persistent endpoints in comparison with normal endpoints.

Since I managed in the past multiple VDI deployments for large enterprises this is my best practice with a strong focus on performance and speed, since we don’t have the time to wait a couple of hours before the non-persistent VDI session is finally onboarded with Defender for Endpoint and the latest updates. The method as part of this blog is a good balance between protection and the enrollment time of new machines.

Of course; consider adding more hardening settings in the image (SmartScreen/ AV/ Firewall and Windows hardening) – since this blog is scoped only for Defender for Endpoint/ Defender AV.

---

Sources

Microsoft: Onboard non-persistent virtual desktop infrastructure (VDI) devices in Microsoft 365 Defender

Microsoft: Onboarding and servicing non-persistent VDI machines with Microsoft Defender ATP

Microsoft: Configuring Microsoft Defender Antivirus for non-persistent VDI machines