NTLite v2.3.8.8889 doesn't fully remove Edge, unlike .8850

Kjell

Member
I'm using all available compatibility filters in components section and I was able to successfully remove Edge's Appx in the previous release (v2.3.7.8850). However, after updating to v2.3.8.8889 I get Edge on my desktop after installing Windows from my custom ISO (Hyper-V).
 
Try switching to previous DISM + Custom App removal mode in the Components page toolbar.
Other than that, there was no changes, potentially Edge Update reinstalled it after setup, as soon there is internet.
 
Try switching to previous DISM + Custom App removal mode in the Components page toolbar.
Other than that, there was no changes, potentially Edge Update reinstalled it after setup, as soon there is internet.
What you say is absolutely true: Edge is reinstalled at installation completion stage.
However, curious as I am, I wanted to investigate the situation and noticed these discrepancies.

PREMISE:
same native ISO source (from UUP 19044.1949, inclusive - ALL - also of the Professional and Enterprise version, x64).

NTLITE:
same "preset" for both the Professional version - before - and Enterprise - after - with production of a specific univocal version - ISO with only Professional, and ISO with only Enterprise;
MS Edge with all Widgets deleted.

INSTALLATION:
on VMware - same settings.

CONCLUSIONS:
1) The VM Professional during the installation phase of the OS will reinstall native MS Edge latest version available, even if then through Control Panel/Programs and Features (after having previously removed the corresponding active Services and active Features) it is possible completely uninstall MS Edge without any unwanted new reinstalls;
2) The VM Enterprise in the installation phase of the DOES NOT present/reinstall MS Edge of which there is no trace in Control Panel/Programs and Features.

CONSIDERATIONS:
1) Surely this discrepancy depends "NATIVELY" on Microsoft, even if perhaps a further investigation could verify if instead it is not NTLITE that "neglects" some new setting;
2) If this were not the case, perhaps NTLITE (and here I throw it as it comes to mind) could somehow foresee - if not already present now and I ignore it so ... always ready to learn - the possibility of disable the network connection until the first post installation boot (Login screen).

Forgive my English and available for any further inquiries. Thank you
 
Edge Update folder could be removed (or renamed) in "Post-Setup", located in \Program Files (x86)\Microsoft\EdgeUpdate.

I have removed EdgeCore, EdgeUpdate, EdgeWebview folders as Edge contains the exact same files (400 MB+) and more (except EdgeUpdate 10 MB).
Edge runs ok, so, I'm ok with that but I don't use it, Brave browser is a must.
 
1) Surely this discrepancy depends "NATIVELY" on Microsoft, even if perhaps a further investigation could verify if instead it is not NTLITE that "neglects" some new setting;
2) If this were not the case, perhaps NTLITE (and here I throw it as it comes to mind) could somehow foresee - if not already present now and I ignore it so ... always ready to learn - the possibility of disable the network connection until the first post installation boot (Login screen).
This is the correct idea, but a wrong approach.

When you install an Edge-free image, EdgeUpdate magically re-appears to install the latest browser (105.0.1343.27).
To understand what's happening, you have to read C:\ProgramData\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log

OOBE WU is installing EdgeUpdater as a mandatory ZDP (Zero Day Package) update. Pre-emptively disabling the network causes all sorts of unintended problems with Setup, and should be avoided.

Tried two different solutions:
1. Bypassing OOBE WU with the localhost WSUS, since your WSUS server is allowed to provide ZDP updates. That didn't work.
2. GPO restrictions on denying Edge updates don't apply here, since we're not inside a joined domain.

Checking MicrosoftEdgeUpdate.log, we see EdgeUpdater hitting the API endpoint to discover what version of Edge to download. MS documents you have to open the firewall to allow specific update hosts.

The answer is to first remove the Edge-related components:
Code:
                <c>edgeupdate 'Microsoft Edge Update'</c>
                <c>microsoft.microsoftedge.stable 'Microsoft Edge (Chromium)'</c>
                <c>Microsoft.MicrosoftEdge 'Microsoft Edge (Legacy)'</c>
                <c>Microsoft.MicrosoftEdgeDevToolsClient 'MicrosoftEdgeDevToolsClient'</c>
                <c>pdfreader 'Windows Reader (PDF)'</c>
Edge (Legacy) is a requirement for some apps, but some of you will insist; and PDF Reader doesn't work w/o Edge.

Then add one line to Windows\System32\etc\hosts:
Code:
127.0.0.1    msedge.api.cdp.microsoft.com

Windows right after install, when you block just the Edge API host:

Windows 10 x64-2022-09-05-10-44-04.png
Windows 10 x64-2022-09-05-10-45-16.png

Windows when you block the entire endpoint list:
Code:
127.0.0.1       msedge.api.cdp.microsoft.com
127.0.0.1       msedge.f.tlu.dl.delivery.mp.microsoft.com msedge.f.dl.delivery.mp.microsoft.com
127.0.0.1       msedge.b.tlu.dl.delivery.mp.microsoft.com msedge.b.dl.delivery.mp.microsoft.com
127.0.0.1       msedge.sf.tlu.dl.delivery.mp.microsoft.com msedge.sf.dl.delivery.mp.microsoft.com
127.0.0.1       msedge.sb.tlu.dl.delivery.mp.microsoft.com msedge.sb.dl.delivery.mp.microsoft.com

PS - I expect all this to break if you install the next monthly CU (which includes Edge).

UPDATE - After more testing, we only need to block the API host and not the full Edge hosts list as originally posted.
 
Last edited:
This registry used to work in 2021, didn't check if it still works lately
Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EdgeUpdateDev\CdpNames]
"msedge-stable-win-x64"="msedge-internal-win-x64"
"msedge-stable-win-x86"="msedge-internal-win-x86"
"msedge-stable-win-x64-zdp"="msedge-internal-win-x64"
"msedge-stable-win-x86-zdp"="msedge-internal-win-x86"
"msedge-stable-win-x64-critical"="msedge-internal-win-x64"
"msedge-stable-win-x86-critical"="msedge-internal-win-x86"
"msedgeupdate-stable-win-x64"="msedge-internal-win-x64"
"msedgeupdate-stable-win-x86"="msedge-internal-win-x86"
"msedgewebview-stable-win-x64"="msedge-internal-win-x64"
"msedgewebview-stable-win-x86"="msedge-internal-win-x86"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\EdgeUpdateDev\CdpNames]
"msedge-stable-win-x64"="msedge-internal-win-x64"
"msedge-stable-win-x86"="msedge-internal-win-x86"
"msedge-stable-win-x64-zdp"="msedge-internal-win-x64"
"msedge-stable-win-x86-zdp"="msedge-internal-win-x86"
"msedge-stable-win-x64-critical"="msedge-internal-win-x64"
"msedge-stable-win-x86-critical"="msedge-internal-win-x86"
"msedgeupdate-stable-win-x64"="msedge-internal-win-x64"
"msedgeupdate-stable-win-x86"="msedge-internal-win-x86"
"msedgewebview-stable-win-x64"="msedge-internal-win-x64"
"msedgewebview-stable-win-x86"="msedge-internal-win-x86"
 
I'm using all available compatibility filters in components section and I was able to successfully remove Edge's Appx in the previous release (v2.3.7.8850). However, after updating to v2.3.8.8889 I get Edge on my desktop after installing Windows from my custom ISO (Hyper-V).

It wasn't being reinstalled over the network, because I tried installing my iso while disconnected from the network, and Edge Chromium was still there. I also confirmed this bug by reloading the image after removing Edge Chromium with the new DISM only app removal method. It still showed on the list of components, suggesting it was never fully removed to begin with.

The problem was the new DISM only app removal method. It did not completely remove Edge Chromium. This was fixed in the latest update (see changelog).
 
Back
Top