Configuring Microsoft Defender Antivirus for non-persistent VDI machines

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:

 

1. Make sure that Microsoft Defender Antivirus security intelligence updates (which contain the Microsoft Defender Antivirus updates) are available for the VDI machines to consume
2. Configure bare minimum settings that tell the VDI machines where to go to get the updates
3. Apply any optimizations and other settings to the VDI machines at first boot. Some security policy settings can be set via the local security policy editor

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:

 

• Manage how and where Microsoft Defender Antivirus receives updates | Microsoft Learn
• PowerShell Gallery | SignatureDownloadCustomTask.ps1 1.4

 

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:

 

1. Fetch x64 security intelligence update and download to local folder that is named as a unique GUID, such as the following:

         C:\Windows\wdav-update\{00000000-0000-0000-0000-yMMddHHmmss}\mpam-fe.exe

 

2. Extract the x64 security intelligence update:

         mpam-fe.exe /X

 

3. The contents of the folder are now the extracted package:        

    

4. Copy the entire C:\Windows\wdav-update\{00000000-0000-0000-0000-yMMddHHmmss}\ folder to the file share at the following path: 
   
   \\fileserver.fqdn\mdatp$\wdav-update
   
   
5. Remove folders older than 7 days (configurable) in the following paths:
   
   C:\Windows\wdav-update\
   \\fileserver.fqdn\mdatp$\wdav-update\
   
   
6. Log all actions to the Application event log on the system

 

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.

 

• Define security intelligence location for VDI clients  This setting offloads the extraction of the security intelligence update onto a host machine (the server that is running the PowerShell job to fetch the updates and place them in the share in this case), which saves CPU, disk, and memory resources on the non-persistent VDI machines.

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:

 

• Trigger an antivirus scan
• Detection information
• Security intelligence updates
• Endpoint detection and response (EDR) in block mode

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.

 

• Specify the scan type to use for a scheduled scan  This setting allows you to specify the type of scan to be used, and for VDI machines the Quick Scan (default) value is recommended.
• Randomize scheduled task times  This setting ensures that scheduled scans are randomized at a four-hour interval and for VDI machines the Enabled or Not Configured (Default) value is recommended.
• Define the number of days before Antivirus security intelligence is considered out of date  This setting does just that. You need to pick the number of days after which you consider an endpoint’s antivirus to be out of date. If a client surpasses the number of days, certain actions, such as failing back to an alternate source and displaying warning icons in the user interface are triggered. This is another one you need to tune for your environment. Plan on tuning this in accordance with the number of days of security intelligence packages that you are keeping on the file share.

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).

 

• Define the number of days before virus security intelligence is considered out of date  This is the same setting as above, treat it and tune the same way. Typically, this will be the same setting as the setting above and in this example, I’ve also set this to “7.”

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