AppV5 - When Application Compatibility Toolkit doesn't work

I have an application that embeds an IE window and generates a small HTML file for some content.  This application has some.....   interesting....  configuration settings that require a folder with "EVERYONE:F" permissions.  This folder cannot be in a path that contains spaces, cannot be a environment variable and the vendor recommends to put the folder on the root of the C: drive as C:\TMP.  To make it more crazy, when launching the application it will generate a folder under the C:\TMP that is locked to the %CLIENTNAME% (e.g., C:\TMP\ComputerName) and every login to the application generates unique files to that session, so technically, each folder underneath TMP is unique to the user.  The vendor actually recommends completely deleting the contents of the TMP folder DAILY.

So why not just store these files in %TEMP% instead?  Great question.  If the vendor made that happen I wouldn't have this lovely blog post.

(Just for a note this application utilized multiple folders on the root of C: as well, TMP being one, since we move our PackageInstallationRoot to a different drive, TMP isn't available on C:)

With that all said, what am I looking to solve?

Well, I don't want to be creating folders on the root of the C: drive as this application will be on our 'generic' PVS Citrix servers and minimizing the potential for pollution on the master image is a goal, having to create a folder and configure permissions is possible and I've done it before but it's not very clean or elegant; really if we're going to do that then we may as well pollute the C: drive.  We want to maintain portability so creating a C:\TMP folder on the master image prevents us from publishing this package on desktops or other systems in the future unless this is well documented requirement.

We've just learned a new trick though, we can try using Microsoft ACT to create a file path shim that redirects the path to a different one.  So let's do that...

The problem.

 I created the shim using the steps from this post.  (C:\TMP;C:\ProgramData\Microsoft\AppV\Client\Integration\D8E3DB68-4E48-4409-8E95-4354CC6E664B\Root\VFS\ProgramFilesX64\dlc11.2\TMP) I then launched the application and...

Huh.  That doesn't look right.

And it didn't work.  I then used procmon.exe to examine to see if it was reading the file correctly:

I see SUCCESS...

Procmon.exe is reporting that it IS reading that HTM file correctly.  So why isn't it being displayed?

I ran across a similar issue on another application and what I found was that the embedded component appears to be running *outside* the bubble.  Since the shim targets applications (in this case prowin32.exe) all reads from prowin32.exe are being redirected by other processes are not.  I suspect (though I have no proof), in this case, that somehow the IE component is breaking outside the bubble and so it's NOT getting redirected.

Can we force all programs to get redirected to the proper path?  Yes, we can.

Using symbolic links we can force any access to the directory to be redirected to the AppV package path.  AppV will then see this is a path within the 'bubble' and redirect *again* to your local profile where the AppV5 writes will take place.

I removed the shim and then executed:

Symbolic Link
mklink /d C:\TMP C:\ProgramData\Microsoft\AppV\Client\Integration\D8E3DB68-4E48-4409-8E95-4354CC6E664B\Root\VFS\ProgramFilesX64\dlc11.2\TMP

Tracing with procmon.exe now showed us this:

And the application now displayed this:

So the application is now working without any issues, all of these 'temp' files are being redirected to a location where they will not be saved between sessions so no cleanup is ever needed.  We need to add the mklink.exe to the DeploymentConfig.xml.



AHS-BDMPHARMACY-PREFLIGHT.CMD:

And we are now done.

AppV5 - Using Application Compatibility Toolkit to solve issues

We have several applications that install folders in the root of the C:\ drive.  For most AppV5 implementations, this wouldn't be an issue but we modify our PackageInstallationRoot folder so the token {AppVPackageDrive} turns into the drive letter specified in the PackageInstallationRoot registry key.  For us, that's the D:\ drive.  This causes an issue because when you sequence an application to C:\ the application has an expectation for it to be there.  Ideally, AppV takes care of that by the use of the tokens, but this breaks down when applications are hardcoded.

So far, we've been able to work around these issues by using junctions or setting the PVAD to the folder as the PVAD acts literally on the value specified, essentially becoming a hard coded, custom, token.

But now we have an application with THREE folders that are installed on the root of the C:\ and the application is hard-coded to look for two of them.

Hello my nemesis's

If we do nothing this is the error we get after attempting to login to the program:

Looking at the appvve we can see the D:\ is coming up with those folders.

So this isn't going to work.  How can we make it work?

Enter Microsoft Application Compatibility Toolkit

After publishing this application on the server, we install ACT on the Citrix server.

Launch the "Compatibility Administrator (32-bit)"

Right-click on "New Database" and select "Create New > Application Fix"

Enter the details and browse to the application and click "Next"

Click 'Next' on the Compatibility Mode screen

Select 'CorrectFilePaths' and then click 'Parameters'

In command line, enter the path that should exist, then a semi-colon divider ";" and then the target path:

C:\webforms;C:\ProgramData\Microsoft\AppV\Client\Integration\A3E3C00D-19F1-47CB-9BA1-464DB85DC3CA\Root\VFS\AppVPackageDrive\webforms

and click "OK"

Try a Test Run.

And the application launches without any error messages!

Click 'Next'

Then Finish.

Click 'Save' then name your database and click "OK":

Save your fix now:

At this stage you now need to put your SDB file somewhere accessible for when the package is published.  We put it on a fileshare.

Now, all we need to is install the fix.

Since we publish our application globally, I added the fix to the DeploymentConfig.xml:

And we are done! The application now works.

Citrix Receiver 4+ rants and "Your apps are not available at this time. Please try again in a few minutes or contact your help desk with this information"

The environment I'm working in is a mix of XenApp 6.5, 5.0 and Presentation Server 4.5.  The 6.5 and 5.0 farm also have a nearly identical test farm.  We've been migrating the applications off the Presentation Server farms and are moving them to XenApp 6.5.  At this point in the migration we have around 5-10 applications left on 4.5 to move, with around 400-450 on the 6.5 farms and probably around 20-30 or so on the 5.0 farms.  These farms utilize a Citrix Webinterface 5.4.2 frontend for web interface and PNA.

We have standardized the environment on mostly Citrix Receiver 3.3 and some 3.4.  Time has marched and we've been tasked with getting Receiver 4+ working the Windows 7/8/10 rollout.  We were not able to do so with the earlier versions of Receiver 4 because things like sort icons into custom folders on the desktop and Start Menu.  This feature came in around 4.2.  In our environment memberships to applications are granted through group membership and Citrix PNA allowed the user to 'roam' from computer to computer only displaying the applications they have access to, as opposed to a bunch of applications they do not have access with the onus on them to pick and choose the correct applications.

So we started work on planning this migration and have started with the latest greatest (as of today) Citrix Receiver 4.3.  We have been able to come close to simulating all the features of the Enterprise editions of 3.3 and 3.4.  Namely:

Citrix Receiver automatically connects and populates a folder (MyApps) in the Start Menu and on the desktop.
No self-service.  Applications are automatically presented to you and defined by Group Membership.
Single sign-on.  Receiver will take your Windows logon credentials to use for authentication.

We do have some outstanding items.  We've set the client to have all applications as 'MANDATORY' which does populate the applications in the MyApps folders; but applications marked as 'Create shortcut on the desktop' in the applications properties in AppCenter are not created.

Anyways, onto the problem.  Now that we have Receiver 4.3 setup, SSON working, PNA working, we logged onto our system and watched the applications populate.

Slowly.

Really Slowly.

Eventually a dialog popped up.

Then another, and another, and another.

And these dialogs are completely custom!  They are NOT native Windows dialogs!

So if you have multiple ones of them, sometimes clicking the X (close button) or OK doesn't work because the dialog appears 'modal' and you need to click the button on the 'active' window.  But you generally don't know which one that is so you have to go through and select each dialog from the task bar and try clicking ok until you magically get lucky and select the one that has priority.  Then you do it all over again as the next primary window *may not be the one on top*.

1 minute 24 seconds to populate 470 applications

Just for giggles, how fast does Receiver 3.3 populate the same list?

8 seconds.  And all the icons show up.

Alright, so you've passed that point and are now looking at your applications.  But they are missing icons!

But not all applications are missing their icons...  Only some.

So let's find out what's consuming all this time and maybe, just maybe, we'll solve our "Your apps are not available" error message.

First thing we need to do is enable Citrix Receiver Logging:


Next is to exit and restart receiver and logs will start to generate.  They are located here:
%USERPROFILE%\AppData\Local\Citrix\Receiver
%USERPROFILE%\AppData\Local\Citrix\AuthManager
%USERPROFILE%\AppData\Local\Citrix\SelfService

The most important log tends to be the 'SelfService.txt' log.  If you search that log for the "Your apps are not available" error message it pops up in locations like this:

So this dialog popped up for an application called 'BMTServe'.  And what does BMTServe look like?

Generic icon!

But BMTServe was not the only application that encountered this dialog.  From my video it popped up numerous times.  Searching the SelfService.txt file for 'Your apps' and looking for the application it references points to an application with a blank icon 100% of the time.  Not every application that produces a blank icon causes this prompt, as we literally have ~250 applications with blank icons and the dialog pops up anywhere from 0 to 10 times.  Sometimes it pops up 2 times, sometimes none, sometimes 10 times.

So, why are these icons blank?

Citrix Receiver 4.3 seems to only prefer 32bit icons or icons of a particular size.  I haven't confirmed what exactly yet, but I do know that 8bit 32x32 icons don't seems to get 'translated'.  The Citrix logs all but confirm this as well.

I confirmed with Citrix that icons are required to be 32bit and the order they are checked is 48x48, 32x32 then 16x16.

This is how Receiver processes icons that are formatted correctly:

The icons were processed instantly. 00:00:00. But if they are formatted in a way that Receiver decides it needs to 'reformat' them:
This call to get an icon took 11.6 seconds!!! If it doesn't get the icon formatted in the way it wants, it appears the SelfService.exe setups a queue of icons that it needs and 're-requests' them from the server. Could it be that Receiver is submitting too many queries? The error mentions to check the authmansvr.txt log file. This log file shows the following:
The error appears to start at "CWindowsReceiver::CallARGetConnectedVpnGateway" When this call is successful it returns:
So, I guess it's possible that trying to re-pull the icon data is causing authmansvr.exe to crash...?  Another crazy thing is I was attempting to automate this process of terminating Receiver and relaunching it to see if I could get a gauge on the frequency of this occurrence and this is what I saw:


Ok, I thought, not so bad.  Just two messages the first couple launches?  It shouldn't be too much of an issue...  But then I looked at my application folder:

Left is when I get all my apps (and usually the message box) the left is all those 'successes'

It appears Receiver removed all applications producing that dialog box.  When I was terminating and relaunching receiver it was ONLY populating 195 applications as opposed to 493 it was supposed to. No wonder I wasn't getting any messages!  On a hunch, I looked at each of the 195 applications it kept and they all had good icons.  I then took a random sampling of about 30 of the 300 or so applications that it did not keep and none of them had proper icons, all blank.  So another bullet towards icons causing my issue.

Force Internet Explorer 10 or 11 to always use 64bit version

I was working on an issue where a user was always prompted to 'Install' the Citrix ICA client.  No matter how many times they downloaded and installed the client it continuously prompted them to install it again from the Web Interface:

I checked the add-on's and saw the following:

No Citrix plugins in site.  I then checked Task Manager to confirm the IE type (32bit vs 64bit) and this is what I saw:

Without the *32, Internet Explorer is running in 64bit mode.  Currently, Citrix does not provide a 64bit plugin to IE so it won't run and it won't be detected.  I then exited IE and browsed to the Internet Explorer folder (C:\program files (x86)\Internet Explorer\iexplore.exe) and attempted to launch iexplore.exe from there.  Still came up as 64bit.  So now this got interesting...  Microsoft does not allow or provide a way to force a 64bit default for IE on Windows 7.

So how is this happening?

It turns out there is a registry key you can set that will force IE to ALWAYS be 64bit:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth (or HKLM)

If the REG_DWORD is 0x0 it will always force IE to be 64bit.  Deleting or changing this value will default IE to 32bit.  So this key *could* be used to force IE to be 64bit.  There is a potential issue to be aware of, this will force IE to use the same process as the launcher for tabs, as opposed to spanning new processes.  Whether that increases/decreases stability would be something you'd have to test.

AppV5 - Integrating Certificates into your AppV package

These are the steps I've found to sequence root certificates into your AppV5 application.



Where do you get certmgr.exe from?

The visual studio downloads apparently contains this tool.

Once you've started your sequencer and run the command it will add the certificate to these two places:
HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\
HKLM\SOFTWARE\Wow6432Node\Microsoft\SystemCertificates\ROOT\Certificates

And that's how you add certificates to a sequenced package.