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...
Thanks for this - apologies I can see you covered that error in the blog (I didn't have the issue the first time I read it..!).
We have (to this point) been configuring the settings for VDI using group policy , not local group policy. I have since rectified this, but noticed a few issues:
1/ the registry in our master image is missing the 'UpdateOnStartUp dword=1' key , despite enabling local group policy setting 'Check for intelligence on startup'
2/ I've followed the guide above closely and have both settings configured in local policy. However, the VM's still fail to update from the file share. The share permissions are below. The VM's can contact the share and
However, even with those both those settings defined it still doesn't work consistently. We have 'Define file shares for downloading sec intelligence updates' set to: \\share\wdav-update. The GPO informational help for that settings suggests multiple sources should be entered in the format {"\\uncshare1 | \\uncshare2"} - we only have 1 share, so I'm assuming that because we only have 1 source, then entering the value without {".."} characters is still valid? e.g. \\share\wdav-update
As you can see, we have both aforementioned policies configured locally, we also have 'Check for intelligence updates on startup' and 'Check for latest virus and spyware intell on startup' too. Strangely, when setting these latter 2 policies on the local policy editor, no registry key is created under HKLM\Software\policies\MS\Windows Defender\Updates..\UpdateOnStartUp dword=1 - but if it's set via group policy on the domain, then those registrry keys are created . I added the key manually on our image, rebooted, but the VM's still don't update.
This is the local group policy settings:
Is this valid as a value, or must we also set the other possible values in order of preference i.e. FileShares|MMPC|UpdateServer etc, and if so, should the values be entered in the same formatting as the help example with a carriage return between each pipe e.g. FileShares | MMPC, or Fileshares|MMPC ?
At this point it's really not clear why this is failing - we've set the baseline policies correctly, and I've even tested it functionally by using psexec to launch cmd prompt as SYSTEM context, browse to the share, and run the mpam-fe.exe file - it installs and updates the VM in moments. Any pointers on what might be causing this misconfiguration? We actually had this working (albeit erratically) by using only group policy, no local policy - some VM's would update, others would not, we have no other AV installed on our image (fresh build). I would also expect our master image (logged in as local admin) to update itself , there are no 'ACCESS DENIED' errors in the event log.
This is how the registry looks on the VM's . When they boot they show up to date. checking the mplog file , it shows the share is being checked, but then it refers to a local definition pack instead of downloading the latest from the share? Note, if I then manually update the definition pack to the latest, the GUI still declares it's up to date, and the engine revision changes accordingly - the VM thinks it's up to date, but it's not...
Sorry for lengthy email, but I'm amazed how convoluted it is to get this working, do you have any ideas/pointers for troubleshooting this please?