This post was originally published on 15 June 2016
In the previous article, we looked at the user installed applications that may lurk in the users’ profile directories. Now it’s time to discuss applications that are deployed, but not really installed…
Virtual applications
Another interesting category of software deployment methodology that has actually existed for about 15 years now, but still not really understood or supported by most systems management or especially software inventory tools, is virtual applications.
On the Windows scene, there’s really only one leading solution in this category and it is Microsoft’s App-V, which they do support these days to some degree in their systems management solution, Systems Center Configuration Manager (SCCM). But the support is mostly centered on the software deployment side of the product, and to a lesser extent in the software inventory side. Other more fringe players in the application virtualization technology side exist besides Microsoft, such as VMware, Symantec and formerly Citrix too, as well as number of smaller companies.
By the recent announcement by Microsoft, App-V technology will actually be inboxed into Windows 10 Enterprise editions when so-called Anniversary edition of Windows 10 is released this summer. So this in all likehoods means that the application virtualization technology will keep rising into more prominent role in the future from what is might have been up so far.
The primary problem with the virtual applications – from software inventory point-of-view – is that they may not necessarily show up in the traditional Windows’ list of installed programs; little bit depending on how and through which delivery channel they were deployed to the PC. And, it also may be that they are not even straight-up discoverable through the executable scanning, even though the trend in the recent years has been more towards having less isolation in favor of more integration to the rest of the system.
But, the case usually is that the software inventory solutions do not “see” these virtual applications unless they have been specifically programmed to find them using the interfaces that those technology vendors provide. If that’s the case you are running into in your environment, it could be that the software reports do not show the actual deployment state of the virtualized applications, again missing intelligence on some – perhaps significant part – of your software assets.
Another case of virtual applications besides the locally virtualized application can be considered to be applications delivered using remote technology.
In the Windows world, this type of usage was pioneered by the Citrix and later offered as part of the core OS functionality in Windows servers and workstations.
Applications are run remotely from the server, just delivering (to describe it very simplified) view of the application screen to the PC and input from the user back to the server, means that those applications do not show up as actual applications on the client from the system’s perspective. Yes, again, it could be that depending on the delivery model ”shortcuts” to remote applications may or may not exists as entries in the installed programs list, but at the very least they do not show as individual executables on the local disk.
So getting an accurate view of the software that is physically run in one place and logically used in multiple others can be hard. Typically, it’s just information that is living in a separate database, in separate management application somewhere that’s managing the remote technology and having information to whom the applications are assigned. In the software inventory reports these applications do not show up unless the tool to gather information is run on those backend devices hosting the physical installations of said applications.
In specific case of servers, there’s general tendency to not run the same [discovery and central management] tools as on the end-user devices, for whatever reasons. Likely this is due to siloed approach of having different administrative boundaries: people in charge of workstations and usually the ones running software inventory and management tools are not allowed any control of the servers, and so the tools they use are not “accepted” into those remote application servers.
In case of Virtual Desktop Infrastructure (VDI) i.e. virtualized workstations instead of multi-user-session model of server-based usage, there potentially exists additional hurdles depending on chosen implementation model.
If the VDI PCs are created on the fly when somebody is assigned to them, and destroyed/reverted back to clean state afterwards, traditional inventory solutions cannot really keep up with the static snapshot-in-time model they operate on. In these non-persistent or pooled usage scenarios, applications are typically also assigned and delivered dynamically on-the-fly based on who’s logging on and possibly other parameters, so it is very hard to keep up with that fast changing environment.
To be sure, it is also typical that all of these models are combined in number of different ways, so some of the applications users are using could be traditionally deployed, some coming from either forms of virtualization described above, and inside the virtualized sessions the applications can again further come from any of these deployment methods!
So you could have remote applications inside remote desktops, running locally and remotely. It’s not hard to imagine that in these extremely dynamic, but for users very use-case flexible scenarios, software inventory as done traditionally is very much in trouble for keeping up with the pace of change.
Next part of the series will concentrate on yet another new type of application delivery (in Windows), born out of Windows 8, Modern/Universal Applications.
