The Compatibility Gladiator

On Optimizing Large Deployments of Windows Analytics

Steve Thomas (MSFT) — Sat, 07 Jul 2018 21:06:19 GMT

One of the more crucial pillars to ongoing success with managing initial Windows 10 deployments, as well as ongoing WaaS (Windows as a Service) servicing is the ability to leverage organization intelligence and key data to optimize ongoing updates and servicing and get in front of potential issues before they become widespread and disruptive. Specifically, analytics - as of now: Windows Analytics.

Telemetry

Windows Analytics is built from telemetry. Telemetry has been the key to Microsoft understanding the true insights of Windows usage and the vast Windows application ecosystem in the consumer space. Microsoft then took these lessons to the enterprise making available the very tools that made us successful transition to WaaS available free for our enterprise customers. However, telemetry involves the transmission of data and there is a level of trust required from our customers (not to mention laws and regulations from various governments and compliance bodies. Microsoft has gone to great lengths to comply with all regulations even at times, suspending collection in order to make proper adjustments when needed. I would recommend the following resources for further reading:

Windows Analytics and privacy https://docs.microsoft.com/en-us/windows/deployment/update/windows-analytics-privacy

Learn about security and privacy at Microsoft data centers http://www.microsoft.com/datacenters

Confidence in the trusted cloud https://azure.microsoft.com/en-us/support/trust-center/

In addition, with versions of Windows 10 1709 and later, a special level of telemetry was created that allows you to submit additional telemetry beyond basic, but only that which is required specifically for Windows Analytics. This new value as well as all the other values are documented and regularly updated here: https://docs.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization Without telemetry, other metrics would have to be leveraged and have been in the past. These insights are often flawed depending on the metric. For example, take support call volume – a common usage metric but it can be flawed in the sense that the products/components that are either the more difficult or defected are inferred to be used more. That is not always the case.

Telemetry Decisions

Due to the varying degrees of telemetry as well as the factor that certain analytical solutions have specific telemetry requirements, the assumption is made that your organization’s various privacy, governance, and legal stakeholders have signed off on a telemetry level adequate for use as it is obviously a fundamental piece of an analytics solution. Microsoft has listened With this , it also important to note that recent factors involving the GDPR play into this as now in European Union nations, there are certain data types that cannot be collected regardless of organizational decisions and those limits are now reflected in the telemetry engines as well.

The Upgrade Readiness Deployment Script - A *Pilot* Script

One useful piece of the Analytics onboarding process is the Upgrade Readiness deployment script. While truly only a real pre-requisite for piloting Upgrade Readiness, it is a great start to evaluating Windows Analytics in a PoC or Pilot environment while at the same time, learning what additional configuration items might be required at scale for your wider deployment (proxy configuration, client telemetry engine updates, etc.) The script is very useful in the pilot phase as it allows you to get in front of any potential large scale issues that may be cumbersome to trouble once widely deployed. What the script essential does is:

Verifies that the Telemetry engine and specifically AppRaiser Module are up to date: This is crucial not only on down-level clients (Windows 7 and 8.1 but also older Windows 10 clients.)
Connectivity: Verifies that connectivity to the telemetry cloud endpoints. In addition, also verifies appropriate access through proxies both authenticated and unauthenticated.
Setting the Corporate ID: Crucial in order to get the information into the right Analytics tenant.
Setting Telemetry Levels and Options: Setting the appropriate level needed depending on solution(s) leveraged.

Finally, the script culminates in a collection and uploading of a full set of telemetry data dependent on telemetry level.

Deployment Pushing out a script can be avoided at scale in favor of more optimal configuration management. While the script also uploads insights regarding script successes and failures, those insights are more useful during piloting for identifying potentially common causes of deployment failures – most commonly pending reboots – which is one of the items checked in the onboarding script. As documented in https://docs.microsoft.com/en-us/windows/deployment/update/windows-analytics-get-started now scaled deployments can leverage management infrastructures to stamp these configuration items on windows endpoints.

CommercialID Value
AllowTelemetry Value (Windows 10)
Optionally setting the LimitEnhancedDiagnosticDataWindowsAnalytics value (1709 and later)
Setting the AllowDeviceNameInTelemetry (Windows 10) parameter. For Windows 10 1803 and later, this value must be explicitly set to ensure device name is collected.
CommercialDataOptIn (Pre-Windows 10 Clients)
IEDataOptin (if using Site Discovery)

In lieu of the deployment script, you can also deploy this configuration at scale using your current management environment including:

Group Policy: The old-fashioned way. Ensuring the Proper ADMX has been imported, the path is Computer Configuration – Administrative Templates – Windows Components – Data Collection and Preview Builds.

MDM via the Policy CSP: The reference is here: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider Specifically, the primary items are:

OMA-URI -> ./Vendor/MSFT/Policy/Config/System/AllowTelemetry

OMA-URI - /Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID

Configuration Manager (1706 and later.) Full information here: https://docs.microsoft.com/en-us/sccm/core/clients/manage/monitor-windows-analytics The process is pretty straight forward: • Create NEW - Client Settings - Windows Analytics • Then apply the settings via Custom Device Settings Then, ensuring the scheduled tasks are in place to establish that there is a periodic full upload of telemetry. Upon deploying the script, you might have noticed the scheduled tasks including these commands:

 CompatTelRunner.exe -m:generaltel.dll -f:DoCensusRun
 CompatTelRunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun ent

A full sync of telemetry data for analytics happens under the following conditions:

When a new version of appraiser is installed (i.e. if the machine installs a monthly Quality Update. However the cadence for updating the AppRaiser module is usually every 2-3 months.)
or
When you run those two commands as System (via Configuration Manager or other management system:)
CompatTelRunner.exe -m:generaltel.dll -f:DoCensusRun
CompatTelRunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun ent
or
Finally, re-running the UR Script will also automatically upload a full data set.

On the Art of Predicting Compatibility Regression when Assessing Risk

Steve Thomas (MSFT) — Fri, 09 Mar 2018 22:08:44 GMT

In my last blog post: (https://blogs.technet.microsoft.com/gladiatormsft/2018/02/20/determining-an-applications-impact-when-assessing-risk/) I discussed my first recommended vector for assessing an application’s risk: impact to business or organization. In this post, I will discuss the second recommended vector: probability of regression. Internally at Microsoft, we refer to these as technical blockers. Throughout the first 5 iterations of Windows 10, we’ve been able to get a good grasp on the overall potential for application compatibility regressions in terms of predicting potential blockers. Over the next 2-3 months, you will likely see more specific guidance in those areas coming from myself and other experts in the compatibility space. These technical factors should be incorporated into an overall organizational strategy for assessing regression probability specifically tailored to your organization. In general, we’ve learned that Major-Version-to-Major-Version compatibility has drastically improved over the last few releases of Windows. Significant decisions were made and for the purposes of making the Windows operating system more stable and secure, the Windows XP to Windows 7 upgrade (well, technically Vista too) broke a lot of applications. You will hear ranges from 25% to 50% depending on the application portfolio’s age and technologies leveraged. For Windows 7 to Windows 8.1 as well as Windows 7 to Windows 10, the percentage was less than 10% even as a worst-case scenario (assuming applications were properly remediated & no technical debt was retained.) For those customers who have been canaries in the coal mine and have traveled with us for these first iterations of Windows 10, the percentage of technical compatibility regressions between feature releases have been extremely low in comparison (around 1-2%.) It *IS* important to point out, however, that even if the percentage is low, if an application critical to the business falls in the bucket, it is still a blocker – which is why we preceded this post with the previous with the one on business impact. J Factors Determining Regression Probability Organizations often promote applications to the top of the list with histories of regressions: Internal Test History Data: Pre-Windows 10, test history does not span more than 3 or 4 operating system major upgrades although many organizations treated Service Pack Upgrades in the same manner. For example, an internal LOB (Line of Business) application developed in 2000 [NOTE: These are not nearly the oldest apps out there] might have been thoroughly regression tested for at least these operating systems with these example initial testing results:

Windows 98 - PASS
Windows 2000 Terminal Services SP1 – FAIL [Remediated]
Windows 2000 Terminal Services SP2 - PASS
Windows 2000 Terminal Services SP3 - PASS
Windows 2000 Terminal Services SP4 - PASS
Windows XP - PASS
Windows XP SP1 - PASS
Windows XP SP2 – FAIL [Remediated]
Windows XP SP3 – FAIL [Remediated]
Windows 7 – FAIL [Remediated]
Windows 7 SP1 - PASS
Windows 2003 Terminal Services - PASS
Windows 2003 Terminal Services SP1 - PASS
Windows 2003 Terminal Services SP2 – FAIL [Remediated]
Windows 2008 R2 RDS – FAIL [Remediated]
Windows 2008 R2 RDS SP1 - PASS

In the above scenario, three out of eight or 37.5% of the time, it fails warranting it to likely be elevated to a higher risk category. Dependent Middleware Regression History: In some cases, groups of application sharing common middleware might get hit with periodic regressions simply when these middleware or component dependencies are patched. For example, I recently visited a customer who had a few examples of and Office-integrated LOB application that was broken after the following MDAC (legacy ODBC data access) patches:

Q823718 Update
Q832483
KB92779
KB954326 Update
KB952287
MDAC 2.8 SP1 Update

In this customer’s case, as in most, it’s difficult and too much overhead to track percentages so only patches where regressions occurred were noted. However, 6 patch regressions across the lifetime of the application in question (in this example 17 years) was enough to warrant elevation of risk priority when coupled with the impact ranking. Known Technical Factors When the Windows operating system evolves, efforts are made on multiple fronts to ensure compatibility. One of the most prominent is providing methods within the operating system to maintain compatibility through technical means that is seamless to the user. In most cases this is automatic (as in recent releases of Windows) although in some cases it requires tweaking and configuration on the application managers part. Another front is through developer evangelism where encouragement to use modern development technologies and platforms ensures better odds at ongoing compatibility. This is part of an ongoing pledge to make Windows 10 the most compatible Windows operating system to date. So far, the numbers are proving that out with greater and greater improvement as subsequent releases of Windows 10 evolve (going into our sixth 1803 as of this writing.) There will be exceptions alongside of those that fall into a single-digit percentage of overall applications. Those exceptions and elements that fall into that small percentage of issues include:

Application which rely on kernel mode drivers (filters, devices, etc.)
Security Software: Often because of drivers.
3^rd-party firewalls/Win32 VPN Clients: Also often because of drivers
Use of Undocumented APIs

These technical risk factors will likely elevate the application to a higher prioritization for testing. Retention of Technical Debt One of the most important (and only major) exception to the Windows 10 ongoing compatibility vector revolves around retention of technical debt. We refer to the term “technical debt” to describe those applications which leveraged some type of last-mile technology that allowed you to “punt” [to use an American football reference] and borrow more time. Doing this creates technical debt that will need to be paid at some point and their will be a cost to servicing that debt. In many cases extending the life of that mortgage could create costs that could exceed retiring that technical debt earlier. For example, we’ve seen cases where the cost of limping along an application for extra years exceeding the cost of redeveloping the application – hence the analogy.

Remaining on legacy operating systems through Custom Support Agreements
Moving to Session Hosts (large example of this was extended XP-compatible application into 2015/2016 using Server 2003 Terminal Services.)
Leveraging virtualization or containerization technologies to provide compatibility through emulation or OS virtualization (i.e. in-line virtual machines.) to preserve older applications.
Turning off UAC: This was a large one leveraged for Windows 7. Turning off UAC in Windows 10 is unsupported and untested [and will likely break a lot of other things in Windows 10.] If your organization resolved a lot of Windows XP/Windows application compatibility issues by turning off UAC, you now will have to deal with truly remediating these application issues.

In the scope of application compatibility testing, these applications will need to be tested early and here’s the bad news: many will likely need remediation. The good news is that if the remediation is solid, it will likely not run into further compatibility issues during iterative feature updates if the technical debt is truly retired. This will allow many to possibly be placed in lower risk groupings.

Determining an Application's Impact when Assessing Risk

Steve Thomas (MSFT) — Tue, 20 Feb 2018 04:12:32 GMT

In my most recent blog (https://blogs.technet.microsoft.com/gladiatormsft/2018/02/14/leverage-a-risk-based-approach-to-application-compatibility-testing/) I discussed how successful shifts to managing application compatibility involve moving to a model that prioritizes testing according to risk factors. The model I usually recommend to customers is to apply a common two-dimensional graph based on two primary risk factors: Impact to business and the application's likelihood of breaking. Both risk factor topics involve their own separate discussions which for me, warrants an additional blog post discussing each more in depth. For today’s discussion, I would like to dive further in how organizations determine an application’s impact to their business and ultimately, their bottom line. I do not necessarily advocate a one-size-fits-all prescriptive guidance approach as that would be very difficult to implement across different types of organizations due to degrees or variance including industry and cultural factors. The right way to assess an application’s impact to the business is the approach that 1.) Properly and accurately assesses the application’s impact while 2.) allowing the stakeholders responsible for ongoing application compatibility testing to rationalize the testing priority properly allowing 3.) the deployment and servicing schedules of Windows and its feature updates to continue unabated. In other words, ensures that you place the applications most critical in early testing rings well in advance of the broader deployments. The “Functional Spec” Approach The most common and simplest method of determining an applications impact is also not the always the most accurate assessment. However, it can still be used as a starting point for narrowing down the filed of applications that will need a more through assessment. It is nicknamed the “Functional Spec” approach because it follows a P0/P1/P2 ternary approach to grouping applications as if one were group features in a functional specification document. It is also simple to grasp. Is this particular application a:

Must Have?
Nice to Have?
Don’t Care?

Again, getting all the applications that we either do not care about or even further, do not want, out of the priority list, is a great first step toward rationalization. This, however, as an end-all be-all approach is flawed in that it does not cover all variables that could apply to the overall risk factor of true impact. It can also fall prey to subjectivism much more easily – especially if not all the correct stakeholders are involved in the process. The Approach that Ranks by Number of Deployments or Users A variable that can never be ignored is the number of deployments of the application. Unfortunately, this type of data collection implies the number of users that use that application which is not always the case. For example, we’ve discovered internally through our own internal research within Microsoft that an application might be placed into a standard image but only actually be used by ¼ to 1/3 of the user base. A standard inventory of all end-user devices will return 100% deployment, but only deeper telemetry can attest to if the application is being used and how often. Barring deep analytics, deployment counts are the only thing most organizations must rely on when determining who uses what application as traditionally, much of the applications are still Win32 applications distributed and inventoried by device rather than by user. In most cases, even if the device is targeted implicitly (because a targeted user is logged on to that device) the application is installed and remains there upon that user logoff for other users. In addition, unless the devices are identified as being part of a specific business unit and the application is targeted specifically to those device groups, it is difficult to ascertain without deep analytics which business units use a specific application. Still, deployment counts matter. And should probably be included in how your organization determines the impact of an application. It just should be a variable and not the approach. True Impact Factors True impact factors are those applications that warrant automatic elevation to a high or critical risk pool. The types of factors often include and application’s: Alignment with Revenue: Does the application have a direct or indirect relationship to revenue? Is the application critical for production or operations of a critical business unit tied to production or revenue? Understand the concept of “production,” “operations,” and “revenue” will vary across industries. A point-of-sale application is more critical in retail organizations while an IT service application is more critical with a service provider that must meet specific SLAs (Service-Level-Agreements.) These applications are almost always elevated into a critical risk pool. Alignment with Compliance or Regulation Requirements: Applications that are in place to maintain data, implement processes and procedures, or audit/measure factors to confirm to various requirements. Non-compliance or violations could lead to fines or other unthinkable results. These applications are almost always elevated to a high risk or critical risk pool. Alignment with Political or Executive Factors: This might be a sensitive one to quantify as the risk varies according to internal tribal policies. For example, there might be an application that only 10 users use, but all those users have titles that are TLAs (three-letter-acronyms) that begin with C. Since any risk factor that could potentially involve someone losing their job is critical or high, sometimes these applications are elevated into a high or critical risk pool. User (HelpDesk) Impact This is more than just angry or annoyed users. Maintaining and training helpdesk staff can be a costly task for large organizations. This is why, in many cases, an application’s user impact weighs as significant importance as factors previously mentioned. For example, an application may encounter a regression where an annoying pop-up might interrupt the user when they click on a specific menu item. The message and outcome might be benign, and it boils down to being merely a cosmetic inconvenience as opposed to a true functional defect. However, if 85% of the user base uses this application and the issue creates a scenario where a significant percentage of them might not realize it is a benign error, work stoppages occur and help desk calls are generated create impact and additional costs to the organization’s bottom line. Which is Best? The simple answer is some or all the above. A slew of variables can be used to calculate an applications true impact, but remember, this needs to be a true assessment of impact to the overall business and emotions need not be a part of the process. I use an exercise with customers during workshops involving these variables as they might apply to a randomly selected subset of applications from an internal portfolio. It is a worthwhile exercise to go through as you discover how much time and resources may have been wasted on unnecessary testing in the past. This, of course, is only part of the process. In my next blog post, we will discuss the other important risk vector – the likelihood of an application breaking when testing a new version (feature update) of Windows.

Leverage a Risk-Based Approach to Application Compatibility Testing

Steve Thomas (MSFT) — Wed, 14 Feb 2018 23:43:49 GMT

Once upon a time, application compatibility projects usually followed these basic tenets: 1.) Find all the applications being used. 2.) Rationalize as much as possible. 3.) Thoroughly test as many as possible. 4.) Repackage all the applications. Depending on the size of the portfolio and the number end-users, these projects lasted from 9 to 12 months on average – longer for large organizations. Each project had a definitive start date and finish date (which often slipped.) The amount of time it took along with potential slippage of dates was never a major issue when the average operating system migration took place every 5 to 7 years. Times have changed. Shadow IT has creeped into the enterprise and innovation within this world has created a desire for faster feature delivery. Combine that with the ongoing agility of cloud products beginning with minimum viable products that continuous expand their feature set, and the traditional delivery of Windows does not make the most sense going forward for most enterprises. Like Office, Azure, and Intune, the Windows service delivery has evolved with WaaS (Windows as a Service.) Instead of drastic operating system updates every few years, more gradual feature updates occur on a semi-annual basis. This warrants a paradigm shift in the world of application management – especially managing compatibility between these gradual operating system updates. The classic project management method of application compatibility just will not work because it 1.) Takes too long and 2.) is often littered with unnecessary work and redundancies. A Risk-Based Approach First introduced in 2016 by Chris Jackson, the recommended approach to application compatibility going forward is a risk-based, ongoing, iterative one. The iteration part is easy to grasp because it basically looks on paper as if there will always be some sort of application testing going on, be it for the current release for some applications, or the next release for the more critical applications. The primary purpose of adopting a risk-based approach is to ultimately determine how and when you will test an application for compatibility with the next feature release. In the case of WaaS, while the critical applications are still thoroughly regression tested, the others might be relegated to simple smoke (ILT – Install-Launch-Tested) or automated testing or even reactive testing (test in Pilot or do not test at all.) Solutions such as Windows Analytics (or partner solutions) can automate and reconcile supportability for a vast amount of commercial vendor (COTS) applications. This can cut down on the time it takes to inventory and rationalize applications. In addition, applications that have been verified as adopted or supported can be relegated out of the critical space in many situations. But what about the rest of the portfolio? How do we get an accurate assessment of how important it will be to test that application? One recommended approach is to adopt a very common risk management practice of leveraging a simple x/y graph where the variables are impact of regression to the business and the probability of regression. The higher of each, the more critical the application and the more necessary it will be to regression test that application. The probability of regression is rooted in history as well as application composition. How an application impacts a business or organization will vary especially across different industries so there is not really a cookie-cutter one-size-fits-all approach to calculating an application’s impact to the business. It will be a potentially difficult process at first yet it will be one that, if implemented properly, will be a permanent risk profile for each application’s lifecycle and adjustments to risk profiles will only need to be managed as new applications are introduced and old ones are retired. Thoughts on Repackaging Bear in mind that for the majority of WaaS Feature Update scenarios, IPU (In-place Upgrades) will be the approach organizations will adopt if they are on a cadence of upgrading every 6-12 months. Operating system deployment images and provisioning packages will still be updated and maintained for new devices, but for the existing devices, the applications will already be installed, and the operating system will be only experiencing a minor in-place upgrade. In most cases, there will be no reason to reinstall and there will be no reason as well to repackage an application unless the purpose of repackaging is to modernize the application for newer delivery mechanisms such as leveraging the Desktop Bridge to bring an application to the Windows Store. The Tenets are Evolving As the deployment and servicing of Windows has evolved so have approaches to managing application compatibility. What we are finding that works well for customers who are able to stay current with Windows and Waas, is an application compatibility management approach that adopts these tenets: 1.) Leverage tools and telemetry to discover and inventory, and even rationalize. 2.) Rationalize into risk profiles. 3.) Test according to risk profiles. 4.) Don’t repackage applications for the sake of repackaging.

How Detailed is Your Enterprise Application Catalog?

Steve Thomas (MSFT) — Tue, 13 Feb 2018 04:51:23 GMT

Over the past several years, I have been involved in many application projects. Whether the project was centered around packaging, virtualization, or compatibility testing for operating system migrations (as my specialty is now) a variable for success was and remains – the enterprise application catalog. You’ll read synonyms for this as well (including package store, app store, app catalog, app inventory, etc.) but the key commonality is solid information about the application’s owner, assets, and documentation. Unnecessary delays in application projects are often rooted in poorly detailed and incomplete catalogs. It is hard to test an application if the application installer is unable to be located. That would seem to be a very unlikely problem at first glance, yet the larger an organization grows; when the organization merges with other organizations, or when users are granted administrative control of their devices and workstations, organizations wind up spending the first significant portion of their application project simply funding out what they actually have. It is also hard to verify that an application has been signed off on UAT (User Acceptance testing) if the application has no owner or responsible user. Before undergoing any type of major application management transformation project, portfolios need to be reconciled as thoroughly as possible. It is most crucial to get this house in order during the shift to Windows 10 and Windows as a Service (WaaS) as application compatibility management will be ongoing and iterative. I would encourage you to read Chris Jackson’s blog post on the subject (https://blogs.msdn.microsoft.com/cjacks/2016/09/12/windows-10-app-compat-strategy/) if you have not already done so. COTS The inventory of what we call COTS or Commercial Off-the-Shelf (or ISV Apps - Independent Software Vendor Apps) is often flawed in that it is assumed there need only to be thorough to the point of identifying vendors and vendor contacts for the applications. Microsoft Windows Analytics (via Upgrade Readiness - https://docs.microsoft.com/en-us/windows/deployment/upgrade/upgrade-readiness-get-started) can easily automate the collection of this information as well as additional supportability and adoption metrics, but what the tool cannot do is assign proper categorization, determine appropriate application owners, or designated subject matter experts (SMEs) for testing. That information is internal and will be needed for those critical off-the-shelf vendor applications which may need frequent testing. LOB Line-of-Business applications or LOB apps, are those applications that are developed internally within your enterprise organization. Cataloging this information is critical starting with flagging it as internal either explicitly or implicitly by using your company name as the vendor. Segmenting the applicationss for which your organization owns the code/IP from those owned by vendors is the first major step in adopting a modern approach to rationalization. A significant amount of rationalization can be achieved with analytics but most of the critical testing will likely apply to LOB applications. Identifiers (Name, Vendor, etc.) Applications are often erroneously tracked due to anomalies and discrepancies with the application name and the vendor being either mis identified or not identified at all. For example, when applications are being tracked for supportability at ReadyforWindows.com they are using the application name and vendor that is either associated with how the application is registered upon installation (in Program and Features) as well as how primary executables are identified and verified via digital signatures. Many organizations will elect to use the identifier from the executable file since in many cases, software may not always properly register itself in the “Programs and Features” Control Panel. In addition to an official name, organizations may also identify the application by an internal or tribal name. For example, Office 365 ProPlus may also be identified internally as Office 2016 for continuity purposes. This is usually not a problem so long as the official name is associated in the same record as the official name is what will be compared with analytical and static analysis compatibility software. Sometimes this tribal name may include references to a legacy vendor which owned said application in the past but has since been acquired. For example, when Invincea was bought by Sophos and was OEM rebranded by Dell, newer versions were branded with the OEM vendor, yet organizations still referred to it tribally by the old vendor name for the purposes of alleviating confusion and maintain vendor lineage. Version Separation It is also recommended that the applications version not be tied directly into its name as it is very likely that your inventory will include more than one version of the same application. This is especially crucial with vendor supportability determination. Again, analytical tools like Upgrade Readiness will take care of this job for you. Owner The Owner is one of the more critical pieces of information as the owner is either also the primary application subject matter expert, or is responsible for designating who that person is. Testers/SMEs The testers and subject matter experts may also be application stakeholders, or simply just representatives of the business group dependent on the application. In most cases when the owner and testers are not the same person, it is still likely the application owner who ultimately signs off on the validation of the application as being properly validated and production ready. Licensing Often applications have some type of license validation or software protection platform. Whether it requires a specific activation server or a license key, not having this information will obviously delay application testing if not included with the application record. Installation Logistics and Documentation In many cases, an application installer may be customized with a transform and repackaged or scripted to simplify deployment with a software distribution system. In many cases, these packages can be deployed as-is, however there may need to be scenarios where the application is traditionally installed and the original installers will need to be located along with any necessary installation documentation. Source Code If the application is an in-house developed LOB application, it should be noted if there is source code being maintained as this will be a critical variable should the application run into issue with compatibility or if the application is slated for further modernization. It is not uncommon to not have source code available. Companies acquire other companies. Companies re-structure their organizational charts and curtail redundancies during mergers and acquisitions. Along with employees leaving, sometimes source code leaves as well. It is a well-known open secret. It is just as important to confirm the absence of source code as much as it is to confirm its existence. Risk Rationalization To quote from Chris Jackson’s blog post referenced earlier: ((https://blogs.msdn.microsoft.com/cjacks/2016/09/12/windows-10-app-compat-strategy/) categorization according to criticality should be part of the ongoing portfolio rationalization. Whether it is in the form of 4 category taxonomy or a more “stoplight-oriented approach, a general recommendation chart is shown below for current recommended practices for category distribution:

App Compat Risk	Characteristics	Typical Distribution
Critical	Typically, complex custom development or highly customized commercial software. App failure can lead to loss of life or irreparable organizational harm. No acceptable workarounds for failure are identified.	2%
High	Typically, complex custom development or highly customized commercial software. App failure can lead to significant loss of productivity or ability to execute organizational mission. Workarounds can take days or weeks to implement, and/or come at a significant cost.	18%
Medium	Typically, commercial software that is current or a recent version, and is commonly used at other organizations using the target platform; or custom development following straightforward patterns. App failure can be addressed with reasonable workarounds that take minutes to hours to implement and which use standard helpdesk procedures.	50%
Low	Typically, commercial software that is up-to-date and supported on the OS you are moving to, or is custom development that was created and/or tested on the target platform. Vendor is accountable for remediating compatibility issues, or organizational mission can be accomplished without the software on a temporary basis. App failure can be addressed with simple workarounds through standard helpdesk procedures.	30%

Putting it all Together If, after reading this, you find you are not working with a complete and thorough inventory of an application portfolio [and you are a primary stakeholder of the application portfolio] the best advice is to get on top of this issue prior to a migration to Windows as a Service as this will be critical to getting current and staying current through ongoing Windows 10 releases.

Recent App-V Case Studies

Steve Thomas (MSFT) — Wed, 24 May 2017 20:53:15 GMT

Internally, I was recently asked if I had any examples of recent App-V Case Studies that other potential App-V customers could view. Many case studies have previously been mentioned on the legacy App-V team blog but those were for older versions of the product. Many of our customers are looking to find examples of App-V 5 and later deployments from various customers and that can be sometimes difficult navigating via the web. I maintain a list for myself and I thought I would share it out for other customers who may also appreciate these. Walsh Construction [2015] https://customers.microsoft.com/en-us/story/construction-firm-upgrades-older-applications-to-lates App-V was a part of a larger 2003 retirement where it was used for lifting and shifting RDSH apps to 2012 R2. Helena Montana Public Schools – Education [2016] https://customers.microsoft.com/en-us/story/in-montana-school-district-windows-10-and-office-365-are-always-classroom-ready App-V was part of a Windows 10/Office365 deployment where App-V was leveraged as the default delivery format for end-user student devices. IGate – Service Provider [2015] https://customers.microsoft.com/en-us/story/it-firm-simplifies-administration-provides-better-serv A global service provider leveraged SCCM/App-V Integration to deliver all application formats under a “single pane of glass” console. Humbolt State University - Education [2014] https://customers.microsoft.com/en-us/story/humboldt-state-boosts-it-productivity-increases-user-s Another example of App-V and MDOP increases productivity and ease of application management in the Education sector. App-V helped to reduce costs and simplify application customization. Hellenic Petroleum – Oil and Gas [2014] https://customers.microsoft.com/en-us/story/greek-oil-company-gets-help-upgrading-it-infrastructur A great example of the use of SCCM/App-V Integration in the Oil and Gas space to limit footprints of older applications to streaming to only those users who absolutely need them. UT-San Antonio – Education [2015] https://customers.microsoft.com/en-us/story/university-reduces-costs-with-streamlined-cross-platf1 UTSA leveraged App-V as part of a full Microsoft Virtualization Stack implementation. You may have noticed that many of the examples I cited were from the Education sector. That is not by accident as App-V continues to be a very popular fit in this space – particularly in environments where application asset and lifecycle management is crucial and often difficult.

A New MED-V Blog Post . . . Yes, for Real

Steve Thomas (MSFT) — Tue, 16 May 2017 05:25:10 GMT

For most individuals in my profession, any plans that were originally made for today were upended by the recent worldwide cybersecurity event. To assist our customers still on legacy systems, patches for the MS07-010 exploit were made available for Windows Server 2003 and Windows XP. While Windows XP has been out of support since 2014, a solution that still leverages the Windows XP operating system is still in extended support: MED-V 2.0. While MED-V 2.0 went out of mainstream support in 2016, it still follows the 5+5 policy and will remain in extended support until 2021 (https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft%20Enterprise%20Desktop%20Virtualization) however, as mentioned 5 years ago in this post (https://blogs.technet.microsoft.com/gladiatormsft/2012/07/29/how-med-v-affects-windows-xp-end-of-life-support-policy-it-doesnt/) the Windows XP Virtual Machine is not covered by the MED-V support policy and would only be covered by an custom support agreement (CSA.) Customers who may still be using MED-V ARE AT RISK from the WannaCrypt Ransomware threat and need to take immediate action as if they were still using Windows XP because they technically STILL are. This message is especially for those who may using MED-V without a Windows XP CSA. If you have not already done so, please download this update and deploy to your MED-V images: https://www.microsoft.com/en-us/download/details.aspx?id=55245

Resolving the App-V 4 - SQL Server 2008 R2 Supportability Conundrum

Steve Thomas (MSFT) — Wed, 05 Apr 2017 20:53:49 GMT

Over the past 6 months, I’ve had quite few customers coming to me with concerns regarding what they see as a potential supportability gap for legacy App-V 4 infrastructures. Their main concern lies with the fact that App-V 4.6 SP3 remains in support through July 2020 while SQL Server 2008 R2 (the latest version it supports) will go out of support in July of 2019, leaving a supportability gap of a year. “What is being done to address this?” “Will there be a patch similar to when Visual C++ 2005 went end of life for App-V 5?” The short answer is no. This is primarily because there is no supportability gap with SQL Server. App-V 4.6 SP3 still uses the App-V 4.5 Management system. There was never a 4.6 server release. Officially, 4.6 was exclusively a client release. While the App-V 4.6 client remains in support until 2020, the App-V server support ends in January of 2019 – before SQL Server 2008 SP3 goes out of support. The release of App-V 4.6 did not extend the 5+5 lifecycle of the server-side products. Here are the respective lifecycle dates for the products involved:

App-V 4.5 SP2 (Client and Server) – Ends 1/2019 - https://support.microsoft.com/en-us/lifecycle/search?alpha=application%20virtualization%204.6%20Service%20Pack%203
SQL Server 2008 R2 SP3 – Ends 7/2019 - https://support.microsoft.com/en-us/lifecycle/search?alpha=SQL%20Server%202008%20R2%20service%20pack%203
App-V 4.6 SP3 Client – Ends 7/14/2020 - https://support.microsoft.com/en-us/lifecycle/search?alpha=application%20virtualization%204.6%20Service%20Pack%203

This also means that those enterprises still using the App-V 4 management system have 18 months less to move over to either App-V 5 or leverage the App-V 4 client in either a stand-alone fashion or SCCM-integration for its last 18 months in support.

On Debugging Virtual Applications Part 4: The Case of the Missing Dump

Steve Thomas (MSFT) — Tue, 27 Sep 2016 20:15:41 GMT

I’ve been blogging lately (well . . . not exactly lately) about debugging virtual applications that misbehave - whether by hanging, crashing, or spewing some strange error message. In discussing the use of tools, one question I often get is the relationship of attaching the debuggers to the virtual application inside or outside the virtual environment. With App-V 5, it only matters in certain circumstances at the user mode level as virtualized applications work from a state-separated registry and file system that leverage the native file system and registry. When a developer is troubleshooting a virtual application that they have developed, or an IT Pro Debugger is attempting to reverse engineer an application issue, I usually recommend they attach to the virtual process as they would any other application at first. You may decide due to necessity or preference to attach a debugger or a tool to the virtual application process within the context of the virtual environment by launching it in the application’s “bubble.” You may want to be advised that once you do this, the debugging tool will also be running virtually and will behave accordingly. I bring this up due to an interesting issue that was encountered by one of our partners a while back: There was an issue with a plug-in to Internet Explorer causing it to hang shortly after the BHO had been triggered while running in standard isolation (i.e. no Dynamic Virtualization involved.) Given that the individual had developed the code for the plug-in, they wanted to capture a full user mode memory dump of the instance of Internet Explorer that was running virtually. The issue could not be reproduced in the developer’s environment so there was the usual suspicion of something environmental being a factor. Since standard WER (Windows Error Reporting) is somewhat limited by default, the customer was leveraging ProcDump -h to capture a user mode memory dump of the IEXPLORE.EXE process. Here’s the thing: while Procdump appeared to attach to and generate a dump successfully, there were no dumps to be found per the developer. Upon further inquiry, I found that the developer was doing the following:

Using C:\ as a target. This is not good on many levels.
Running ProcDump from a command prompt in the application’s (IEXPLORE.EXE) virtual environment.

While running it in the bubble was not necessarily a bad thing, I had the developer simply redirect the output to %TEMP% instead of C:\. The dumps showed up as normal. When asked why C:\ mattered, I told him that due to coupling factors (specifying an unexcluded folder, VFS Write mode, running as an administrator, and launching in the bubble, the dump file was treated as application state data and was redirected to the VFS CoW location. Upon a quick demonstration, it was discovered buried beneath the user’s VFS folder. I should note that there shouldn’t be any concern with regards to the usability of these redirected dumps. I will also note that upon repairing the App-V package in questions, the user freed up around 12GB of disk space. I guess they had been trying the ProcDump command quite a bit. J

Application Virtualization and Compatibility at Microsoft Ignite 2016!

Steve Thomas (MSFT) — Mon, 26 Sep 2016 00:21:19 GMT

Greetings all! If you are headed to Atlanta for #MSIgnite this year, I wanted to give you a heads up of some key sessions that will interest those of you looking specifically for application compatibility, App-V, and UE-V-related content. If you do not have a chance to see any of these in person, you can choose to later view the recordings (which I will post links to) or even catch some of them streamed live! AppCompat and WaaS, App-V, UE-V, IE EMIE, Office AppCompat, and UWP compatibility all are being covered at this event! I'm excited and will be there! Dave Falkus and I will be speaking on Friday discussing App-V, UE-V, and its incorporation in the Windows 10 Anniversary Edition! (BRK2207) BRK2125: Evaluate compatibility in Windows 10 and WaaS using telemetry driven insights – 9/28 (Wed) 9-9:45 EST https://myignite.microsoft.com/sessions/2763 Bring existing desktop apps to the Universal Windows Platform (Project Centennial) – 9/27 (Tues) 12:30pm - 1:45pm https://myignite.microsoft.com/sessions/2566 BRK2066: Bring existing web apps to Windows 10 with Hosted Web Apps – 9/27 (Tues) 2:15pm - 3:30pm https://myignite.microsoft.com/sessions/2576 BRK2207: Discover how App-V and UE-V align with an Evergreen Windows 10 – 9/30 (Fri) 10:45am - 12:00pm https://myignite.microsoft.com/sessions/3218 BRK4018: Fix web app compatibility with Enterprise Mode – 9/29 (Thu) 12:30pm - 1:45pm https://myignite.microsoft.com/sessions/2856 BRK4003: Discover Microsoft browser security and compatibility internals - 9/28 (Wed) 2:15pm - 3:30pm https://myignite.microsoft.com/sessions/2583 BRK3047: Secure Tier 2: hardening workstations and retiring technical debt – 9/29 (Thu) 9:00am - 10:15am https://myignite.microsoft.com/sessions/2584