So occasionally I do product reviews, but this isn’t actually a review – it’s a bit more of an evangelization. I’ve been using AppVentiX – the product formerly known as the App-V Scheduler – for a couple of years now, and I have to say, I’m pretty sold on it. As both a slick, reliable and low-maintenance application delivery method, and now, what looks like a useful on-ramp to the adoption of MSIX as a packaging standard, it ticks all of my boxes. And when you combine it with FSLogix – it is a vital tool in my armoury that helps me steer away from multiple image hell.
Obviously, to use AppVentiX you have to be invested into App-V (or MSIX, now that it supports that), but I’d hazard a guess that you’re more likely to have applications packaged via App-V than by MSIX right now. I’ve done a lot of App-V, and I’m pretty familiar with it, which makes me pretty comfortable with dealing with it. App-V moved on pretty well with version 5, away from isolation and more towards deployment, and now that it is integrated into Windows and can be turned on via GPO it’s pretty much easy to get into.
The drawbacks for App-V, in my opinion, were always around the infrastructure required. Databases, publishing servers, streaming servers – and trying to do App-V in cloud was very challenging too (I seem to remember it needed full-fat SQL rather than the SQL services, making it prohibitively expensive). Of course, you could always combine it with Citrix and deliver the packages through the Citrix App-V integration – but again, this I never found particularly slick or reliable. It always ended up with lots of faffing about with shares and XML files, or in other cases even needed the full App-V infrastructure alongside it anyway (when in dual admin mode).
With all this in mind App-V, for all I was comfortable with it, was never really my first choice for application delivery in Citrix environments. I always ended up leaning towards other, simpler technologies with lower infrastructure requirements (I remember doing a lot of Numecent at the time). But then, a few years later, fellow CTP Dave Brett introduced me to the App-V Scheduler (which I’d heard a bit about already), and as soon as I saw it in action, I was back to App-V as my preferred deployment technology. Basically, the App-V Scheduler (which eventually became AppVentiX) was App-V without the hassle.
There are two things you need to have to get the best out of AppVentiX – a passing familiarity with App-V, and a chunk of storage (dependent on how many apps you’re going to deliver). Aside from that, you just need the console, some Active Directory, and – well that’s about it. Simplicity rocks!
App-Ving it
Now although I said you need to be familiar with App-V, it doesn’t mean you have to be an expert. I’ve actually worked in environments where we have converted masses of MSI-based install packages into App-V packages just by running them quickly through the Sequencer.
Of course, as with any environment, you will find stuff that doesn’t suit App-V. I try not to get too hung up about this. If you can manage to get 70-80% of your apps delivered as part of the App-V solution, then that’s pretty much enough for me. The rest I either install into the base image (Chocolatey being my favourite method of that, for now) and mask them out with FSLogix, or wrap them up in some compatibility tool (such as Turbo or Cloudhouse) if I’m having issues getting them to run. I’m not a fan of putting together huge swathes of tooling to accommodate all apps – I saw an estate recently where they used SCCM, App Layering, App-V, App Masking and FlexApp all together, which was a nightmare from a support perspective. Naturally, your mileage may vary, always like to try and stick to a maximum of maybe three delivery methods, and pick the “main” one as something the customer either is familiar with or can easily get to grips with.
One thing that has stood out for me from AppVentiX is that it significantly reduces the complexity of putting App-V into place. App-V 5.1 isn’t anywhere near as complicated as the 4.x version from a raw packaging perspective, and it’s usually the infrastructure and supporting components that make it feel unwieldy and difficult to implement. With AppVentiX, a lot of that complexity is removed and there are a lot less hurdles to get across. If you’re trying to get a customer to adopt App-V, believe me, it’s far easier this way!
How it works
AppVentiX is simple. You configure a file share or shares that hold all of your App-V packages. You install the AppVentiX agent onto your target devices. When the targets boot for the first time, the agent starts, and it caches all of the App-V packages down onto the local device (if you’ve configured it that way – you can pull them on demand if required). If any of the packages in the remote file share are updated, the AppVentiX agent polls at an interval (or at next reboot) and pulls down any updated packages into the file share, making deploying updates really straightforward.
In a nutshell, that’s it. It doesn’t just do App-V packages, it can now do MSIX packages too, but it simply pulls the packages from an SMB share onto the machine and presents them to the users via the local cache. Hence why I say it needs a chunk of storage – we have about 25GB of App-V packages to deliver in production and henceforth we have to allow each worker 25GB storage overhead to store that cache. But to be honest, our workers had about 50GB free space once provisioned anyway, so there wasn’t any extra cost involved. If you’re using PVS, then obviously you’d want to keep that chunk of storage out of the write cache, but in general this should be something you could easily absorb (unless your packages are HUGE). AppVentiX has options that allow you to detect PVS and MCS and take appropriate package management options as well – it has a lot of handy features that can make your life easier.
There is a Central View console that you use for management of the environment, which is pretty lightweight and easily installed on a jump box or admin station.
If storage is an issue, you can leverage Shared Content Storage mode so that packages are only streamed to the worker when invoked. Obviously the trade-off here is initial launch time, but you can mix and match with “Managed Mode” so you can force frequently-used packages to be cached at boot time and deliver the rest on demand to save disk space. In my environment I prefer to boot the workers and set the setting so that logons are disabled until the caching has finished, and I cache all of the applications at this point so that my launch times are as fast as possible. But the beauty of it is you can configure it in various different ways so that you can tune it for your environment. There are loads of ways you can skin it to meet your needs, and they are too many to cover here – I may well do articles about different configurations in the future, but I’d encourage anyone just to download the trial version and see what you can do.
You can divide workers up into Machine Groups and apply different settings or configuration shares to all of these, so you can easily target different application sets to different groups of worker machines. This means you can easily run a single image and deploy different application sets to different silos, should you wish to do that. You can configure multiple content shares to allow failover or any one of the host of resilience options that you get in standard Windows environments – they’re just file shares, nothing complicated, so it’s dead easy to factor in high availability. However, if you’re like me, I don’t really care if the file shares go offline, because all my apps are cached at boot. As long as the file shares are up when I want to deploy an update, they could essentially spend every other moment being offline, and my users wouldn’t know any different.
Can you use it in the cloud? Sure, we do, and it works well – as I said, it’s just a file share with some packages in it, right? Cloud actually offers you some really good SMB file-sharing services (such as FSx in AWS, or ANF in Azure) that can allow you to broaden the feature set of how you manage the shares and their content.
Enter FSLogix
When we start mentioning siloing I always start getting a sinking feeling, I’d much rather instead insist on deploying all my App-V apps onto all of my servers at boot. In order to manage this, I lean on FSLogix to provide application security controls – so, for instance, if I have an application that is regarded as “sensitive” and should only be presented to certain groups of users, we use App Masking to achieve this. The entire estate runs from a single image with the same sets of applications – but contextual access is provided to groups of users, allowing us to effectively present radically different desktops to users without having to worry about splitting out into different images.
In order to get FSLogix and the AppVEntiX agent working together, there are just a few things to remember. Firstly, keep your packages tidy so that they don’t drop shortcuts out anywhere other than the %ALLUSERSPROFILE% folder (C:\ProgramData\Microsoft\Windows\Start Menu for the rest of us). This means we know where to expect to find the shortcut when we are setting up our FSLogix rules – you don’t want to be hunting around in the user profile or on the desktop.
Next, you just need to find the folder that the App-V package deploys to, which will be a subfolder of the App-V deployment directory (usually C:\ProgramData\App-V, although this can be changed).
Once you have these bits of information, you can set up the items to mask, which should generally just be a shortcut and a folder as shown below
Finally, don’t forget that the App-V client process also needs access to the package and the shortcuts in order to run properly. Below is shown an example of setting up an AppVEntiX app assignment to be masked via FSLogix. This provides access to no users except those specified in the AD group.
The masking is applied to Everyone, unless they are in the specified AD group in the second row. The three other assignments are added so that the application can execute properly.
Again, we find this works really simply and really well. We can easily update our AppVEntiX applications without waiting for the monthly rebuilds that we use – we just update the file share(s), send a sync, and the updated app will actually appear on-the-fly even if a user is logged in and using the system! If the user isn’t entitled to see it, though, they never even know it is there. Bringing new applications on board is as simple as running an MSI through the Sequencer and then creating the FSLogix rules, and then popping the output files into the share. I have to say, we’ve been very impressed with it because it’s really easy to manage and it just does what it says on the tin.
Moving forwards
Longer-term, we are looking to adopt MSIX as a packaging standard. We’ve got some initiatives looking at MMD (Microsoft Managed Desktop) and the like, so MSIX has to become our new standard. However, as you may know, deploying MSIX App Attach isn’t too slick at the moment, so seeing that AppVEntiX now lets us deploy MSIX packages as well is a great bonus, because it gives us an easy on-ramp towards MSIX adoption without worrying about the processes of deployment.
There are newer MSIX features coming to AppVEntiX and I’d love to see something that gave you the option to maybe convert MSI or App-V packages into MSIX and then deploy them all through the same console. If we could get to that stage, I’d be totally sold on it for the foreseeable future. Here’s hoping that the new features turn out the way I’ve imagined them! – Update…there are now direct conversion features in the latest version for moving from App-V to MSIX packages, and they all deploy in the same fashion, which is awesome! Just remember to create a publishing task for each MSIX package (they don’t support global publishing like App-V packages do).
But for now, if you want a slick, simple, low-overhead and cheap (yes, it is very affordable!) method of deploying your non-core apps into your estate, AppVEntiX is currently one of my favourite pieces of kit. We combine it with Packer, Chocolatey and FSLogix to give us a pretty highly-automated hands-free deployment method (possibly more coming on the details of this in future articles). I’d say it is well worth an hour or so of any admin’s time to go and download the trial version and give it a whirl.
