Category Archives: Uncategorized

On a Windows computer, is it possible to configure either Google Chrome or Adobe Acrobat DC so that Welcome to Adobe Acrobat message is not displayed in a new tab when Chrome is launched for the first time?

Welcome to Adobe Acrobat for Chrome

One of my goals as a desktop engineer is to remove for the users as many distractions and marketing messages as I can, mainly by understanding what settings are available to suppress notifications from various applications and deploying those settings to workstations. I’m pretty successful at this, but every now and then I get stumped, and the Adobe Acrobat extension for Chrome is one of those cases. The behavior I’m trying to control is the display of a new tab in Chrome that is launched when Chrome starts for the first time after the Adobe Acrobat extension is enabled, which displays a “Welcome to Adobe Acrobat for Chrome” PDF. In the past, the address bar for the new tab would display ““, but more recently, the address is “chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/“. Complicating matters is that it’s not clear whether the change needs to be made to Chrome or Acrobat.

The most official-looking information on this comes straight from Adobe, on the page at, which provides instructions on how to use a registry value to prevent the extension from displaying a welcome PDF in a new tab in Chrome. So, the people at Adobe obviously know exactly what they are doing and are able to provide a way out if they want. Unfortunately, I’ve not gotten consistent results using this method.

I’ve also tried the Adobe Acrobat FeatureLockDown registry values bToggleFTE and bWhatsNewExp that disable the Welcome/Start Tour screen and the What’s New experience pages in Acrobat. But these values didn’t appear to have an effect on the Chrome extension.

What may have worked is either (or a combination of) the HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\efaidnbmnnnibpcajpcglclefindmkaj\policy\OpenHelpx registry value set to false (and specifically set to lowercase – although it’s not clear that this is case sensitive) or the HKLM\Software\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown\cWelcomeScreen\bShowWelcomeScreen REG_DWORD value set to 0 in addition to the bToggleFTE and bWhatsNewExp values. In an environment with all four of these registry values configured, it appears that Acrobat no longer causes a new tab to be opened in Chrome.

Disabling the Adobe Acrobat DC Welcome screen with bShowWelcomeScreen is recommended as a security improvement according to and for Adobe Reader DC

In light of CVE-2023-4863, I started looking into updating the Microsoft.WebpImageExtension app on Windows 10/Windows 11 via a command line. In the process, I discovered a few things about winget and PowerShell commands for Appx and thought I’d share them here.

The vulnerability I’m concerned with is documented at, and Specifically, I’m concerned with updating the Microsoft.WebpImageExtension app, because while the Microsoft Store is supposed to keep things up-to-date, and maybe eventually it gets around to doing that, it doesn’t do so quickly enough to satisfy me.

Microsoft’s guidance for updating the Webp app is predictably consumer-oriented. “The Microsoft Store will automatically update affected customers. Alternatively, customers can get the update immediately; see here for details.” I wanted to find a way to update systems to version 1.0.62681.0 programatically and immediately.

My first stop was to open Terminal and query winget, the Windows package manager. I’m excited about the potential that this utility offers, please keep investing in it, Microsoft!

Checking the version of Microsoft.WebpImageExtension with winget list, I confirmed that the currently installed version was vulnerable and needed updating.

PS C:\WINDOWS\system32> winget list Microsoft.WebpImageExtension
Failed when searching source; results will not be included: winget
Name                  Id                                         Version
Webp Image Extensions Microsoft.WebpImageExtension_8wekyb3d8bbwe 1.0.62011.0

I then searched the MSStore source for “Webp Image Extensions” with winget search, using the name that winget list returned, to find the ID of the package.

PS C:\WINDOWS\system32> winget search "Webp Image Extensions" --source=msstore
Name                  Id           Version
Webp Image Extensions 9PG2DK419DRG Unknown

Note that the version for this Microsoft Store app is “Unknown” by winget. This is important, because while the Windows Store knows about the versions of apps, currently that information is not surfaced to winget. This prevents winget from determining whether an upgrade is available, as I would soon discover. Hopefully, this will improve in time.

The Get-AppxPackage PowerShell cmdlet can provide a good deal more information than winget, and it along with Remove-AppxPackage are useful for managing installed Appx packages. But in this case, winget turned out to be the solution to my problem.

PS C:\WINDOWS\system32> Get-AppxPackage -Name Microsoft.WebpImageExtension

Name              : Microsoft.WebpImageExtension
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 1.0.62011.0
PackageFullName   : Microsoft.WebpImageExtension_1.0.62011.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WebpImageExtension_1.0.62011.0_x64__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.WebpImageExtension_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

It took me a few tries to figure out the correct switches, because winget couldn’t tell that the version in the store was newer than the installed version.

PS C:\WINDOWS\system32> winget install --silent --id=9PG2DK419DRG --source=msstore --accept-package-agreements
Found an existing package already installed. Trying to upgrade the installed package...
No available upgrade found.
No newer package versions are available from the configured sources.

I was surprised to find that winget upgrade didn’t by default attempt to upgrade the package.

PS C:\WINDOWS\system32> winget upgrade --silent --id=9PG2DK419DRG --source=msstore --uninstall-previous --accept-package-agreements
No available upgrade found.
No newer package versions are available from the configured sources.

Eventually, I was able to assemble the arguments into a command that did what I wanted.

The magic command line turned out to be winget install --silent --id=9PG2DK419DRG --source=msstore --uninstall-previous --accept-package-agreements --force.

PS C:\WINDOWS\system32> winget install --silent --id=9PG2DK419DRG --source=msstore --uninstall-previous --accept-package-agreements --force
Found Webp Image Extensions [9PG2DK419DRG] Version Unknown
This package is provided through Microsoft Store. winget may need to acquire the package from Microsoft Store on behalf of the current user.
Agreements for Webp Image Extensions [9PG2DK419DRG] Version Unknown
Version: Unknown
Publisher: Microsoft Corporation
Publisher Url:
Description: The WebP Image Extension will enable you to view WebP images in the Windows 10 Microsoft Edge browser. WebP is a modern image format that provides lossless and lossy compression for smaller, richer images on the web.
Privacy Url:
Copyright: © 2018 Microsoft
Category: System Components
Pricing: Free
Free Trial: No
Terms of Transaction:
Seizure Warning:
Store License Terms:

Starting package install...
  ██████████████████████████████  100%
Successfully installed

Interestingly, post-update, winget list now shows the source is “msstore”.

PS C:\WINDOWS\system32> winget list Microsoft.WebpImageExtension
Failed when searching source; results will not be included: winget
Name                  Id           Version     Source
Webp Image Extensions 9PG2DK419DRG 1.0.62681.0 msstore

I have found error ID 40, with the description “The event logging service encountered an error when attempting to apply one or more policy settings.” is written to the System event log when the Group Policy setting “Specify the maximum log file size (KB)” under “Windows Components/Event Log Service/System” is configured (either enabled and set to a valid size or disabled).

Log Name:      System
Source:        Microsoft-Windows-Eventlog
Date:          2/18/2016 11:44:46 AM
Event ID:      40
Task Category: None
Level:         Error
Keywords:      Service availability
User:          LOCAL SERVICE
The event logging service encountered an error when attempting to apply one or more policy settings.
Event Xml:
<Event xmlns="">
    <Provider Name="Microsoft-Windows-Eventlog" Guid="{FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}" />
    <TimeCreated SystemTime="2016-02-18T17:44:46.789855700Z" />
    <Correlation />
    <Execution ProcessID="1140" ThreadID="5600" />
    <Security UserID="S-1-5-19" />
    <ChannelPolicyApplicationError xmlns="">
      <Error Code="5">

The same error will appear when the Group Policy setting “Specify the maximum log file size (KB)” is configured under “Windows Components/Event Log Service/Application” or “Windows Components/Event Log Service/Security”.

Unfortunately, the SCM Windows 10 TH2 – Computer GPO (which I like to use as a baseline security GPO) sets the maximum log size for the Application, Security and System logs, and because disabling the setting in a GPO with a lower link order does not prevent the errors from appearing, I have to choose between changing the Microsoft security baseline GPO and living with the errors in the event log. I have decided to modify the GPO and set the three maximum log size settings to Not Configured, and then change the size of the System event log using the command “wevtutil sl System /ms:33554432”, the Application event log with “wevtutil sl Application /ms:33554432” and the Security event log with “wevtutil sl Security /ms:201326592” during the SCCM OSD task sequence.

The outcome is that the logs are configured to their recommended sizes, as specified in the SCM GPO, but GP is not enforcing the log size. I feel like this is an acceptable workaround, as it avoid the errors in the System event logs, sets the logs to the Microsoft-recommended size, and standard users will not be able to change the maximum log size via the Log Properties page.

Today I learned that Microsoft Edge on Windows 10 does work with an Enterprise Mode Site List after all. I had been trying in vain for weeks (off and on) to get it to redirect into Internet Explorer those sites that I had configured to do so through the Enterprise Mode Site List XML file. As far as I could tell, I was correctly using the Group Policy setting “Allows you to configure the Enterprise Site list”, providing a valid UNC path to the sites.xml file on our DFS. No matter how I configured the contents of the file, Edge simply would not perform the redirection. The redirection would work flawlessly if I configured the Group Policy setting “Sends all intranet traffic over to Internet Explorer”, but I didn’t want to open all of our intranet sites in IE, and there were plenty of Internet sites that I wanted to open in IE.

Internet Explorer 11 on Windows 7 had been successfully retrieving the sites.xml file via a UNC path, rather than an URL, for months. Furthermore, Internet Explorer 11 on Windows 10 was able to retrieve the file via UNC path. Running short of new things to try, on a whim, I copied the sites.xml file to a web server and provided the path in the Group Policy setting as an HTTP address, and lo and behold, Edge happily loaded the file and redirected users to Internet Explorer.

To be sure I wasn’t making up the ability to use a UNC path, I checked the TechNet article Use Enterprise Mode to improve compatibility, which is part of the Microsoft Edge – Deployment Guide for IT Pros. It clearly states that the SiteList value at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode accepts a UNC path, and this is what was being created by my Group Policy setting. However, the Group Policy setting’s field, into which you enter the path, asks for a URL. So, perhaps the TechNet document is wrong. Maybe the editor simply copied and pasted from the IE11 article Turn on Enterprise Mode and use a site list, and did not validate those instructions for Microsoft Edge.

Anyway, I hope that this post helps other systems administrators who may find themselves in the same situation, but I also wish that Microsoft would address this inconsistency between Edge and IE. A UNC path on our DFS (which is something within my control) is far easier for me to administer than a file on a web server (which is outside of my control).

After the eBay database breach, all users are being asked to change their passwords. However, many people are rightfully complaining that the password reset form prevents them from pasting into the form fields, which makes it difficult to use long, complex passwords. Although, there has also been much criticism of eBay’s password length and complexity requirements being too lax.

Ars Technica has a good article at After the breach: eBay’s flawed password reset leaves much to be desired describing the various flaws.

In changing my own password, I was determined to use a complex password that was the maximum length (20-characters) and to ensure that the password was correctly recorded, I needed to be able to paste that password into the form fields.

Through some experimentation, I found that passwords can be pasted into the form after disabling JavaScript in your browser.

The instructions below are for Chrome on Windows, but this should be similarly possible in other browsers:

  1. Open the JavaScript Console (Ctrl+Shift+J), then click on the gear icon at the top-right to open the Settings dialog box.
  2. In the General area, check the box next to “Disable JavaScript”.
  3. You should now be able to paste into the password input fields (but be mindful of the 20-character limit).
  4. Clear the check from the box next to “Disable JavaScript” and close the Settings dialog box, then close the JavaScript Console.
  5. Submit the form.

If you happen to enter more than 20 characters, the form will be submitted successfully and your password will be successfully changed, but the password will be truncated to the first 20 characters.

For those of you who reluctantly used a less secure password due to the limitations of the form, hopefully this allows you to reset your password again and use a more satisfying password.