• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Broken Database Connectivity in App-V Apps

Written by Dan Gough. Posted in App-V v5.x

Error

In my previous post I described an issue with an in-house developed app that was unable to connect to it’s database when running inside App-V. A few weeks later, different client, different app (Trojan CASPAR), and I encounter the issue again:

Error

SQL Database Logon Error

Form: FrmUserLogin

Procedure: Open database

Error Code: -2147467259

Description: [DBNETLIB][ConnectionOpen (Initialize()()).]General network error. Check your network documentation.

I fixed it previously by disabling the entire virtual registry at the package level; but this was not an  option this time as there were vital registry entries in this package. And unfortunately I didn’t have any ‘network documentation’ to check.

So, I busted out Procmon, but could not find anything that jumped out at me. Then I decided to give SpyStudio a whirl (which by the way is now available free of charge for the full version). The great thing about this app is that it lets you do two captures and compare them; so I did one with the app running natively, and one with the app running inside the bubble. Straight away I could see a big block of different behaviour in green so I checked there first. The broken app was making numerous call to HKLM\System\CurrentControlSet\Services\WinSock2\Parameters:

SpyStudio

 

The package did not contain any registry entries under this location, so I decided to add a pass through path so that the App-V client directs all reads and writes to this key directly to the real registry, bypassing the virtual registry entirely. Under HKLM\Software\Microsoft\AppV\Subsystem\VirtualRegistry is a multi-sz value PassThroughPaths that lists various keys that bypass the virtual registry. I added this WinSock2 key here, closed and restarted the app, and it could then connect without a hitch!

So, next step is to automate applying this key via an App-V script. I stuck with vbscript for this since it’s simple to use, and I already had a script in my toolbox to do the job! Save this as AddWinSock.vbs under the Scripts folder of the App-V package:

Then I added this to DeploymentConfig.xml under an AddPackage trigger:

I did not add a RemovePackage equivalent to undo the change just in case there ended up being multiple apps requiring this fix then removing one could break the others. But if you want to implement it, the function to do so it right there in the vbscript.

Changing this key affects all packages on the client however. So, unless you can find a package that contains and requires entries under the WinSock2 key, which I have not yet come across, then this should be safe to apply – but of course use this at your own risk!

 

Today’s Fixed App-V Apps!

Written by Dan Gough. Posted in App-V v5.x

If you didn’t know, I spend most of my days sequencing and packaging applications, and fixing broken packages. This is just a quick post to detail two App-V 5 apps I’ve fixed today, perhaps the information may be of use if you encounter similar issues on the front line!

Access 2007

This customer had Office 2007 on the base and Access 2007 deployed via App-V so that they could control who had ‘access’ to it (badoom-tish). All worked fine until you tried to export some data to Excel, where Excel would refuse to load with an ‘out of memory’ error. It turns out that Excel just flat out refused to open inside the virtual environment of this package. I suspected that it was because this Access package had been sequenced on a clean machine, making various Office folders and registry keys set to override. Resequencing with Office 2007 already on the base resolved the issue.

In-house App

This in-house line of business application was located on a network share, and the App-V package was simply used to create a shortcut pointing to the exe on the network share. For some reason, it refused to connect to its database when run inside the virtual environment. Since the App-V package contained no files or registry entries, I decided to start my troubleshooting by disabling these virtual subsystems in the package config files. I started with the registry:

<Registry Enabled=”false“>

Hey presto, that worked, but I’m not going to pretend to know the reason why! But sometimes you just have to accept you’ve fixed it and move on, there’s plenty more broken apps needing my attention!

Beware When Sequencing Access Runtime!

Written by Dan Gough. Posted in App-V v5.x

Just a quick post to warn of something I encountered today. I had an application that required an older Access 2007 Runtime (Access 2013 was installed locally). The sequencer picked up Access 2007 as an application along with all of its filetype associations, which I duly deleted in the last tab of the sequencer before saving the package.

However these filetype associations still exist, and after publishing the application, Office 2013 triggers a time consuming self-repair when the user double-clicks on an mdb file.

The solution is to disable these FTA’s from within the configuration files; I could do this quickly by disabling the entire subsystem as my application did not register any. But if your application has some, you will need to comment out all of the Access related ones, which is no simple task as there are so many!

I applied this change to both DeploymentConfig and UserConfig xml files (as I did not know how the app was going to be published):

<FileTypeAssociations Enabled=”false“>

Whilst I was digging around in this file I also noticed an app path was registered. Trying to run msaccess.exe via Explorer’s run box tried to launch the virtual Access 2007 runtime rather than my local Access 2013. It would be possible to disable this entire subsystem also:

<AppPaths Enabled=”false“>

However my application had an app path I wished to keep so I just commented out the ones I did not require:

<!–Extension Category=”AppV.AppPath”>
<AppPath>
<Name>MSACCESS.EXE</Name>
<ApplicationPath>[{ProgramFilesX86}{~}]\MICROS~1\Office12\MSACCESS.EXE</ApplicationPath>
<PATHEnvironmentVariablePrefix>[{ProgramFilesX86}]\Microsoft Office\Office12\</PATHEnvironmentVariablePrefix>
<ApplicationId>[{ProgramFilesX86}]\Microsoft Office\Office12\MSACCESS.EXE</ApplicationId>
<CanAcceptUrl>1</CanAcceptUrl>
</AppPath>
</Extension>
<Extension Category=”AppV.AppPath”>
<AppPath>
<Name>MsoHtmEd.exe</Name>
<CanAcceptUrl>1</CanAcceptUrl>
</AppPath>
</Extension>

Remember these config files are not used by default when either publishing from the App-V Mangement Server or installing from the MSI so they will need to be specified. If you are using the MSI packages I have a solution to import the config files over here.

 

Fix for Mouse Freezes in App-V Apps (.NET 4.5.2 and WISPTIS.exe)

Written by Dan Gough. Posted in App-V v4.x, App-V v5.x

You may have seen Nicke Källén’s blog post about this issue recently along with some workarounds provided by the App-V community:

http://www.applepie.se/app-v-and-wisptis-exe

Microsoft have now however provided an official fix in the form of an update rollup to the .NET Framework, I recommend anyone using App-V apply this as soon as possible!

http://support.microsoft.com/kb/3026376/en-us