Forum Discussion
The ms-appinstaller protocol has been disabled.
I just found out that users can no longer install my MSIX from my website. This is a WPF application packaged with "Windows Application Packaging Project" (wapproj). When users click the "Get the app" button they now see the error below saying the protocol has been disabled. Why is this? Is this permanent? Is there a way to enable it?
There's a short mention of this in the docs but it doesn't mention why this is happening or how to enable it.
Installing Windows 10 apps from a web page - MSIX | Microsoft Docs
Is this no longer supported?
<html>
<body>
<h1> MyApp Web Page </h1>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a>
</body>
</html>
The ms-appinstaller protocol has been disabled. Please ask the vendor to update the weblink. For more information go to aka.ms/ms-appinstaller-disabled
bvenhaus Thank you for your question. We removed the ms-appinstaller custom scheme due to a security vulnerability. We do intend to bring this back, and are working on it. For now, you can update the link on your website by removing 'ms-appinstaller:?source='
<html> <body> <h1> MyApp Web Page </h1> <a href="http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
- JayBeaversBrass Contributor
This broke the installation and update process for my commercial Windows app overnight because some hacker used a legitimate, documented "this is how you publish Windows apps" to distribute malware?
How is this considered an acceptable mitigation?
I have a $3k Extended Identity certificate that I sign my installer packages with, but now it's illegitimate to install it because a malicious payload was discovered somewhere else?
- JayBeaversBrass ContributorI've reported this as a DoS to the Microsoft Security team:
https://msrc.microsoft.com/submission/VULN-058721- JayBeaversBrass Contributor
The security team declined to investigate the issue, citing this thread as the official guidance.
If you have a support channel through MSFT from your business, please open and escalate an issue. It doesn't feel like the people engaged in this conversation realize the implication of their actions and I haven't yet found someone to take responsibility for fixing it.---
Received via email:
Hello Jay,
Thank you for contacting the Microsoft Security Response Center (MSRC). We appreciate the time taken to submit this issue.
We are aware of the issue you have reported regarding the MSIX installer. While this issue doesn't meet the definition of a vulnerability that MSRC can help with, we are aware that the issue is being supported through the following resources:
<"https://docs.microsoft.com/en-us/windows/msix/app-installer/installing-windows10-apps-web"> -> "The ms-appinstaller scheme(protocol) has been disabled."
and
<"https://techcommunity.microsoft.com/t5/msix-deployment/the-ms-appinstaller-protocol-has-been-disabled/m-p/3038361"> where Aditi_Narvekar from Microsoft has replied.
and you may also contact support for more information:
Contact Us - Microsoft Support
We have also shared your feedback with the engineering team who own the ms-appinstaller scheme(protocol).
As such, this MSRC thread is being closed and no longer monitored. We apologize for any inconvenience this may have caused. More information on reporting a security vulnerability can be found at <"https://www.microsoft.com/msrc/faqs-report-an-issue.">
Regards,
Duncan 
MSRC
- BC2112Copper ContributorThis is a killer. Please provide an ETA for this fix.
- tomcrevierBrass ContributorAgreed, this is crazy, how can you break our devops workflow like this?
- ChreesMBrass Contributor
Aditi_Narvekar - As MSIX is the flagship technology for deploying and updating Microsoft applications, I hope M$ is taking what amounts to a service outage as a very high priority. This issue has broken our entire devops workflow and is affecting user confidence in the solution. The additional manual steps required as a workaround at the moment are not appropriate for our user base.
- ticktokCopper ContributorI'm affected by this bas well. Can we have a timeline for when this is likely to be fixed?
- Reilly_Wood2335Brass Contributor
This is completely unacceptable for an installation technology. MSIX team: if you’re not willing to properly support AppInstaller, please put it it out of its misery.
- hrb-2Brass ContributorReilly, while I agree completely with you about the support being unacceptable, the proper action would be to make it work no matter how many band-aids are required until an acceptable replacement is available. For UWP apps the writing may be on the wall anyway. This is starting to feel a lot like Silverlight. I only hope that we get a fix to carry us over till a re-write can be done in another technology. A company that can spend 67.8 BILLION on an acquisition but does not supply the necessary resources to fix an internal problem has lost interest in that product.
- SonofsmogCopper Contributor
hrb-2 Maybe for UWP. Our UWP line of business App is actually in the Windows Store (well Windows Store for Business), but this was such a simpler solution. And Microsoft pushed the Windows Application Packaging Platform for everything so we have been using it to sideload WPF projects, but NoooOo.. They gotta break it just when things were getting easier to deploy. Unbelievable.. lol actually totally believable.
- XanderTheManderCopper Contributor
For anybody that is still having issues with this here is how I temporarily solved this problem.
When my application starts up it checks the version number (manually maintained in my App.xaml) against the version hosted on our webserver. If there is an updated version it downloads a zip file with msix and the generated shell scripts. It then upzips the files and runs the shell script through PowerShell to install the new version.Note that this requires the device be in developer mode because executing the shell script is considered installing from an unknown publisher. I'm sure somebody smarter than me could find a work around that doesn't require developer mode (if so reply so I can make the changes).
- hrb-2Brass ContributorThanks for sharing this information. Are you willing to share your scripts (genericized for security concerns of course) and/or provide further details? Unfortunately, it won't help us much as we were in the early stages of an initial rollout so 90% of our users community would not be able to use this workaround but it may help others with an established user base. This Microsoft created debacle also impacts new installs from the internet which use the same protocol, so we are unable to move forward.
- DuncanStoneCopper Contributor
hrb-2You can see my solution here https://github.com/MicrosoftDocs/msix-docs/issues/59#issuecomment-832260691
It does not use shell scripts (which also means it does not require developer mode) but you should be able to work out how to change that.
This is a workaround for a much older
bugfeature but it works here too.While we are on the subject, if you are manually editing your appinstaller file and/or your users are doing a lot of patching or installing at the moment, it is worth paying attention to this one as well: https://stackoverflow.com/questions/64381453/appinstaller-xml-issue/67390614#67390614
- jmiddourCopper ContributorYou might want to try signing the powershell scripts. We looked into doing that (for other reasons) a while back and it made windows significantly happier when it came to uac issues.
- JayBeaversBrass ContributorFYI, there is now a blog post about this:
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/disabling-the-msix-ms-appinstaller-protocol-handler/ba-p/3119479
- Aditi_NarvekarMicrosoft
bvenhaus Thank you for your question. We removed the ms-appinstaller custom scheme due to a security vulnerability. We do intend to bring this back, and are working on it. For now, you can update the link on your website by removing 'ms-appinstaller:?source='
<html> <body> <h1> MyApp Web Page </h1> <a href="http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
- JayBeaversBrass Contributor
Aditi_Narvekar could you please restore this functionality ASAP? This was a major sweeping break of what must be thousands of apps, if not more.
If the issue is unsigned apps using ms-appinstaller and carrying a malicious payload, please mitigate by disabling unsigned apps. If the issue is an EV certificate signed app using ms-appinstaller and carrying a malicious payload, please use certificate revocation to address the vulnerability.
I switched my application to use MSIX and an EV certificate because this is the best practice and most up to date tooling (via Visual Studio) for distributing a Windows app outside of the MS Store. This action has revoked, without notification, the proper way to securely distribute non-public Windows apps.
The cure is more harmful than the disease in this case.- 27k1ismsCopper ContributorI wonder if Aditi_Narvekar understands the implication for Microsoft customers with this issue? It would also be good for a reply to Jay Beavers' request.
It leaves our customers in a vulnerable situation by not being able to receive security updates to the framework, downloading the app is not a viable option - please restore this prootocol asap, we will all be losing business caused by this issue.
- GrufusCopper Contributor
Aditi_Narvekar Do you have a timeframe on when it will come back?? Removing the ms-appinstaller prefix doesn't really work as it then asks the user to download the file. Once downloaded they have to chose to run it which is a complete deviation from what ms-appinstaller did. Also you can not pass parameters on to the application with a direct link, ms-appinstaller allowed for that. Unfortunatly this has completly brought down our distribution system.
- ernieCopper Contributor
Aditi_Narvekar Could you provide us any additional information on this? This has serious implications on how we distribute certain apps.
Can you at least confirm at least if it will eventually be restored? I understand if you cannot provide a timeline yet but we would like to know so we can plan accordingly. I would hate to go through the trouble of implementing an alternative (albeit less effective) approach only to have it restored shortly afterwards.
Thanks.
Ernie
- JayBeaversBrass ContributorI've now opened a business support ticket on this from my company's support contract and set it to Sev-A, Critical Impact. I'll post here if I get traction.
- MikeHBrass ContributorUpdates do work, yes. The .appinstaller file helpfully contains its own URL and that's what's used for update checking.
- deonb1Copper Contributor
Do you have a timeframe on when this will be addressed?
We have an .exe that is shipped on thousands of 3rd party drives that calls an ms-appinstaller link through the shell (no browser or web page involved). There isn't a way for us to just "update" the URL to not use ms-appinstaller.
- jmiddourCopper Contributor
To anyone else facing implementing a workaround and is using Azure pipelines:
here is a yaml task that will edit the generated html to remove the protocol and include explicit instructions that the button will cause a download, and the downloaded file should be run.
Anonymized example from my implementation:
And here is the task:
- task: PowerShell@2 inputs: targetType: 'inline' script: | $x = gci -Recurse *.html $page = get-content $x $newpage = $page | foreach { [regex]::Replace( $_,'ms-appinstaller\:\?source\=','' ) } $newpage = $newpage | foreach { [regex]::Replace( $_,'(<div class.*app-description[^<]*</div>)','$1'+[System.Environment]::NewLine+'<div class="insert instructions"><p style="color:red" >Installation instructions:<br>1. Click the install button to begin download of installer file<br>2. After download completes run installer file to install application</p></div>' ) } set-content $x -Value $newpage
Note that there may be more efficient ways of accomplishing this, but I went with what I knew and could make generic.
- zipswichBrass ContributorOur Microsoft Store app package for sideloading on our website has this issue.
If my understanding is correct, we just need to remove "ms-appinstaller:?source=" in index.html generated by Visual Studio.
In other words:
Change
<a href='ms-appinstaller:?source=https://www.mydomain.com/download/myapp.appinstaller'>
to
<a href='https://www.mydomain.com/download/myapp.appinstaller'> - JamievanWalsumCopper ContributorThanks for this.
Do you know if the auto update feature to work still when applying this work around?
I am using the AppInstallerUpdateFrequency msbuild argum in my build pipeline.- jmiddourCopper ContributorJamievanWalsum -- as far as I know, the auto update will still work. Our apps that have been converted to msix don't have frequent updates right now, so I don't know from first hand experience yet. If I run into issues, I will post here.
- 27k1ismsCopper ContributorWhat is link supposed to mean? I have the same issue and the app cannot be installed by our clients.
I also could not access Microsoft sites from the Firefox browser and had to disable OCSP settings, I think this is the same issue, it started yesterday.