Posts Tagged ‘citrix’

App-V 5 and Citrix Integration Resources

September 9, 2014 2 comments

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 Official App-V 5 Version Support Matrix for XenDesktop or XenApp and App-V 5.0

Choosing an application and desktop delivery method

XenDesktop 7.5 and XenApp 7.5 Features and Entitlements

Reviewer’s Guide XenDesktop 7.5

Citrix App-V 5 Integration: Internals

User Profile Management and App-V 5  – Required UPM exclusions for App-V

Random Application Fails When Using Standard Image Mode with the “Write Cache on Target Hard Disk” Option

Troubleshooting App-V 5

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:

Citrix EDocs on App-V 5 XenDesktop 7.1 Studio Publishing Integration:



App-V 5 and Citrix Integration

Microsoft-Citrix Virtual Desktop Infrastructure Technical Whitepaper 


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

August 21, 2014 2 comments

Last year, I wrote a blog post on registry staging in App-V and how it can affect initial publishing times – particularly on VDI ( 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 ( 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 @ #msTechEd 2014 – View the recordings in case you missed it!

May 17, 2014 3 comments

We had quite a few breakout sessions on App-V at TechEd North America this year! If you were there and were not able to attend all of them or missed TechEd altogether, you can view the recorded sessions here on Channel 9:

My Presentation 🙂

Sizing App-V 5.0: Planning and Designing a Highly Available, Scalable, and Resilient Management and Delivery System

Then we have an excellent presentation by Briton Zircher on deploying Office 2013 with App-V 5:

Everything You Need to Know for a Successful Microsoft Office 2013 App-V Deployment

You also will want to see Project VRC's presentation on their independent performance analysis of App-V 5.

Project Virtual Reality Check: Microsoft App-V 5.0 Performance, Tuning, and Optimization (App-V PTO)

Are you thinking about or planning to deploy App-V 5 with Citrix XenDesktop and studio integration? You will want to see this:

Deploying Microsoft App-V 5.0 and Citrix XenDesktop 7

New to Intune? Want to understand how applications are managed with Intune? Want to know your App-V options with Intune, check out this presentation:

Application Management with Microsoft System Center Configuration Manager and Windows Intune

Finally, my favorite of the event – done by the Virtual Vibe guy himself -Thamim Karim:

The Circle of Life for an App-V 5.0 Package: From Sequence to Termination

App-V 5 and Citrix Integration: New Whitepaper

October 30, 2013 4 comments

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 –

App-V: On Registry Staging and how it can affect VDI Environments

September 25, 2013 15 comments


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:


Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>

Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>



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.


Why is Internet Explorer Crashing on Shutdown? An interesting App-V-related Issue . . .

November 20, 2012 Leave a comment

Recently, I came across something very interesting. I was working with a customer who was working with several internally developed applications that leveraged HTML files by creating links that would open them inside the user’s default browser. These applications can easily be virtualized with both App-V 5.0 and 4.6 (VAE, <LOCAL_INTERACTION_ALLOWED>)

What was happening was that these applications were behaving oddly when running virtualized with App-V. The applications would trigger the local browser (running outside the bubble) for these help documents (in this example, Internet Explorer 8.) While there were no issues with this particular function, every time a user would close one of the Internet Explorer windows containing one of these documents, the window would disappear as normal. Then, almost a second or two later, a window would pop up stated that the application had crashed.

Oddly enough, we knew pretty quickly that this had to be somewhat environmental because we could never prove these issues on a vanilla test machine. This was not due to a limitation or a potential code defect within the App-V virtualization engine. After rudimentary elimination of all factors (I.E Settings, App-V, GPO, branding from the IEAK) – we decided to just cut to the chase and debug it with WINDBG to determine why we could not reproduce the issue outside the customer’s environment.

Of course there are several ways to collect user dumps (process dumps.) In this case, the issue was happening on Windows 7 so often, the default AE (Application Experience) debugger – WER (Windows Error Reporting) will suffice. We configured WER to generate a user dump by making a few registry changes.
We gave the customer the following .REG file to import into one of the offending machines.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps]
This created a full user process dump and it put the location of the user dumps in the C:Dumps folder.

Then once we had the user dump we took a look at the stack trace of the corrupting shutdown thread inside of WINDBG:

0:000> k
ChildEBP RetAddr 
0013f714 77476a04 ntdll!KiFastSystemCallRet
0013f718 75656a36 ntdll!NtWaitForMultipleObjects+0xc
0013f7b4 75dfbd1e KERNELBASE!WaitForMultipleObjectsEx+0x100
0013f7fc 75dfbd8c kernel32!WaitForMultipleObjectsExImplementation+0xe0
0013f818 75e105df kernel32!WaitForMultipleObjects+0x18
0013f884 75e1087a kernel32!WerpReportFaultInternal+0x186
0013f898 75e10828 kernel32!WerpReportFault+0x70
0013f8a8 75e107a3 kernel32!BasepReportFault+0x20
0013f934 774a7f02 kernel32!UnhandledExceptionFilter+0x1af
0013f93c 7744e324 ntdll!__RtlUserThreadStart+0x62
0013f950 7744e1b4 ntdll!_EH4_CallFilterFunc+0x12
0013f978 77477199 ntdll!_except_handler4+0x8e
0013f99c 7747716b ntdll!ExecuteHandler2+0x26
0013f9c0 7744f98f ntdll!ExecuteHandler+0x24
0013fa4c 77476ff7 ntdll!RtlDispatchException+0x127
0013fa4c 5483ccd4 ntdll!KiUserExceptionDispatcher+0xf
WARNING: Frame IP not in any known module. Following frames may be wrong.
0013fd60 7748d690 <Unloaded_PseudoServerInproc.dll>+0xccd4
0013fd7c 7748e3d9 ntdll!RtlProcessFlsData+0x57
0013fe14 7748e12f ntdll!LdrShutdownProcess+0xbd
0013fe28 75e0bbd6 ntdll!RtlExitUserProcess+0x74
0013fe3c 775836dc kernel32!ExitProcessStub+0x12
0013fe48 77583371 msvcrt!__crtExitProcess+0x17
0013fe80 775836bb msvcrt!doexit+0xac
0013fe94 0103129e msvcrt!exit+0x11
0013ff1c 75dfed4c iexplore!__wmainCRTStartup+0x164
0013ff28 7749377b kernel32!BaseThreadInitThunk+0xe
0013ff68 7749374e ntdll!__RtlUserThreadStart+0x70
0013ff80 00000000 ntdll!_RtlUserThreadStart+0x1b
There was this external DLL (not part of the standard Windows build) that was loaded into the stack and ad appeared to be partially or fully unloaded by the time that WER could capture the exception. We wanted to see if this DLL was being injected by way of AppInit_DLLs key. At the time, we did not know what this particular DLL was part of. All we knew was PseudoServerInproc.dll appears to be an unknown DLL that was injected into the IE process
We went to AppInits_DLL in the registry and found the MFAHook which is a commonly known master hook DLL used in Citrix products. We disengaged all DLLS in that Key by using the following .REG file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindows]
The issue immediately went away. Now that we knew it was tied to one of ythe Citrix products being leveraged on the machine, we went back to the AppInit_DLL key to examine MFAHook. This will require us going further to investigate which specific hook DLL is the issue. We know the DLL was PseudoServerInproc.dll
So we went into the Citrix configuration to get all of the specific hook agents and the processes they inject into and found our DLL under the following registry key:
Key: HKEY_LOCAL_MACHINESOFTWARECitrixCtxHookAppInit_DllsHDXMediaStreamForFlash
Value: FilePathName
Data: C:\Program Files\Citrix\ICAService\PseudoServerInproc.dll

A subkey denotes the exe’s it hooks into:
We found that by deleting it – this also fixed the issue. Upon further investigation with Citrix, we found that this was related to a known issue with one of there products from their VDI suite – AND – they already had a fix for this issue (which worked like a champ!~)

More info here:

On a side note, if you want to use a more extensive tool for collecting these kind of crashes for analysis, I would highly encourage you to download ProcDump and configure it to be your default application experience debugger. You can enable it by importing the following .REG file:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAeDebug]
“Debugger”=”C:\procdump\procdump.exe /accepteula -ma %ld C:\Dumps”

[HKEY_LOCAL_MACHINESOFTWAREWoW6432NodeMicrosoftWindows NTCurrentVersionAeDebug]
“Debugger”=”C:\procdump\procdump.exe /accepteula -ma %ld C:\Dumps”

“Debugger”=”C:\procdump\procdump.exe /accepteula -ma %ld C:\Dumps”

“Debugger”=”C:\procdump\procdump.exe /accepteula -ma %ld C:\Dumps”
This will register Procdump as the default post-mortem debugger instead of WER. It will intercept the exception and will store a dump file in the specified folder.

Error when you Attempt to Delete a Package using the XenApp Connector for Configuration Manager 2007 R2

September 7, 2011 Leave a comment

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.

Categories: Uncategorized Tags: , , , , ,