Access denied error when updating Microsoft Defender from Fileshare

%3CLINGO-SUB%20id%3D%22lingo-sub-2882856%22%20slang%3D%22en-US%22%3EAccess%20denied%20error%20when%20updating%20Microsoft%20Defender%20from%20Fileshare%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2882856%22%20slang%3D%22en-US%22%3E%3CP%3EI%20read%20this%20document%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fsecurity%2Fdefender-endpoint%2Fdeployment-vdi-microsoft-defender-antivirus%3Fview%3Do365-worldwide%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EMicrosoft%20Defender%20Antivirus%20Virtual%20Desktop%20Infrastructure%20deployment%20guide%20%7C%20Microsoft%20Docs%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eand%20I%20created%20a%20share%20on%20a%20VM%20called%20%5C%5Ccsabots2019%5Cwdav-udpate%20-%20the%20share%20has%20everyone%20full%20control%2C%20but%20the%20ACL's%20on%20the%20share%20have%20Domain%20Computers%20Read%2FExecute%20and%20Authenticated%20Users%20Read%2FExecute.%20I've%20verified%20the%20VDI%20vm's%20can%20read%20the%20share%20as%20the%20logged%20in%20user%20and%20as%20SYSTEM.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20I%20type%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EC%3A%5CProgram%20Files%5CWindows%20Defender%26gt%3BMpCmdRun.exe%20-SignatureUpdate%20-UNC%20%22%5C%5Ccsabots2019%5Cwdav-update%22%3CBR%20%2F%3ESignature%20update%20started%20.%20.%20.%3CBR%20%2F%3ESignature%20update%20finished.%20No%20updates%20needed%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESimilar%20%22success%22%20message%20if%20I%20use%20update-mpsignature%20-UpdateSource%20Fileshare%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20know%20its%20not%20updated%20as%20when%20I%20type%20get-mpcomputerstatus%20it%20shows%20the%20AV%20dats%20are%20dated%202019.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20Microsoft%20Defender%20goes%20to%20update%20all%20I%20get%20in%20the%20logs%20is%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-applescript%22%3E%3CCODE%3E2021-10-25T17%3A36%3A14.153Z%20UpdateEngine%20start%3A%20Source%3A%209%2C%20szUpdateDirectory%3A%20%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%0A2021-10-25T17%3A36%3A14.202Z%20Verifying%20engine%20and%20signature%20files%20(source%3A%200)%20...%0A2021-10-25T17%3A36%3A14.202Z%20Skipped%20verification%20of%20%5B%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%5Cmpengine.dll%5D%20due%20to%20PPL.%0A2021-10-25T17%3A36%3A14.202Z%20Skipped%20verification%20of%20%5B%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%5Cmpasbase.vdm%5D%20due%20to%20PPL.%0A2021-10-25T17%3A36%3A14.202Z%20Skipped%20verification%20of%20%5B%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%5Cmpasdlta.vdm%5D%20due%20to%20PPL.%0A2021-10-25T17%3A36%3A14.202Z%20Skipped%20verification%20of%20%5B%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%5Cmpavbase.vdm%5D%20due%20to%20PPL.%0A2021-10-25T17%3A36%3A14.202Z%20Skipped%20verification%20of%20%5B%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%5Cmpavdlta.vdm%5D%20due%20to%20PPL.%0A2021-10-25T17%3A36%3A14.390Z%20UpdateEngine%20finished%20with%200x80070005%3A%20Source%3A%209%2C%20szUpdateDirectory%3A%20%5C%5Ccsabots2019%5Cwdav-update%5C%7B00000000-0000-0000-0000-211025101106%7D%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20you%20put%26nbsp%3B0x80070005%20into%20cmtrace%20you%20find%20that%20it%20means%20access%20denied.%20I%20think%20the%20fileshare%20works%20as%20the%20mp%20engine%20actually%20read%20through%20the%20files%20on%20the%20filesserver%20(I%20can%20see%20it%20via%20the%20fileserver%20access%20logs!).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThings%20I've%20tried%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20run%20procmon%20while%20its%20updating%20-%20I%20don't%20see%20any%20access%20denied%20errors%20at%20all%20honestly.%20The%20AV%20agent%20appears%20to%20have%20access%20to%20the%20updates%20as%20it%20lists%20them%20in%20the%20log...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20made%20the%20permissions%20more%20permissive%20-%20like%20as%20anyone%20on%20the%20planet%20who%20had%20the%20unc%20path%20more%20permissive.%20All%20this%20did%20was%20the%20first%20VM%20to%20try%20and%20update%20would%20delete%20all%20the%20files%20(still%20errored%20out%20with%20the%20same%20error%20above).%20I've%20also%20tried%20just%20everyone%20Read%20-%20still%20fails.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20tried%20having%20a%20non%20VDI%20VM%20update%20off%20the%20same%20share%20-%20same%20failure.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESomeone%20on%20stack%20exchange%20here%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fserverfault.com%2Fquestions%2F866557%2Ftrying-to-update-windows-defender-from-unc-path-continuously-fails%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Eanti%20virus%20-%20Trying%20to%20update%20windows%20defender%20from%20UNC%20path%20continuously%20fails%20-%20Server%20Fault%3C%2FA%3E%26nbsp%3Bhas%20the%20same%20issue.%20Some%20of%20the%20suggestions%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20top%20rated%20post%20admits%20he%20couldn't%20get%20it%20working%20until%20he%20put%20share%20on%20a%20non%20domain%20bound%20nas...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnother%20post%3A%20said%20that%20that%20the%20access%20denied%20came%20from%20access%20denied%20to%20the%20log%20file%20%22C%3A%5CWindows%5CTemp%5CMpSigStub.log%22%20-%20there%20are%20no%20MD%20log%20files%20in%20C%3A%5CWindows%5CTemp%20and%20the%20log%20files%20in%20C%3A%5CProgramData%5CMicrosoft%5CWindows%20Defender%5CSupport%20seem%20to%20update%20just%20fine.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnother%20post%20said%20that%20they%20have%20to%20be%20in%20a%20x64%20directory%20below%20the%20guid%20directory%20-%20this%20didn't%20seem%20to%20work%20as%20it%20stopped%20even%20trying%20to%20update%20all%20together.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnyone%20else%20make%20this%20work%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Visitor

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?

0 Replies
www.000webhost.com