One of my colleagues in support let me know of an important note for those upgrading to App-V 5.0 Service Pack 2 Hotfix 4. It appears that the value for Shared Content Store (registry value SharedContentStoreMode in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming or the same option using Set-AppvClientConfiguration) can be set back to 1 from 0 thus turning it off. If you have not yet upgraded to Hotfix 4 and are planning to, you will need to ensure that this value get reset after installing the hotfix prior to rebooting the App-V client post installation. If you are currently using Shared Content Store Mode, and this value gets set back to 0, some interesting things may happen. This will likely not be a factor if you are controlling the configuration of your App-V 5 client through Group Policy.
To tell if a value is controlled by policy, you can quickly run the Get-AppVClientConfiguration –Name SharedContentStoreMode to check the SetByGroupPolicy value.
New Launches Will Stream to Disk
This is the most obvious change and you will likely notice this by seeing the streaming progress indicator which was not used when running in Shared Content Store mode.
You may also find Packages Start Magically Populating in the App-V Cache
You will notice that the sparse files in the PackageInstallationRoot may start populating. This is because the Autoload setting which was ignored while running under Shared Content Store mode is now in effect. The Autoload value is in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming and has the following possible values:
1: Previously Used Packages only (Default.)
2: All Packages
Since 1 is the default, and the packages were already previous launched, guess what? Yes, they will start background streaming which is why those sparse files are populating. All packages under HKLMSoftwareMicrosoftAppVClientStreamingpackages that have PreviouslyUsed set to 1 will background stream.
Setting it back to 0 Alone may not Fix Everything
Once a client is in Shared Content Store Mode, you can easily stream to disk overriding it on a per-package basis by pre-caching the application using the Mount-AppvClientPackage powershell cmdlet. In addition, when applications are launched and the PackageState value stored under HKLMSoftwareMicrosoftAppVClientStreamingPackages is set to 3, it will still launch from the cache. It will also likely continue streaming if the StreamedBytes value is populated.
The values under HKLMSoftwareMicrosoftAppVClientStreamingPackages are great for troubleshooting and debugging, but if you want to revert these packages back to proper functionality under Shared Content Store mode, I would advise you remove the packages and republish them (or resync with the publishing server after removing the packages depending on how you are delivering the applications.) Modifying these values directly can be dangerous and may yield undesirable results which would require you removing and republishing them anyway.
When you use App-V with roaming profiles or a service or product that may roam integration settings of virtual applications, it was historically assumed by App-V that once a package’s extension points are laid down (or integrated,) roaming user profiles will carry it alongside the user’s catalog, keeping the two in sync. The App-V 5 Client Integration component depends on the ability to rely on the client’s copy of the catalog to determine which extension points get generated (or re-generated.) This is how App-V 5 Integration quickly calculates which extension points and integration links (junction points) will be needed to be created during publishing. Back in previous versions when everything was isolated into individual FSD and PKG files, it was pretty easy to integrate App-V data into your roaming user environments.
As you may note, I am purposely using the term “Roaming User Environment” – as in – a generic term that not only refers to Roaming User Profiles native to Windows, but also environments which may be roamed using Citrix UPM (User Profile Manager, AppSense UEM, UE-V, RES, Immidio, etc.) Many of these environment managers work more granularly than the standard Windows configuration. The App-V 5 client configuration allows administrators to align their roaming user environment configuration with their App-V client configuration. Specifically, administrators identify which registry key locations under HKCU and which directory locations under %USERPROFILE% do not roam.
The App-V Client Integration component uses its Client Configuration to set and get roaming exclusions. The exclusion lists are captured in the App-V Client Configuration using the following keys:
Each roaming exclusion list is a REG_SZ value which is a semicolon-separated list of paths to excluded data. File exclusion paths are relative to %USERPROFILE% and contain no leading slash or trailing slash. Registry exclusion paths are paths to keys relative to HKEY_CURRENT_USER and contain no leading or trailing slashes. The App-V client setup establishes a default roaming configuration for the client machine as a best effort during client installation according to these well-known Windows settings. For example, Windows never roams registry data under SOFTWAREClasses, and may erase it on logoff, so the exclusion list set during AppV Client setup will always include SOFTWAREClasses.
Configuration of Roaming Exclusions
Of course, one should recognize that this may not be enough. Administrators that wish to change the list of roaming exclusions from the default configuration populated during client installation can do so. Roaming Exclusions can be configured by way of:
Manual Registry Configuration: Per the information in the proceeding paragraphs, you can make adjustments by modifying HKLMSoftwareMicrosoftAppVClientIntegrationRoamingFileExclusions
Please bear in mind that the changes you make will take effect for new users only logging onto that App-V 5 client.
PowerShell: You can use the following PowerShell Cmdlets to set roaming exclusions:
Please bear in mind that like everything else the CmdLet will check to see if these settings are applied and managed via GPO by checking HKLMSoftwarePoliciesMicrosoftApplication Virtualization. If any of the provided configuration is in the GP registry node, the cmdlet will fail. If the group policy does not own any of the supplied configuration, the settings are written to the HKLMSoftwareMicrosoft. Please also Please bear in mind that the changes you make will take effect for new users only logging onto that App-V 5 client.
Group Policy Object (GPO): The MDOP ADMX templates include settings for both Roaming File and Roaming Registry Exclusions. This will enable you to pre-deploy these configurations via GPO. The ADMX template can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=41183
Deployment Using Installer Switch: Per http://technet.microsoft.com/en-US/library/jj687745.aspx – you can supply this configuration upon deployment of the App-V Client using the following switches:
Usage: /ROAMINGFILEEXCLUSIONS='desktop;my pictures'
Administrators managing environments that don’t support roaming user profiles can disable all roaming exclusions by emptying the list using Group Policy. This yields the best possible performance for integrated extension points because extension points are never re-integrated unless explicitly requested through manifest policy, dynamic configuration, or package updates.
The App-V 5 integration system (that creates and manages shortcuts, FTA’s, Integration Path junction points, etc.) use the roaming exclusions to force integration of extension points that otherwise appear to be up to date by maintaining this list of exclusions and comparing them at logon. At that time, for each package the user has published, all integration and extension points that package has will be checked to see whether it was integrated to a location included in the roaming exclusion lists. If so, that extension point will be re-integrated. Otherwise, no re-integration is necessary.
It was no coincidence that the inaugural release of Microsoft User Experience Virtualization (UE-V) directly coincided with the release of APP-V 5.0 For most modern enterprise user scenarios (BYOD, flexible workspace, mobile computing, etc.) the need to have portable applications that roam user settings across application delivery formats is an essential ask from customers. UE-V also allows more granularity to users and administrators allowing key applications to roam settings without the bloat and overhead of roaming user profiles (yes, I said it.)
As I have been doing with APP-V 5.0 and Office 2013, I am continuing on my theme of aggregating essential content for deploying key elements of newest Windows client solutions. I have compiled this list of essential UE-V resources and like the others, I will update this as additional key content becomes available.
UE-V deployment Guide:
UE-V Cmdlet Resources
Technet Online Administrative Guidance:
UE-V Technet Main Page:
UE-V Technet Forum:
Technet Lab: UE-V Deployment
UE-V Template Resources:
UE-V TechNet Wiki Articles:
UE-V and SkyDrive Integration Not Supported
How to repair an unsuccessful UE-V Uninstall
UE-V and High Availability
How to Verify a Successful UE-V Installation
UE-V Deployment and Setup:
Group Policy Management of UE-V:
Deploying the UE-V Agent with Config Manager
Deploying the UE-V Agent with MDT
UE-V Template Verification Steps and Best Practices
UE-V Registry Settings
How to repair a corrupted UE-V install
Microsoft Office Support in Microsoft User Experience Virtualization (UE-V)
How to troubleshoot UE-V replication issues
UE-V settings replicated by Internet Explorer
UE-V Registry Settings
UE-V Template Verification Steps and Best Practices
UE-V Agent installation fails with error: The Offline Files service is not running
UE-V does not update the theme on RDS or VDI sessions
Microsoft Desktop Optimization Pack Administrative Templates
System Center 2012 Configuration Pack for Microsoft User Experience Virtualization 2.0
By default, Windows firewall blocks Virtual PC 2007 SP1 network activity, and when Virtual PC 2007 SP1 initiates on the client computer, there is a firewall message that blocks its startup sequence and all network access. If you are logged on to the machine as an administrator, you have the option to enable these exceptions.
For newly deployed MED-V Clients where the user logging for the first time are not local Administrators, they will not have this option and they will not have virtual machine network access
The cause of this is an issue by design with Virtual PC 2007 in Windows Vista and Windows 7.
Right now, the current solution is to update the firewall exception by using Group Policy before MED-V is used by the end user. a Domain level group policy is probably the most recommended route to take here.