Trying to update windows defender from UNC path continuously fails

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

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.

Permission Denied Message is caused by Access Denied to the LogFile

C:\Windows\Temp\MpSigStub.log

Just delete this LogFile before running

Update-MpSignature -UpdateSource FileShares -Verbose

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

Another caveat...

The Defender GUI runs the update download as one of two processes:

1. MSascui.exe - which uses the current session account (this one can usually access the file share as most defender update file shares would allow read to all)
2. Msmpeng.exe - which uses the NT AUTHORITY/SYSTEM account (this will have the computer name account, which in most domain-based systems will also allow access)

For the Update-MpSignature cmdlet, it's a bit different. It runs the update download as wmiprvse.exe which uses NT AUTHORITY/LOCAL SYSTEM. This account has minimum privileges on the computer and uses anonymous credentials on the network. Generally speaking, most network shares won't be configured for anonymous access, so this is why you can get the GUI to work, but the cmdlet doesn't.