All about application delivery

and one more how to for shims – the thing is about redirecting registry queries. This you do with the shim “virtualRegistry” – the parameter is:

AddRedirect(Originalkey^Redirectedkey) blanks need to be filled with %20 so for example if you want to reidrect “HKLM\Software\with blank” to “HKCU\Software\Blank” you have to write:

AddRedirect(HKLM\Software\with%20blank^HKCU\Software\Blank)

A colleague (Peter Nap) released today this coooool tool for App-V support. Read the full article here

http://www.brianmadden.com/blogs/jeroenvandekamp/archive/2010/01/19/new-free-app-v-self-support-tool-and-make-friends-at-the-helpdesk.aspx

I think trimtransfer is a very cool technology. It is still somewhat slow but I like the idea that a system is checked on block level what is there and only missing parts are transferred. If this technology gets more mature bandwidth usage could be dramatically reduced. In Med-V it still takes about 15 minutes to transfer a Windows XP image so probably copying the image on a standard way could be much fast but the trimtransfer stresses the network much less. I would like to share this (I find) nice picture I created for a presentation which explains the method of trimtransfer.

App-V, Med-V, RDS, XP-Mode, Shims – when to use what???

I think there is a lot confusion out there regearding the question “when to use which solution to get an application running” – and this is what IT is about, or not? Delivering an application to a user to access data. So it is about the application and how to get it to the user in the most effective way. But there are so many technologies out there that you can get confused which solution you should use for which problem.

I would like to give a small summary about all the Microsoft based solutions that are currently hot and possible.

RDS

Well, I think nearly everyone here knows Remote Desktop Services also known as Terminal Services, aka known as Citrix Presentation server, aka VDI aka XenDesktop and we could continue this list. The basic Principe is that the application is running in the datacenter and only the graphics and mouse and keyboard entries are transmitted. The big advantage is, that you can run even big data ware house queries over a thin line. It comes to an end, if the data center is too far from the client. To far means hosting a data center in Europe and working on a device in Sulawesi. There the latency because of the pure distance becomes too high and it is not very nice to work whole day over such a line. Other limiting factors are rich contents with video and sound. Here the bandwidth consumption grows dramatically so that the former mentioned benefit is reduced. Yes – I know that there are protocols like HDX to improve this but all together rich media can be a pita.

App-V

App-V is a technology for application virtualization which includes application isolation and application streaming. The application isolation helps to eliminate conflicts between applications on the same system. The most used example is the use of different Java versions on one machine. With App-V you can isolate these Java Versions from each other and the dependant applications so that they can live in peace on the same system. I saw for example a terminal server environment, where 350 applications were running next to each other on one box. Without application isolation I can imagine that there would exist the one or other problem. The streaming part of application virtualization is a kind of a deployment solution. It is on demand, the user does not need to stop working and the system does not need a reboot. Nice feature – espacially reagrding maintenance different windows for dieffernt applications on the same box– but I think in enterprise environments the isolation is the more important faeture.

Med-V

This technology is a step further than App-V because it isolates the full operating system including the applications. The OS image is also streamed to the client but only the parts are streamed that are not existent on the local Operating System, so it can happen, that the streamed part has only a small footprint (for example if the basic OS is Windows 7 and the streamed OS is also Windows7). The Image can be centrally managed. Med-V is part part and licensed via MDOP.

XP-Mode

The XP-Mode is introduced with Windows 7 and is more or less a virtual PC that is running on the Windows 7 host and is integrates seamless applications that are installed on the Windows XP virtual desktop. It is the light version of Med-V I would say, because there are no streaming mechanisms to deploy the XP-Mode Image of round about 450 MB. The XP-mode is included in Windows 7 regarding licensing – it just has to be downloaded. The funny thing is, that the XP mode is more mature regarding integration because it uses RDP as display protocoll, while Med-V still uses the protocoll formerly developed by kidaro – thus the integration is a little bit more intutive (if you save something on the desktop you save it on the desktop of the real OS and not in the virtual OS.

SHIMS

Shims are designed to mitigate application compatibility issues with operating system versions. Shims for example can lie to an application that it is running on Windows XPSp2 instead of the real underlying OS Windows7. There are already round about 6000 shims integrated with Windows 7- mostly all my old favorite games are included! Wondered why some old famous gold star games run – then thank shims (which managment software is part of the application compatibility toolkit).

When to use what

After I shortly introduced the basic technologies, also knowing that I cannot cover all aspects in a blog (otherwise more than 10 years of experience would not be that much) I would like to give a hint when to use which solution.

Let’s start with Med-V and Windows XP-Mode, because the outcome of the technologies is quiet similar. The good thing is, that you can run old applications that run on Windows XP through these technologies on Windows7. But both isolate the application completely from the underlying operating system – so no real interaction between the local running applications and the ones that run in the virtual OS (except of clipboard).  Med-V takes also a tremendous time to synchronize (stream) the image. Yeah – it is fun to show an application running on Windows 7 in a XP Mode – but hey – the real challenge is to really integrate the application into windows 7 or Windows 2008! But exactly thi9s can be the use case. Imagine a business critical application that is only supported on Windows XP.  Then you cannot run the application on Windows 7, because mostly there is no one in the company who will take the risk if it is really a critical application. The back draws of these technologies are that you then need to manage two OS – the real one and the virtualized. Also the client hardware needs to be somewhat powerful to run the local OS and the virtual. Patch management is also somewhat difficult because the user will be confused if he has to accept a patch management on the local system and inside of the virtual machine.

Now looking at App-V – I only can recommend using it. I think it is sooner or later the standard for a lot of applications (also Office 2010 uses it if you want to evaluate the beta J). It reduces packaging times (sequencing), reduces testing because you don’t need to test the full build but more or less only the isolated application against the basic OS. If you also use the streaming part you can very dynamically deploy applications and so forth. You need MDOP licenses which pushes you into Software Assurance. If you are still in negotiation pay attention that you may buy out the right to use App-V if SA is canceled. Otherwise you are not allowed to use it, because it is a rental license model. Some customers ask me “should I use App-V or RDS (terminal services)?” I would say – use both because the technologies solve different problems. Ok in former times you solved application compatibility issues sometimes also with RDS by installing the application on a server and then publishing it. Because the application then runs on a different machine, it cannot harm the local desktop. But why then still use RDS? Because it helps you to run application over the WAN – so it helps you centralizing your applications and making them by that more robust, you can deliver faster applications, can reduce data centers and so long. Should I choose a terminal server or hosted desktop solution? Well – hosted desktop solutions (also called VDI) are much more expensive and much more complex. Currently I only see them as a complementary solution. Projects that we saw that do a full scale hosted desktop design will mainly run into financial problems. Why? Because the storage need will grow tremendous. Again why? Because most companies IT is not developed (strong?) enough to create golden images thus leading to that each user has its own virtual disk. So I would go mainly for terminal servers in a design, but not all applications are programmed to work on a terminal server. In my IT live honestly I saw only very few applications that will not run on a terminal server. With App-V you can again reduce these applications, because in App-V every user has his own user space. But you can also use SHIMS to help out with that. If for example an INI file is stored in system32 – no problem – redirect it via shims to for example %appdata% and make it by that user specific. So SHIMS cannot only help you to make an application work on Windows 7 but it also can help you making an application work on terminal server.

So to make a long story short. Use application virtualization – is suitable use first terminal services before vdi because of costs. Use shims to make an application work on Windows 7 or on terminal server if App-V does not help and as last solution use MED-V and XP-Mode only if you dont have MDOP (licensing). For sure this summary does not fit to all scenarios but should be a good estimation for most of them.

Comments and questions are very welcome!

There are two main ways how to manage updates on your Med-V images. The one is the old style – you just manage your image with the exitsting infrastructure. You use WSUS and SCCM or whatever  for software deployment and patch management. The second way is the med-v way. You update image and put it into your med-v infrastructure. Then the differences are transfered via trimtransfer to the end devices.  At the first glance I would say – use the existing environement. By this you dont need to change your processes and you dont need to build a second infrastructure ( well – this is the opinion from business perspective and not from the technical guy who thinks – yeah let me play with the new stuff). The question is, if the end users can handle this. Imagine a patch management on a virtual machine where you normally just see one application and not the full desktop. What would the user do if something will ask him to reboot. Or if the reboot is forced while the user works in the virtual application.  He will probably turn off all his apps and not the virtual one and will reboot his physical device. So I think using the traditinol way will give some additional headaches on the end user site.  So probably the new way is not the worsest one.

In Med-V you can define an IIS based image repository server.  A client checks if the image on the central place changed and if yes it downloads the changes vie trimtransfer. This means, that only differences to the image are downloaded and trimtransfer will also check on block level if certain blocks are already on the target machine – this saves a lot of bandwidth.

But what will happen if the user on the virtual machine that is updated will for example change somehting in an application? This will be normally stored in his profile on the virtual machine. Or if the user accidentially saves a file to the virtual hard disk. The data would be gone! Med-V will reset the local image to its default. So if you want to use a central image management solution you have to care, that no living data is on the virtual Windows XP.  You need for example a roaming profile for the virtual machine – well better use FlexProfiles I would say but this is another story.

again and again I hear that Med-V for Windows 7 is out.
NO, it is not!!!
MDOP for Windows 7 is out but Med-V is currently not supported on Windows 7. The Support will come with SP1 for Med-V 1.0 which should come in Q1 2010

(But my it runs on Windows 7 if you set in the MSI installation SKIP_OS_CHECK=1)

Today at a customer I wanted to show shims of the microsoft application compatibility toolkit (ACT5.5) with a redirectEXE shim. The redirectEXE shim kills the original exe and launches another executable (or better should). Here are some screenshots how to make your colleague mad by redirecting notepad.exe to regedit.exe

Create a new fix

Define a name for the fix and browse for the executable

Choose “none” because we want to define a special fix

Choose the redirectEXE shim and then press the Button parameters or ALT+P

Define the new executable (here regedit.exe, so if somebody wants to launch Notepad.exe regedit will be started)

Finish defining the shim – in the next steps you save the shim database and install it…

Save the database

Give the database a name

Define the path to the database

And finally install database. From now on you cannot launch notepad.exe anymore. Well at least this I thought but at my showcase it did not work. Why – I assume because my OS is Windows7. The exact same way works on Windows XP. So Probably the used ACT version 5.5 does not work with all shims on Windows7 yet.

Another point is for what you can use the redirectExe shim. A colleague of mine used it in former times for online patching of Terminal Servers. We had a customer with a very “update friendly” application. Every wednesday a new version came out and on thursday the emergency update. With the redirectEXE shim you could justr copy the new EXE on the server and redirect all new launches of the EXE to the new version. Doing this you dont need to kick the users….

—-

Some days ago a colleague showed me that redirectexe also works on Windows 7. And he figured out, that it is a problem with notepad – so it seems that redirectexe has a problem only with notepad   – thanks to Michael

we just had a road show and I demonstrated shims and we had the feeling, that shims are still very unknown in the market. Ever wondered why your old application (game) runs on a new operating system? It is mostly because Microsoft created a shim for it and included it into the operating system. What is a shim? A shim will redirect certain api calls of an application. With this technology you can for example redirect the saving of ini files from c:\windows to %appdata% or you can lie to an application and tell it that it is running on windows xp instead of windows 7. There are round about 6000 basic shims (a lot for games) that are also updated via windows update. You can build own shims with the application compatibility toolkit. More about shims soon here.

again and again customers are getting confused about licensing VDI based infrastrucutres. With vdi I mean virutal desktop infrastructures in general and I just want to look at the microsoft part of it. Every VDI solution needs Virtual Enterprise Centraliced Desktop (VECD) licenses. You may not just put your for example Windows XP license into the data center running virtualized on a server and using a thin client to access it, but you need to purchase a VECD license. There are two kinds of VECD licenses – one for customers with SA. The pay round about 23 $ per year (it is a rental license) and may then run 4 virtual instances on the same time – but you also need a valid license for your desktop operating system. Then there is also a VECD license for Clients, that have no license or no SA (Thin Clients or customers without SA). This license cost round about 110$ per year. The licenses are bound to a client device and may be changed to another device after 90 days of use or if the device breaks. So please calculate these cost in your VDI ROI! – and as I said – it is a yearly fee!