Updated 3/23/2023 to focus on the shared security intelligence feature for VDI.
Virtual Desktop Infrastructure (VDI) brings an interesting dynamic when tuning the platform. The delicate balance...
I am appreciating for accepting the challenge! 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...