So I’ve been receiving a lot of feedback on ways to enhance App-V toolkits for customers and their in-house troubleshooting. I’ve received usually two kinds of feedback on previous articles such as http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspxand http://blogs.technet.com/b/gladiatormsft/archive/2013/04/24/app-v-5-0-launching-native-local-processes-within-the-virtual-environment.aspx - 1) This is great! Can I have more?” and 2) “It’s about @*#&% time!Can I have more?
Do we have a “Cached OSD” equivalent in App-V 5.0?
Remember when you were troubleshooting configuration for a virtual application in App-V 4.x? Instead of going through the trouble of modifying the OSD file at the content root, removing and republishing as well as re-streaming the application – instead you locate the application’s cached OSD file and make modifications there while you do your temporary testing of adjustments to the XML configuration. The cached OSD files were located in a subdirectory of where you set the GlobalDataDirectory value in V4. Identifying which of the OSD files applied to your application could easily be achieved by viewing the properties of the application using the App-V 4 Client Admin UI.
In v5, this information will likely be stored in either the deployment configuration or the user configuration file (what we refer to as the dynamic configuration files.) To determine the source of the Deployment Configuration for a particular application, you can take advantage of PowerShell and the App-V Client API’s to find the location of this information without having to know the actual GUID of the package.
$AppVPackage = Get-AppvClientPackage –name <PACKAGE>
You can then proceed to test out these changes.
How can I tell which Virtual Environment (package\connection group) an Application is Running in?
Often on systems that are running a bunch of different virtual applications that may or may not be grouped together via connection groups (RDS\Citrix Servers) you might want to verify a running process is running in the correct virtual environment. You can use the following PowerShell commands to determine the current package version and also possible connection groups (virtual environments.)
Start-AppVVirtualProcess cmd –AppvClientObject $AppVPackage
Get-AppvVirtualProcess | select -ExpandProperty AppvPackageData
In the example below, we use the CMD prompt to verify the version and package ID running.
How Can I tell if an Application was Running Virtualized simply by looking at a Process Monitor Log?
Any executable that is running within an App-V virtual environment will have the module "AppVEntSubsystems64.dll" injected into the process. So all you have to do when viewing a process monitor trace is double-click on any event containing the process you need to check. When the "Event Properties" dialog box appears, Click on "Module" tab and look for AppVEntSubsystems64.dll.