Getting Windows Defender Application Guard (WDAG) working

Once I had solved my recent Windows Defender Application Guard (WDAG) problems:

Resolving Windows Defender Application Guard Issues

I now wanted to get it working in a manner that suited me. That meant that I wanted Microsoft Edge to work normally for things like Microsoft 365, Azure and other Microsoft sites but to automatically open Edge with WDAG if I ventured outside that. I also wanted to retain the flexibility to have a third party browser (Brave) also working on my machines. In essence, I am trying to achieve the ability to automatically ‘sandbox’ general internet browsing from work in the Microsoft Cloud as way of protecting the workstation from malicious web sites.

I’m not going to cover off setting up WDAG on your machine or via Intune because there are plenty of articles out there that show you how to enable it. You can start here:

Windows Defender Application Guard Overview

In essence, WDAG opens a defined set of URLs in a sandboxed version of Edge automatically. This means you’ll need to do a little configuration and add some features to your local version of Windows prior to getting it working. You can read about that here:

Prepare to install Windows Defender Application Guard

My configuration will be in Enterprise-managed mode. This means that I can automatically ‘white-list’ domains that I don’t want WDAG to operate with via a policy pushed from the Internet. In my case, these will be Microsoft Cloud URLs like, and so on. Everything, apart from what I ‘white list’ I want to open using WDAG for protection.

The first thing to note here is that if you want to use Enterprise-managed mode you will need to have Windows 10 Enterprise edition. Windows 10 Pro edition only supports stand alone mode. This means:

In this mode, you must install Application Guard and then the employee must manually start Microsoft Edge in Application Guard while browsing untrusted sites.

To do this manually, you must edit the local computer policy using the local Group Policy editor or like as shown here:

Application Guard in stand alone mode

It is pretty easy to set up and get working but not really scalable. Scripting may help overcome that.

In Enterprise-mode my initial questions was ‘Where do I define my sites?’. As it turns out, this isn’t particularly obvious, so it took me a while to track down. The definitions for the sites you want to ‘white list’ for WDAG are actually in the Intune App Protection policy settings.


Turns out they are in the Advanced settings of your Intune App Protection policy, as shown above.

I had wrestled with these settings previously, which I detailed here:

Intune App Protection Policy blocking browser

What I didn’t appreciate initially was that sites you define here however ALSO APPLY to WDAG! Makes sense now that I look at it, but I certainly didn’t think it was the place I should be looking to ‘white list’ sites for WDAG. Now you too are the wiser.

Another subtle configuration option that took me a while to figure out was:

Network isolation wildcards

Initially, I had white listed from WDAG but in fact the navigation was going to, which means WDAG would trigger and open because it wasn’t ‘white listed’. Then I thought * would work, but no. Maybe Nope. Turns out what I needed was


Trust all levels of the domain hierarchy that are to the left of the dot. Matching sites include,,, but NOT itself.

So be super careful with how you configure you network perimeter settings and domain wildcards as it can make things very confusing if you don’t have a good handle on it. My suggestion is to start with only one or two sites in your network perimeter and ensure that they work. Only then scale up once you have verified it is operating as expected.

Finally, with all that configured correctly, WDGA was working as expected. Yeah! This meant that when I went to a Microsoft Cloud URLs like,, etc. WDGA wasn’t activated, but if I went elsewhere, WDGA launched and navigated to that site in the WDAG container. In the end I also white listed sites like,, etc as I go there many times a day.


If you browse to a non ‘white listed’ site (here, then a WDAG session is launched. You’ll see WDAG spin up, if it is the very first time it has been activated. You’ll then see the browser load the site in question and then you’ll notice a WDAG icon in the toolbar as shown above, which, when opened, will let you know that the current browser is using WDAG.


You configure WDAG settings via Intune Endpoint protection policies as shown above.


My suggestion would be to enable the option to Retain user generated browser data as shown above.  This means things like extensions, session cookies and the like will be retained between sessions. However, if you want a totally clean experience each time, then disable that option.


By default, you’ll find that any file you download while WDAG is active, will be saved into an Untrusted files folder as shown above.


You can also get a WDAG companion app from the Windows store:

This allows you to manually launch a WDAG session, which is probably handy if you are not using Enterprise-managed mode. It will launch this is a container isolated from anything that automatically launches via your browsing, keeping that separate as well.


If you want non Microsoft browsers to also be protected with WDAG then you’ll find plugins available:

for Chrome

for Firefox

With these plug ins installed, those browsers will also only open non-whitelisted sites. Anything else will be opened in an Edge WDAG session for protection.

So now I have WDAG working the way I wanted. My main stumbling block was no appreciating that the WDAG ‘white list’ was the same as WIP and set via Intune App Protection policies. I now have a better appreciation for the breath of the settings in these policies.

I’m sure I’ll be tweaking WDAG along the way but I feel much more secure in the fact that I have it working and protecting my ‘random browsing’. Like most security configurations, WDAG takes a little bit of understanding and setup to get working but the end result is a much safer environment to work in and I’m all for that. Hopefully you are too!

Resolving Windows Application Guard Issues

A while back I wrote about a issue I was having with Windows Defender Application Guard (WDAG). You’ll find it here:

Microsoft Defender App Guard issue

I have now managed to find a solution for this. In short, the issue, as it turns out, has to do with disk encryption. I found some information about the general issue here:

Why does my encryption driver break Windows Defender Application Guard?

which says:

Windows Defender Application Guard accesses files from a VHD mounted on the host that needs to be written during setup. If an encryption driver prevents a VHD from being mounted or from being written to, WDAG will not work and result in an error message (“0x80070013 ERROR_WRITE_PROTECT”).

Chatting with good people at Microsoft, it seems that in my particular case was solved by this update:

and was due to a BitLocker issue (being drive encryption).

So, the good news is that my issue is resolved and I can run Windows Defender Application Guard without any errors.

If you can’t install the KB for some reason and you need a quick work around, the issue was linked the BitLocker “Deny write access to fixed drives not protected by Bitlocker” policy and you should clear any group policy and set the following in Intune to Not configured as well as a work around.



So in the end it was an issue with drive encryption that was rectified with an update. Yeah!

Thanks to the people at Microsoft for the assist on this one. Now onto the next challenge.

Microsoft Defender App Guard issue

**** Update **** – Solution is here – Resolving Windows Application Guard issues

This article is bit different from most others. In this post I’ll be sharing a current issues I have with Defender Application Guard. If you have some suggestions of any additional troubleshooting, I’d love to hear, because currently, I’m not having much luck finding a solution.


The issue is that if I go into the new Edge browser and select a New Application Guard Window, I end up with:


WDAG Report – Container: Error: 0x80070013, Ext error: 0x00000001; RDP: Error: 0x00000000, Ext error: 0x00000000 Location: 0x00000000

I have tried the wdagtool command line tool with the following result:


I have also run a:

sfc /scannow

across my machine with no integrity issues.

If I dig into Event viewer | Application and services log | Microsoft  | Windows | WDAG-Manager, I see:


A Failure has occurred: HResult = The media is write protected., File = windows\hvsi\hvsimgr\container\hvsicontainer.cpp, LineNumber = 769, Function = NULL, Message = NULL, CallingContext = NULL, Module = hvsimgr.exe, Code = NULL

and in Event viewer | Application and services log | Microsoft  | Windows | WDAG-Service, I see:


Container service failed to start the container: The media is write protected.

I have the App Guard Service enabled in my Windows Features  as well.


I have tried:

  • Re-installing Windows
  • Re-running Windows install again
  • Removing all App Guard components, rebooting, reinstalling all the components again and rebooting
  • Installing Hyper V service
  • Installing Sandboxing Service

I am still trying to resolve this issue, and have tried quite a few knowledgeable people who haven’t had much luck either. So, if you have any suggestion of what may help, please let me know.