Archive
App-V 5 and Citrix Integration Resources
Whether it is integration with XenApp, XenDesktop, PVS, or UPM, App-V 5 is the recommended application virtualization and streaming model for Citrix Session and VDI environments. I work with a lot of customers who leverage App-V in this capacity and they have been asking me to maintain a “living post” that contains links and references to Citrix and App-V 5 integration resources.
So with help of App-V 5 SEE John Behneman, (you may recognize him from the official App-V support blog) below is a collection of Citrix KB and documentation links related to App-V 5.0 when integrated with Citrix technologies:
(Page will be updated)
Citrix-Hosted
Citrix Official App-V 5 Version Support Matrix for XenDesktop or XenApp and App-V 5.0
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-hosted-apps-intro.html
Choosing an application and desktop delivery method
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-apps-compare-delivery-methods.html
XenDesktop 7.5 and XenApp 7.5 Features and Entitlements
https://www.citrix.com/go/products/xendesktop/feature-matrix
Reviewer’s Guide XenDesktop 7.5
http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/xendesktop-reviewers-guide.pdf
Citrix App-V 5 Integration: Internals
http://blogs.citrix.com/2013/12/23/citrix-app-v-integration-internals/
User Profile Management and App-V 5 – Required UPM exclusions for App-V
http://support.citrix.com/proddocs/topic/user-profile-manager-5-x/upm-using-with-app-v.html
Random Application Fails When Using Standard Image Mode with the “Write Cache on Target Hard Disk” Option
http://support.citrix.com/article/CTX139627
Troubleshooting App-V 5
http://support.citrix.com/proddocs/topic/xendesktop-71/app-v-troubleshooting.html
Citrix EDocs on App-V XenApp 6.5 Publishing: Note that they redirect you to how to publish App-V 5 apps with Server 2012 RDS:
http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-pub-app-v.html
Citrix EDocs on App-V 5 XenDesktop 7.1 Studio Publishing Integration:
http://support.citrix.com/proddocs/topic/xendesktop-71/cds-get-started-current-configure-app-v.html#cds-get-started-current-configure-app-v
Microsoft-Hosted
App-V 5 and Citrix Integration
http://www.microsoft.com/en-us/download/details.aspx?id=40885
Microsoft-Citrix Virtual Desktop Infrastructure Technical Whitepaper
http://download.microsoft.com/download/1/7/C/17C16807-317A-4EFE-8197-16E76CB04D18/MS-Citrix%20VDI%20Whitepaper.docx
Community Resources
App-V: A Configuration Template for Deploying to Stateless RDS Clients on Citrix Published Desktops with Citrix UPM for Profile Management
App-V 5: Revisiting Registry Staging
Last year, I wrote a blog post on registry staging in App-V and how it can affect initial publishing times – particularly on VDI (http://blogs.technet.com/b/gladiatormsft/archive/2013/09/25/app-v-on-registry-staging-and-how-it-can-affect-vdi-environments.aspx) and many people wrote me to tell me it was very helpful in reducing publishing times. This was especially important especially for those non-persistent VDI and RDS/XenApp environments.
A colleague at Microsoft recently reminded me of an alleged “controversy” regarding our registry staging configuration recommendations within current recommended practices that has grown out there in the webosphere. As App-V 5 has changed a lot with service releases and hotfixes over the last two years, have my recommendations changed? Well . . . it depends.
After Service Pack 2 and definitely after Hotfix 4 for Service Pack 2, App-V 5 has improved in terms of publishing time and has been adjusted to work better with user environment management solutions and non-persistent environments.
When questioned about whether the previous blog article is valid or not still post App-V 5 SP2 HF4, customers refer to the TechEd 2014 presentation by Login VSI (https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B362#fbid=) on App-V 5 performance in VDI environments. [This was an excellent presentation by Login VSI and prior to the presentation, Ment van der Plas and I discussed the findings prior to the presentation.] Customers are basically asking me, “Are they right or are you right?”
We are both right – within the right context. My article discussed how disabling background registry staging would reduce the time to complete publishing. The net effect of this means that registry staging would be shifted to on-demand which means the staging begins upon first launch. In essence, we are punting – to use an American football analogy. However, there are no free lunches in nature – and that includes computer science. So to decrease the publishing time, we are moving the burden to the application’s first launch. Could this cause a performance hit on launch? Yes – especially for applications with large registries. Turning back on background registry staging will allow the registry staging to occur prior to first launch which reduces overhead on the application initial launch. This is why Login VSI is right to say this value has a negative effect on first launch.
Am I wrong in the sense that I should have specifically pointed this out more clearly in my article? I will concede that. 😉
App-V 5: Why are all of these Different Language Shortcuts Displaying in my Start Menu?
If you have been using App-V 5 SP1 with RDS (Remote Desktop Services) or Citrix XenApp servers, you may have noticed that when you installed the App-V 5.0 Service Pack 1 RDS Client using the EXE installer (no extraction) – this creates shortcuts for all 24 language packs on the start menu for Windows Server 2008 R2 machines. This was indeed a mistake which has been corrected with the SP2 EXE installer.
However, you may have noticed the SP2 version of the EXE installer still installs all of the 24 language packs. You will not notice this in any shortcuts but it will be visible in the Programs Control Panel as well as the App-V client installation folder. This is by design as the RDS EXE installer installs all the language packs so as to be able to service users from multiple locales by default. If you only want to install a certain language pack, I would advise for you to extract the MSI for the client and subsequent language packs by using the /LAYOUT and /layoutdir switches to extract the MSI files out.
More information on these switches can be found here: http://technet.microsoft.com/en-US/library/jj713460.aspx
Then you can install the MSI separately and will also allow you to suppress reboots for silent deployments using the /norestart switch. Bear in mind the EXE installer also detects (and applies if not found) some (but not all) prerequisites. Remember these will have to be deployed in advance when installing the App-V Client using the MSI installer.
App-V 5 and Citrix Integration: New Whitepaper
Ever since the summer (TechEd) I have been promising customers we would have a white paper coming on this. Well, we have just published a new App-V 5.0 and Citrix
integration overview white paper.
Whitepaper Title: App-V 5.0 and Citrix Integration overview
Abstract: This whitepaper is designed to provide administrators with guidance for combining Microsoft’s App-V 5.0 and Citrix solutions. It discusses the benefits of an App-V 5.0 and Citrix combined solution, and includes recommendations for Citrix images, App-V cache management, App-V management with Citrix, and other factors that impact user experience and administrative effort. Whether you are using XenApp or XenDesktop, this paper will be a must read!
It is available to download here
(Direct Link – http://download.microsoft.com/download/C/4/1/C416F9FD-1B51-4E1D-9DBE-87C12AB329A2/App-V5_and_Citrix_Integration_Overview.docx)
App-V: On Registry Staging and how it can affect VDI Environments
UPDATE: PLEASE READ THIS AFTER READING THIS ARTICLE: http://blogs.technet.com/b/gladiatormsft/archive/2014/08/22/app-v-5-revisiting-registry-staging.aspx
The App-V 5.0 Virtual Registry is isolated for each application (or virtual environment when using Connection Groups.) With this release, there is a better view into the Virtual Registry subsystem. In fact, the App-V 5 virtual registry is divided into two main parts: The Virtual Registry itself (VREG) and the registry staging subsystem.
The APPV package file is a human-readable set of assets. As many of you may have already figured out, you can simply rename the file to a ZIP extension and browse it from within Explorer. Some of you have discovered the hard ay that you destroy the package once you try to modify it this way. Yes – it is a mechanism for VIEWING ONLY. If you have had a chance to do this, you have probably noticed that each APPV package contains its own registry hive file (.DAT)
This is where all of the registry assets captured during sequencing reside. When a package is being published, part of the overall package publishing includes the staging of the registry. Both registry machine data and user data will occur. The staging allows the virtual registry not just to be made available, but to also set up the opacity configuration and other important relationships with the native registry. This is to ensure that the applications have a consistent view of both. If you launch REGEDIT.EXE inside one of the App-V bubbles, you will see this converged registry.
If you are using a traditional App-V 5 server-based infrastructure, you might find yourself in an interesting situation. When synchronizing with a publishing server for the first time, all of the publishing blocks for all of the applications targeted to that machine or user will be passed down and each application will be published on the App-V client either to the user or globally depending on the target methodology. In addition to shortcuts, file type associations, and other extension point registrations, there will also be the staging of the virtual registry occurring in the background. This staging can produce some significant overhead during these sync and on first launch – and when many applications are being used (as well as applications with thick registries) this overhead can delay availability of those applications. This can be especially critical when using pooled VDI scenarios incorporating SCS (Shared Content Store) because you also have the additional overhead of sparse file creation.
Registry staging occurs upon the initial launching of a package if it has not been completed. It extracts the .DAT file from the APPV Package Root (which was copied from the APPV file) and then copies it again over to %PROGRAMDATA%MicrosoftAppVClientVREG. It will then mount the hive file through a background thread and recreate it in the package registry location inside the native registry. Registry staging will occur for both individual packages and connection groups. The time it takes depends on several factors including the size of the hive.
The native registry locations where these are stored are:
Machine:
Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
User:
Package Registry Staging: HKCUSoftwareClassesAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKCUSoftwareClassesAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
You will also be able to tell if the registry staging for a specific application has been completed as there will be an additional key called RegistryStagingFinished (beneath the <VERSION_GUID> entry.) Registry staging can occur in the background or on-demand. In VDI environments, we are seeing heavy CPU utilization with background staging in some circumstances. You can gain significant improvement by switching to on-demand staging. You can do this by adding the following registry value in the HKEY_LOCAL_MACHINESoftwareMicrosoftAppVSubsystem key
Value: NoBackgroundRegistryStaging
Data Type: DWORD
Data: 1
This is showing to improve first launch experiences in App-V 5 VDI environments.
Error when you Attempt to Delete a Package using the XenApp Connector for Configuration Manager 2007 R2
The following issue may occur when you are using the XenApp Connector for Configuration Manager 2007. When you click to delete a package under the System Center Configuration Manager node – Site Database – Computer Management – Software Distribution – XenApp Publications, you get the following error:
ConfigMgr cannot delete the specified object. Please verify that you have delete access to the selected object and refresh the ConfigMgr Administrator console to verify that another administrator has not moved or deleted the object.
This error occurs in spite of the permissions being correct. In addition, the SmsAdminUI.log will show the following error:
[3][8/31/2011 1:21:04 PM] :Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryExceptionrnFailure deleting management objectrn at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Delete(ReportProgress progressReport)
at Microsoft.ConfigurationManagement.AdminConsole.ConsoleView.ConsoleFormView.DeleteResultItems(Object sender, ActionDescription actionDescription, Status status, IResultObject selectedResultObject, PropertyDataUpdated dataUpdatedDelegate)rnConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
CauseInfo = “4”;
Description = “CSspPkgProgram: Unknown offer error!”;
ErrorCode = 2152205061;
File = “c:\qfe\nts_sms_fre\sms\siteserver\sdk_provider\smsprov\ssppkgprogram.cpp”;
Line = 541;
Operation = “DeleteInstance”;
ParameterInfo = “SMS_Program.PackageID=”SBT00153″,ProgramName=”Microsoft Office Professional 2007″”;
ProviderName = “WinMgmt”;
StatusCode = 2147749889;
This can happen if the assets related to this XenApp package are deleted but the database record has not been deleted. These packages are stored in the same manner as other packages and advertisements. You can connect to the SQL Configuration Manager database and run a SQL statement to delete these records. You will need to know the Advertisement and Package ID’s. You can find this information out for sure by running a SQL Profiler trace while reproducing the issue as shown in the following profiler trace output:
Once you know what needs to be removed, you will need to run the SQL scripts to remove the entries. If you only need to worry about the package, we can simply ignore the advertisement steps and use the package steps.
To remove the stale advertisements, run the following SQL statement:
Select * from programoffers where offerid = ‘advertismentID’
Delete from programoffers where offerid = ‘advertismentID’
– where advertisementID refers to the ID you found in the above trace.
To remove the stale packages, run the following SQL statement:
Select * from smspackages where pkgid = ‘PackageID’
Delete from smspackages where pkgid = ‘PackageID’
– where PackageID refers to the ID you found in the above trace.
Once these are deleted, additional SQL triggers will remove the other remaining references and entries related to these records in other tables.
madvirtualizer
The Mad Virtualizer at Microsoft 