We work a lot with enterprise customers to understand the challenges of managing application compatibility over a large application estate. In fact, we must! That’s how I got started in my illustrious career as The App Compat Guy: data on enterprise compatibility would be trapped behind an organization’s corporate firewall, so I would hop on a plane and cross that firewall with my feet. I would then take what I learned back to Microsoft to continue to shape our engineering processes to further minimize the impact on enterprise compatibility as Windows continued to evolve. (Hopefully you’ll agree that our compatibility story is significantly better today than it was in the Windows XP to Windows Vista transition.)
We continue to partner with enterprise customers to help understand both the technical and non-technical challenges. In our engagements and partnerships so far, we’re starting to see some trends emerge. This blog post won’t be diving into technical challenges. Why? Because one of the biggest trends we’ve noticed is that we’re skipping too quickly into the technology and forgetting some of the basics along the way. So, what quick wins could you achieve that you might be missing today?
Check for app updates
This is one of the very first things that Microsoft does when we’re investigating an issue: find out if the app is the most recent version of the app. We just head to the vendor’s website and see if we can find the latest version.
In a recent example, we had a customer who discovered that an app was broken and that the issue was blocking 400 users from upgrading to Windows 10, version 1709. When clarifying the request, we looked up and discovered that there was a newer version of the app available (they were several versions behind) and that the update was free. The customer had so busy testing all of the different scenarios (old version worked on Windows 7, old version worked on version 1607, old version breaks on version 1709, cataloging the ways in which it broke on version 1709) that they hadn’t actually looked to see if an updated version was available. Once they tested the update, they discovered that it worked great on version 1709 and their users were unblocked.
We check for app updates as a first step when working with a customer because it’s so easy for both us and members of the customer’s IT team so assume that this was already done. In truth, so much existing software requires active maintenance, which is why it’s worth considering if it makes sense to migrate to a store model (like the Microsoft Store for Business) where apps can be automatically updated without requiring an administrator to actively manage the app by detecting update releases (usually by polling the website), downloading the update, and deploying the update through solutions like System Center Configuration Manager. If a store model doesn’t work for you, though, three minutes of web searches can save you hours of non-value-add testing!
Speaking of web searches, here’s the next tip…
Improve your web search mojo
The query we typically start with is:
Windows 10 <dateversion> <isv> <app> <version> <issue>
This pattern tends to work well to help us understand what is already known. For example, here is a recent query we used:
Windows 10 1803 Autodesk Civil 3D 12.0.1386.0 Hydraflow Calculation
Here are the results we found:
We found a forum conversation, but more importantly, we found a knowledge base (KB) article. By following the KB article, we found that a fix was already available and received directions on how to solve the issue:
If a general web search is generating too much noise, we also have a couple of additional search locations that can help (though, honestly, we do most of our searching through a general-purpose search engine). These locations are, of course, indexed, but may not show up in search results above vendor or community resources:
- Microsoft Support Knowledge Base - https://support.microsoft.com
- Microsoft Community Knowledge Base - https://answers.microsoft.com
Improving your search mojo can save you significant time when it comes to troubleshooting.
Work with the software vendor
This is an area we’ve struggled with for a while. Many customers come to Microsoft first and hope that we can solve all their software issues for them. We do want to help and to drive the best possible ecosystem, but, ultimately, we often have very little control.
To use a metaphor: when you buy a car, you absolutely can customize it. Don’t like the stereo? You can pull it out and replace it. And you should be able to reasonably expect that the power feed leading to the radio will deliver clean, consistent power, and connect to the speakers. So, if the power is surging every 10 minutes and blowing up your stereo, you go to the car manufacturer and report that as a defect. But, if the stereo suddenly stops playing CDs (wait, do those still exist?), then the best person to help you fix it will be the stereo manufacturer. If you call the car manufacturer, they may be disappointed that you’re not enjoying your car as much as you could, but they are constrained in what they can do.
Why can’t we at least broker the conversation, then? Doesn’t everyone listen to us?
To start with, we aren’t the vendor’s customer. We don’t give them any money and given a choice between pleasing us and pleasing paying customers, you (the paying customer) win.
We also don’t pay support fees. If information is trapped behind a support paywall, we may not even be able to access it to so that we are aware of what is known and what is not known.
Microsoft continues to strive to aggregate information to minimize the outreach you must do to discover what is known about an app, but if you run into a problem, searching on the vendor’s support site, forums, or even giving them a call can often be the fastest way to discover if there is a known issue.
Where we have found that we can help is if we’ve discovered a previously unknown issue. Debugging is hard, and the finger pointing of “She broke it, no he did, no she did” is annoying. We have engaged, and will continue to engage, in application compatibility investigations to discover the root cause and make a productive conversation with the vendor to more quickly resolve the issue. On other words, “Here’s the problem, it’s understood, here’s how we can fix it.”
Wrapping things up
You’ll notice that I didn’t end up getting technical in a post about remediation—and that’s on purpose! These first few steps (we typically group them together as “vendor research” on flowcharts) end up resolving a huge number of the issues discovered and, by following them, you can save yourself a lot of time in a debugger looking for the root cause of something that is not root caused. (I guess that’s good practice in debugging though…) These steps are often easy to forget and, if you notice that you’re finding that a lot of apps are not up to date, it’s worth quantifying and looking at your software asset management workflows to understand if perhaps you have an opportunity to get ahead and move from reactive to proactive app management.
Microsoft
