Updated 3/23/2023 to focus on the shared security intelligence feature for VDI.
Virtual Desktop Infrastructure (VDI) brings an interesting dynamic when tuning the platform. The delicate balance of performance and usability are key to the user experience and can require fine tuning of all sorts of items in Windows. Antivirus can also benefit from VDI specific configurations and tuning. Among all other settings, it's crucial to ensure antivirus protection on the device is configured optimally.
Microsoft Defender Antivirus is a critical and built-in component in the Microsoft endpoint protection platform. this article includes guidance and recommendations for Microsoft Defender Antivirus on non-persistent VDI machines. This article covers optimizations, best practices, and recommended settings for configuring Microsoft Defender AV in a non-persistent VDI environment.
In my first VDI post I described how the non-persistent VDI deployment type works and interacts in a VDI master/child relationship. When non-persistent VDI machines are onboarded to Microsoft Defender for Endpoint at first boot, you also want to provide Microsoft Defender AV protection for non-persistent VDI machines at first boot.
To ensure you have protection for VDI machines at first boot, follow these recommendations:
Part 1: Security intelligence updates download and availability
As described in the first VDI post, non-persistent VDI machines generally don’t use a configuration management solution like Microsoft Intune because they don’t persist their state (all changes to the VDI machine are lost at logoff, reboot, or shutdown). This means the usual recommended delivery mechanism for security intelligence updates can’t be used. Fortunately, you have options to configure how the updates are delivered to Windows.
There are two different ways a Windows device can consume security intelligence from a UNC file share.
The first method is to use the signature fallback order to consume the mpam-fe.exe update from the UNC share. This method requires the following folder path in the UNC share (architecture\mpam-fe.exe). For example: \\fileserver.fqdn\mdatp$\wdav-update\x64 This method is not optimized for non-persistent VDI and is intended to be a fallback/additional method for Windows clients to get the update. References are here:
Note: As this method is NOT optimized for non-persistent VDI, it will not be the focus of this article.
The second method involves using the Define security intelligence location for VDI clients setting. This setting offloads the extraction of the security intelligence update onto a host machine, which saves CPU, disk, and memory resources on the non-persistent VDI machines.
Note: This method configures non-persistent VDI machines to load pre-extracted security intelligence directly from the UNC share. When this setting is configured it disables all other forms of security intelligence update.
The settings can be accessed in the local group policy editor at the following path:
Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus
It’s important to understand how to get the security intelligence packages to the file share in question. This means that a single server or machine must fetch the updates on behalf of the VMs at an interval and place them in the file share for consumption.
First, create an SMB/CIFS file share. In the following example, a file share is created with the following share permissions, and an NTFS permission is added for Authenticated Users:Read:
For this example, the file share is:
\\fileserver.fqdn\mdatp$\wdav-update
Ensure that the VDI devices have read access via the SYSTEM context to the share in order to fetch the updates. Also ensure that the server or machine that is fetching the updates has read/write access to it so that it can write the security intelligence updates into the wdav-update folder. General guidance on how to download and unpack the updates with a PowerShell script and run it as a scheduled task are here.
In addition, there are some other things to consider for this operation and tie them all together. I’ve written a sample PowerShell script (based on the guidance) that can be run at an interval as a scheduled task. The script takes the following steps:
C:\Windows\wdav-update\{00000000-0000-0000-0000-yMMddHHmmss}\mpam-fe.exe
mpam-fe.exe /X
That’s a quick breakdown of what the sample does and it’s available here. It takes care of fetching the security intelligence updates, unpacking them, and copying them to the file share that the VDI machines will grab them from. To recap, at this point, the VDI machines are configured to go to the file share for the updates, and a single machine gets the updates to the file share.
Part 2: First boot Microsoft Defender Antivirus settings
When the file share is all set up and populated with the updates, you can configure a few things on the VDI master. Remember to configure these settings in the VDI master so that the child VDI machines will have the settings at first boot. The settings can be viewed in the local security policy editor here:
Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus
Note: Depending on the release of Windows the ADMX template can vary and the path will either include “Windows Defender Antivirus” or “Microsoft Defender Antivirus” in the latest templates.
In this tree of the editor the setting to configure is below.
Note: This setting requires a reboot of the VDI machine for it to take effect. This is why it is critical to include it as a first boot policy. All other signature update mechanisms as well as manual signature updates via mpcmdrun -signatureupdate or via the Update-MpSignature PowerShell cmdlet are disabled when using this setting. Here is a snip from the MPLog (located in C:\ProgramData\Microsoft\Windows Defender\Support) after enabling the setting:
VDI machines expect the extracted security intelligence update to be available at the following location:
\\fileserver.fqdn\mdatp$\wdav-update\{GUID}
When a VDI machine is using the define security intelligence location for VDI clients setting , in the MPLog (located in C:\ProgramData\Microsoft\Windows Defender\Support) you’ll see it parse the GUID folder in the file share looking for the security intelligence update:
If you see an access denied message when trying to update security intelligence in the operational log, check the share and NTFS permissions that were mentioned above.
The biggest thing to remember is what folder machines will go to for the security intelligence update when the Define security intelligence location for VDI clients setting is enabled.
For VDI systems with the Define security intelligence location for VDI clients setting enabled, they will look at the following path for updates:
\\fileserver.fqdn\mdatp$\wdav-update\{00000000-0000-0000-0000-yMMddHHmmss}
Part 3: Microsoft Defender Antivirus settings
One of the most important settings to consider is the Turn off Microsoft Defender Antivirus setting. We strongly recommend that you do NOT change this setting to Enabled as doing so will disable Microsoft Defender Antivirus. Even if you are using a third-party antivirus solution, Microsoft still recommends leaving this setting at its default setting of Not Configured.
The reason for this is that when a third-party antivirus registers itself with the Microsoft Defender Security Center in Windows Microsoft Defender Antivirus will automatically go into passive mode if it is onboarded into Defender for Endpoint. When Microsoft Defender Antivirus is in passive mode, Microsoft Defender for Endpoint still uses the AV engine to perform certain functions, some of which are in the Microsoft 365 Defender portal (https://security.microsoft.com). A few examples are:
More information on Microsoft Defender Antivirus in passive mode can be found here. The rest of the settings are pulled from the Microsoft Defender Antivirus VDI guidance, but let’s go over the optimal settings for when you are using the Define security intelligence location for VDI clients setting.
For this example, I’m removing security intelligence package downloads (via the PowerShell sample script) from the file share that are older than 7 days, so I’ve also set this setting to 7 (since I only keep 7 days’ worth anyway).
Tying it all together
In summary, we’ve configured a scheduled task on a designated machine to fetch, extract, and place the uncompressed security intelligence packages in a file share. Non-persistent VDI machines are pointed to this share in order to fetch the updates. We also went over a few of the bare minimum settings to provide first boot protection for non-persistent VDI machines, as well as a few other settings that should be optimized for them. Automation is definitely the glue here that keeps all of this together.
From the VDI master perspective, fold all of these settings together either in the registry or by using a local group policy object.
Tools like the Microsoft Deployment Toolkit (MDT) allow for automation of applying these settings to the VDI master, and as mentioned in my last post I’ve also integrated these first boot Microsoft Defender Antivirus settings into a sample script that’s used to stage the Microsoft Defender ATP onboarding script on your VDI master during an MDT task sequence.
Hopefully, this helps you test, optimize, and deploy Microsoft Defender Antivirus on your non-persistent VDI pools! Let us know what you think by leaving a comment below.
Jesse Esquivel, Product Manager
Microsoft Defender for Endpoint
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.