Getting Started with App-V Management
NOTE: This post is part of a series. You might want to start at the beginning:
- “I’m new to App-V so how do I get started?”
- What is App-V and how does it work?
- How do I get App-V?
- Getting Started with Sequencing
- To Manage or not to Manage
To distribute App-V packages, you have a variety of options. I have saved this for last because people tend to make this decision too early in their learning process.
For most customers, a single option from below will meet all of there needs. Some may choose multiple options for the different client scenarios present. A flow chart to walk you through options is included in the What Would Tim Do tool. The information below is just an introduction to your options. You will likely need to perform a Proof Of Concept to evaluate and learn all of the specific dirty little secrets required for a successful deployment.
App-V Server The App-V server is the “traditional” method. The server is installed, along with a back end database. Packages are imported to the server and assigned to users and/or machines. The App-V client pulls this information from the server when the user logs in and adds/publishes the packages. The server is highly scalable and usually installed redundantly, although the impact of all servers being down may be extremely negligible for some customers. This design works well with all kinds of clients.
Configuration Manager Microsoft Configuration Manager can be used for App-V as well as traditional native installers and OS images. Packages are imported into the SCCM console and assigned to users and/or machines. The SCCM agent will pull this information down to process. SCCM has proven itself to be unacceptable for non-persistent (e.g.: VDI), semi-persistent (XenApp, especially with PVS), and shared workstation (tellecommuter/kiosk/patent room) scenarios due to the length of time it takes to publish the apps after logon.
Between these two, I’ll just say that if SCCM is not in place today, installing it to just do App-V is probably a mistake. On the other side of the coin, leveraging an existing SCCM infrastructure makes a heck of a lot of sense as long as the client scenarios work out.
Standalone/Third Party tools
Ultimately, packages are added and published using a couple of PowerShell commands no matter how you deploy. It is possible to skip both of the previously described server choices and “roll your own” or use a pre-built third party tool instead. The biggest options include:
- Add the add/publish cmdlets to an existing post build/boot scripts.
- Use free AVSS tool (TMurgent.com). You install additional agent onto all clients, but no back-end server. Use AD Security groups matching package names in a share for authorization. Automatic mode or self-service mode available.
- Use App-V Scheduler tool (appvscheduler.com). Has both free version and paid version with additional features, which implies support. Back-end component can be a simple PC and file share accessed via a remote console.
Another note about non-persistent/semi-persistent Situations
While App-V is great at making applications dynamically deployable, it still takes a little time to add/publish an application to a machine. For persistent machines this is not a problem, but (out of the box) it does take longer than users expect to publish all their apps if they are logging into a “fresh” machine every time they log in. There are a lot of tricks available to make this situation more bearable, such as not configuring streaming, shared content store mode (when applicable), pre-caching, and pre-“registry staging”. Cody Lambert maintains an excellent wiki page on TechNet devoted to setups with Citrix and PVS.