by Tobias Kreidl, CTP, Steering Committee

Many users may be familiar with the nearly decade-old Microsoft App-V application virtualization product, which supports applications as services in real time, and as needed, without an actual installation or complex modification of the registry. Individual applications are instead packaged from what would normally become locally installed products into centrally managed services and these can be made available to selected groups and individuals without any need to preconfigure the client computer or to change any of its operating system settings.

In the process of reviewing how to deploy potentially hundreds of diverse applications that would normally take around a hundred or so distinct and separate Windows images, App-V appeared to be the bread and butter solution we’ve been looking for. But to serve up that many options and with the many limitations that exist with the overhead and infrastructure needed to distribute this many applications to a very large user base using Microsoft’s System Center Configuration Manager (SCCM) seemed difficult. What’s one to do when faced with a task that appears so daunting on the surface?

Enter the application App-V Scheduler (http://www.appvscheduler.com) as one serious option to consider. And to immediately clarify, am I trying to thinly disguise this article as a sales pitch? Of course not — I have nothing to personally gain from this other than making the user community aware of what options exist and trying to inform those who might find themselves in similar situations. It’s an attempt to educate and enlighten others, and in the process, learn something myself along with my team. That’s what CUGC is all about: education and sharing experiences and knowledge with others!

I will continue then and just say that our initial trial with this product produced impressive results. The outcome of those and where our experiments with App-V Scheduler lead will remain a topic for hopefully a future follow-up article.

For now, the main purpose of this article is that I primarily wanted to clarify some points that we didn’t fully understand about App-V, let alone how it integrates with App-V Scheduler. The primary questions really revolved around how you control access. Plus a recent discussion involved how with some other applications, such as licensing software, my colleagues wanted to also use Active Directory to create machine groups instead of ones assembled manually from NetBIOS names.

My understanding now is that App-V can support both, and simultaneously. Having discussed App-V with current users in the community, it seems to be now apparent that you can also support Active Directory (AD) groups of client machines as well as users. This is buried pretty deeply in the documentation, and even so, isn’t exactly crystal clear. (Note that I’m intrinsically a Linux person, so the Microsoft world still holds many secrets that remain obscure to me!) Given that, the next logical question was that if we didn’t really want to use SCCM what other options were there?

Several CTPs and a CTA jumped in with a number of suggestions and I’m pleased to say, got us headed in the right direction to research things further. One possible avenue ended up being App-V Scheduler. We still, however had a number of questions about the product, so we approached the source.

I consequently wanted to share a few questions we posed to Bram Wolfs, founder and “the man” behind App-V Scheduler, to also hopefully enlighten you as to what this product can do to enhance the management of App-V. We were not only interested in how applications themselves were handled, but also underlying nuances such as the interaction with license servers.

Questions: “Is it correct that in App-V Scheduler, that user groups can be either manually assembled from selections of machines or that AD can be used to supply collections, or a combination of both? This would greatly simplify the ability to create and manage groups via AD as we could make use of them in more than one utility and have just those AD machine groups to maintain that would serve multiple purposes. And if supported, how are these differentiated in the management GUI?

Also, do you happen to know if App-V Scheduler will run compatibly with Sassafras Software’s K2-KeyServer license server and be aware of clients accessing application software even with the App-V Scheduler layer involved?”

Here are the responses:

“Independent from what deployment mechanism is used: App-V packages are always delivered to a machine and from there it can be published to a user or globally on the machine.

With this in mind, this is how App-V Scheduler enhances and manages the App-V deployment, I will write it down in steps it takes to configure the deployment:

Package delivery:

– You create an AD group containing the machine accounts, after that this group can be managed and configured in the Central View console.

– You create an UNC path where this group of machines read the packages from. This UNC path is also used to store the central configuration.

– You can create subgroups from this group in Central View (2.5). These subgroups are not AD groups but App-V Scheduler machine groups. Machines belonging in a subgroup can switch to another content share to read packages from, in this way you can split your deployment further, for example: in production, test or Campus just to name some examples.

– You can also create multiple AD machine groups and create subgroups of those to further fine grain your deployment. This way it’s very flexible.

– Packages are deployed and configured when the deploy cycle runs, this deploy cycle is executed by the App-V Scheduler agent and can be triggered in the following ways:

– Time interval
– Manually in the agent GUI
– Remote through the Central View console

After delivery:

– You can create publishing tasks in Central View, you can configure which packages are deployed globally to the machine and which packages only to certain users. You can create AD user groups, App-V Scheduler reads this group when a user logs in or when the deploy cycle is triggered remotely to even publish packages while users are still logged on.

Note:
– Global publishing can also take place when users are logged on
– When a global or user publishing task is executed and the package isn’t deployed on the machine App-V Scheduler will add it on the fly

I recommend global publishing as much as possible and only use user publishing on RDS\XenApp where you want to make sure an app is only accessible for certain users.

The question about the license software is simple, if App-V supports it App-V Scheduler also supports it :)”

There you have it. In short, there is a lot of flexibility built into this product. And as it turns out, the K2-KeyServer product requires but a small additional configuration step for any application packaged with App-V to be made fully functional: click here for details. A new release of App-V Scheduler 2.5 should be out in Q4 of 2016 and will include a number of new features. It’s also compatible with applications served via Citrix XenApp and virtual desktop environments.

Stay tuned for hopefully a future blog entry that will tell more about where the next steps take us when we give App-V Scheduler a full-blown tryout. We’re optimistic that it will take a good chunk of the bread and butter virtual application delivery operations of our environment and add the jam to sweeten the experience.

Thanks go out to CTPs Barry Schiffer, Timothy Mangan, Jason Samuel, Trond Eirik Haavarstein and CTA Rory Monaghan for invaluable advice regarding both these products.