Configuring Windows Defender AV for VDI

Windows Defender AV for non-persistent instant clone desktops is a lightweight and free AV solution for VDI that is growing in popularity as an alternative to typical third party options as people move to O365 and want to align themselves with Microsoft across their software stack.

Below is a quick guide on how to configure Defender for Endpoint (not ATP) which is a free version of Defender included with E3 O365 licensing using.

A file share is used as the source for definition files. I recently had to setup a proof of concept of this for a client who had been using McAfee ENS and we saw a notable improvement in performance and overall desktop experience.

The guide does not cover how to configure VM’s to use MMPC, WSUS , Cloud based definitons or ATP/MAPS.

Environment: VMWare Instant Clones, Win 10 1909.

What you’ll need

  • 1x SMB file and an endpoint for handling the scheduled tasks needed for Defender definition updates
  • 2x scheduled tasks, one to perform the definition download and unpack, and a second to clean-up old definitions. Both scripts provided.
  • VDI specific Defender settings that are configured on local group policy on the master image, and remaining settings configured on domain group policy.

Before getting started..

  • Check you have the latest ADMX templates for your OS.
  • Use a clean build, ideally with an image that has not had any AV agent previously installed.

Step 1: Setup a share and scheduled tasks to download, unpack and clean-up definitions…

Identify a virtual machine/server/desktop or some endpoint that will be responsible for running the scheduled tasks for fetching definitions and storing them in an SMB file share. The endpoint will require internet access and I refer to this machine as the management VM.

Create an SMB file share to store definitions.

Setup a file share that will store the unpacked definitions. The below example resides in C:\wdav-update on the management VM. I recommend using the same folder names as this will tie together with the download script that will be used later on.

Share permission: Authenticated Users: Read

Folder Permission: Authenticated Users: Read/Execute, SYSTEM: Read/Writed

Get-SMBShareAccess -name wdav-update result should mirror the above

*IMPORTANT* if you provide FULL CONTROL to the folder or share, then you may experience the definitions being automatically purged by the child VM’s after they self-update, making the definitions unavailable at next boot . From my limited testing this behaviour appeared to be by design can’t be controlled by any GPO settings, so avoid this by setting the NTFS permissions correctly.

Create scheduled tasks to download definitions

Microsoft provide the following PS script which handles downloading and unpacking of definitions. There is an alternative script available here but I found the below script does the job and is easier to understand. Adjust the value for $vdmpathbase accordingly, but do not change the [0000…] folder naming convention. This is required otherwise the child VM’s will not be able to parse the folders and will fail to self-update.

$vdmpathbase = "$env:systemdrive\wdav-update\{00000000-0000-0000-0000-"
$vdmpathtime = Get-Date -format "yMMddHHmmss"
$vdmpath = $vdmpathbase + $vdmpathtime + '}'
$vdmpackage = $vdmpath + '\mpam-fe.exe'
New-Item -ItemType Directory -Force -Path $vdmpath | Out-Null
Invoke-WebRequest -Uri '' -OutFile $vdmpackage
cmd /c "cd $vdmpath & c: & mpam-fe.exe /x"

Add a clean-up task…

I configured the below task to clean-up any definition files older than 3 days. Configure this as a scheduled task to run daily.

Get-Childitem "C:\wdav-update" |
 Where {$_.CreationTime -lt (get-date).adddays(-3)} | Remove-Item -recurse -force

Tips for configuring the scheduled tasks:

-Configure definition update to run every 2 or 4 hours , typically MS publish new definitions twice per day, around 8-12 hours between each update.

– If the scheduled tasks are failing, ensure the account used to run the task (local SYSTEM or service account) has internet access – you may need to allow unauthenticated traffic from your management machine if using the SYSTEM account. If you use a zScaler/Proxy device and authenticate clients using a .pac file then you may need to launch IE as the SYSTEM account (on your management VM) and configure the .pac file accordinalty. To do this , download PSExec and run the below command to launch IE in the context of SYSTEM, then configure the .pac file in IE settings.

psexec.exe -i -s "c:\program files\internet explorer\iexplore.exe"

Step 2: Configure Defender local group policy settings on your master image

Defender for non-persistent VDI relies on several local group policy settings being baked into your image to ensure they are available at boot time. Configure the following 5 settings via gpedit.msc on your master image.

Location: Computer Configuration\Administrative Templates\Windows Components\Windows Defender Antivirus\Security Intelligence Updates

IMPORTANT: You must configure Define security intelligence location for VDI clients and Define file shares for downloading security intelligence updates . If you do not configure both, the service will not work.

Values to use:

Define the order of sources for downloading security intelligence: FileShares

Define Security intelligence location for VDI clients: \\yourfileserver\wdav-update

This concludes the minimal settings that are required on the master image.


  • You may want to use LGPO.exe to export a template of the Defender settings for your environment for quick setup in future, or add to an MDT task-sequence for your image builds.
  • If your master image has picked up policies you don’t need or for some reason you’ve had your hand forced to use a crappy image – you can wipe all the local and domain policy by running the below command (elevated). This will wipe all local policy WARNING – do this at your own peril (it will remove OSOT optimizations and all domain+local policy). Remember to re-join to domain and update policy afterwards.
    • RD /S /Q "%WinDir%\System32\GroupPolicyUsers" && RD /S /Q "%WinDir%\System32\GroupPolicy"

Install A BASELINE set of defender av DEFINITIONS

  • If your enterprise has never used Defender before and/or has used a different AV product to date, then it’s highly likely you’ll have domain policy in place to disable Defender and/or your base image will have no pre-existing Defender engine/definitions installed. In this case, you may have to install a baseline definition pack so the Defender engine is activated in the build. This may not apply to all environments but I experienced VM’s failing to update on their first boot because no existing definitions were installed. If this happens, Download the latest definition set from Microsoft and install the mpam-fe.exe file – this will install a definition pack and give you an engine status/last updated point to work from.

Step 3: Configure Defender domain group policy settings…

There’s a plethora of settings for Defender and I won’t cover every setting here. The high level suggestions are covered in the Microsoft blogs – so refer to these, but also be aware that services like MAPS and ATP rely on many of the options available – and we’re not configuring these services in this blog post – only the ‘barebones’ AV product. Some examples of VDI-friendly settings you may want to use are below.

Important: do not configure any of the settings configured in Step 1 on the master using local policy on our domain group policy.

\Windows Defender Antivirus

  • Turn off windows Defender: Disabled
  • Randomize Scheduled tasks times: Enabled


  • Allow users to pause scan: Disabled
  • Check for the latest virus and spyware security intelligence before running a scheduled scan: Enable

\Security Intelligence Updates

  • Specify the interval to check for security intelligence updates: 2 hours

Step 4: Verify that it all works!

So lets recap on what we’ve done;

  • We’ve setup a file share and it’s populating every 2 hours with the latest definition files, unpacked, and ready to be read by our VM’s. We have the necessary NTFS and share permissions in place to make our \wdav-update share accessible from the VM’s and it can be read/written to by the SYSTEM account and/or your service account responsible for running the scheduled tasks.
  • Your master image has the necessary local group policy settings required at boot so the VM’s should be reading from the share and self-updating at every logon, and this should be reflected in the Virus and Threat Protection console in Windows on the VM’s, example below.
  • Your domain group policy settings are configured to manage things like scan times, quarantine behavior, UI and notifications etc and critically you’ve checked the Disable Windows Defender policy is set to disable..!

Spin up your VM’s and check the below log file – search: UpdateEngine – here you can see the subfolders in our definition share being traversed. The log output Skipped verification….Due to PPL is expected and this does not indicate an error. Any errors will be indicated in the entry that begins: UpdateEngine start:


Virus & threat protection settings should show Last Update: today’s date

To Hell and Back with Hybrid AD Join for VDI

*Update 22/01/22 After much effort spent getting this to work at a customer site, it turns out there was never any need to have conditional access enforcing VDI devices to be hybrid-joined. By turning off the conditional access policy that checks the device is Azure-AD joined, there was no longer any issue. Note, if you’re using a zscaler you’ll need to configure source IP anchoring as well.

*Update 31/07/21 After migrating a customer from Appsense to VMware DEM I had to find a new method to perform the hybrid join. The below article now provides two methods for performing the join.

Read this post if you’re having problems performing Hybrid Azure AD join on non-persistent VDI. This post covers the how to configure Hybrid AD join on VDI , how we discovered it was broken and a clean solution to fix it.

The running environment was Windows 10 1909, VMWare Instant Clones on Horizon 7.10, with zScaler proxy (.pac files).

For the solution, click here or scroll to end of article.

How to configure Hybrid AD join and why it might be failing for you…

In our case, hybrid AD join was always broken – we just hadn’t noticed because the device join was successful which is all that is required for O365 services to work (Outlook gets a license – everyone is happy!) but the user PRT token (which I’ll refer to as user-join) was failing – which, if you have InTune in place for MDM policies and all that fancy stuff – you may find these devices are broken when the VDI is in use.

Microsoft offer very little guidance on how to implement Hybrid AD join on VDI but Google yields a lot of negative feedback from folks implementing this for VDI. This VMware thread was helpful in our discovery, and the guidance from Microsoft is helpful, but not as detailed as it should be.

Microsoft’s suggestions are:

Implement dsregcmd /join as part of VM boot sequence.

DO NOT execute dsregcmd /leave as part of VM shutdown/restart process.

  Define and implement process for managing stale devices.

We used a start-up task to perform /join. 

A .bat file or powershell can perform the join as follows, and configure this to run as a start-up task. Note, the task should be ran under the context of the SYSTEM account, and ensure your network is configured to allow this traffic (see zScaler section).

dsregcmd.exe /join

Master Image

You should ensure your master image does not perform an AAD join at all.  You should run the /leave command  as SYSTEM account  prior to sealing your image and taking a snapshot, although we would often forget to do this. Whether this contributed to the issues covered, I’m not sure. Additionally, some threads suggest your master image should not be domain-joined – in our case, the master image IS domain joined, but was NOT AAD joined.

Use PSExec to perform a /Leave command as SYSTEM account:

Psexec -I -s dsregcmd.exe /leave

zScaler .pac on VDI for Hybrid AD Join

If you’re using a zScaler to manage internet traffic you may find that Hybrid AD join fails because the traffic is sent from the VM’s under the context of the SYSTEM account and if no .PAC file is configured against that account, then it will fail (unless you allow unauthenticated traffic on your zscaler devices). If we also throw into the mix that Microsoft recommend you join AAD during device start-up – your user will not have authenticated to zScaler when the /join takes place, so you must configure this.

On your master image, launch Internet Explorer as SYSTEM account, and then manually configure the .PAC file manually. Download PSTools and then run the following command from an elevated cmd prompt:

Psexec -I -s “c:\program files\internet explorer\iexplorer.exe”

The above steps explain how we were configured for Hybrid AD join BEFORE we discovered it was not working. Read on for the discovery, and adjustments we made. Click here for the solution.

How to identify a VM has failed Hybrid AD Join

As a large enterprise with multiple VDI sites managed by different teams, we discovered some sites were performing the /join during the ‘Desktop Created’ stage of the logon process (i.e. once the user is logged In and desktop shell fully loaded) – in these pools we saw the device join was successful,  but user join (PRT token) was unsuccessful – this is because  the user was not logging into an AAD-joined device, so the device was deemed unauthorized to receive a PRT token.

  1. Open cmd prompt and run: dsregcmd /status 
  2. Review the output –note you may also see that the Tenant Name is blank in your output. The device will show as joined, but no PRT/User join had taken place –

Device State shows successful AAD join:

User-join has failed and the AzureADPrt token is not present.

Contrary to MS guidance we experimented with adding a /leave command at logoff – on these pools we saw the object in AAD was updated more accurately in Azure – the ‘Last Activity’ times reflecting the join/leave times of when the desktop sessions were in use.  Howeverthe underlying lesson here is that the device must be joined first then the user is logging into an authorized device and a second /join should take place to fetch the user PRT token.

On the pools configured to use a start-up taskwe found the device join would periodically fail – but this became more frequent as time passed until we had complete failure of all devices in a given pool.

VM template objects flooding Azure AD

We searched AAD to compare on-prem device names to their records in AAD and discovered we had a ton of VM’s joining AAD under the machine name of itXXXX – this is the internal template object which is created by ESXi when a new snapshot is published to a desktop pool. AAD was being flooded with these objects every time we changed the snapshot on a desktop pool.

VM’s were joining AAD successfully (device-join only) but their ID did not match their counter-part object in AAD – instead, it matched the internal VM template.

 At this point we knew that when a new snapshot was published, a new AAD object was being created with the VM’s template account ID. Additionally, it proved the /join was taking place too early in the logon process (at machine start-up) – and instead of joining the hostname of the VM that is provided by QuickPrep (e.g. PROD-VM-1)  the ID of the instant clone template was being used to join the machine to AAD.

To verify this:

  1. Open AAD and search for device name: it

Note, this applies to VMware Instant Clones environments only, Citrix and Hyper-V hypervisors will use a different provisioning process, check your vendor documentation to know what to search for)

Template VM objects in AAD –

Duplicate VM device ID’s

Another symptom of this issue was VM’s would recycle their Device ID – we found the same Device ID (after the device had joined AAD) was in use by other VM’s in the same pool. Presumably this is a hangover from previous symptom.

  1. Take 2 VM’s from the same pool, open CMD prompt and run dsreg
  2. cmd /status, compare the device ID’s on both devices – are they identical?

Verifying AAD Join process

To check if your VM’s are joining AAD with an incorrect computer name:

  1. Check the local VM event log Applications and Services LogMicrosoft/Windows/User Device Registration for event ID 335.
  2. Note, the computer name is itXXXX , user SYSTEM.

Let’s recap what we’ve learned so far:

  • VM’s are joining AAD with the wrong computer name
  • AAD is populated with stale records for our VM’s
  • Our VM’s are recycling device ID’s
  • The User-join (PRT token) is not working

After several hours of toil, testing and swearing, We tried moving the /join to different stages of the logon sequence, but only found Start-up to be ‘successful’ for the device-join. During testing we removed the /join altogether – and low and behold, we discovered the VM’s were still joining AAD – this is because there are 3 scheduled tasks baked into the Windows 10 1909 OS to perform auto-AAD join. 

Microsoft don’t tell you this in their VDI guide because they prefer ‘the Community’ to figure it out…they’re real nice like that.

Configuring Hybrid AD for VDI the right way! #how-to-configure-hybrid-ad-join-for-vdi

Method 1

1/ Perform the /join operation TWICE, once at Start-up, and again before the desktop shell has loaded.This ensures the the Device and the User PRT token are both issued succesfully.

2/ Ensure the dsregcmd.exe /join operation is managed by your profile management tool. Don’t try to mix combinations of scheduled tasks/group policy/profile tool.

3/ Delete the Automatic Device Join scheduled task. This was the root cause of all our pain. The task will perform a join under user context and has 2 triggers – a ‘special event’ and at logon.

4/ Always perform dsregcmd /leave on your master image. Ideally, avoid the master image from joining AAD in the first place.

5/ (Optional) Add a /leave command at logoff of the VM. This is unsupported by Microsoft, the only benefit we found from including this was the ‘Joined’ and ‘Last Activity’ timestamp was kept up to date in Azure AD – but again, not supported.

6/ (Optional) Set the machine GPO ‘Windows Components/Device Registration/Register domain joined computers as devices‘ to disabled. This helps keep things tidy and you can be confident the join is only handled by your profile management tool.

**Alternative Method**

I recently had to decommission Appsense for a customer and move them to VMware DEM. In doing so, the method described above had to be changed. Although DEM can run tasks at Startup of the VM (it hi-jacks the native group policy startup/logoff scripts) which isn’t suitable for performing a /join because the template account for the pool is then joined to Azure AD. Which we don’t want. Thanks to some feedback on the DEM forums, I’ve found the below method works nicely:

1/ Configure a .bat file that has a /leave and /join. You’ll call this as the post-synchronization script when you configure the pool. Example file.

cd c:\windows\system32
dsregcmd.exe /leave
dsregcmd.exe /join

2/ Make the file available on your master image, ideally in the C:\ root somewhere and configure it as the post-synchronization script for the pool.

3/ You should now see the devices populate in AAD when the pool is being composed. When a user logs in , because the VM is now ‘trusted’ the PRT token should be issued. Microsoft does not support the /leave as part of non-persistent devices so I’ve ommitted this. It is possible to add a /leave command (perhaps as a shutdown script), but we’ve discovered no issues with leaving the devices joined in AAD indefinitely.

Master Image configuration

Step 1: Delete the Auto-Join scheduled task in Win 10 1909

  1. On your master image open task scheduler: Microsoft > Windows >Workplace Join
  • Delete the Auto-Join task – this must be deleted and not disabled – because it’s a system task.
  • The remaining 2 tasks should be left in their default state – they should not require any manual intervention. If these tasks are disabled or not present on your image – then check OSOT or group policy if these are being deleted by an upstream policy.

Step 2: Remove your master image from AAD

  1. Launch psexec from an administrative command prompt using: psexec.exe -i -s dsregcmd.exe /leave
  2. You may see the below exit code 0.
  3. Confirm the /leave was successful by checking AAD – you should not see the machine account, and the /status output should be as below.

/status output when device has left

Step 3: Remove existing itXXXX or stale records from Azure AD

  1. Remove any of the stale device records from AAD. This should include the itXXXX devices , and any VM’s in pools your going to test in.

Step 4 (optional): Bake your user profile configuration into the master image

If you’re unlucky enough to use AppSense or a similar tool – you may have to bake your configuration into the master image. Other profile management tools may not require this step.

Profile Management Tool Configuration

Step 4: Configure the dsregcmd /join operations

Start-up task:

  1. Configure the 1st /join operation during Start-up of the machine (or machine boot).

2. Scope this to only apply to machines with your VM naming conventions – this ensure the correct devices join AAD, but also prevent the itXXX devices joining (or your master images).  If you have no profile management tool, then this might work with scheduled tasks or a group policy object, but we did not validate this.

Pre-Desktop task:

  • Perform a 2nd /join operation during the ‘Pre-Desktop’ stage– this is the point at which user authentication has completed, but the desktop is still loading. This should ensure the PRT is issued to the device, and also provides a backup to one of the scheduled tasks (re-sync) which does the same thing.

Has this fixed it for you?

1/ We no longer need to delete ‘stale’ AAD objects – there is only 1 AAD object per VM. Each VM joins to the same AAD object – no duplication, no dodgy device ID.

2/ When a new snapshot is published, we did not see the itXXXX devices appearing in AAD (clean joins!).

2/ User-join was always successful – this is probably because the Auto-Join scheduled task is not interfering with the registration process.

I hope this helps someone, if you find other solutions or suggestions to improve on this find I’d love to know