<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Application compatibility.. No longer an issue?	</title>
	<atom:link href="https://blog.myvirtualvision.com/2013/06/12/application-compatibility/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.myvirtualvision.com/2013/06/12/application-compatibility/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=application-compatibility</link>
	<description>My thoughts on application delivery</description>
	<lastBuildDate>Thu, 13 Jun 2013 09:14:20 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>
		By: Remko Weijnen		</title>
		<link>https://blog.myvirtualvision.com/2013/06/12/application-compatibility/#comment-486</link>

		<dc:creator><![CDATA[Remko Weijnen]]></dc:creator>
		<pubDate>Thu, 13 Jun 2013 09:14:20 +0000</pubDate>
		<guid isPermaLink="false">http://blog.myvirtualvision.com/?p=1966#comment-486</guid>

					<description><![CDATA[I think that App Compat will become more important than ever because the legacy platforms  that we&#039;re using to deliver incompatible applications (Windows XP, Server 2003, XenApp 5) are finally EOL.

This means we need to choose: bite the bullet and migrate those Apps to current platforms (x64, UAC etc) or replace them with well written Apps.

In an ideal world we would push Vendors hard enough to fix their CRAPplications or convince the customer to replace them. This depends on the Vendor&#039;s cooperation though and IT should be in control to enforce it. Sadly this isn&#039;t always the reality. The difficulty is often that the business sees the App from a functional point of view where it might work brilliantly. 

I guess we’ll always have some legacy applications around for whatever reasons…
We need to make a choice: do we deliver those Apps from non-supported platforms? Or do we apply mitigations, shims or even patches so we can deliver them from supported platforms? 

Either way we&#039;ll be on our own because we don&#039;t have vendor support for the Apps or no Vendor support for the OS. As IT, do you really want to be responsible for an OS that no longer gets security updates?? That’s a big risk for your whole environment! I’d rather run an App no longer supported by the Vendor but on a secured and supported OS.

As an extra argument for that choice: I am assuming that if we did have proper vendor support, they would fix the App in the first place. If they didn’t, what’s their support actually worth? 

So my personal choice is to run the App on a supported platform, even if this means we need to apply (serious) mitigations.]]></description>
			<content:encoded><![CDATA[<p>I think that App Compat will become more important than ever because the legacy platforms  that we&#8217;re using to deliver incompatible applications (Windows XP, Server 2003, XenApp 5) are finally EOL.</p>
<p>This means we need to choose: bite the bullet and migrate those Apps to current platforms (x64, UAC etc) or replace them with well written Apps.</p>
<p>In an ideal world we would push Vendors hard enough to fix their CRAPplications or convince the customer to replace them. This depends on the Vendor&#8217;s cooperation though and IT should be in control to enforce it. Sadly this isn&#8217;t always the reality. The difficulty is often that the business sees the App from a functional point of view where it might work brilliantly. </p>
<p>I guess we’ll always have some legacy applications around for whatever reasons…<br />
We need to make a choice: do we deliver those Apps from non-supported platforms? Or do we apply mitigations, shims or even patches so we can deliver them from supported platforms? </p>
<p>Either way we&#8217;ll be on our own because we don&#8217;t have vendor support for the Apps or no Vendor support for the OS. As IT, do you really want to be responsible for an OS that no longer gets security updates?? That’s a big risk for your whole environment! I’d rather run an App no longer supported by the Vendor but on a secured and supported OS.</p>
<p>As an extra argument for that choice: I am assuming that if we did have proper vendor support, they would fix the App in the first place. If they didn’t, what’s their support actually worth? </p>
<p>So my personal choice is to run the App on a supported platform, even if this means we need to apply (serious) mitigations.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
