App-V: Structural Limitations.

This post is a little different, it isn't a tip, trick or solution. This is a commentary on App-V, specifically a couple of it's more irksome qualities as regards enterprise use.

The Scenario:
You have Office 2010 deployed, it's been a year, your patches are starting to accumulate, something goes wrong or a new configuration is needed (maybe you didn't include Access and now you need to). Whatever the case you are left with one real option, re-sequencing.

In and of itself this isn't a major issue, re-sequencing office (if you've done it as many times as I have) is, monotonous but not too taxing. But know you are left with a problem. How to cleanly get Office 2010 to the masses.

The Problem(s):
The first problem is the ADK, notoriously finicky, with a flat out awful installer. If you have a background in repackaging software into MSI's you will be appalled to see how kludgy it is, and how many things are hardcoded. The fact that you cannot even use a transform tells you something, and MSI's are M-S technology, see it right there in the name? M-S-I...continuing the long, not so proud, tradition of MS being one of the worst abusers of it's own technology.

They give you very little useful information about the nuts and bolts functionality of the ADK and opt instead for a birds eye view of "understanding proxies". End of the day this part of the problem SEEMS solved easily enough by changing 8 registry keys in: HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\CVH

How you change them is another story. You can try using GPO, but it is about as reliable as GPO's usually are. You can try using AppSense Env. Manager, which is only marginaly more reliable than GPO if it's in a bad mood. You can run an MSI or WiseScript or other method via SCCM, but then you are stuck waiting for it to go down to the machine and there will innevitably be issues with users who have gotten the fix and some who haven't yet, so some portion of the population will be without working proxies.

And now we get to the real problem. The pointlessness of GUID's in App-V and the lack of segregation of data.

To start with the first point, GUID's being useless, you have to understand that App-V does not store things intelligently. It relies heavily on plain text files, OSD's, SPRJ's, even SPRT's are all XML files, and that is great and fine as an open method of transfer. As a data store it's flat out awful. There is no intelligence to it, no normalization, a lot of small file parsing, they could have used the registry to better effect! And that's saying something, something bad. But the real problem lies in HOW it organizes the data, not how it transmits it.

If you've used App-V for very long at all you have undoubtedly realized that no two applications of the same name and version can be either in the App-V server or client. Why bother having this limitations when you have GUID's? You can say it's a design choice and it's subjective as to whether it was right or wrong, but the truth of the matter is, it's a needless restriction.

Take for instance Adobe applications. Oh how they love Adobe Bridge, and Extension Manager, and the oh-so-annoying Air that seems to install no matter how many boxes you tick saying not to.

If I sequence DreamWeaver, Flash Pro and Fireworks I WILL have three versions of Air, three of Extension Manager and three of Bridge. I can't sequence them seperately because a) that is a lot of added work for no reason, b) they behave horribly when attempting to make three different Adobe apps share the same suited sequence c) it adds a lot of uncharted overhead to managing App-V, someone has to write down "oh and if the user gets dreamweaver they also need Bridge, Air and ExManager" and then if one updates the others need to update.

Essentially as it is right now the datastore looks something like this:

----Root
--------Application 1
--------Application 2
--------Application 3
xxxxxxApplication 4
--------Application 4
--------Application 5

Everything is under the root, and the primary ID is the app name/version. Worse still is FTA's, where EVERY FTA controlled by any application is grouped together in one big lump. On the server it CAN be seen by application but not in an intelligent way, instead of doing it like they do in the sequencer, where it's hived out under the individual application (which is still an EPIC pain if you are trying to find out what took over a specific FTA as there is no search, you either go through the main list with thousands upon thousands of entries, or you go app by app, having the data in two places makes no sense, it's an option you use when building in a simple search ability seems, I don't know, too hard, not worth it, overlooked).

Why doesn't it look like this?

----Root
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA

Problem solved, no conflicts, no issues...well, you didn't think we'd get off that easy did you? FTA's are the next problem. There is no way to set an applications FTA priority. For instance if I have Dreamweaver CS4 and Dreamweaver CS5 both on my machine (something App-V kindly makes doable) I have no way of telling App-V to ignore CS4's FTA's in favor of CS5's. Sure I can strip the FTA's off the machine, but unless I prevent them from refreshing (kind of a problem) the next time they refresh, back come the FTA's. I could take them off the server, but if I have some users licensed for CS4 and some for CS5 I will be leaving all the CS4 users without FTA's.

I appreciate the simplicity of App-V's console, it spares you a great many of the needlessly complicated and hidden problems of, say, SCCM, but it's a bit TOO spartan, and lacks any real sense of organization.

So lets go back to Office 2010.

Even I sequence it with a different version (say 14.0.4756.1000 instead of 14.0.4755.1000), which WILL let me have two versions of Office 2010 in App-V at the same time, I now have to change the regkeys before a person could be switched over. So if I take, say, 100 users, put them in a transition group and assign an SCCM package to run to update their registry keys, I have no way of ensuring it happens at a specific time, at best I can run it overnight and hope they all complete timely (and nobody is on a laptop off the network).

But even this doesn't work because doing this wreaks holy hell and havoc with the FTA's, the most noticeable of which are "Could not send command to program" and a lot of missing icons on Office file types.

So even if I use a pre-launch script in the OSD to change the regkeys, I'm still in a lurch.

Oh and making it worse still is that if you have any of the components in Startup (which their own prescriptive guidance and another KB tell you to put MSOCache and the Sharepoint Proxy in startup, and most users wants Communicator/Lync in startup) the odds of it CORRECTLY polling the server and swapping out the old version for the new is slim at best, on average it takes us four reboots before it will finally be timed right and discard the old version. That is ridiculous.

So now you have to write something that shuts down App-V, as you can't shut down JUST the office components because even though you CAN tell what apps are running virtual you cannot easily (at all?) tell what apps are running in what environment. So if a user manages to get IE or Explorer hooked into you have no way of knowing. Once App-V is shut down programatically delete the package using SFTMIME.EXE and THEN refresh the server toget the new package.

All because there is absolutely no collision prevention in a platform that's entire purpose is to eliminate support costs, make software conflicts a thing of the past, and more intelligently manage your software. Yet it lacks basic organization and control functionality.

It is for reasons like this that I get SO frustrated when I see things like 4.6 SP1 come out, where they make the easiest part of sequencing more convoluted but, I guess, easier to people who PROBABLY shouldn't be sequencing to begin with (I'm sorry but if it made the difference for you, you probably shouldn't be doing it professionally) and more cumbersome for the more advanced users. While introducing plenty of frankly inexcusable bugs (can't set settings without exporting them as a template because it triggers a New Project, which now means you cannot use them with accelerators because the two aren't supported together).

I was once told by one of the App-V people that they had to make choices between "released in time to be relevant" and "perfect". My sincere response to them is that App-V is not relevant, nor are any of their competitors yet, nor would fixing these problems make it perfect. And 4.6 SP1 did not go in either of those directions, it was just a pointless and tangential side trip, wasting time they could have been using to make some of these fundamental changes.

My biggest concern about App-V? Whether or not the people who use it know enough about what is wrong to have any idea how to fix it. Right now, it doesn't seem like they do.

/rant