Accessing Virtual Application Resources
Applications consist of a set of resources (e.g. files, registry values, services, web sites, WMI providers, etc.) that work together to deliver product functionality. When one of these resources is not configured or functioning properly, the application may fail to operate and require an administrator to troubleshoot and correct the problem. Virtualization can hide or move these resources making them more difficult to locate while managing and troubleshooting. This post outlines three features provided by Server App-V that give greater visibility into virtual applications.
1. Native Registration
Server App-V integrates many virtual application components with the native operating system. A few examples include NT services, IIS based websites, WMI providers and COM objects. Since these components are registered natively, existing tools can see and interact with them as if the application were installed. This makes managing and troubleshooting these types of components consistent with how they were managed in the past. A few examples of this are:
· Starting/Stopping services from the Services MMC
· Viewing IIS web application settings from IIS Manager
· Viewing application specific users and groups in Computer Management
· Accessing an application’s WMI provider via Powershell
Although Server App-V integrates many virtual application components with the native system, there are two key aspects of a virtual application which do not appear in the same location as a native installation: the application’s registry and file resources. These can be accessed with the following techniques.
2. Running in the virtual environment
State separation is achieved by redirecting registry and file access for processes running in a given virtual environment to an alternate location. For the file system, this location is on the virtual file system drive (Q by default) and for registry entries, the virtual registry is used. This redirection occurs transparently to the application; in fact, the application itself may request the file C:\Program Files\MyApp\foo.txt but the request will actually be fulfilled by a file that resides in Q:\MyApp\VFS\CSIDL_PROGRAM_FILES\foo.txt. In many cases, it is advantageous to troubleshoot the operation of a virtual application by running tools inside the same environment that the application itself runs in, thereby allowing the utility to interact with the application’s registry and file resources the same way that the virtual application does.
Server App-V has made this process very straightforward with the addition of the /RunInVE parameter. This parameter can be appended to the command line of any process and it takes the form of /RunInVE:Package, where Package is the package GUID (available in the package manifest) or the name of the package that was specified when it was added. Note: /RunInVE must be the last parameter on the application’s command line.
Launching “cmd.exe /RunInVE:Package” produces a command prompt that sees the same redirected file system view as the package’s virtual applications. To see the merged virtual registry view, use “regedit.exe /RunInVE:Package”.
3. Viewing the virtual registry and file system outside of a virtual environment.
Server App-V has also made it possible to view virtual file system and registry resources from outside the virtual environment entirely. The file system can be navigated (without the redirection benefits mentioned in the previous section) by simply navigating to the virtual file system drive (Q by default) and the virtual registry can be accessed via WMI.
When each package is added to the machine, a new WMI namespace is created under root\microsoft\appvirt\server called “package_packageGUID” where packageGUID is the package identifier without braces or dashes. Within this namespace, you can use the StdRegProv class to access the virtual registry. More details on the StdRegProv class can be found at https://msdn.microsoft.com/en-us/library/aa393664(VS.85).aspx
The following example uses powershell to access a “test” value in the virtual registry of a package with the identifier {ADDA1A2D-62E7-4B5B-8CE0-662FD0659C46}.
# WMI Connection Parameters
$savHost = "localhost"
$namespace = "root\microsoft\appvirt\server\package_adda1a2d62e74b5b8ce0662fd0659c46"
$authLevel = "PacketPrivacy"
# Parameters for GetStringValue
$hklm = 2147483650
$keyName = "Software"
$valueName = "test"
invoke-wmimethod -Authentication $authLevel -Namespace $namespace -Class StdRegProv -Name GetStringValue -ArgumentList $hklm, $keyName, $valueName -ComputerName $savHost
Using native management tools, running utilities in the virtual environment and knowing how to browse virtual resources outside of the virtual environment simplifies the task of managing and troubleshooting virtual applications.