0

Again, it will be all about the apps

Windows 10 and Server 2016 will arrive soon and with that we’ll also have some application and desktop migrations coming up again. Most software that will run Windows 7, Windows 8, Windows 2008 or 2012 will run on Windows 10 or Server 2016 as well. At least, I have played around with a bag full of applications and most of them did function as expected. Unfortunately not all the applications did run as expected. Sometimes it’s the way applications have been programmed by a vendor, sometimes there are restrictions built into the application package that were included during the building of the application package or virtual application. There might be other reasons why applications do not work that come around. Anyway, just like with any other Windows-version that has been introduced, in many projects the applications will cause headaches and delays.

Most companies and organizations are using some way of building application packages/virtual applications or have already been building their applications with their favorite tool. These application packages/virtual applications are made flexible installable and are being distributed using the company’s software distribution mechanism ready to be delivered to users, servers and or workstations. Very important is the quality of the application packages/ virtual applications. Quality nearly always is lacking, resulting in unwanted problems, error messages, but also unwanted behavior of the applications and desktop of the user.

This blog will talk about the fact that a stable, well performing desktop will for a big part depend on the quality of the packaged/virtualized applications and the process that is used to build these application packages / virtual applications.

Especially with a new operating system that is about to arrive, a new chance to do it right this time or at least to remind again when creating new application packages and virtual applications.

 

Applications

Applications, one of the most ‘forgotten’ parts in a desktop migration project or in an already available (virtual) desktop environment. People that often work in desktop migration projects know that they shouldn’t be forgotten and are usually one of the most important things within a (virtual) desktop environment.

  • How many applications are being used within the company?
  • Which application versions are being used?
  • Will the current application version run on the new operating system?
  • Who is in a technical and functional way responsible for this applications?
  • Are there any licenses available?
  • How does the application has to be installed?
  • How will the application be used by the users that will use it?
  • Are there any dependencies with other applications or is the application an application dependency itself?
  • How will the application will be delivered and provided to the users on the new desktop environment?
  • Are there any items that need to be personalized?

These questions are just some of the questions that need to be answered, before the application can be delivered to a user’s desktop, being a regular application package or a virtual application.

 

Application packaging/application virtualization

For those who don’t know:

Application packaging is the creation of re-usable installation packages that can be installed with little or without user intervention. An application package is meant to deploy applications as easy as possible.

Application virtualization is the separation of applications from the operating system without any installation and can be executed immediately when put on a desktop (with or without an application virtualization client). The application is installed in this virtual application.

 

Application packaging/application virtualization basics

Traditional (msi) packaging has become less in the past few years and is for a big part been replaced by application virtualization. But, knowledge of msi packaging still is necessary. Not just to package to the msi-format itself, but also applications that exist in companies or are being distributed by the vendors are available in this format. It’s important to know how to edit a msi package, how to use the command line parameters or how the internal msi- database is working in case of changing any particular msi database fields.

It‘s also important to know how a msi package has been built, how the msi and Microsoft Windows Installer mechanism works and which failings it has. A msi package is a file that is actually a relataional database. Inside this database besides the placement of registry keys, files, directories, services, environment variable (called the standard actions) there are usually also some custom actions that can be executed.

This custom actions may contain VB, PowerShell and other scripts, dll files, driver installations, license registration and so on. Customizations to the original installation that cannot be covered (or easily covered) with standard actions. This custom actions may contain some valuable information that can be also used when virtualizing an application. For example an application msi that holds the installation files and a way of installing a particular device driver or some licensing mechanism. Sometimes they are placed inside an msi. In case of the driver, this might be a way of driver installation that can be extracted from the msi database, including the files that are needed. The application itself can be virtualized and the driver can be installed outside the virtualized application. This is important because drivers are that part that cannot be virtualized.

There can be given a lot more examples and or reasons why also with application virtualization this knowledge about msi files is needed. Just to keep in mind!

 

Application Packaging and application virtualization as an art!

Not everyone is able to make a painting, never mind building a house. The people who can build houses, do have all kinds of different ways of to build it with different quality that’s being delivered. Also the packaging of applications are one example of this: not everyone can do it, does it in his own way and quality is depending on who builds this application packages.

Recently is visited a customer that seemed to know exactly how to virtualize applications. Just, Next, Next, Finish between the two snapshots they told me. Having about 200 applications to virtualize and already having made some virtualized application I really was wondering what their quality of the virtualized applications was. This quality can be measured in many terms, but definitely includes starting up and shutting down an application without any errors. Also, what’s inside this package? Any unnecessary items like uninstallers, log files or registry settings that are not needed? Does the package apply to the packaging guidelines? Are there any packaging guidelines? Based on what information has the application package been built? Based on what it is tested? Were there any problems when virtualizing this application and how have they been solved? Does the solution fit into the desktop design? Almost none of this questions could be answered……as expected. Also the application virtualization quality was lacking according to any average quality guidelines as expected.

The explanation of this is commonly still the fact that the creation of (virtualized) applications by people that are not totally focused on application packaging / virtualization and are doing it as one of their many things they have to do. Not every company has budget for hiring this specific kind of people that do see application virtualization or application packaging as an art!

There are different kinds of people when it comes to application packaging and application virtualization:

  • People who think that packaging or virtualizing applications is something that can be done by everyone. People who want to deploy application as soon as possible and not or less caring about the quality of a package;
  • People who think that application packaging and virtualization is an art. Know what is about, know what they are doing, why they are doing it and what the consequences are when making an application package of bad quality. This type of people are a group a people who know that a stable desktop depends for the biggest part with application packages of good quality.

To build and deliver high quality application packages and virtual applications it’s important to know in what kind of desktop environment the application needs to run:

  • What software is already installed or will be installed;
  • How is software being installed and how it’s being used;
  • Are there any dependencies between the applications and the OS or between applications;
  • What parts of the OS are restricted for the users, are users allowed to make their own settings.

Of course there are a lot more items that are within a user’s desktop environment.

And besides that a very important thing is that there are some processes in place when it comes to building, changing and releasing new builds of the users’ desktop. For example a change management process, a release management process and a packaging process.

Let’s talk a little more about the packaging process.

 

Packaging process

The packaging process is one of the processes that needs to be in place for delivering good application package/virtual application quality but is often forgotten. The importance of how applications and what applications have been installed on a desktop, but also how applications use the OS, is being used by the users, which settings are involved and what the dependencies between are between the applications and or the OS. The bottom line is that it is important to know exactly how a users’ desktop has been built.

The packaging process is that process that is taking care of this and …. way of creating and delivering application packages / virtual applications. This process consists of at least the following steps:

  • The Intake (in this step an intake document will be filled out together with the customer on how an application needs to be installed and what dependencies there are with underlying operating system and or back end systems);
  • The Building (in this step an application package/virtual application is being build according to the intake form. In this step also a document called package document is being created in which is documented how the application package / virtual application has been built. For examples what the name of the package is, what files, folders, registry keys have been deleted and what VB-, PowerShell- or whatever script shave been used to give some extra functionality or solve some problems.
  • The Testing (in this step the application will be tested according to the intake document);
  • The Deployment (in this step an approved application package will be deployed to the rest of the users that need the application).

An application package/virtual application that had gone through some sort of process is providing more insight into the installed application, giving it a higher quality and making the desktop environment a more stable one.

 

In conclusion

Maybe the migrations of applications with Windows 10 and Server 2016 will be a lot easier than it used to be. We shall see.

In any event, above story needs to be considered (again) when updating or making application packages and/or virtual applications when making a project plan where this is involved.

Not always giving a nicer schedule, but definitely a more realistic one!

However, a big part of the upcoming migrations to the latest desktop and server operating systems will be a lot about applications in whatever format that need to be installed on desktops and servers.

 

So, again, it will be all about the apps!

Leave a Reply

Your email address will not be published. Required fields are marked *