We recently made a promise I’ve been hoping to make for a long time: if an app works on a previous version of Windows and, when you update to the latest version of Windows 10, it stops working, we’ll fix it for free.
This is a big deal to me personally, because we’ve finally found a way to share the risk.
You see, in the past, every time we released a build of Windows, we came out announcing that it was “highly compatible” with existing software. But organizations noticed that “highly” seemed to be defined somewhat differently each time. When we made the transition away from “everyone is an admin all the time” to “even admins aren’t admins all the time,” it is estimated that up to one in five enterprise applications were impacted. User Account Control (UAC) remediated a lot of apps, but far from all of them. (Yes, you read that right—UAC isn’t the technology that breaks apps, running as a standard user is what broke apps. UAC tried to fix them and make it easier to build new apps that worked as a standard user!)
When we released Windows 7, application compatibility became a core tenet[i] of Windows. From an operational standpoint, this meant that you couldn’t check in code unless you understood the compatibility impact—and, if there was going to be a significant compatibility impact, it had to be reviewed and approved as doing more good than harm. We were doing our best, but if we were to overlook something, who bore the risk? The customers who were deploying.
We thought we could do better.
The Desktop App Assure program is a shared risk program. Your organization still bears the risk of validating that applications work, but if something fails, then we accept the risk of finding a way to remediate the app! We could fix Windows itself, work with the vendor who wrote the app, or suggest a code change. And I think that’s a really big deal.
Of course, we wish you didn’t have to bear any risk, but we don’t know what every application does, so we haven’t yet thought of a way to understand if there is a compatibility issue with a given app in a deterministic way. Why not? Because a compatibility bug is just a special type of bug, and it’s already been proven mathematically impossible (by Sir Alan Turing, way back in 1936) to find all bugs. Any scanning we could do, therefore, is inherently statistical in nature (though we are working on that too). So, for now, the best way to understand if a compatibility issue will impact you is to test your applications.
One thing I’ve noticed is that many customers are over-testing apps—and they’re doing so with good reason. We’ve measured a very small failure rate of apps when moving from build to build of Windows 10. For example, with a recent build, we measured a 0.03% average app failure rate among a small group of customers with whom we worked close. (We understand that the plural of anecdote is not data and, while we see no reason that results would vary radically across customers, we don’t have statistically meaningful numbers here.)
Why are customers then over-testing apps if the failure rate is so small? Because the smaller the failure rate, typically the more difficult the remediation. When things fail on a larger scale, you tend to find blogs, forum posts, and even tools to help you out. When things fail in very small numbers, you are typically on your own for the difficult task of debugging. WinDbg is much harder to use than LUA Buglight. If you happen to hit a failure in pilot testing or even production, chances are you’ll be addressing it longer, because you’ll have a harder problem to solve.
With Desktop App Assure, if you hit a snag in a pilot or your deployment, you have a team of application compatibility experts who will support you and get you back up and running as quickly as possible. This makes it much easier to align your testing patterns to your predicted or measured failure rates.
We had several calls from customers during the pilot of this program where, after the niceties of introductions and talking about the program, it was revealed that they didn’t have any apps that were broken. We had successfully delivered on the compatibility promise in the OS! Why did they reach out? They wanted to make sure that the program existed in case they ran into an issue next time. We brought them confidence. And that matters too.
So, with that bit of introduction, what kinds of application compatibility issues can you bring to Desktop App Assure? Let’s look at some examples.
The Desktop App Assure program can definitely help with this! Whether you’re moving from one build of Windows 10 to another, or from Windows 7 to Windows 10, we’ll help with troubleshooting your application and suggest a remediation. For some apps, it may be a change in behavior of Windows that causes the issue, and we’ll go and revert the change in Windows to fix the application. (We’ve already done this several times.)
Alas, it’s not always that easy. For example, it could be that you’ve run up against a change that was made to improve the security of the Windows OS. We often expose the option to disable a security feature, but you may not want to lower the security to fix your compatibility issue. If that’s the case, we’ll suggest a way to modify the code so your developers can quickly make the change and get the application working again with the new configuration.
We also know that not all customers have the source code for every application they run. In fact, a significant number of enterprise line of business (LOB) apps are developed by contractors and provided without source code, which makes even a simple source code change difficult. In that case, we may suggest an application compatibility shim that you can apply to remediate the application, and provide you with a custom shim database which you could either apply directly or merge into a shim database you already have.
Not all solutions can be used for all apps, but we’ll work with you to find the right path to unblock the application in your environment!
We’ll happily work with you through the Desktop App Assure program on these apps as well! We recommend, of course, that you check to see if you’ve already grabbed the latest version as the vendor may have already fixed the issue, but if you have the latest version and there is a still a problem, we’ll help you troubleshoot and understand what went wrong.
As with LOB apps, we may be able to change the behavior of Windows itself in order to get the application working. Or, we may have a suggestion for changing the code. We are happy to work with the vendor to share with them the results of our troubleshooting (debugging is hard so it is extremely helpful to bring in an issue already debugged). We will often want to keep you involved in this process because we’re not the customer and don’t give your vendors any money. Believe it or not, you (their customers) are the ones they listen to the most!
The Desktop App Assure program is not limited to installed Win32 apps. We will happily take on issues with web applications. If your app worked on Internet Explorer 11, or any previously supported version of Internet Explorer, in Windows 7, but fails on Internet Explorer in Windows 10, we’ll help you troubleshoot and remediate.
We aren’t committing to modernizing every web app, mind you. For example, if you’re running Internet Explorer 11 in IE5 Quirks mode (a 1999 implementation of web standards), rewriting the code to run in Microsoft Edge would be out of scope. However, that is part of the reason we left Internet Explorer 11 in Windows 10—as a compatibility solution for your existing web apps. Consequently, we would help make sure that IE5 Quirks in Internet Explorer 11 on the latest build of Windows 10 does what it’s supposed to do. (Of course, if you are interested in modernizing your web apps, here's an Microsoft Ignite session to get you started!)
If you are also moving to Office 365 Pro Plus and your Office plug-in isn’t working, the Desktop App Assure program will help you troubleshoot and remediate that issue as well. We understand that the definition of an app must integrate with all these technology platforms, and we want to make it possible for you to stay current on the whole Microsoft 365 stack.
Yes! And I’m super happy about this one!
Many customers simplified the transition to Windows 7 by taking on some technical debt. Some customers deployed a 32-bit version of Windows 7, which made compatibility easier. If your application is breaking on Windows 10 64-bit (which, let’s face it, you probably want), the Desktop App Assure program can help you remediate that app too.
What about UAC issues? Some customers disabled UAC for Windows 7. This wasn’t the best idea for Windows 7 as we didn’t do a lot of testing in this configuration and you lost a lot of valuable security features. That said, disabling UAC is a completely untested configuration on Windows 10, and there are loads of key scenarios we already know will break (and, no doubt, a great many more) because we don’t test this configuration. If your application is failing because of administrator rights removal, we can help with that.
Some customers also simplified the transition to standard user rights by purchasing third-party software that elevated only a specific application to administrator privileges as a stop-gap solution. What if that application has not yet resolved that dependency and still requires that stop gap? The Desktop App Assure program can help you address this situation as well by troubleshooting to understand why there is an administrator rights dependency and offering solutions to remediate the issue so you can finally get to the other side of your bridge to least privilege (rather than sitting in the middle).
We really do want to make sure you can get to a secure, modern configuration of Microsoft 365 and Windows 10 and, with Desktop App Assure, have tried to identify and include all the key scenarios you may encounter in your environment. We have also tried to make the process of getting started with Desktop App Assure as easy as possible. Simply visit Microsoft FastTrack and Request Desktop App Assure. I even made what I thought was a clever shortcut to help you remember: https://aka.ms/800appcompat.
[i] To clarify, application compatibility has always mattered. Check out this search on Raymond Chen’s blog for great stories of the contortions we’ve done for compatibility over the history of Windows.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.