Microsoft Edge – A Closer Look at Automatic Updates
The latest Edge browser from Microsoft is, so far, an excellent browser for business and personal use. One area that is a bit of a change from the old Edge is the update cadence. We can expect brand new “Feature Updates” every 6 weeks or so and “Quality” updates on an ‘undefined’ schedule. This loss of control can be a concern to IT Pros who have to balance security concerns, impact to the user experience and to also ensure network bandwidth is not overwhelmed.
The following is a post on updates to the Edge browser and some of my findings on the automatic update process using updates downloaded directly from Microsoft. I have not explored the process from MECM in any detail so best to look elsewhere for information if that’s the approach you hope to take.
This post highlight the problem with trying to remain on a “patch Tuesday” triggered release cycle and I show some of my findings regarding the update sizes we can expect to see in production environments – this should help to inform future decisions and help us to tailor configuration appropriately for the enterprises we all look after.
Edge Updates – Highlighting the Problem
You might be thinking, as I did, that the best approach is to introduce Edge updates into well established, Patch Tuesday triggered release schedules. This is a viable approach but I think we can do better.
The following table highlights the problem and provides an argument for creating a separate release schedule for Edge – the “7 Day Schedule” column shows how many days the browser is without patches since the time of release if an automatic update check is configured to run once every 7 days:
Caveat: The table is hypothetical and assumes patches are released to production on Patch Tuesday. This doesn’t reflect reality but in most organisations does dictate what is included in the initial patch testing cycle and its schedule.
Note: You may need to rotate your mobile phone to see all of the table columns.
Release Date | Days Between Releases | Next Patch Tuesday | Vulnerable days | Severity | 7 Day Schedule |
17/01/20 | 0 | 14/01/20 | 0 | Critical | 0 |
07/02/20 | 21 | 11/02/20 | 4 | High | 0 (max 7) |
20/02/20 | 13 | 10/03/20 | 19 | High | 0 (max 7) |
25/02/20 | 5 | 10/03/20 | 14 | High (exploits detected in wild) | 3 |
04/03/20 | 8 | 10/03/20 | 6 | High | 2 |
19/03/20 | 15 | 14/04/20 | 26 | High | 1 |
01/04/20 | 13 | 14/04/20 | 13 | High | 2 |
13/04/20 | 12 | 14/04/20 | 1 | High | 4 |
17/04/20 | 4 | 12/05/20 | 25 | Critical | 0 (max 7) |
23/04/20 | 6 | 12/05/20 | 19 | High | 1 |
29/04/20 | 6 | 12/05/20 | 13 | High | 2 |
07/05/20 | 8 | 12/05/20 | 5 | High | 1 |
21/05/20 | 14 | 09/06/20 | 19 | High | 1 |
04/06/20 | 14 | 09/06/20 | 5 | High | 1 |
Source: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200002
Evidently, attempting to introduce Edge updates into “traditional” patch Tuesday triggered schedules could leave the primary browser vulnerable to exploits for up to 26 days at a time with long stretches between patch releases also expected. Couple this with the fact that the browser is used by almost all users and is therefore a high value target for bad actors – it makes sense in my opinion to adjust and introduce a new update schedule for MS Edge.
Exploring the Update Process
The update process for Edge can be examined more closely via a log file found in this location:
“C:\ProgramData\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log”
In my experience the typical behaviour is to see this log populated during the installation of Edge and the first update check is carried out around 5 minutes after the browser has been installed.
This is evidenced here where a test installation has completed at 22.06 and an update check follows at 22.10:
The log can be easily deciphered – I’ve highlighted some key lines that show that an update is requested for the Stable channel, downloaded and installed successfully by my test VM:
Controlling the Edge Update Cadence
The update schedule can be controlled, along with many other update settings by GPO or an Endpoint Manager policy. Full capabilities are documented here:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies
Key items to be aware of are summarised below:
-
- Update policy override – Can be used to control how updates are handled for each channel. E.g. We can set allow manual and automatic for the Beta channel but Automatic updates only for the Stable channel
- AutoUpdateCheckPeriodMinutes – Specifies the time in minutes between updates. Checks still occur every hour but are ignored if the time period set here has not elapsed since the last update installation
- Target version override – Supported in Edge v83 and above. Pins the version specified to the device. Automatic updates are no longer applied if the target version is already installed.
It’s safe to deploy a GPO/MDM policy containing updates settings to your devices prior to installing the Edge application if you so wish. If you are concerned about when the update cycle will get triggered and the subsequent impact on the network, the following should help to provide some insight into the expected behavior:
- Edge GPO/MDM settings are deployed to all systems. The HKLM\Software\Policies\EdgeUpdates “AutoUpdateCheckPeriodMinutes” will contain information about the update check period in minutes
- When Edge is installed the value in “AutoUpdateCheckPeriodMinutes” set by GPO/MDM is not checked by the application
- MicrosoftEdgeUpdate.exe (a separate executable installed as part of the main application) is triggered approx. 5 mins after the Edge installation has completed (check the MicrosoftEdgeUpdate.log if you want to see this in action)
- Once MicrosoftEdgeUpdate.exe has completed its first update check, a registry value here HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate is updated with the “LastChecked” value – its in UNIX date format so get the decimal value and then visit this site to convert it to something you can read: https://www.unixtimestamp.com/index.php My example has the date code of: 1597504302 which when converted is 08/15/2020 @ 3:11pm (UTC)
- MicrosoftEdgeUpdate.exe then runs once per hour, and my guess is that the value in “LastChecked” value is then compared to the value in “AutoUpdateCheckPeriodMinutes” to figure out if an update should be performed.
Update Sizes
Update sizes depend on whether the device requires a smaller “quality” update i.e. moving from version 83.1.2 to version 83.2.0 or a larger “feature update” – for example moving from version 83.2.0 to version 84.0.1 (note: version numbers have been made up for this example )
To discover more precise sizes I used an excellent and free network monitoring tool called “GlassWire” (https://www.glasswire.com/) and set up a VM with Edge version 83.0.478.54 installed. I set a couple of registry values so that the update doesn’t automatically apply on first launch and my device is locked to version 83.0.478.54 and the manually adjusted them when I did want to pull down an update so that I could monitor the download sizes in Glasswire:
In the GlassWire application, on the “usage” tab its possible to see bandwidth utilisation by process:
However, the MS Edge Update process is carried out by a separate executable (MSEdgeUpdate.exe) which is not shown in the list of apps. Instead when Edge is updated its bandwidth consumption is bundled into the “Host process for Windows Services” bucket.
Controlling when the update occurs and what version Edge updates to is essential if a more precise estimate of the update size is sought.
Changing this value to a “1” ensures that updates can be triggered manually (3 = automatic updates only) – this helps to control the ‘when’ part:
Altering the TargetVersionPrefix value enables us to control the “what” part of our update testing:
For the first test I will adjust the values so that I can manually update and I will capture the update size for a minor “quality” update to version 83.0.478.56
(Versions can be obtained from this link: https://www.microsoft.com/en-us/edge/business/download)
This is achieved by changing the registry values below:
Note: Edge must be restarted for it to apply the new update parameters set in the registry.
The best approach is to clear the history in GlassWire and to then make a note of the current size of the “Host Process for Windows Services”. Then its a case of triggering the update by navigating to Help and Feedback > About Microsoft Edge:
And then monitoring the update progress:
Once completed its a simple exercise to check GlassWire to examine the hosts that were contacted via Host Process for Windows Services to figure out accurately the size of the download.
The following table summarises the tests I performed and subsequent download sizes:
Start Version | Upgrade Version | Update Size (MB) | Skipped Builds |
81.0.416.68 | 83.0.478.37 | 77.1 | 2 |
83.0.478.37 | 83.0.478.45 | 3.5 | 0 |
83.0.478.45 | 83.0.478.54 | 3.6 | 0 |
83.0.478.54 | 83.0.478.56 | 3.2 | 0 |
83.0.478.56 | 83.0.478.58 | 4.4 | 0 |
83.0.478.58 | 83.0.478.61 | 3.3 | 0 |
83.0.478.61 | 83.0.478.64 | 3.4 | 0 |
83.0.478.64 | 84.0.522.40 | 40 | 0 |
83.0.478.54 | 84.0.522.61 | 81.3 | 12 |
81.0.416.68 | 84.0.522.61 | 86.4 | 19 |
So the maximum update size expected is in the order of 86MB. Smaller updates are between 3 and 5MB. It also appears to make sense to perform regular updates so that the intensity of impact to the network is minimised.
Delivery Optimisation
The impact to the network can be reduced further by using Delivery Optimisation. Edge does…or at least it will in the coming months…fully support DO. So far in my lab DO has not been initiated successfully but some digging tells me that this is a feature that will be enabled by the Edge team soon enough.
Thanks for reading.