Configuring Microsoft Defender Antivirus for non-persistent VDI machines

Published 06-25-2020 10:07 AM 20.7K Views

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 ATP 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 Endpoint Manager 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. The settings can be accessed in the local group policy editor at the following path:


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 be “Windows Defender Antivirus” or “Microsoft Defender Antivirus” in the latest templates. The Define the order of sources for downloading security intelligence updates setting is what you should configure first. There are four ways the update can be delivered to the VDI machine:


  1. InternalDefinitionUpdateServer
  2. MicrosoftUpdateServer
  3. Security intelligence updates (formerly known as the Microsoft Malware Protection Center (MMPC) security intelligence)
  4. FileShares

These are the only possible values for the setting. You can configure the order that VDI machines will check these locations by listing them in the preferred order and delimiting them with the pipe (|) character. Guidance on configuring this setting is documented here.


For VDI, the most optimal choice is to have the non-persistent machines fetch the security intelligence update from a file share on the LAN. The recommended setting would look like this:


  1. FilesShares
  2. MicrosoftUpdateServer
  3. Security intelligence updates (formerly known as the Microsoft Malware Protection Center (MMPC) security intelligence)
  4. InternalDefinitionUpdateServer

Steps 3 and 4 can be swapped if you have a Windows Server Update Service (WSUS) server that hosts the updates. As noted in the guidance, security intelligence updates (formerly MMPC) should be a last resort, due to the increased size of the updates. In a case where there is no WSUS server in the environment, in the local group policy editor, the setting will look like this:




When a preference order is set for the VDI machines, 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:



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:



  1. Extract the x64 security intelligence update:

         mpam-fe.exe /X


  1. The contents of the folder are now the compressed package (mpam-fe.exe) and the contents of the package (this is important later)        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:



  1. Copy the file  C:\Windows\wdav-update\{00000000-0000-0000-0000-yMMddHHmmss}\mpam-fe.exe to the following path:



   Note: The x64 directory MUST be present or clients will fail to find the security intelligence

   package update.


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




  1. 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 there are a couple of settings to configure and they are listed below.


“Define file shares for downloading security intelligence updates” This setting tells the VDI machines what the UNC path to the file share that holds the updates is. In this example we set it to:




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. Here is a snip from the MPLog (located in C:\ProgramData\Microsoft\Windows Defender\Support) after enabling the setting:




All VDI machines (that will use a file share) must have this setting enabled, even if they are using the shared security intelligence feature below Define security intelligence location for VDI clients.


  • Initiate Security Intelligence on startup  This setting tells the VDI machines to update security intelligence on startup when there is no antimalware engine present. In our example, we set it to Enabled or Not Configured.
  • Check for the latest virus and spyware security intelligence on startup  This setting tells the VDI machines to check for the latest AV and spyware updates at startup. In our example we set it to Enabled.
  • 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: Defining a security intelligence location only works in Windows 10, version 1703 and above. If you are running 1703 or later, then you can enable this setting, but be aware that the VDI machines expect the extracted security intelligence update to be available at the following location:


This is why in the PowerShell sample, not only do we copy the compressed security intelligence package (mpam-fe.exe) to the share, but we also copy the extracted contents of it as well. Since we copy both the package and the contents, we can point any version of Windows 10 to the same share for the security intelligence updates.


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:




Note: This setting will NOT work without the Define file shares for downloading security intelligence updates setting also enabled. If you do not enable this other setting, you will see the following error in the operational log:




The biggest thing to remember is what folders machines will go to for the security intelligence update depending on whether or not 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:




For VDI systems (or physical machines that will use a file share) that DO NOT have the Define security intelligence location for VDI clients setting enabled, they will look at the following path for updates:




This is why the x64 directory is required. This is detailed in the MPLog (located in C:\ProgramData\Microsoft\Windows Defender\Support):



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. When Microsoft Defender Antivirus is in passive mode, Microsoft Defender ATP still uses the AV engine to perform certain functions, some of which are in the Microsoft Defender Security Center portal ( 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 them here as well for our example scenario.


  • 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.
  • Specify the day of the week to check for security intelligence updates  This setting allows you to specify the day of the week that you want the VDI machines to check for updates. Since VDI machines are non-persistent and are in some cases short lived the recommended setting for this is Every Day or Not Configured (Default Setting).
  • Specify the interval to check for security intelligence updates  This setting sets the interval (in hours) at which the VDI machines will check the file share for security intelligence updates. Tune this based on the interval that your scheduled task (on the server) is downloading the security intelligence packages, and other environmental factors. For our example, my server machine  is fetching security intelligence packages every 4 hours, and I’ve set this to every 2 hours on the VDI machines.

  Note: Microsoft releases security intelligence updates up to every four hours.


  • 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 compressed and 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, Program Manager

Microsoft Defender ATP

Occasional Visitor

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?



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






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

New 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 



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:


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 ?



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


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?










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

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



Occasional Visitor


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?


@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


New Contributor



I've written a blog post about this - 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


Occasional Visitor



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

New Contributor

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


@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:




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

My NTFS permissions are the same:




















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:






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




New 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!


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?





New 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:



- 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




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:


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:



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





New Contributor

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



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?

New 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: 

- 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?

New Contributor


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



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.





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




New 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?


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.




Occasional Visitor

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? 

Version history
Last update:
‎Nov 30 2020 07:48 AM
Updated by: