Geek of All Trades: VMM 2012 and Server App-V: happy together
Microsoft quietly added Server App-V to System Center Virtual Machine Manager 2012, an excellent move on both the technical and strategic level.
It’s important to maintain objectivity as an independent voice within the IT industry. It’s essential to the job of helping you make good decisions on products and strategies. Doing that job well requires maintaining neutrality throughout a never-ending stream of product pitches and vendor marketing.
Every now and then, though, you see something that changes everything. Objectivity takes a back seat to excitement. This time that something is Server App-V, a quiet addition to System Center Virtual Machine Manager (VMM) 2012. It’s so quiet, in fact, that an unfocused eye could almost miss this impressive new tool. Trust me, you wouldn’t want to miss this.
Server App-V gives your servers the same level of application delivery automation you’ve been enjoying on desktops for years. Couple this with the new VMM service-oriented provisioning model, and you can quickly see how the task of creating virtual machines (VMs) is about to improve dramatically. In the ongoing struggle for virtual platform market share, joining Server App-V with VMM could be Microsoft’s most brilliant move yet.
The App-V that isn’t App-V
You can think of Server App-V as a “quiet addition” because it’s so well-integrated into the VMM management experience. It’s tightly integrated, almost to a fault. The Microsoft nomenclature adds to its obscurity. It shares most of a name with the other App-V we’ve known for years. That makes sense, due to their similarities. However, it has the unfortunate consequence of burying the details of Server App-V in a casual Web search.
Make no mistake: These two technologies have plenty in common. They’re both solutions for virtualizing applications. They also sport their fair share of differences. Architecturally, App-V is generally focused on delivering applications to desktops. Server App-V is absolutely meant for servers.
At a more technical level, there are further differences. Server applications aren’t generally designed to be used by multiple users on the same machine. They’re more likely to be background applications that rarely see console logins. As a result, Server App-V treats its virtualized applications somewhat differently than traditional App-V.
Here’s a look at some of the key differences between the two:
Server App-V: If an application creates data or modifies configuration in a user-specific location in the registry when the application is sequenced, the data or configuration remains associated with the same user at deployment time and at run time.
App-V: If an application creates data or modifies configuration in a registry location specific to the current user when the application is sequenced, the data or configuration is mapped so it’s accessible to any user running the application.
Server App-V: Application files that are part of a virtual application package, such as the .exe files and libraries required to run the application, are available to all processes running on the computer where the application is copied.
App-V: Application files that are part of a virtual application package are only available to that virtual application and any other processes started in that application's virtual environment.
Server App-V: COM objects, DCOM objects, COM+ objects, Windows Management Instrumentation (WMI) Providers and NT Services that are part of a virtual application package are exposed on the local system to let the OS, tools and other applications interact with them. For example, you can use the native Service Control Manager (SCM) to start a service that’s part of a virtual application package.
App-V: COM, DCOM, COM+, WMI and service information associated with a virtual application package is kept within that package, unavailable to any processes running outside that package. For example, the native SCM won’t see any NT services running inside a virtual environment.
Server App-V: The Server App-V Agent uses heuristics to automatically detect which processes on a computer must be run within virtual environments. Typically, no launcher shim is needed. To explicitly add a process to a virtual environment, you can add “/RunInVE:<package GUID>” to the end of the process command line.
App-V: For a process to be virtualized, an App-V program such as sfttray.exe must open that process, or it has to be the child of another virtual process. To explicitly add a process to a virtual environment, you can run the command “sfttray.exe /exe <executable to launch> /app <name of application>.”
Server App-V also uses a special tool called the Server Application Virtualization Sequencer (see Figure 1) to create application packages. Don’t confuse this with the traditional App-V equivalent, Application Virtualization Sequencer. One word, as you might imagine, makes all the difference.
Figure 1 Server App-V uses the Server Application Virtualization Sequencer to create app packages.
Oddly enough, the Server Application Virtualization Sequencer installation bits can be tough to find. Whereas the traditional App-V sequencer has long been found in the Microsoft Desktop Optimization Pack, the Server App-V sequencer is instead secreted away within the VMM installation media. Look for a folder named \SAV. There you’ll find the setup files (see Figure 2) for the Server App-V agent and , along with Windows PowerShell cmdlets for managing both.
Figure 2 Server App-V installation files.
VMM application profiles
Whether for traditional App-V or Server App-V, the application packaging process starts with a bare-bones computer. Install the sequencer onto that computer, create a new virtual application package and launch your application’s installation from within the wizard. Many applications package successfully right out of the box. Others require a bit more fine-tuning to ensure they’re properly configured.
The Server Application Virtualization Sequencer editor deserves special attention. After packaging an application, choose Modify an Existing Virtual Application Package. Select Edit Package and browse for your package’s SPRJ file, then you’ll see a tab marked Deployment Configuration (see Figure 3).
Figure 3 You’ll find the editor under the Deployment Configuration tab.
Microsoft has built intelligence into the packaging tool that helps the tool enumerate a wide range of package-specific configurations you can specify at deployment. To see the available configurations, click the Add Deployment Configuration Item link. Enter an asterisk (“*”) to view the entire set of potentially configurable items (see Figure 4). Select those you wish to expose for later configuration and click the Add button.
Figure 4 You can select and add Deployment Configuration items.
Once you’ve added your items to the package, you can set a default value for each by double-clicking the item and adjusting its properties (see Figure 5). You can mark items requiring configuration as mandatory, a decision that becomes important as you bring packages into VMM.
Figure 5 You can adjust the properties of Deployment Configuration items.
You start that process by creating an Application Profile in the VMM console. That profile contains the metadata VMM uses to manage the package, such as application configuration, dependencies, rights and permissions, and any scripts you’ll need in combination with the package’s installation.
Here’s where things get exciting. Settings you exposed as Deployment Configuration Items in the sequencer are now available as VMM Application Profile properties (see Figure 6). This exposure offers the flexibility to deliver one application package across a variety of use cases. Just set whatever settings match those required for each server. For even greater flexibility, you can use the variables in the format @variablename@ to designate values to be set at the time of deployment.
Figure 6 Deployment Configuration items become your VMM Application Profile properties.
Much better together
The combination of VMM and Server App-V can revolutionize how you deliver services atop servers. You now have the tools to move past the days of simple copy-and-paste VM provisioning.
Automated VMM service provisioning isn’t something you’ll be implementing overnight. There’s a significant amount of up-front effort required to initially build the automations and software packages you intend to deploy. That requires effort long before you reap the rewards.
The more advanced features of VMM aren’t for the squeamish, and automation-phobic IT pros need not apply. If you’re ready, though, this version of VMM-plus-Server App-V delivers two impressive solutions that are undoubtedly much better together.