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.
For the past couple of years, Microsoft has been advising customers of the planned end of extended support date for Windows XP. We’ve even been using a countdown clock on the Windows XP page (http://www.microsoft.com/en-us/windows/enterprise/end-of-support.aspx ) In fact, you’ve probably also been made aware of or have seen first-hand the end of notifications that are now popping up on Windows XP machines. You may have also recently read this as well:
The update KB 2934207 (Information Here – http://support.microsoft.com/kb/2934207) also adds in a notification prompt (which some in the press have affectionately referred to it as the “Death Notice.”)
If you are not seeing this update, it is likely because your Windows XP machine is being managed by WSUS, or Configuration Manager, or through the cloud with Windows Intune. Only Windows XP machines (Windows XP Home and Professional editions) who receive updates via WindowsMicrosoft Update will see these notifications.
If for some reason you are receiving these notices and you would like to disable them, you can do so in the registry under the one of the following keys:
Set the value of DisableEOSNotification (DWORD) to 1 to disable notifications. ) enables it.
Regardless of this change, the fact remains that end of all support except for custom support agreements is still April 8, 2014. If you are still running Windows XP in *ANY* form (physical desktops, VDI, MED-V, etc.) this affects you. Without a CSA, you will receive no further security updates and you run a risk of being vulnerable after that date. Also bear in mind that if you are virtualizing Internet Explorer 6, 7, or 8 with any non-Microsoft application virtualization solution, you will be indirectly affected as well.
Consumers, and Small-to-Midsize customers looking to update, can receive special offers and discounts via out Get2Modern page here: http://www.microsoft.com/en-us/windows/business/retiring-xp.aspx
A Custom Support Agreement (CSA) requires a Premier Services Agreement with Microsoft. If you are current an enterprise customer with a Premier contract, we have been making some changes to the Windows XP Custom Support Standard Program, which provides critical security updates, technical assistance and continued support for the product after April 8th. Please contact your Technical Account Manager (TAM) for more information.
Please note. This applies to Windows XP and NOT Windows XP Embedded. Windows XP Embedded is a different operating system designed for specialized OEM embedded devices and it has always ran on a different support lifecycle ending in 2016, which has been in place for a while in spite of what you may have read in articles out there on the Internet.
If you believe in the openness, freedom, and affordability of the Internet, this blog is very important. – http://blog.netflix.com/2014/03/internet-tolls-and-case-for-strong-net.html
If you are currently still running MED-V 2.0, be very aware of a known issue. If you install the RDP/RDC 8.1 update for Windows 7 SP1, you may notice after installing the update, you are seeing application crashes of the MED-V Workspace. This update is labeled KB2830477. It was originally released last year and there were sporadic reports of problems with MED-V hosts running it. It has recently been re-released (February 11, 2014) and I have noticed many more reports of this occurring. This issue has been reported for both XP Mode and MED-V in the Technet forums as well.
Right now, there is an investigation ongoing. I would advise in the meantime that you do not install this update on MED-V hosts. If you have already installed this update on MED-V hosts and are experiencing the problem, you can simply uninstall the update and the issues should disappear.
Please note that this is an optional update. This update is not needed for MED-V or Windows 7 functionality. It is not a security update either. It may provide enhanced features if you need to connect your Windows 7 host to Windows Server 2012 or Windows Server 2012 R2-based RDP Sessions or RemoteApps.
Here is the subsequent KB article on the update:
KB2830477: “Update for RemoteApp and Desktop Connections feature is available for Windows”
Microsoft has already announced that one of the World Finalist teams in its 2014 Imagine Cup student competition will get to meet co-founder Bill Gates. Now there’s word that the company will give the winners in three of its categories some extra prizes in the form of software boot camps and experiences.
Sequencing Templates (.APPVT) files are designed for automating the sequencing of applications. While you can take advantage of some of the benefits of templates with manual, interactive sequencing, be careful making assumptions when sequencing following the importing of a template in the Sequencer GUI. Sequencing Templates are also essential for the upgrading of packages.
Remember this from the App-V Sequencing Guide:
“Templates are also very important for upgrade scenarios. The Sequencer does not save state so when a new Sequencer session is open and a package is opened for upgrade, the settings are in the default state. If certain sequencer settings were changed when sequencing a package, the changes will not remain at time of upgrade. Therefore, it is recommended to save a template for any package that has Sequencer customizations, and re-apply them on upgrade. A template may also contain additional options such as Package Deployment Settings and Advanced Monitoring Options.”
Creating a Sequencing Template
Creating a sequencing template is pretty straight forward. You launch the App-V Sequencer and first set your advanced options for sequencing. You do this by going to the “Tools” menu and selecting “Options.”
All of the General Items and Exclusion Items can be adjusted using this dialog box. All of these settings will be saved into the template.
If you plan on only using these settings in your template, you can proceed to save as template using the “File” menu to “Save as Template.” However, if you want to include additional settings (for automated sequencing with PowerShell) instead of saving as template, proceed and go through the process of creating a blank dummy package. Make sure you click through to the advanced options so you can configure:
- Operating System Options
- Advanced Interaction
Once you have all of these settings the way you want them then you can proceed to save the template. Notice you will get a specific alert when doing so.
While it implies that the additional settings (OS, COM, objects) will not be saved in the template, you will find that they are, in fact, saved. What the effect of this message is any settings other than General Options or Exclusion Items will NOT be imported if you import the template into the sequencer GUI for the sequencing of a new package.
All of the settings will however be used if the template is used in conjunction with the New-AppVSequencerPackage PowerShell cmdlet. It will support the use of all of the template items. The use of PowerShell with templates opens the door of many possibilities for automating the sequencing of your packages. Here is an example:
Once the package has been created, you can verify the configuration held by observing the information in the App-V manifests.
Throughout my tenure while working in support, I would occasionally come across issues where the issue I was troubleshooting with a particular product was the actual installation. Too often the error would be some generic error (with an error code of 1603 or something similar) or one of those “unexpected errors.”
One way to get to more detailed information was to enable advanced debug logging of the Windows Installer service. You can enable advanced logging for a particular package by using the following synatx when attempting to run the installation:
Msiexec /i <path to your .msi package> /L*V C:\Setup.log
where the “L*V” is what enables the Windows Installer to create a verbose log file.
But what if you want to turn on debug logging for not just the packages being installed, but also for the Windows Installer service itself? This was used to isolate the strict name checking issue with App-V 5 MSI wrappers. You will need to do what we call the “Voice Warmup” trick. It gets its name from the fact that enabling all options spells out “voicewarmup.” To do so, do the following
1. From an elevated command prompt, stop the Windows Installer Service if started:
net stop msiserver
2. Open up the Registry Editor.
3. Navigate to the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
4. Create a new string value (REG_SZ) called “logging.” (No Quotes)
5. In the data field, type “voicewarmup!” (No Quotes)
6. In the same key, you will also need to create a new DWORD value called “debug.”
7. In the data field, type “7.”
8. Exit the Registry Editor.
9. Restart the Windows Installer Service.
net start msiserver
After you install (or attempt to install) the application, the log files will be located in %TEMP%.
I would advise not keeping these values in place on a production server.