Thursday, November 26, 2015

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?


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.
at

4 comments:

  1. Vigneshwaran9:07 PM

    Good to know that we have an option with ACT. Thanks for sharing.
    I have one question here.Why not we use mklink? Any special reason to go with shims?

    ReplyDelete
  2. Trentent9:39 PM

    I prefer Shims for a couple reasons:

    1) Shims 'target' an application whereas mklink applies for the whole system. I think you can have two shims for the same directory path (haven't tested but I assume). I prefer targeting if possible because it feels more precise. mklink really feels like a hammer and ACT feels like a laser.

    2) Shims leave more recognizable traces of their purpose. You name the shims (ideally something meaningful) that is displayed in 'Add/Remove Programs'. mklink's only trace is the target directory. The organization we have sometimes has very poorly named shares that could have multiple meanings and makes it confusing to understand which application it is referring to (something like \\files\wt12x63

    Why I would use mklink:

    1) An application that is 32bit on a 64bit system has hard-coded paths to the "C:\Program Files" directory. A junction from "C:\Program Files\App" to "C:\Program Files (x86)\App" is a nice an neat solution.

    2) The application is able to recognize Shims or fails even with a shim in place.

    3) Mklink will create short-paths in NTFS, Shims will not

    Some time ago I found this article that details the difference pretty well. Highly recommended read :)

    ReplyDelete
  3. Vigneshwaran10:53 PM

    Well explained :) Thanks for sharing the article.

    ReplyDelete
  4. Rose C10:42 PM

    This is greatt

    ReplyDelete