VM Junkie

February 25, 2011

View 4.6 and ThinApp 4.6.1 are out!

Filed under: thinapp, view, vmware — Justin Emerson @ 1:29 am

Good news, everyone!

After an agonizing wait for some of us in the know, View 4.6 is finally out as of an hour ago. This is not a super-huge release, but rather an incremental release that fixes a lot of bugs, but does add a couple pretty important features:

  • The Security Server can now proxy PCoIP connections. This was semi-announced as a feature back when Mark Benson made this post on the Office of the CTO blog.
  • (Experimental) Windows 7 SP1 support. Note that View 4.5 is not compatible with Windows 7 SP1, so don’t go deploying it to all your View desktops before upgrading your View Agents to 4.6!
  • USB improvements. Now (if you’re crazy) you can sync iPods over View’s USB redirection.

There’s also a few cool bits under the hood that make it work a bit better with things like Teradici’s new firmware 3.3 for their zero clients, as well as some enhancements that will become obvious in the next month or so when another client becomes available (which I’m not sure I can talk about publicly in detail).

So with that out of the way, what’s missing? Unfortunately, profile integration, such as any technology from the RTO acquisition, is still not included in View 4.6. We can only hope in the meantime that when the next major version of View comes out, we will see it or something like it included. In the interim, we’ll have to rely on solutions like LiquidwareLabs ProfileUnity, AppSense, or others.

And also as per usual, the new View release is accompanied by a release of VMware ThinApp, although in this case an even more minor update from 4.6 to 4.6.1. Primarily this release adds better support for Office 2010 and virtualized IE7 and IE8, but you can read the official VMware blog posting about it here.

August 31, 2010

VMworld sesson DV7180 – ThinApp Futures

Filed under: thinapp, Uncategorized, vmware, vmworld — Justin Emerson @ 3:17 pm

Cool highlights from this session, I’m going to skip all the pre-ThinApp 4.6 stuff since it’s old news:

  • ThinApp (as of 4.6) now does transparent page sharing for applications (like in TS environments) just like ESX does for VMs. Pretty neat!
  • In ThinApp 4.6 you can “harvest” IE6 straight out of an XP system and run it on Win7. Only WinXP specific file that gets put in the package is Shell32.dll, otherwise icons and menus don’t work correctly. The resulting ThinApp performs like IE6 SP1.
  • ThinApp Converter which is included in ThinApp 4.6 allows you to automatically build a package from an automated installer. You can take existing install packages (like from Wise, Alritis, or LANDesk) and convert them to ThinApp packages easily with a simple command line and a blank VM.
  • The futures stuff was talking about a new features called “ThinApp Factory.” It’s a prototype which can download RSS feeds of applications and automatically download the app installer, silently install it and capture the package using ThinApp Converter, and then publish it to users or allow users to download it from an “App Store” kind of thing. This will probably feed into the Horizon stuff they showed this morning in the keynote.

March 16, 2010

What’s new with ThinApp 4.5

Filed under: thinapp, vmware — Justin Emerson @ 10:45 pm

A lot of great features I heard about for ThinApp 4.5 when I was VMware Partner Exchange have been posted on the official ThinApp blog. I highly recommend reading it.
From what I’ve heard, ThinApp 4.5 is a total rewrite of the underlying ThinApp code (which has been mostly the same since the Thinstall 2.0 days) and as you can see from the article, the list of new features is staggering for a point-five release:

  • Relink
  • Improved MSI Support (>2GB MSIs)
  • I/O Improvements for VDI
  • Memory Sharing for SBC/Terminal Services workloads
  • Startup time improvements
  • Reduced bandwidth consuption
  • Quality reporting
  • Sandbox journaling
  • Improved AppLocker support
  • Improvements to WINE compatibility

Read the full article, but this is a really exciting release! You can download it here at VMware’s website.

April 6, 2009

VMware ThinApp in 20 minutes

Filed under: thinapp, vmware — Justin Emerson @ 12:21 pm

The fantastic Eric Sloof has just posted a great couple of tutorials on how to use VMware ThinApp over at his blog. I highly recommend checking it out – I think ThinApp is one of the most important pieces of any VMware View deployment.

And like a true Dutchman, he’s got some great Trance music to get you movin’.

Also, I’ll be posting a brief Part 3 to my WinFLP entries hopefully in a day or so with some more WinFLP-specific optimizations.

January 20, 2009

VMware View article at BrianMadden

Filed under: thinapp, vdi, vmware — Justin Emerson @ 1:27 pm

Roland van der Kruk over at BrianMadden.com has been writing up some articles about VMware View, his latest one has some conclusions at the end which I wanted to take issue with:

  1. Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
    This is not the case. The way a linked-disk in VMware ESX works is that the linked disk can only grow to the maximum size of the hard disk it was based off of. So a 20GB system disk fully provisioned is 20GB, and the maximum size of a thin-provisioned disk is 20GB. If Roland would like to test this, just use IOMeter to write a giant file to your system disk and see the size increase and stop.
    At the same time, you can specify at what size to automatically recompose a VM, so if it grows over, say 10GB you can automatically recompose it.
  2. If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
    This is correct, but this is clearly outlined in the documentation. The purpose of the User Data Disk (or just using Roaming Profiles of some kind) is to keep the user’s profile persistent between Recompositions. As for how you handle Applications, see below.
  3. What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
    This is only half-true. Any persistence made in user space are guaranteed by the recomposition. If it’s a change made to HKEY_CURRENT_USER, or to anything in Documents and Settings, it will be persistent across recomposition or refreshes.
  4. As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.
    This exact reason is why you cannot purchase View Composer without purchasing ThinApp. In order to make sure applications persist between rebuilds, as well as application settings and such, you need to use ThinApp (or at least some kind of Application Virtualization technology).

View Composer deployments do not make sense unless the base operating system is disposable. You have 4 components in any desktop:

The Desktop Blob

The Desktop Blob

User Data is handled by Roaming Profiles or the User Data Disk. Applications need to be either disposable (you can throw them out because they are stateless) or through App Virtualization. The hardware is just a VM hardware which is always identical or easily changeable. If those three things are taken care of, the OS itself is disposable, so a desktop recomposition should have no negative effects.

I will agree that View Composer is not perfect, but I think it’s come closest to the best possible solution available so far. That being said, you can ignore the whole recomposition options entirely and just use thin provisioned desktops, but they will grow over time just due to the way Windows writes to the filesystem.

On the upside, there is a really great session from VMworld which talks about performance and best practices for VDI which contains information on modifications you can make to a default Windows XP installation to reduce the amount of space that will be used by the OS at idle. Check out Slide 39 on the PDF.

January 5, 2009

Why ThinApp is revolutionary from a security perspective

Filed under: thinapp, vmware — Justin Emerson @ 1:28 pm

Hi everyone, I hope you all had a great holiday break and a happy new year. I took some time off myself, so in hindsight maybe I should have started the blog post-holiday! But them’s the breaks.

Today I wanted to make a post about ThinApp, and one reason why I think it’s so incredibly important for the desktop; one that few people seem to be pointing out. I’m going to take a leap of faith at this point and assume you’re somewhat familiar with ThinApp. If you aren’t, I highly recommend looking at some of the product info at the previous link, or the product documentation. There’s also an official ThinApp Blog at VMware.

Among ThinApp’s many strengths are surprise, fear application/OS independence, easy application updates and regression testing, and app compatibility. But I think one of the most important points about ThinApp is, somewhat by accident, it changes the permission paradigm for applications to talk to each other. Traditionally, in Windows and pretty much any OS, if you’re running an application, it has access to the other applications you have running. The simplest example of this is I want to cut and paste text from one program to another. Every program has access to the clipboard. What if my computer gets infected with a trojan and that trojan constantly monitors my clipboard for a number resembling a SSN or a Credit Card number?

There’s also much more sinister examples. It’s possible for any application you run to overwrite the memory of any other application you’re running (assuming one’s not a system process or running in another user context). This can be great – it allows applications to talk to each other directly and can give you some cool integration between different applications. But the security implications of it are that every app has full permission to every other app by default, with no real way to deny permission. This is why we run into many of the security problems (and for that matter, compatibility and stability problems) on modern desktops. When we see application vulnerabilities today, usually they scope of the vulnerability is everything the application has access to is potentially compromised. This means that browser remote code execution vulnerability can’t take over the entire machine (because it wasn’t the OS itself that was compromised) but there’s plenty of damage that can be done because for an application, the whole user session is the sandbox.

ThinApp changes this because each application gets its own Virtual OS (VOS) sandbox to play in. Depending on how you build your packages, you can make it so applications can’t see each other, and don’t even see their files. You can even isolate certain parts of the underlying OS from the application so it has no visibility into those areas. This is important because we are now limiting the scope of infection in the case of a security problem. The VOS is now the sandbox, as opposed to the entire user session. And even better, if you build your packages correctly, the infection can be removed simply by deleting the ThinApp sandbox.

The other implication of this is that ThinApp changes permissions between applications to deny by default. By bundling each app in its own ThinApp package, they can’t talk to each other anymore, potentially preventing many malicious or compromised applications for doing their dastardly deeds. Now, I say this changes things to deny by default, not just deny, because with AppLink what we’re essentially doing is granting permission for one application to talk to another.

This is really an important concept to grasp, I think, because from a security perspective this can mean a whole new world of permission granularity. Do I ever need this app to talk to this other app? If not, why do I leave that hole open for someone to potentially exploit? ThinApp reduces your exposure at the desktop in a way that just hasn’t been possible without application virtualization.

Blog at WordPress.com.