<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>JimMoyle.com &#187; App-V</title>
	<atom:link href="http://www.jimmoyle.com/tag/app-v/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jimmoyle.com</link>
	<description>An insight into the world of desktop and application delivery</description>
	<lastBuildDate>Fri, 16 Jul 2010 15:11:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Where&#8217;s my MSI?</title>
		<link>http://www.jimmoyle.com/2009/06/where-is-my-msi/</link>
		<comments>http://www.jimmoyle.com/2009/06/where-is-my-msi/#comments</comments>
		<pubDate>Thu, 18 Jun 2009 20:45:43 +0000</pubDate>
		<dc:creator>Jim Moyle</dc:creator>
				<category><![CDATA[MSI]]></category>
		<category><![CDATA[Admin Studio]]></category>
		<category><![CDATA[App-DNA]]></category>
		<category><![CDATA[App-V]]></category>
		<category><![CDATA[Application]]></category>
		<category><![CDATA[Application Virtualisation]]></category>
		<category><![CDATA[Best Practice]]></category>
		<category><![CDATA[Microsoft]]></category>
		<category><![CDATA[Streaming]]></category>
		<category><![CDATA[Terminal Server]]></category>
		<category><![CDATA[Tools]]></category>
		<category><![CDATA[VDI]]></category>
		<category><![CDATA[VMware]]></category>

		<guid isPermaLink="false">http://www.jimmoyle.com/2009/06/wheres-my-msi/</guid>
		<description><![CDATA[Small application vendors need to raise their game, it's no longer good enough to code an application, check it works on your local copy of XP or Vista and sell it to the customer.  Terminal services has been around fifteen years, and Application Virtualisation five years, these are no longer new technologies.  If I phone up a vendor and ask them what's the correct way to install their application on terminal services or App-V, I don't want to hear 'sorry that isn't supported'.]]></description>
			<content:encoded><![CDATA[<div>When implementing a new VDI or terminal server project, the biggest stumbling block is not usually the solution framework, be that VMware, Microsoft or Citrix.  It&#8217;s the applications.</div>
<div>It&#8217;s those odd one or two apps that have either been created in house, are cheap bespoke applications or an app so old that it&#8217;s ceased being developed and is now out of support.</div>
<div>If the application is old and out of support I can&#8217;t blame the vendors, it&#8217;s the customer who should never have gotten themselves into that situation.  It&#8217;s the other two situations that need to be looked at.</div>
<p>Small application vendors need to raise their game, it&#8217;s no longer good enough to code an application, check it works on your local copy of XP or Vista and sell it to the customer.  Terminal services has been around fifteen years, and Application Virtualisation five years, these are no longer new technologies.  If I phone up a vendor and ask them what&#8217;s the correct way to install their application on terminal services or App-V, I don&#8217;t want to hear &#8217;sorry that isn&#8217;t supported&#8217;.</p>
<div>In the past, I&#8217;ve had an application vendor hand me a ten sheet document with installation instructions for their app on TS, it went like this:</div>
<div><em>Create user X, </em></div>
<div><em>Assign Y and Z rights to User X</em></div>
<div><em>Install weird application service</em></div>
<div><em>Add User X to application service</em></div>
<div><em>Find Reg key HKLMSoftwareVendorxxxxxxxxxxxxxxxxxx-xxx-xxxxxxxxxxxxx and create DWORD value zzz <strong>IMPORTANT! see note</strong></em></div>
<div><em>Once all these steps are finished, run the application and click the buttons m through p</em></div>
<div><em><span style="text-decoration: underline;">Once done install the plug-in as normal.</span></em></div>
<div><em>note:</em></div>
<div><em>If you cannot find the regkey DO NOT install weird application service, create ODBC connection as shown on page 9</em></p>
<p><em>etc.<br />
</em></div>
<div>In my opinion the customer should have refused to accept this and asked the vendor to finish the application.</div>
<div>The reason that I want vendors to provide MSIs is that they have several advantages over other methods of installation:</p>
<ul>
<li>Database driven instead of script driven</li>
<li>The application is installed in an administrative context</li>
<li>MSI provides a standard package format</li>
<li>Transactional install and rollback</li>
<li>Customisation via MST files</li>
<li>Many tools available</li>
</ul>
</div>
<p>The tools part is starting to get really interesting, Apptitude have released their <a id="hpe." title="App-DNA" href="http://www.app-dna.com/">App-DNA</a> product, which will test whether your app is suitable for Citrix, App-V, Windows 7, x64 and more.  If you have an MSI, it only needs to look at the MSI tables, you don&#8217;t even have to install the application to get the report.</p>
<p>Acresso, the folks who make <a id="ijej" title="Admin Studio" href="http://www.acresso.com/products/as/adminstudio-overview.htm">Admin Studio</a>, have developed a new feature which allows direct conversion from an MSI to an App-V, Citrix Streaming or VMware ThinApp package.</p>
<p>Both the above technologies can drastically reduce the time taken to implement new application delivery methods.  To best take advantage of both tools you need applications provided in an MSI format.</p>
<p>The main reason that I have found applications not being delivered in the correct format is that organisations have not realised that it is vital that the IT department of any organisation is involved in the decision making process when it comes to purchasing new applications, at the very least they need to set the minimum standards required:</p>
<ul>
<li>The application should be provided in an MSI format</li>
<li>The vendor must suport multi user OS deployment</li>
<li>The vendor must support application virtualisation/streaming</li>
</ul>
<p>If you are an application vendor and it&#8217;s &#8216;too much effort&#8217; to support the above minimum standards, I would suggest you are cutting yourself off from a large and growing sector of the market.</p>
<p>If you develop applications in-house or are purchasing a bespoke product, there is no reason why standards should slip, apply the same set of rules to these as you would to an off the shelf product.  A bit more development time, is going to save you a whole lot of heartache in the future.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.jimmoyle.com/2009/06/where-is-my-msi/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Why is VDI changing into Terminal Server?</title>
		<link>http://www.jimmoyle.com/2009/05/why-is-vdi-changing-into-terminal-server/</link>
		<comments>http://www.jimmoyle.com/2009/05/why-is-vdi-changing-into-terminal-server/#comments</comments>
		<pubDate>Thu, 21 May 2009 22:05:09 +0000</pubDate>
		<dc:creator>Jim Moyle</dc:creator>
				<category><![CDATA[VDI]]></category>
		<category><![CDATA[App-V]]></category>
		<category><![CDATA[Citrix]]></category>
		<category><![CDATA[Streaming]]></category>
		<category><![CDATA[Terminal Server]]></category>
		<category><![CDATA[ThinApp]]></category>
		<category><![CDATA[VMware]]></category>

		<guid isPermaLink="false">http://www.jimmoyle.com/2009/05/why-is-vdi-changing-into-terminal-ser/</guid>
		<description><![CDATA[Why is VDI changing into Terminal Server?

It is, and I'm about to try and prove it to you.  Not only is VDI changing into Terminal Server it's been done through a series of entirely logical and yet very stupid choices.]]></description>
			<content:encoded><![CDATA[<p>It is, and I&#8217;m about to try and prove it to you.  Not only is VDI changing into Terminal Server it&#8217;s been done through a series of entirely logical and yet very stupid choices.</p>
<p>To work this out we need to start from first principles, way back in 2005ish.  We had many expensively maintained fat desktops, spare CPU cycles in the data center and a virtualisation layer.  This meant that we could take the fat desktops not already covered by terminal server (which only counted for around 20%) and move them into the data-center.  These new desktops would allow our users to install apps, personalise their OS, and IT could keep the environment stable.  People were saying things like &#8216;I can give my users local admin privileges!&#8217;.</p>
<p>That was the dream and it all sounded pretty good.  Then people realised that they would have to change cheap storage on the end point for expensive storage in the data-center.  Also it just seemed, well silly, to have 5000 copies of explorer.exe sitting on the SAN.  The advantages of data de-dupe were talked about, but the model that everyone settled on was a golden OS image, Citrix had Provisioning Server and VMware had linked clones.  Not only did this solve the high SAN demands, it enabled us to only update/patch one golden image and it worked for everyone! Double win!</p>
<p>So now we have thousands of users on one golden image, trouble is we need different application sets.  No Problem! said the industry, we have application virtualisation, it&#8217;s even a fairly mature technology, ThinApp, Citrix Streaming, App-V and all the rest.  Except not all applications are suitable for streaming, some have license requirements that rely on MAC addresses, some install drivers or services, etc. etc.</p>
<p>In any large organisation there are maybe 2% of these applications which are generally more than 10 years old, but that can&#8217;t be dumped.  Out of say six hundred apps that&#8217;s only twelve apps that need to be in the golden image, so we increase the number of golden images to twelve, and the rest of the applications are streamed.</p>
<p>So far so good, although with this golden image model, we have hit a snag, to allow users to install applications, we need to use block level deltas to save the personal information.  Over time these block level deltas can grow to the size of the original installation, ruining our nice SAN space saving ideas!  Not only that, when you update the base image you can&#8217;t reconcile the deltas, you have to throw them away.  That&#8217;s no good, you can&#8217;t give users a facility and then randomly remove their changes.  OK, lets lock down the OS, we can use a profile solution to save user personalisation using the file system (although obviously no user installed apps).  For a great explanation of block vs file see Brian Madden&#8217;s post &#8220;<a id="owjt" title="Atlantis Computing hopes to solve the " href="http://www.brianmadden.com/blogs/brianmadden/archive/2009/02/18/brian-dump-atlantis-computing-hopes-to-solve-the-quot-file-based-quot-versus-quot-block-based-quot-vdi-disk-image-challenge.aspx">Atlantis Computing hopes to solve the &#8220;file-based&#8221; versus &#8220;block-based&#8221; VDI disk image challenge</a> &#8221;</p>
<p>Lots of vendors already in the Terminal Server space, immediately said &#8216;We have a profile solution!&#8217; and Appsense, RES, RTO, Tricerat etc put out VDI profile solutions.</p>
<p>All of this worked great in the POCs and pilots, trouble is when it scaled up to 1000s of users we found that the power users who were moving gigs of VMDK&#8217;s around or working with large media files etc. meant we had to have REALLY expensive Tier 1 storage at the SAN, it became uneconomical to move those users to VDI so we left them on their fat desktops.</p>
<p>So where does that leave us on our big VDI project?</p>
<ul>
<li>Multiple users on an OS image</li>
<li>Application silos</li>
<li>Locked down desktops</li>
<li>Profile solutions from Appsense, RTO, RES etc.</li>
<li>Users limited to Task and knowledge workers</li>
<li>Oh yeah, print solutions from Citrix and ThinPrint.</li>
<li>Desktops accessed via RDP or ICA</li>
</ul>
<p>I mean what does that sound like to you?  To me it sounds EXACTLY like Terminal Server.  What we have done is taken a VDI dream and apply terminal server thinking to it, unsurprisingly, it&#8217;s now looking just like terminal server, but with extra licensing costs.</p>
<p>We need to apply some brand new thinking, there are vendors out there trying to do this, like the afore mentioned Atlantis, but before VDI really takes off we need to rethink a lot of things or Gartners prediction of <a id="eb7u" title="VDI being a $65 billion business  with 40% of the worlds professional desktops" href="http://www.connectitnews.com/usa/story.cfm?item=3173">VDI being a $65 billion business  with 40% of the worlds professional desktops</a> seems to be a long way off.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.jimmoyle.com/2009/05/why-is-vdi-changing-into-terminal-server/feed/</wfw:commentRss>
		<slash:comments>14</slash:comments>
		</item>
	</channel>
</rss>
