scripting

AppV5 – Sequencing an application that has Com+ Applications

2015-12-04
/ / /

AppV has a few weaknesses, one of them is Com+ Objects.  It doesn’t like Com+ Objects and sequencing an application with them generally results in this error message:

The Resolution seem easy enough:
1) Try extracting and installing the COM+ component natively on both sequencing station and the client
2) Thoroughly test your virtual application package to verify functionality.
But how do you extract the COM+ components?
1) Open ‘Component Services’
2) Expand until you find your Com+ Applications, right-click and select ‘Export’
3) Click ‘Next’
4) Enter a path to save your MSI then click ‘Next’
5) Click ‘Finish’
Since this application had two Com+ Applications I exported my second one as well:
To ensure they work, I took them to our XenApp Test server and installed them.
Both *appeared* to have installed correctly.  But this application requires the Com+ Application to run under a service account.  Checking the original install:
I can see under the ‘Identity’ tab that it is configured for ‘This user:’.  I then checked the MSI install on the XenApp Test server and looked at the Identity tab:

 

It appears it defaults to ‘System Account’ even though I selected ‘Export user identities with roles’.  To change the user account silently, I used this script supplied by the vendor (as a encrypted vbe):
This script changes the user account on the Com+ applications to use the proper account.  When browsing the properties of the components of the SFSQL object I saw it referenced the dll to it:

 

 

Fortunately, it seems these files are captured by the MSI export of the Com+ Application.
To test everything now, I must now create my AppV package.  Before doing the install I installed my prerequisites (the Com+ Applications) into the Sequencer so they are not captured by the package.
I ran this script to do my prereq install:
Now I startup the sequencer and do my sequencing first steps.
I selected a batch file I created for the install (per the vendor’s initial instructions):
Once the install completed I saved my package and took it to my XenApp Test server and published the application and ran it.
No, this is not correct
For some reason my application was failing.  I double checked the COM+ Applications are installed and appear to be working, so I opened Procmon.exe to see if I can find where it’s going wrong:
I’ve used procmon enough now to practically pull the old’ Matrix, “blonde, brunette, red head“.  Working from bottom to top, the message box is generated from the ‘Text’ (LanguagePack) back to the KernelBase.dll.  So we can exclude that has the cause, this is telling us *of* the issue.  So if we look at the lines preceding it, one of them must be causing our message.
Looking at the first keys, the OLE keys, I can compare them to my sequencer and they match exactly, so the likelihood of them causing our issues is none.
So we go back a little further to the AppID key and jumping to the *SUCCESS* location to look at it’s value…
I am on a server called WSCTXAPP301T but the registry key for this value is pointing to the system I did my sequencing on.  I changed the value to the actual server name and did a registry search for “WSAPVSEQ07” to see if it appeared anywhere else.  It did in one other location so I modified the value there as well to point to the local server:
And tested my application again:
Success!  The login screen.  This is as far as I can take this app until I get credentials or a user to login and try testing for me.  So, for now, I can create a preflight-script to setup some prerequisites when the application is published.  I modified my preflight script to include the two registry values being updated:

Then I updated the Deployment_Config.xml file for this application:

Lastly, I logged onto a new, fresh, system and manually tested my XML file by publishing from the command line:

Using Procmon to monitor to ensure the prerequisites get installed:

“Exit Status: 0” –> Usually a good thing 🙂

Testing the application:

Looks good

Then testing removal and monitoring with Procmon:

Com+ Application are removed cleanly 🙂

So everything looks good and I can now add this application to our AppV Management Server and deploy it to the machines that need it.

Read More

AppV5 – When Application Compatibility Toolkit doesn’t work

2015-11-27
/ / /

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:TMPComputerName) 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:ProgramDataMicrosoftAppVClientIntegrationD8E3DB68-4E48-4409-8E95-4354CC6E664BRootVFSProgramFilesX64dlc11.2TMP) 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:ProgramDataMicrosoftAppVClientIntegrationD8E3DB68-4E48-4409-8E95-4354CC6E664BRootVFSProgramFilesX64dlc11.2TMP

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.

Read More

AppV5 – Prelaunch Script for Citrix XenApp 6.5 applications with varying environments

2015-07-07
/ / /

We utilize a lot of pre-launch scripts for our AppV5 applications that we use in our Citrix XenApp 6.5 environment.  They become a necessity very quickly as AppV5 stores the executable down a very long path.  Citrix XenApp 6.5 has a maximum launch string of 160 characters and this maximum prevents a lot of applications from working if they require parameters to be passed to them.  An example looks like this:

This launch path is too long for XenApp 6.5.  The string will be truncated and the program will fail to launch properly.   We have several environments that work with the same package files so we set them as variables.  To get this package to launch properly we create a prelaunch script that looks like so:
At this point we set our application to point to this CMD file.
And the application will launch with the shorter string with the ability for us to change the environment and location quickly and easily.
Read More

AppV5 – Recipe for Epic 2012

2015-07-03
/ / /

Prerequisites:
AppV5 – Sequencing first steps

Recipe:

I create install.cmd files for all of my applications so that, if required in the future, I can re-sequence an application quickly completely through script or via one of those ‘PowerShell AppV5 automated GUI’s’.

install.cmd

Supplemental files:
None
 
 
1) Select ‘install.cmd’ and click ‘Next’
2) Name the package and click ‘Next’
3) Let the install script do its thing (note the clock)…

4) AppV5 – Post install sequencing steps

5) Review for any extra registry keys/files (generally there are none or very few) and remove and save the package.

6) In order for Epic to launch in a reasonable amount of time, registry staging must be done.  Without a pre-executed registry staging, first launch performance of Epic can take hundreds of seconds.

Read More

AppV5 – Recipe for ScreenTest III

2015-07-03
/ / /

This is the most recent app I sequenced and a good template for how I am going to do my recipes.

Prerequisites:
AppV5 – Sequencing first steps

Recipe:

I create install.cmd files for all of my applications so that, if required in the future, I can re-sequence an application quickly completely through script or via one of those ‘PowerShell AppV5 automated GUI’s’.

install.cmd

Supplemental files:
odbc.reg
 
 
 
1) Select ‘install.cmd’ and click ‘Next’
2) Name the package and click ‘Next’
3) Let the install script do its thing…

4) AppV5 – Post install sequencing steps

5) Review for any extra registry keys/files (generally there are none or very few) and remove and save the package.

Read More

AppV5 – Post install sequencing steps

2015-07-03
/ / /

1) Check ‘I am finished installing’ and click ‘Next’

2) Wait out the ‘Collecting system changes’…

3) You may choose to ‘select’ your application and click ‘Run Selected‘ then click ‘Next’

4) Click ‘Next’

5) Select ‘Customize’ and click ‘Next’

6) Select ‘Force applications to be fully downloaded’ and click ‘Next’

7) Select ‘Allow this package to run on any operating system’ and click ‘Next’

8) Select ‘Continue to modify this package without saving using the package editor’ and click ‘Next’

9) Click ‘Close’

Read More

AppV5 – Sequencing first steps

2015-07-03
/ / /

I follow a specific pattern when sequencing my applications.  I’m going to put the same first steps for every application I sequence here.

1) Open the ‘Microsoft Application Virtualization Sequencer’ and select the menu ‘File’ then ‘Load Template…’

2) Browse to and select your template.

3) Click OK

4) Click ‘Create a New Virtual Application Package’

5) Click ‘Next’

6) Click ‘Next’

7) Choose ‘Standard Application’ and click ‘Next’

Read More

HPSIM – Disable system monitoring for 1 hour

2015-03-27
/ / /

This script will disable monitoring in HPSIM for 1 hour.

 

Read More

AppV5 – Data Precache script (used for XenApp)

2015-03-20
/ / /

This is the AppV5 Data Precache script we use to load our AppV5 packages on our Citrix XenApp servers.  Because we use PVS and store the AppV package installation root folder on a persistent disk, we sometimes encounter issues that require us to ‘clean up’ the package installation root folder before the AppV5 packages will load.  What this script attempts to do is setup AppV5 as if it’s a new install, grab any packages from the publishing server, then, if sharedcontentstore is disabled, fully mount/load the packages.

AppV5DataPrecache.cmd

 

Read More

PVS Target Device Update Script — Supplemental File, 1_pre-get_partition_and_netinfo.cmd / 2_post-remove_nonpresent_hardware_v33.cmd

2015-03-20
/ / /

These are two scripts we use to remove nonpresent hardware from device manager.  These devices are generated when we update the Target Device Hardware and VMWare Tools and sit unused so are removed.  If there is ever modifications to the vDisk that generate additional hardware this script ensures the vDisk is as clean as possible. You’ll need devcon.exe as well.

1_pre-get_partition_and_netinfo.cmd

2_post-remove_nonpresent_hardware_v33.cmd

 

Read More