Access denied error when updating Microsoft Defender from Fileshare

[Angelworks42]

I read this document: Microsoft Defender Antivirus Virtual Desktop Infrastructure deployment guide | Microsoft Docs

and I created a share on a VM called \\csabots2019\wdav-udpate - the share has everyone full control, but the ACL's on the share have Domain Computers Read/Execute and Authenticated Users Read/Execute. I've verified the VDI vm's can read the share as the logged in user and as SYSTEM.

When I type:

C:\Program Files\Windows Defender>MpCmdRun.exe -SignatureUpdate -UNC "\\csabots2019\wdav-update"
Signature update started . . .
Signature update finished. No updates needed

Similar "success" message if I use update-mpsignature -UpdateSource Fileshare

I know its not updated as when I type get-mpcomputerstatus it shows the AV dats are dated 2019.

When Microsoft Defender goes to update all I get in the logs is:

2021-10-25T17:36:14.153Z UpdateEngine start: Source: 9, szUpdateDirectory: \\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}
2021-10-25T17:36:14.202Z Verifying engine and signature files (source: 0) ...
2021-10-25T17:36:14.202Z Skipped verification of [\\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}\mpengine.dll] due to PPL.
2021-10-25T17:36:14.202Z Skipped verification of [\\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}\mpasbase.vdm] due to PPL.
2021-10-25T17:36:14.202Z Skipped verification of [\\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}\mpasdlta.vdm] due to PPL.
2021-10-25T17:36:14.202Z Skipped verification of [\\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}\mpavbase.vdm] due to PPL.
2021-10-25T17:36:14.202Z Skipped verification of [\\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}\mpavdlta.vdm] due to PPL.
2021-10-25T17:36:14.390Z UpdateEngine finished with 0x80070005: Source: 9, szUpdateDirectory: \\csabots2019\wdav-update\{00000000-0000-0000-0000-211025101106}

If you put 0x80070005 into cmtrace you find that it means access denied. I think the fileshare works as the mp engine actually read through the files on the filesserver (I can see it via the fileserver access logs!).

Things I've tried:

I've run procmon while its updating - I don't see any access denied errors at all honestly. The AV agent appears to have access to the updates as it lists them in the log...

I've made the permissions more permissive - like as anyone on the planet who had the unc path more permissive. All this did was the first VM to try and update would delete all the files (still errored out with the same error above). I've also tried just everyone Read - still fails.

I've tried having a non VDI VM update off the same share - same failure.

Someone on stack exchange here: anti virus - Trying to update windows defender from UNC path continuously fails - Server Fault has the same issue. Some of the suggestions:

The top rated post admits he couldn't get it working until he put share on a non domain bound nas...

Another post: said that that the access denied came from access denied to the log file "C:\Windows\Temp\MpSigStub.log" - there are no MD log files in C:\Windows\Temp and the log files in C:\ProgramData\Microsoft\Windows Defender\Support seem to update just fine.

Another post said that they have to be in a x64 directory below the guid directory - this didn't seem to work as it stopped even trying to update all together.

Anyone else make this work?

[#2]

Did you ever get this to work? If so, what did you have to change? It worked in my QA environment for a few days after adding "Domain Computers" to the Share/NTFS rights, but now is refusing to update again with no changes made, and I see the same errors as you.

[#3 · Accepted solution]

We did, but we had to update MS Defender to the absolute latest version during the image build process. We used this process here: https://support.microsoft.com/en-us/topic/microsoft-defender-update-for-windows-operating-system-ins...

We also found that once it is working - if you set the update path post windows install it works, but says something like "it won't take effect until restart"... So I had to change that option during image build using a ps script:

Set-MpPreference -SharedSignaturesPath \\csabots2019\wdav-update - then reboot before sysprep.

Bottom line - the MS doc on how to do this is woefully incomplete.

[#4]

Funny, after I replied that's exactly what I found - the required reboot before changes took effect. I didn't want to bake those settings into my image, but here we are. I baked them in via PowerShell just like you have, and since doing that, updates have been working flawlessly.

[#5]

@NickPanaccio Nice! I should add we're just using configmgr to make the reference vdi image - so it was pretty simple to add another reboot.