# Trying to update windows defender from UNC path continuously fails

I'm trying to update Windows Defender (on Win 10) using definistions stored on a UNC path.

I'm setting the path the the mpam-fe.exe file like this

Set-MpPreference -SignatureDefinitionUpdateFileSharesSources \\path\to\mpam.exe


Then I'm running Get-MpPreference to verify that the path was set (it is). Once I verify that the path is correct for SignatureDefinitionUpdateFileSharesSources I run

Update-MpSignature -UpdateSource FileShares


I instantly get the error

Update-MpSignature : Virus and spyware definitions update was completed with errors.
At line:1 char:1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound:    (MSFT_MpSignature:ROOT\Microsoft\...SFT_MpSignature) [Update-MpSignature], CimException
+ FullyQualifiedErrorId : HRESULT 0x80070002,Update-MpSignature


This failure happens almost instantly. Just to verify that the specific powershell instance can access the fileshare in question - I followed it up by just executing the mpam-fe.exe file and it worked.

• Do the permissions on the share include "Domain Computers" so the Defender service can read the data? – Clayton Aug 3 '17 at 0:43
• Are you actually specifying the name of the executable mpamfe.exe in the source or are you just specifying the path to the source folder? The source folder is supposed to have more than just the mpamfe.exe file. – Appleoddity Aug 3 '17 at 4:20
• @Clayton No, the permissions aren't set like that but now that you mention it - it completely makes sense that they would need to be. I will tweak the folder permissions so that all domain computers can access and re-test – George Kendros Aug 3 '17 at 13:56
• @Appleoddity No, i'm only specifying the folder that contains mpam-fe.exe. With that said, there is absolutely nothing else in that folder but from your comment I'm gathering there should be? – George Kendros Aug 3 '17 at 13:58

I have never done this before, but your question made me curious and I started doing some testing. I was able to reproduce your issue. It's clear that not many people do this, because there is zero coherent information on the internet about how to do this. So, it's no surprise you're getting nowhere.

So, here is what I discovered while using Process Monitor. I was able to successfully get Defender to update from a file source.

• First, the update packages consist of three files: mpam-fe.exe, mpam-d.exe, and nis_full.exe. I tried using just mpam-fe.exe and it failed.
• Second, there are 32-bit and 64-bit versions of updates. When you run the Update-MPSignature command it expects to find the updates under the x64 or x86 folder in your source path. So, you need to create the additional folders under your source path and place the update files in there.
• Third, the process that updates Windows Defender is wmiprvse.exe (WMI) - it runs as Local System. Be aware that the connection is made to the file source using the computer account and not a user account. I tried several different things to try to get it to connect to a file share on a domain joined server. This included adding the computer account, domain computers, Everyone, and Anonymous. Nothing worked. It failed every time with Access Denied. I was only able to get it to work when I put the files on my NAS which has zero security restrictions.

Here are other references I used to get this to work: https://technet.microsoft.com/en-us/itpro/powershell/windows/defender/update-mpsignature?f=255&MSPPError=-2147217396

https://technet.microsoft.com/en-us/itpro/powershell/windows/defender/set-mppreference

https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/deployment-vdi-windows-defender-antivirus

• Wow, thanks. I believe your post is very likely to be the single largest repository of info on the internet regarding this process. In specific, what you posted about the folder structure and needed files is the only place I've found this (and I've specifically looked into that when I was getting failures even when using localhost as the unc path). – George Kendros Aug 3 '17 at 16:06
• I used the PS script to download the needed files. Once I had the files downloaded to a drive on my system I set the fileshare path as \\127.0.0.1\c$\folder. It was still failing at this point through powershell but when I went into defender itself and ran the update it was successful (and I know it didn't pull it down over the internet because this machine has no connection outside the intranet) – George Kendros Aug 3 '17 at 18:01 • Ok, did you download the files for your specific architecture to \\127.0.0.1\c$\folder\x64 or x86? I did my testing from powershell, so it should work. Just make sure you downloaded all 3 files to the proper x86 or x64 folder and make sure there aren't any security problems with the share. It's worth noting that I found you don't have to use a UNC path. If you want, you could just specify C:\folder for testing purposes. – Appleoddity Aug 3 '17 at 18:07
• Yeah, I created the x64 folder - then dropped the 3 files in there. I then ran "Update-MpSignature -UpdateSource FileShares". It still failed, but this time it at least brought up a progress bar and seemed like it was working for a bit before giving me a different error (Permission Denied). I'm sure it just had something to do with the context that I was running powershell in. When I went into Defender itself and told it to update, it pulled the files from the fileshare and updated. – George Kendros Aug 3 '17 at 18:23

Appleoddity's answer gives everything you need. Some caveats though;

• Update-MpSignature never worked for me in powershell. I spent a lot of time trying to set up the environment for these updates to work and was using Update-MpSignature as the test.
• Once I actually run Defender/MSE's built in update function and realized that the update worked correctly in a situation where Update-MpSignature was failing I started backtracking and testing other scenarios which I though weren't working because they were failing through powershell

So basically, as you work through the issue using Appleoddity's guide make sure not to rely solely on powershell and Update-MpSignature to test what you're doing. YMMV but it my case I was never able to succesfully run Update-MpSignature. I had jumped to the conclusion that I had set something up wrong, but after more testing I saw that defender itself was updating without issue and only powershell was having problems.

C:\Windows\Temp\MpSigStub.log


Just delete this LogFile before running

Update-MpSignature -UpdateSource FileShares -Verbose


I've had this exact issue. The issue was resolved by creating a x64 folder in the share and moving the definitions to that folder. I can't find this requirement anywhere but it works. SCEP uses this folder structure so that's where I got the idea. Even the script provided by Microsoft doesn't create the architecture folder!

Server setup:

• File share (e.g. \\Server\Share$) with full share permissions and Read permissions for Everyone (Domain Computers not required!) • Folder x64 containing 64-bit definition files (e.g. \\Server\Share$\x64\mpam-fe.exe)

Client setup (powershell):

Set-MpPreference -SignatureDefinitionUpdateFileSharesSources \\Server\Share$Set-MpPreference -SignatureFallbackOrder 'FileShares' Update-MPSignature  Here is the powershell script I have running hourly on a server, then I just point my clients to it. The big point was NOT to extract the file. Windows Defender points to the exe itself. $vdmpathbase = 'E:\VirusDef\latest\x64'
$vdmpackage =$vdmpathbase + '\mpam-fe.exe'
cmd /c "del $vdmpackage /q" Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64' -OutFile$vdmpackage