App Volumes 2.10 vs. 3.0
One of my customers recently asked us to pilot App Volumes for them. We decided to go with the latest and greatest, and so used App Volumes 3.0... and that's turned out to have been a bit of a mistake. Unfortunately, it appears that the 3.0 release may have been a bit premature, as it has some issues. Specifically, you can't delete an AppStack once created (without a phone call with VMware technical support)... which is particularly difficult, as there's no way to upgrade an AppStack, instead the work flow is to copy the existing one and modify the copy. Also, and this may have been an issue that was site specific, but we found that whenever we restarted our Capture machine, our AppStack creation process failed.
After a few weeks of wrestling with these issues, we decided to roll back to version 2.10 (ie. reinstall and go back to the older version). 2.10 worked much better for our purposes (we were able to capture applications that required reboots and could delete our large and dynamic collection of test AppStacks), but it is very different! Besides the obvious interface changes, the two versions seem to have differing management philosophies.
In App Volumes 3.0, you manage applications. You still create an AppStack, but the system scans it for executables and then, as the administrator, you entitle users to those executables. Since there's a very high likelihood of interdependency, when you select an executable from one AppStack, all executables from that AppStack are automatically selected. So, while the interface is presenting me with applications, I'm still effectively managing AppStacks themselves.
In App Volumes 2.0, you manage AppStacks. When you want to entitle a group to use an application, you entitle it via the AppStack itself, which then automatically mounts the appropriate vmdk file and thus puts all of the executables onto the system. If you drill down into your AppStack, you can even see a list of the executables that it contains, which I found to be a very helpful feature.
So, since they're both managing AppStacks, what's the big difference? Transparency. In 2.10, if I want to roll out a new version of my MS Office AppStack, I create the new version (maybe called MS Office 5/31/2016), then remove the entitlement for the old version and replace it with the entitlement for my new MS Office 5/31/2016 version.
What's that workflow look like in 3.0? I have a group of users who are entitled to use Word.exe. I need to remove that entitlement from the system, then entitle them to use the other instance of Word.exe that shows up in my inventory. But which is which? That's not intuitive to find out. And it only gets worse as I collect more and more MS Office AppStacks, since I can't delete the old ones.
So, right now, I'd suggest sticking with App Volumes 2.x, rather than upgrading to 3.0. I'm sure that 3.1 or 3.0.b or whatever they're going to call the next version will address these issues, but for now the older 2.x version is much more manageable and generally usable.
After a few weeks of wrestling with these issues, we decided to roll back to version 2.10 (ie. reinstall and go back to the older version). 2.10 worked much better for our purposes (we were able to capture applications that required reboots and could delete our large and dynamic collection of test AppStacks), but it is very different! Besides the obvious interface changes, the two versions seem to have differing management philosophies.
In App Volumes 3.0, you manage applications. You still create an AppStack, but the system scans it for executables and then, as the administrator, you entitle users to those executables. Since there's a very high likelihood of interdependency, when you select an executable from one AppStack, all executables from that AppStack are automatically selected. So, while the interface is presenting me with applications, I'm still effectively managing AppStacks themselves.
In App Volumes 2.0, you manage AppStacks. When you want to entitle a group to use an application, you entitle it via the AppStack itself, which then automatically mounts the appropriate vmdk file and thus puts all of the executables onto the system. If you drill down into your AppStack, you can even see a list of the executables that it contains, which I found to be a very helpful feature.
So, since they're both managing AppStacks, what's the big difference? Transparency. In 2.10, if I want to roll out a new version of my MS Office AppStack, I create the new version (maybe called MS Office 5/31/2016), then remove the entitlement for the old version and replace it with the entitlement for my new MS Office 5/31/2016 version.
What's that workflow look like in 3.0? I have a group of users who are entitled to use Word.exe. I need to remove that entitlement from the system, then entitle them to use the other instance of Word.exe that shows up in my inventory. But which is which? That's not intuitive to find out. And it only gets worse as I collect more and more MS Office AppStacks, since I can't delete the old ones.
So, right now, I'd suggest sticking with App Volumes 2.x, rather than upgrading to 3.0. I'm sure that 3.1 or 3.0.b or whatever they're going to call the next version will address these issues, but for now the older 2.x version is much more manageable and generally usable.
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,