Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Configuring Microsoft Defender Antivirus for non-persistent VDI machines
Published Jun 25 2020 10:07 AM 75.4K Views
Microsoft

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:

 

 

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:

 

JesseEsquivel_1-1644599473076.png

 

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

 

  1. Extract the x64 security intelligence update:

         mpam-fe.exe /X

 

  1. The contents of the folder are now the extracted package:        JesseEsquivel_2-1593101705280.png

     

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

  3. Remove folders older than 7 days (configurable) in the following paths:

    C:\Windows\wdav-update\
    \\fileserver.fqdn\mdatp$\wdav-update\

  4. 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:

 

JesseEsquivel_3-1593101705281.png

 

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:

 

JesseEsquivel_4-1593101705288.png

 

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.

 

JesseEsquivel_5-1593101705296.png

 

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

48 Comments
Copper Contributor

Hello Jesse,

Question 1)
In your article you mention: Note: Defining a security intelligence location only works in Windows 10, version 1703 and above.
If I follow the link, the article begins with: In Windows 10, version 1903, we introduced the shared security intelligence feature.

So little confusion here is it from 1703 or 1903. I configured it here with 1809 and it seems to work.

Question 2)

I also have an other question. If the fileshare isn't available the VDI clients will boot without definitions.
Is it possible to start with a local definition set (build in the masterimage, this image is mostly build once in a month with new security patches.) 
So the image have at least a defnition set to start (of course it get outdated) and as soon as it start it trggers a update and update to the newest definiton set. In case the DFS/Fileshare is not available there is at least an definiton set loaded, there is some protection?

question 3)
We did some testing and see that immediatly after placing a new definition set on the file share als VDI client get updated in a few minutes
How do the clients know so fast that a new definition set is placed on the wdv-update share?

regards
Bert 



Microsoft

Hi Bert,

 

1) Thanks for pointing this out, the other article should say 1703 as the change was backported.  We'll get the article updated.

2) If you're running Windows update on your master image (before you deploy your pools) then you should have the latest SIU installed already : )  You can also choose to install the latest security intelligence update manually as part of your master image if you like.
    Microsoft Defender update for Windows operating system installation images

3) When the client checks for an update is controlled by a few settings (or default settings), have a look under Computer Configuration/Administrative Templates/Windows Components/Microsoft (or Windows) Defender Antivirus/Security Intelligence Updates

Best,

 

Jesse

 

Microsoft

Hi Baker - Check that you have both of these settings enabled:

Define file shares for downloading security intelligence updates

Define security intelligence location for VDI clients

Copper Contributor

Thanks for this - apologies I can see you covered that error in the blog (I didn't have the issue the first time I read it..!).

 

We have (to this point) been configuring the settings for VDI using group policy , not local group policy. I have since rectified this, but noticed a few issues:

1/ the registry in our master image is missing the 'UpdateOnStartUp dword=1' key , despite enabling local group policy setting 'Check for intelligence on startup'

 

2/ I've followed the guide above closely and have both settings configured in local policy. However, the VM's still fail to update from the file share. The share permissions are below. The VM's can contact the share and 

 

image.png

However, even with those both those settings defined it still doesn't work consistently.  We have 'Define file shares for downloading sec intelligence updates' set to: \\share\wdav-update.  The GPO informational help for that settings suggests multiple sources should be entered in the format {"\\uncshare1 | \\uncshare2"} - we only have 1 share, so I'm assuming that because we only have 1 source, then entering the value without {".."} characters is still valid? e.g.  \\share\wdav-update

As you can see, we have both aforementioned policies configured locally, we also have 'Check for intelligence updates on startup' and 'Check for latest virus and spyware intell on startup' too. Strangely, when setting these latter 2 policies on the local policy editor, no registry key is created under HKLM\Software\policies\MS\Windows Defender\Updates..\UpdateOnStartUp dword=1  - but if it's set via group policy on the domain, then those registrry keys are created . I added the key manually on our image, rebooted, but the VM's still don't update. 

 

This is the local group policy settings:

image.png

Is this valid as a value, or must we also set the other possible values in order of preference i.e. FileShares|MMPC|UpdateServer etc, and if so, should the values be entered in the same formatting as the help example with a carriage return between each pipe e.g. FileShares | MMPC, or Fileshares|MMPC ?

image.png

 

At this point it's really not clear why this is failing - we've set the baseline policies correctly, and I've even tested it functionally by using psexec to launch cmd prompt as SYSTEM context, browse to the share, and run the mpam-fe.exe file - it installs and updates the VM in moments. Any pointers on what might be causing this misconfiguration? We actually had this working (albeit erratically) by using only group policy, no local policy - some VM's would update, others would not, we have no other AV installed on our image (fresh build). I would also expect our master image (logged in as local admin) to update itself , there are no 'ACCESS DENIED' errors in the event log.

 

This is how the registry looks on the VM's . When they boot they show up to date. checking the mplog file , it shows the share is being checked, but then it refers to a local definition pack instead of downloading the latest from the share? Note, if I then manually update the definition pack to the latest, the GUI still declares it's up to date, and the engine revision changes accordingly - the VM thinks it's up to date, but it's not...

image.pngimage.pngimage.png

Sorry for lengthy email, but I'm amazed how convoluted it is to get this working, do you have any ideas/pointers for troubleshooting this please?

 

 

 

 

 

 

 

 

Microsoft

Hi Baker - the best course of action to receive help on this is to open a Microsoft support case.

Copper Contributor

For anyone else experiencing issues with this - we resolved it by doing the following:

1/ Delete the local group policy cache %windir%\System32\GroupPolicy (hidden) User and Machine folder.

2/ Configure the settings mentioned in the above blog in local policy only, reboot.

3/ Configure the other settings (scan times, quarantine actions etc) in domain group policy.

4/Set the 'Define order of sources..' as 'Fileshares' only, no other values.

 

Thanks

Copper Contributor

Hi,

Really good article, thank you.

 

My question relates to reporting on Defender antivirus compliance.

Microsoft's documentation states this is usually achieved through SCCM, Intune or MEM.  However traitionaly non-persistent VDI desktops are not managed by these systems due to their starless nature.

What is the best way to report antivirus compliance for the non-persistent desktops?

Copper Contributor

@baker999855How does your setup looks alike (e.g. NTFS Security Permissions?)

I am trying getting to work it for weeks - and I am still failing.

 

What does work on my lab:

  • Downloading the Windows Defender Updates mpam-fe.exe from the x64 shared folder and extratcting it on all VDI's - that's not my golden target. I want to save the CPU performance for extracting the mpam-fe.exe on every VDI

What dows not work on my lab:

  • Downloading the extracted Security Intelligence Update files from the mpam-fe.exe in the GUID shared folder and self deploying it without any extracting task on all VDI's - the well known permission error is appearing in Windows Defender log file and Eventlog

I am curious how you have got it to work.

 

Thank you in advande

Daniel

Copper Contributor

Hi

 

I've written a blog post about this desktopsurgery.com - check it out. If, like me, you read the microsoft blog posts too quickly - the most important thing is to ensure your local group policy on your master image is configured correctly and you enable all three settings on the local image local group policy. 

 

Define file shares for downloading security intelligence updates = \\YOURSMBShare\wdav-update

Define file shares for downloading security intelligence updates = \\YOURSMBShare\wdav-update

Define order of sources for definition updates = "Fileshares"

 

Re. smb permissions - they are all defined in the blog post.

 

Happy to help if you get stuck

Dave

Copper Contributor

Jesse,

 

Do the above steps from this blog work if you have Windows Update disabled in your non-persistent VDI?

Copper Contributor

@dwrice0  yes they do - we have windows update and windows modules installer disabled on our images and Defender works without issue.

Copper Contributor

@baker999855  I'm going crazy. I can't get it for working even with your blog.

I have created a fresh new test share on my 2019er lab DC. I can see - based on your posted screenshot for SMB Access - that you have added the BUILTIN\Administors Group. On an Active Directory you can setup such a file share only on a Domain Controller. Not on any other server member system.

My share permissions are exactly the same:

23-03-_2021_12-49-51.png

 

 

I have shared the folder with following UNC-Path: "\\ADS01\wdav-update".

My NTFS permissions are the same:

23-03-_2021_12-52-38.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I have cleared up the Group Policy Cache on my MDT fresh installed Win 10 20H2 VM and only added the above mentioned UNC path in the Local Group Policy Editor under "Define File Shares for downloading Intelligence Security Updates" and "Define Security Intelligence location for VDI Clients". And of course setting the local GPO "Define the order of the sources for downloading security intelligence updates" to "FileShares" only.

 

The joke is:

  • when I am modifying the NTFS permissions for Authenticated Users in Write permissions, the GUID folders will be deleted on the share published by my DC from my fresh MDT installed Win 10 20H2 VM with new applied Group Policy Cache. 
  • But the Windows Defender eventlog is always logging the Event ID 2001 and Event ID 2003 - Access denied to the security intelligence updates whether Authenticated Users have read only permissions or write permissions.

I am openminded for new ideas I can trying for. :smile:

 

Best,

Daniel

Best,

Daniel

Copper Contributor

I forgot to mention - did you also configure

'Check for updates on startup' = enabled

'Disable Windows Defender Antivirus' = Disabled

 

Onyour master image local group policy?

 

Also - try installing an 'old' mpam-fe.exe file from yesterday (or whatever the oldest file you have is) - we found that if there are no pre-existing definitions for Defender, it simply didn't update itself - I had to manually install the mpam-fe.exe on the image, reboot, wait for a new definition to be published, then it started working...

 

Also, if you try setting EVERYONE permission to the share - do you see the definition folders being deleted/purged when your VM's boot (assuming you've enabled 'check at startup..)? This would suggest the VM's are parsing the folders - so you're nearly there...Let me know re. the above , below are the permissions on our share, and the underlying NTFS folder perms.

 

baker999855_0-1616501837933.pngbaker999855_1-1616501884059.png

 

Copper Contributor

Also -try adding SYSTEM account permissions - at start-up the machine is querying the folders as the SYSTEM account - so I suspect this might be contributing - although Authenticated Users will also include authenticated computers, perhaps the actual parsing of the definition folders happens under the SYSTEM context -worth bearing in mind!

Copper Contributor

Hello @baker999855,

yes I have set up modifying NTFS permissions for SYSTEM account (look at my permissions screenshot above).

I have tried your suggestions, too: check for updates on startup, prevent Windows Defender from deactivating and installing an old mpam-fe.ex from two days before.

Nothing helps, I can't download any security intelligence updates form my file share.

Time to speak about your master. I'm using MDT and WDS for deploying the default Win 10 20H2 Pro wim file on my master image. After that the default actions for

  • joining the domain
  • installing software
  • and installing WSUS updates from my WSUS server

are running in the task sequence. Nothing else. After the reboot from WSUS MDT tasks I am clearing the local GPO cache, install the old mpam-fe.exe manually and setting up the new local GPO with the five settings:

  • Define file share for security intelligence updates
  • Define file share for security intelligence updates for VDI clients
  • Define the order only to "FileShares"
  • Check for updates on startup
  • deactivate the Windows Defender deactivating policy

Then I perform the reboot of my master. After startup checking the Windows Defender event logs will provide me the "Access denied" entries and no update has happened.

 

How about your master image setup? Are you using MDT and WDS? Are you joining the domain with your master?

 

Best,

Daniel

 

Copper Contributor

Yes our master is joined to the domain, but logged in/modified using a local admin account.

Some more things to try:

- Can you browse to your UNC share from your master and execute the mpam-fe.exe file over the network (i.e. could a GPO be preventing running executable over the network?)

- What does your Virus and Threat Protection console look like, and is your mplog.log file showing that the UNC share is being parsed? (see the ‘validating’ section of my blog post)

-Are the downloaded definitions being unpacked - you should have  (i.e. are you using the microsoft script - I assume so?) should look like this:

baker999855_0-1616508952645.png

 

- Download PSEXEC and run a cmd prompt as the SYSTEM context (blog post explains how) – then try browsing to the UNC share and executing the mpam-fe.exe remotely over the network under SYSTEM context – does that work?

-Are the ADMX template you’re using on your DC suitable for 20H2 Windows? This is bleeding edge windows version - so maybe there's some known issues with that?

-Try disabling UAC completely on your master image and make Authenticated Users part of the Administrators group in lusrmgr.msc - see if it's some issue with account context ?

 

-If you configure the group policy settings at domain level - do these apply? Can you see the settings in the registry under HKLM\Software\Windows Components...\Defender...I can't remember the tree - but search your registry for the \\UNCshare\ to find where they apply.

 

We are using MDT to build our images and similar to you - we build, join to domain, install software etc, nothing different. The local gpo settings are applied , I then double check them (we have a domain policy that disables Defender, so I have to ensure that's not been applied..).  

 

 

You present a good challenge!! Keep me posted

 

 

Copper Contributor

Hello @baker999855 ,

I am appreciating for accepting the challenge! :smile: And I am hoping that my non-native english writing skills are suitable for you, too. 

To answer you questions:

Yes I can execute the mpam-fe.exe with SYSTEM account on my master image. The login on to the master image has been executed with the local Administrator Account which MDT is activating:

23-03-_2021_16-25-40.png

The successful update event is logged correctly in the Windows Defender event log as "NT Authority\SYSTEM" user.

The Domain GPO's are executed correctly. You can refer to the following registry path for analysis: "HKLM\SOFTWARE\POLICIES\MICROSOFT\Windows Defender". Under HKLM\SOFTWARE\POLICIES\MICROSOFT\Windows Defender\Signature Updates" the file share settings were saved. Under the "Windows Defender" folder you can find many other settings - if you have activated them with local GPO or Domain GPO's. 

After a reboot the master will fail furthermore fetching the signature updates with executing the Domain GPO's.

 

Adding the "Authenticated Users" to the local Administrators group on the master image does not make any difference. Fetching the signature updates from the file share will still fail.

 

My GUID folder on the file share does look like yours, too. The only difference is that I am using @JesseEsquivel MDT "long term" script and  not the "short term" one referencing the VDI Windows Defender guide for fetching the updates. But i think that does not matter because I can successfully execute the mpam-fe.exe file with a SYSTEM account on that file share.

 

When I am trying for updating the signature updates over the Windows Security Dashboard the progress cycle is shown with the hint that I am already up-to-date - and nothing happens. I have to abort manually because the update process will never finish. The interesting thing is: Neither one log entry in the mplog file is created for that update process nor the eventlog will monitor this failing - nothing for the manual update is monitored at all.

 

When I am rebooting the master image for fetching the signature updates during boot cycle the following mplog entry will be logged:

23-03-_2021_16-15-08.png

 

So you can see the decimal error code for "Access Denied" in the mplog as well.

I am starting for beliving that I have found a bug in Win 10 Pro 20H2...

 

Best,

Daniel

 

Copper Contributor

The event log also has Defender log which is useful. Screenshot of what settings are enabled in LGPO:

baker999855_0-1616515233406.png

 

I see the same thing (manually updating defender on the image will just egg-timer and not log any event). If you publish your master image to a pool, then log into one of the child vms and browse to the UNC share - can you execute the mpam-fe.exe as the logged in user without any UAC issue?

Copper Contributor

@Daniel-San  funnily enough, I have just rebuilt a 1909 image and tried to configure defender (with all the pre-existing infrastructure in place..) and I see the same problem you are having  8007005 error in the event log and VM's not updating. I'm comparing my working build to this one, can't find anything different and a few things that I've checked that I hadn't shared earlier-

-March OS patching for windows - I've not explored if this could have broken something?

- This article has a few other bits to check in your registry: https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/troubleshoot-onboarding?vi... 

- I've enabled SMB 1.0 via windows features - in our environment we have a number of v old file servers - I don't know if our definitions are on a box running smb 1.0...

 

Let me know how you get on as I suspect I have the same problem as you at this point?

Copper Contributor

baker999855_0-1616610187179.png

I got the same problem - the VM's are parsing the share, but not applying? Got knows how this permissions thing has recurred - I've made zero changes to my group policy (local or domain)....

 

Copper Contributor

Hi @baker999855,

 

I can confirm that my testings all have running with the newest WSUS updates - so Windows 10 Cumulative Updates for march are installed on my master Win 10 20H2.

If this problem is production fencing for you, you can create as a workaround the "x64" folder under the "wdav-update" shared folder and copy the newest mpam-fe.exe under this "x64" folder.

With temporarily deactivating the local GPO on your master template for "Define file share for security intelligence updates" and only activating the local GPO "Define file share for security intelligence updates" all pooled VDI clients will download the mpam-fe.exe file from the "x64" folder from the share and are extracting it by themselves for updating Windows Defender.

That's why I am using the long term script of @JesseEsquivel for downloading the security intelligence updates. The script is considering this circumstance and will create the GUID folder for the extracted delta signature updates and is copying the newest mpam-fe.exe to a "x64" subfolder on the "wdav-update" share.

 

Best,

Daniel

Copper Contributor

Hi @baker999855,

little correction. I mean:

...With temporarily deactivating the local GPO on your master template for "Define file share for security intelligence updates for VDI clients" and only activating the local GPO "Define file share for security intelligence updates" all pooled VDI clients will download the mpam-fe.exe file from the "x64" folder from the share and are extracting it by themselves for updating Windows Defender...

 

Best,

Daniel

Copper Contributor

I will try that - but did you fix your problem by simply adding the x64 directory, or are your VM's still failing to download definitions?

Copper Contributor

Hello @baker999855,

the VDI's are still failing, when you want them for downloading the extracted deltas of signature updates. At the moment they will only have the ability for downloading the single file mpam-fe.exe from the x64 folder and then they will all extract this .exe file by themselves and applying the extracted deltas of the single .exe file with the delta signature updates by themselves, too.

So with the problem we have qualified the big advantage for every VDI is lost that they are able for downloading the extracted delta files for the signature updates from a file share. And this, of course will generate more load on every single VDI - depending of the count in your production environment because the task for self extracting of the .exe file has to be done on every single VDI.

 

Best,

Daniel

Copper Contributor

Hello ,

 

How does the alerting work in this case ? We did setup Windows Defender in our non-persistant VDI infrastructure, however, since SCCM is not in the equation ,we don't have any email alerting system in palce.

Any suggestion? 

Copper Contributor

Hi all,

 

We're currently trying to set up Microsoft defender on a non-persistent VDI image. We got the image to connect with the definition server however its failed to pull in the new definitions.

We ensured that the authenticated users had read and execute permissions on the shares. It looked to have parse through but it unfortunately defaults to the local definitions on the machine.

Any suggestions on what we can do here? We've set up the image and definition server to how the blog has it set up above.

 

Regards,

Keith

 

Copper Contributor

The only way our VMs were able to pull updates from the share is when we granted Domain Computers read access to it, so Microsoft should probably update their requirements. It certainly doesn't work with just the listed permissions.

Copper Contributor

Can you advise on making the download proxy aware?  Thanks.

Copper Contributor

what is the recommended size for this share?

 

Apologies if I missed it.

 

Thanks!

 

Ellen

Copper Contributor

I just came across this thread and was hoping to get some feedback on an issue we're having with Onboarding our Horizon Instant Clone desktops into Defender.

 

In a nutshell:

  1. We are NOT using a shared intelligence server, we are allowing the desktops to pull down updates directly from WU.
  2. We are utilizing a post-sync task on the Horizon pool that runs a script that:
    Clears any onboarding data in place (gold image is clear but we do this anyway)
    Runs the Onboard NonPersistent Powershell

The thing we're running into, is we see a very high utilization number on the disk inside our VMs. Unfortunately, we're unable to trigger this on demand, it seems a bit random. Last night I republished a pool of 700 desktops. It got through the first 480ish no problem, running the task and all, when all of a sudden the remaining ones were not finishing their tasks and they errored out. When I looked into it, the VMs were showing the disk at 100% like this:

EdwardAnsbro_0-1669739066053.png

 

Is there a "bottleneck" where X devices onboarding at once can hit a wall? Or are we suffering the consequences of not having the shared intelligence server? We did speak with a Microsoft rep on this, and he led us to believe a shared intelligence box in our environment wasn't necessary. That allowing WU to handle the updates would be sufficient.

 

Thanks in advance.

Microsoft

Hi @Edward Ansbro That service in your screenshot is the Defender AV service. It is not related to EDR specifically and has nothing to do with onboarding. Sending your non-persistent VDI machines to WU/MU for security intelligence (SIU) can put unnecessary strain on the network and be repetitive each time your VMs are provisioned. Updating the SIU also requires the machine to use disk resources to download the update, extract, and apply it. I would consider trying the shared security intelligence method and see if it makes a difference. Also make sure your master is running the latest AV platform/engine before deploying your pools.  Best course of action is to open a support case to understand what AV operation is using the disk.

Copper Contributor

Hi @JesseEsquivel,

 

1st of all thanks for the reply. Very much appreciate your feedback.

 

We have multiple VDI pools that we're attempting to get on Defender. At the most basic level, we have Defender installed and active on our gold image. For the sake of this discussion, we'll say the image is fully patched up Windows 10 20H2 as of October 1st, including any Defender patches/updates we have. We then published all of our pools with said image, and in the other pools, we don't SEEM to be seeing this issue. Now there are several difference/possible differences:

 

  1. The different pools technically have different images. Yes, we try to keep them identical except when software requirements differ, but by and large they are similar. Similar though does not mean EXACT.
  2. The different pools are on different back-end hardware. This problem pool lives on hardware with 8180 processors, the pools we don't feel it in, live on 8280 processors. All are on vSan storage from VMware.
  3. The pools where we don't see the issue are not performing any onboarding whatsoever, Defender just runs as is from the gold image.
  4. ALL of the pools are sharing one VDI GPO for settings/exclusions whether onboarded or not. I could certainly see this GPO needing to be fine-tuned. It is basically a copy of the GPO our server group uses for Defender, with our VDI exclusions piled on, but it wouldn't shock me if we need this cleaned up.

Point #3 is where I keep going back to the onboarding as a possible culprit, but perhaps it's time we circled back to looking at the shard intelligence server.

 

I'm on a virtual desktop still that got created/onboarded last night and rode through the high disk usage (it's the screenshot I provided), and this is how it looks now. Keep in mind I've just been connected to this, I haven't really done any work with it. Just been squatting on it. Disk you can see is down, expected. Memory seems high to me but, maybe it's expected:

EdwardAnsbro_0-1669775112487.png

 

For contacting Microsoft support, can you recommend any certain team/verbiage to use to get a solid group to look into this with us? The reason I ask, is it feels like we're always kind of getting contacts from Microsoft that aren't familiar with what we're trying to do, Defender on VDI non persistent. Almost like they're seeing it for the 1st or 2nd time. Like I said, it was a Microsoft contact who actually told us to just go straight to WU for Defender intelligence updates, even though we made them aware of the shared intelligence deployment write up.

 

In regard to your line about making sure the latest Defender software is on the gold image, in a VDI world where you have a gold image you have to update/snapshot and then push the update, is it reasonable to do this monthly/bi-monthly? That's really the shortest maintenance window we can get in our environment. If these aren't quick enough, can it be problematic?

 

Again, thanks very much for the reply.

Microsoft

Hi @Edward Ansbro I would open a case: "High disk usage on Windows 10 non-persistent VDI when using Defender for Endpoint." That should route the case appropriately. Yes monthly is fine for keeping your master up to date, typically see it updated at least once a month around patch Tuesday. As long as the defender platform/engine is n-3 (one of the three most recent releases) it is supported.

Copper Contributor

@JesseEsquivel,

 

Thanks again for the reply. We're in the process of building up the SI server, and my teammate ran into this:

I'm playing around with the powershell script from Microsoft's instructions and it appears whenever it runs to gather the latest definitions, it downloads the definitions and unpacks them into a new folder, but the old ones are not removed.

 

When the script ran the second time, it downloaded the full package so we know its not an incremental/partial update or anything like that.

 

My concern is if each download is 250MB or so, we will be eating up over 1GB of disk space per week before manually clearing out. (if we're scheduling this to run once every evening)

 

Our 1st thought is to create a scheduled task to remove old files. Is this the route you would go?

Copper Contributor

and actually Jesse, I just re-read your write up and saw this. Answer my question on space.

 

  1. Remove folders older than 7 days (configurable) in the following paths:

  C:\Windows\wdav-update\

  \\fileserver.fqdn\mdatp$\wdav-update\

Copper Contributor

@JesseEsquivel 

 

Our environment is seeing still random incidents of large Horizon instant clone pools experiencing the high disk usage. This is even though we've completely removed the onboarding process on the gold image, to help isolate the issue further. Seems to enforce what you stated earlier that the issue isn't onboarding related.

 

We still have not built a Security Intelligence server but we are looking to today. I feel like this is also not our issue honestly though, as the problematic pool we saw yesterday has been spun up for a while, and also was republished Sunday afternoon. If a SIU was going to crush it, would we not see it sooner? We went through Sunday, Monday, and all day Tuesday until 2PM Eastern when we saw it.

 

Right now my suspicion is on the Defender GPO we have applied to where these machines live. The policy being used there was not designed specifically for VDI, it was actually a server GPO that our Defender admins seemed fine copying and just adding VDI specific exclusions for, but I'm thinking this was probably not the way to go. We're seeing things in there such as:

Screenshot 2022-12-07 081659.png

 

I really feel perhaps there is a scan/randomized task that is happening on our pools, that causes that issue. From 2PM until maybe 9PM yesterday we were seeing the issue, then without really any kind of change, it stopped. Implying that Defender runs normal, until something happens that starts killing disk, that eventually does end.

 

Sorry if all over the place, we were up pretty late. In a nutshell: we're going to review that GPO and see if we can test modding it on a dev OU/Horizon pool. I'm in favor or just removing Defender's GPO outright and having plain vanilla settings to test for a bit, perhaps with Horizon exclusions only, but that's where we're starting. We still haven't had any luck getting Microsoft support on a call, but hoping to push that some.

 

Thanks in advance.

 

Edit: wanted to add, as a troubleshooting step last night, we cloned the problematic image to a separate data center/ESXi host hardware and spun up 2 spare pools. The provisioning on them was BRUTAL, the exact same behavior. Once we hit like 800 VMs, the remaining 400 to provisioning were terrible. We looked at it, and the disk was high. We took the image again and this time disabled Defender outright on the image by disabling these services: Microsoft Defender Antivirus Service, Security Center, Windows Defender Advanced Threat Protection, and Windows Security Service. After disabling them, snapping, and republishing the pool, it went smooth as silk.

Copper Contributor

We ended up tracking it down to a scheduled task that was on our gold image. I'll post more details in the morning.

Copper Contributor

We believe we've identified what was causing our VMs to see a disk usage crush inside Windows on deployment. One of our security admins was seeing inside the Defender/Sentinel console a task being kicked off on all the deployed VMs, but we couldn't find it on them. It was really driving us nuts. We decided to crack open the gold image and look there for something else, and we happened upon it. It's disabled now, but last night this task "Windows Defender Scheduled Scan" was enabled:

 

EdwardAnsbro_2-1670502017575.png

 

 

 

Again, on the deployed VMs OFF THIS SNAPSHOT, the task isn't there. We're still not sure what whacks it after deployment, but it certainly kicks off after deployment. This was the action he was seeing in the console that we were trying to track down, and eventually did back to that task:

 

EdwardAnsbro_3-1670502035486.png

 

 

 

If anyone else has run into this, I'd love to hear any input/feedback on your experience. This has been a real doozy. We also were NOT running scans inside the gold image before last night, we ran a Quick Scan before sealing it, and it sounds like we'll make that part of our image process.

 

Thanks.

Copper Contributor

@JesseEsquivel 

 

We're looking to make our non-persistent desktops strictly use realtime scanning only. We don't want any quick or full scans in the environment at all, none whatsoever. We can have buy in from our security group for non-persistents specifically to be this way.

 

We've disable settings across our policy, and while we have no indication anything we did/didn't do is having a negative impact, we also are seeing what appears to be daily quick scans happening, even though our GPO has ScanScheduleDay set to 8 which is never.

 

Mine for example has done a quick scan at 2:15AM the past 2 mornings. Below is a Get-MpPreference from my machine, you'll see ScanScheduleDelay is 8. Are we missing more settings?

 

AllowDatagramProcessingOnWinServer : False
AllowNetworkProtectionDownLevel : False
AllowNetworkProtectionOnWinServer : False
AllowSwitchToAsyncInspection : False
AttackSurfaceReductionOnlyExclusions : {N/A: Must be and administrator to view exclusions}
AttackSurfaceReductionRules_Actions :
AttackSurfaceReductionRules_Ids :
CheckForSignaturesBeforeRunningScan : True
CloudBlockLevel : 0
CloudExtendedTimeout : 0
ComputerID : REMOVED JUST BECAUSE
ControlledFolderAccessAllowedApplications : {N/A: Must be and administrator to view exclusions}
ControlledFolderAccessProtectedFolders :
DefinitionUpdatesChannel : 0
DisableArchiveScanning : False
DisableAutoExclusions : False
DisableBehaviorMonitoring : False
DisableBlockAtFirstSeen : False
DisableCatchupFullScan : True
DisableCatchupQuickScan : True
DisableCpuThrottleOnIdleScans : True
DisableDatagramProcessing : False
DisableDnsOverTcpParsing : False
DisableDnsParsing : False
DisableEmailScanning : True
DisableFtpParsing : False
DisableGradualRelease : False
DisableHttpParsing : False
DisableInboundConnectionFiltering : False
DisableIOAVProtection : False
DisableNetworkProtectionPerfTelemetry : False
DisablePrivacyMode : False
DisableRdpParsing : False
DisableRealtimeMonitoring : False
DisableRemovableDriveScanning : True
DisableRestorePoint : True
DisableScanningMappedNetworkDrivesForFullScan : True
DisableScanningNetworkFiles : False
DisableScriptScanning : False
DisableSmtpParsing : False
DisableSshParsing : False
DisableTlsParsing : False
EnableControlledFolderAccess : 0
EnableDnsSinkhole : True
EnableFileHashComputation : False
EnableFullScanOnBatteryPower : False
EnableLowCpuPriority : False
EnableNetworkProtection : 0
EngineUpdatesChannel : 0
ExclusionExtension : {N/A: Must be and administrator to view exclusions}
ExclusionIpAddress : {N/A: Must be and administrator to view exclusions}
ExclusionPath : {N/A: Must be and administrator to view exclusions}
ExclusionProcess : {N/A: Must be and administrator to view exclusions}
ForceUseProxyOnly : False
HighThreatDefaultAction : 0
IntelTDTEnabled : True
LowThreatDefaultAction : 0
MAPSReporting : 2
MeteredConnectionUpdates : False
ModerateThreatDefaultAction : 0
PlatformUpdatesChannel : 0
ProxyBypass :
ProxyPacUrl :
ProxyServer :
PUAProtection : 1
QuarantinePurgeItemsAfterDelay : 30
RandomizeScheduleTaskTimes : True
RealTimeScanDirection : 0
RemediationScheduleDay : 8
RemediationScheduleTime : 02:30:00
ReportDynamicSignatureDroppedEvent : False
ReportingAdditionalActionTimeOut : 10080
ReportingCriticalFailureTimeOut : 10080
ReportingNonCriticalTimeOut : 1440
ScanAvgCPULoadFactor : 20
ScanOnlyIfIdleEnabled : False
ScanParameters : 1
ScanPurgeItemsAfterDelay : 15
ScanScheduleDay : 8
ScanScheduleOffset : 120
ScanScheduleQuickScanTime : 00:30:00
ScanScheduleTime : 02:00:00
SchedulerRandomizationTime : 4
ServiceHealthReportInterval : 60
SevereThreatDefaultAction : 0
SharedSignaturesPath :
SignatureAuGracePeriod : 0
SignatureBlobFileSharesSources :
SignatureBlobUpdateInterval : 60
SignatureDefinitionUpdateFileSharesSources :
SignatureDisableUpdateOnStartupWithoutEngine : True
SignatureFallbackOrder : InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC
SignatureFirstAuGracePeriod : 120
SignatureScheduleDay : 0
SignatureScheduleTime : 07:00:00
SignatureUpdateCatchupInterval : 1
SignatureUpdateInterval : 8
SubmitSamplesConsent : 3
ThreatIDDefaultAction_Actions :
ThreatIDDefaultAction_Ids :
ThrottleForScheduledScanOnly : True
TrustLabelProtectionStatus : 0
UILockdown : False
UnknownThreatDefaultAction : 0
PSComputerName :

Copper Contributor

and I spoke to soon. We saw similar behavior again today, even though we disabled that Task. I don't know. I'm just getting lost.

Copper Contributor

We've configured our test pools to use the newly created intelligence server. Hopefully around 4PM we'll see a difference. Fingers crossed.

Microsoft

Hi @Edward Ansbro please open a support ticket on this issue.

Copper Contributor

Didn't seem to matter. Around 3:30PM we saw the high disk behavior, even though no apparent tasks seem to be running and we've randomized as much as we can seem to.

 

Thanks @JesseEsquivel, we have a ticket ongoing with Microsoft we started last week.

Copper Contributor

I was on 2 VMs today when the issue started, around 3:40PM. It calmed down around 4:30PM give or take. When I looked in Task Scheduler on both VMs, we saw the tasks for Defender all ran, and finished, in this window:

VM#1:

EdwardAnsbro_0-1670880538761.png

 

VM#2:

EdwardAnsbro_1-1670880546069.png

 

Our assumption is the clone is going out with the tasks in that ballpark, and the child VMs are all running these together or around about. We have a GPO for Randomization of tasks, but perhaps this isn't in reference to THOSE tasks. We're wondering if we should maybe disable these tasks outright on the gold image.

Copper Contributor

Thank you so much for writing and sharing this information.

 

On your script I had to change line 155 so it extracts. Basically, just added /d
Start-Process C:\windows\system32\cmd.exe -ArgumentList "/c cd $vdmpath & mpam-fe.exe /x" -Wait -WindowStyle Hidden to  Start-Process C:\windows\system32\cmd.exe -ArgumentList "/c cd /d $vdmpath & mpam-fe.exe /x" -Wait -WindowStyle Hidden

 

Might be useful to add a variable for the destination, if possible, instead of \\fileserver.fqdn\mdatp$\wdav-update\x64

 

Maybe some instructions saying that you will need to change the following viables for your environment:

$vdmpathbase

 

 

Brass Contributor

@Edward Ansbro 

A late response since I came across this post today

 

These values should be evaluated and changed (with testing etc), CloudExtendedTimeout is very none-intrusive but since it's a VDI I recommend proper testing

CloudBlockLevel : 0

CloudExtendedTimeout : 0

SubmitSamplesConsent : 3

to

CloudBlockLevel : 2 (high)
CloudExtendedTimeout : 50s

Depending on the reason why it's set to 3, but really recommend 1 (always send) otherwise cloud protection does not work fully, the other option is 2 (send safe samples automatically)

SubmitSamplesConsent : 1

 

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/cloud-protection-microsof...

 

Also quarantine on all threat levels

 

 

Best

 

Mattias

Security MVP

Brass Contributor

Hi,

I'm using a non-persistent VDI and am currently setting the First Boot settings such as SharedSignatureRoot and UpdateOnStartUp using LGPO.exe plus setting the onboarding PS1 script as a Computer Startup script via gpedit before then shutting down and snapshotting my golden image.

We will be moving to VMware Instant Clones soon which are more complicated due to their parent VMs.  Should both of the above be done from the ClonePrep Post Sync script or do I continue to do the LGPO bit via Computer Startup in the golden image as currently and just do the onboarding from Post Sync?

Thanks!

Microsoft

@Andrew Johnson you can continue to use the documented onboarding method. 

Co-Authors
Version history
Last update:
‎Mar 23 2023 08:59 AM
Updated by: