Forum Discussion

Daniel Smith's avatar
Daniel Smith
Brass Contributor
Jan 17, 2023

[Feature Request]: PWA pre-installation and protocol handling improvements.


We want to silently (and fully) pre-install the PWA for "Outlook Online" and have it assume the role as the default protocol handler for all "mailto" links. We want the end-user to encounter absolutely no confirmation prompts related to this process. Their first encounter with a "mailto" link should be seamless and immediately direct them to the deeplink location for drafting a new mail message on "Outlook Online":


Here's what we've done so far:

  1. We're using the "WebAppInstallForceList" GPO to pre-install the PWA for "Outlook Online".

    This works "okay", but it takes a deliberate page view of https://outlook.office365.com in order to fully complete the installation of the PWA. We've gotten around this by adding an entry to the user's "RunOnce" registry key to launch Edge and visit that site (yes, we have SSO for Azure enabled). Not ideal, but it works.

  2. We're then using the "Set a default association configuration file" GPO to define "mailto" = "MSEdge.3675880767".

    "MSEdge.3675880767 seems to be the common identifier for the "Outlook Online" PWA (at least on Windows 11). This works fine only if the PWA has fully installed itself (see above).  Due to timing issues and order of operations, the failure of a PWA to fully install before a "mailto" link is used can cause hiccups. When the "WebAppInstallForceList" GPO does its work, it appears that only a "stub" of the desired PWA is put into place, requiring a manual visit by the user to the PWA's site on the web (see above). 

    You can also see if the "Outlook (PWA)" entry is available in the list for selecting "Default Apps". It won't appear here unless that first website visit has been is completed:


    Request
    : Please fully pre-install the PWA (if enforced by GPO).

  3. Here's where we run into the largest wrinkle we're trying to eliminate. Upon first use of a "mailto" link, the user is prompted by Edge to confirm whether this is okay.

    We do not want the end-users to encounter this prompt as we're already pre-installing the PWA and setting it as the default "mailto" handler via GPO. 



  4. We've tried using the "Register protocol handlers" GPO, but that only adds an entry under the "Handlers for email links" section of "Site permissions / Protocol handers". It doesn't eliminate this prompt. In fact the "Register protocol handlers" GPO doesn't seem to be related to pre-approving the use of PWAs as protocol handlers at all its just for "URLs".

    As you can see, the entry under "Apps" only appears when the user accepts the prompt (shown above). We've done a deep-dive into GPO and Chromium settings and there doesn't seem to be a way to add any entries under the "Apps" category for installed PWAs:

     

    Request: Please allow PWAs to be pre-approved for use as a protocol handler via GPO.

    EDIT/UPDATE: We've also tried both of the following settings with the "AutoLaunchProtocolsFromOrigins" GPO, but to no effect:

    [{"protocol": "mailto","allowed_origins": ["https://outlook.office365.com"]}]
    [{"protocol": "mailto","allowed_origins": ["*"]}]

In summary:

I hope others are helped by this write-up. We hope that Microsoft can take a look at these issues related to protocol handling and the pre-installation of PWAs in Edge. It would be fantastic if we could have users directly use the Outlook PWA without any prompting or issues related to the pre-installation of the app.

 

Thanks for your time!

  • Daniel Smith Hello!  Thanks for reaching out, appreciate the thoughtful and thorough explanation.  

     

    Regarding the first request about pre-install of the PWA, this question has come up previously and our developers have said the browser needs to run at least once if the WebAppInstallForceList policy is used to install apps because the policy regkey is only read once on browser launch.  

     

    For the second request about the protocol handlers, have you looked at the AutoLaunchProtocolsFromOrigins policy?  I have not tested but the description looked like it might be helpful in your scenario.  

     

    -Kelly

    • Daniel Smith's avatar
      Daniel Smith
      Brass Contributor
      Yes, I forgot to add that tidbit about our testing of the GPO you mentioned.

      We've tried both of the following with the "AutoLaunchProtocolsFromOrigins", but to no effect:

      [{"protocol": "mailto","allowed_origins": ["https://outlook.office365.com"]}]
      [{"protocol": "mailto","allowed_origins": ["*"]}]

      As for a first launch of Edge scenario, we tried launching Edge as a service (using the command line switch "--no-startup-window") along with piping in the desired URL. Alas, that didn't work either. Our best hack would be to launch edge via a "hidden" window using vbscript or something similar.

      Thanks for engaging us on this!
      • Kelly_Y's avatar
        Kelly_Y
        Icon for Microsoft rankMicrosoft

        Daniel Smith Hey!  I've passed your questions on to the team and will follow up if they share any insights or recommendations for your scenario.  Thanks! 

         

        -Kelly

  • lucafabbri365's avatar
    lucafabbri365
    Brass Contributor
    Hello Daniel,
    did you manage to avoid the Allow/Don't allow prompt appearing to end-users on first time ?
    • DaveONeal's avatar
      DaveONeal
      Copper Contributor

      lucafabbri365 

      I got this this to work by launching Chrome with command line options to launch outlook.office.com as an app (pwa) and then I had to do some registry entries to enable Chrome as the default browser and Chrome as the mailto: handler in Chrome. It's a workaround and Microsoft definitely needs to make it easier. It still doesn't work with MAPI requests to send mail and Microsoft needs to fix that for enterprise customers. (Example , mail from Excel is a MAPI request, not mailto: )

Resources