App-V Part 2: Architecture
(2 votes, average: 4.5 out of 5)
Loading ...App-V can be a pretty complicated beast. Heck, anytime you see the word “System Center” in a product name, you usually know it’s not as simple as just running Setup.exe! So an important part of this article is going to be making sense of the various App-V components.
First off, let’s cover the clients. There are basically two client types: The Terminal Services Client or the Desktop Client. Whichever client you choose to use must be installed on every machine that will be utilizing App-V-ified apps. The client’s pretty little, and can be deployed with Group Policy. The main visual interface is just a notification icon. The client’s job is to gather up all the available virtual applications from an App-V Management Server, and display that list to the user. The client handles launching apps on-demand, manages the client-side app cache (which helps improve performance by keeping copies of the local “sandboxes” on the client machine).
The client also creates the “virtual environment” that apps run in. This environment includes a Virtual Registry, Virtual File System, and Virtual Services Manager. The virtual environment is what provides the “sandbox” (or “bubble,” as some folks prefer) that apps run in. Essentially, the virtual environment is an overlay on top of the desktop’s physical environment. The Virtual Registry starts out as a copy of the real registry; changes made to the virtual registry are stored separately, though, and the real registry is never affected.
Think of a piece of paper, with a bunch of settings typed on it, as the real registry. The Virtual Registry is a piece of transparent plastic laid over top of that paper. You can make changes to the Virtual Registry by using a marker to write on the plastic; the underlying real registry is still visible, but can’t be changed directly.
The App-V client gives you three deployment options: Full Infrastructure, Lightweight Infrastructure, and Standalone:
- Full Infrastructure includes the App-V Management Server and the App-V Streaming Server, requires AD and SQL Server, and provides the full set of App-V capabilities.
- Lightweight Infrastructure includes the App-V Streaming Server - you don’t need AD or SQL Server, there’s no desktop configuration service, and you don’t get software licensing and metering.
- Standalone uses the App-V sequencer (coming up) to create an MSI file that automates the addition of a virtualized app. You don’t need any infrastructure components, but you get the smallest set of App-V features.
So let’s briefly cover the other elements of the infrastructure and what they do:
- The App-V Sequencer is designed to take a real app and make it into a virtualized app. This creates a “sandbox” package as I like to call it, and that package is what gets deployed to clients.
- The App-V Management Server (technically, “System Center Application Virtualization Management Server,” but that’s a mouthful) hosts virtualized apps (those “sandboxes”), delivers them to clients, and handles updates and patches to those apps. The server needs SQL Server to host the App-V database, and wants to use AD groups as the main mechanism for controlling access to virtualized apps. All of this is managed though the App-V Management Console, which is an MMC snap-in.
- The App-V Streaming Server (”System Center Application Virtualization Streaming Server,” bleh) enabled apps to be streamed to clients on-demand.
Future articles will look at each of the three deployment modes in turn, starting with Standalone, which is the “lightest,” requiring the least infrastructure and the fewest additional concepts.
Related Posts
Rate this Post
(2 votes, average: 4.5 out of 5) Loading ...
