Why you need to take notice of the .APPX installer framework

At Build 2015 in March, Andrew Clinick said: “APPX is now our deployment model. MSI isn’t going to go away, but we want you to move to APPX. We’re investing all of our efforts into making AppX the ultimate installer across the Windows ecosystem.” At build 2015 however Windows Phone was still being discussed along with “Continuum” (the idea that your phone can be a PC in your pocket) and UWP Apps (which only come in APPX format) were important for Windows Phone. Come build 2016, Windows Phone was missing and many people now regard it as dead.

In May we heard about Appinstaller (with Windows 10 Anniversary Update) allowing you to install an .appx file by double clicking on it.

There has been recent news about Desktop Bridge and the Desktop App Converter. This is about making it easy/easier to move/shoehorn existing apps on to the .APPX model (but not making them UWP Apps). This news was fairly low key and I didn’t find the benefit arguments given too compelling for a corporate environment (Live tiles, Notifications, Cortana Integration, Re-installation of your apps after a broken PC), but there are productivity and admin reduction advantages to self-service app-stores, particularly for apps where licensing is not an issue and admin rights are not required.

For Nano Server, the news is that .APPX is the deployment framework and .MSI has been excluded:  See “Installing Windows Server Apps on Nano Server“. So it appears Andrew is still at work and APPX is still considered to have advantages over the .MSI model.

So the underlying message here for us .MSI Packagers is that although things have gone very quiet on Windows Phone and the Windows Store hasn’t taken off yet we are still going to have to take notice of the .APPX format. The good news (announced at the same Desktop Bridge session) is that the format is now supported by both Advanced installer and Installshield.

To throw in a final titbit, did you know that packages created with the Desktop App Converter use the same techniques as App-V and seemingly you can even use the SDK Tool MakeAppX.exe to Pack & Unpack App-V 5.0 Files.


App-V 5.0 SP2 Integration Issues with Connection Groups

Recently I was attempting to publish a Connection Group and experienced some interesting challenges that I want to share:

My application needed to integrate with Microsoft Visio and Flash player so I published a connection group but the shortcuts failed to appear in my Start Menu. Using the App-V Client UI I could see that I had no Connection Groups listed and the Powershell command Get-AppvClientConnectionGroup also gave me nil response.

Logging onto the publishing server I found a 20001 event in the App-V Client Admin log:

The connection group {c7765ec4-17a2-43be-8a4f-1a84849c7a2d} version {b65411b8-ad8b-419f-bdca-7dd47c28476a} could not be published because the virtual COM settings of the individual packages conflict.  Verify that the virtual COM settings are the same for all member packages and try again.
Error code: 0x8E90070A – 0x3000F


I was unable to find any documentation relating to this error other than a single forum post, but It seems where COM Settings are concerned it’s all for one & one for all. As the message indicates, the fix is to check the virtual COM settings are the same for all the packages in the connection group.

Note: to verify the message relates to a specific Connection Group,  view Connection Groups in the publishing console (if you haven’t found where these are hidden yet, after opening the console click on Packages at the left and a pane slides to one side, TaDa. I’m serious! (Not sure why Microsoft hide it, perhaps the Developer wanted to show off their Silverlight skills).  Once you click on a connection group a “Show Id” option magically appears in the lower pane at the right. If you step through the list of Connection Groups you will see the GUID appear for each one and can match this against the GUID given in the message.

I had used the following settings in Visio via deploymentconfig.xml to get OLE working

<COM Mode=”Integrated”>
<IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”false” />

<Objects Enabled=”true” />

So I changed the settings in my parent app to match – I needed to do this anyway to integrate with Office 2010 which was installed on the build.

This isn’t quite as restrictive as it appears at first. With Flash I didn’t want to change the default settings as it was likely to be a member of other Connection Groups which didn’t have COM integration configured the same and by fixing my connection group this way I was concerned I may introduce the original error to other packages – catch 22. The solution I came up with was to create a UserConfig.XML for Flash with these COM settings in and associate this with the Domain Local AD Group for my parent app after adding the group to the Flash Player package in the Publishing Console.

This did the trick and my Connection Group was published on the next Publishing Refresh. Caveat: this appeared to work but the package never went into production for other reasons so I would appreciate feedback from anyone else who has tried this.

That wasn’t the end of the story, although my shortcuts now appeared in the Start Menu, when I tried to launch the application I got “The application failed to launch. This may be due to a network failure” Error Code 0x5220110A-0004006:

Failed to launch

A “network failure” seemed unlikely to be the problem. Looking again at the App-V Client Admin log on the publishing server I found a 16001 event:
“A conflict was detected in the configuration settings for Virtual Object exclusions in virtual application connection group {c7765ec4-17a2-43be-8a4f-1a84849c7a2d} version {b65411b8-ad8b-419f-bdca-7dd47c28476a}. The virtual application could not be started. Verify that the settings are correct and try again.”

I could see this had the same GUID as my Connection Group but it wasn’t particularly helpful. As it mentioned Virtual Object Exclusions, I decided to switch on the Debug log for Subsystem-Vobjects and try again. Lo and behold a new message appeared:

Event 122

This technet blog post gives some idea what the * relates to:
http://blogs.technet.com/b/gladiatormsft/archive/2013/11/05/app-v-on-named-kernel-object-virtualization-a-k-a-the-vobjects-subsystem.aspx and why it’s not something we want in the package itself particularly as we have <Objects Enabled=”true” /> set in the XML

Unfortunately the message does not identify the problem package but I suspected this related to Visio and I was able to use Gridmetric Application Virtualisation Explorer to prove this (I also could have removed Visio or Flash from the CG to eliminate) and resolve the issue by viewing Object isolation exclusions and unticking the “Exclude all objects from Isolation” option:


Without AVE I would probably have had to resort to re-sequencing the package from scratch as the sequencer provides no interface to edit the exclusions.