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.

Advanced Installer Evaluation

A few months ago I carried out an evaluation of Advanced Installer from Caphyon in comparison with InstallShield and decided I should share this on my Blog for the benefit of anyone else who may be trying to choose an MSI Packaging tool as I couldn’t find many other people offering reviews:

1.1         General

Advanced Installer uses a similar 3 pane view to Installshield with main areas of functionality listed down the left hand side. This view can be easily customised to only include features you use (e.g. I removed Game explorer). The screenshot view below has been customised to just show the most relevant features. You will notice there is no shortcuts option, shortcuts are found in the relevant folder(s) in the Files & Folders view.

image2

Note: Advanced Installer also includes the ability to create build & edit projects from the command line.

Unusually each and every resource including individual registry values is given it’s own component and the approach to COM data is radically different to Installshild. There is a section in the interface dedicated to COM where the various properties are displayed as fields on a form (with drop down lists where relevant for allowable values), but the COM tables do not get populated in the MSI it produces, except for a single field in the PROGID table.

Limitations: Apart from the minor inconvenience of locating shortcuts manually, the one resource per component approach will impact on performance. e.g. Target registry overhead will be greater and Installs/Uninstalls will be slower on larger packages (I did not have opportunity to run further tests to quantify this).

Transforms

Normal transform functionality is supported, although support for multiple transforms appears to be limited to during the creation of a response transform, at which point you can specify multiple additional transforms to include. The transform differences are not displayed by default in the table view. I suspect this is for performance reasons.

It is possible to merge a transform into an .MSI via file save as.
A transform can be created from the differences between 2 .MSI files.

New:

  • A nice feature about response transform creation is that on completion you are immediately shown the properties that have been created/set.
  • When transform differences are displayed you have the option to revert any rows to their original setting(s).

Limitations: Cannot display the combined result from multiple transforms. Cannot merge transforms other than during creation of a response transform.

Alternatives: Insted has excellent transform support. Orca is also available.

Custom Actions

Equivalent functionality appears to be available for custom actions although the range of predefined custom action types is greater.

New:

  • A much wider range of pre-defined custom action types is provided, including things like Run Powershell script (for which they have their own launcher .dll), detect service, stop service, detect if a user exists, Test ODBC connection etc.
  • Selecting where in the sequence to run your action has been made more straightforward and a range of predefined conditions can be selected from a list in a condition builder dialog. e.g. AI_DETECTED_JRE_VERSION >= “1.7”, AI_DETECTED_INTERNET_CONNECTION. The “AI_DETECTED” relates to custom Advanced Installer functionality implemented by their own .DLLs.
  • Custom Actions can be copied to another project via copy and paste.

Manipulating the Registry

Each registry key is added to it’s own component by the repackager so there is no concept here of moving registry out of the bucket components into a component associated with the owning file. Import of .REG files is available.

Registry components each have a KeyPath registered that is an offset to another registry component of +37 so component __1012 has a KeyPath of __1049 so all the registry entries appears to be chained together.

Limitations:

  • It isn’t possible to directly export registry keys, although you could work round this by using the MSI diff capability: Generate 2 MSIs, one with the required registry keys deleted and use MSI diff to generatate a transform containing the keys. To get a .REG file out however might require an old copy of InstallShield. NB It should be noted you can copy and paste registry from one project to another. I’m told that adding registry export capability is planned for a new release. (update: export capability has been added in Version 13.3)
  • It isn’t possible to drag n drop registry keys from the registry on the host PC into the package although in my experience this functionality is not typically used by repackagers.
  • Limited use is made of the COM tables with CLASS not being populated at all and a much smaller number of entries in the PROGID table than in a comparison InstallShield capture. I suspect this is related to the Caphyon design choice (as above) of one component for each resource rather than the more common approach of linking a COM .DLL with it’s associated advertising registry in the same component. This generates ICE33 warnings, but ICE33 appears to be considered obsolete by Microsoft https://msdn.microsoft.com/en-us/library/aa368957(v=vs.85).aspx Presumably however this would affect self-repair such that for example if you had a package without an advertised shortcut which was launched via a file type or MIME type association and you were relying on self-repair to create some HKCU registry keys in the logged on user’s profile, this would fail.
  • I could not see an option to extract COM data from a file included in your project. COM registry would normally be captured during repackaging anyway but this is not always the case. Another area where this functionality can be useful, is for identifying which component bucket registry belongs to, but this would appear to be irrelavent with the Advance Installer approach.
  • The way registry entries are chained together led to numerous ICE69 warnings in my test package. Deleting some registry keys to simulate junk cleaning, appeared to confirm this leads to a loss of referential integrity, as you now have component(s) with a missing KeyPath(s).

Alternatives: Wisecomcapture.exe can be used to extract COM registry into a .REG file which could be imported.

Manipulating Files

Text file manipulation is provided in the form of Append/Overwrite and find & replace. Regular expressions can be used for finding text. It is also possible to add variables say to an .INI file and replace these with properties specified at install time. A tick box is provided to enable the existing fle to be backed up before making changes.

Limitations: XML Files can be created but the functionality doesn’t seem to be as rich as Installshield (although I have never used this).

Repackager

Repackager is incorporated into the main application’s functionality rather than being separate as it is with InstallShield and turn’s the approach to using Virtual Machine’s on it’s head by allowing you to nominate the VM and specific snapshot to be used for the capture and controlling the process externally (a bit like the way AppDNA works) rather than lauching repackaging from within the VM. Exclusions can be configured as part of the process flow before the capture begins. This process I found to be a bit problematic, with VMware, but didn’t have time to explore it fully. I got it to work with a snapshot that was suspended while logged onto the account specified and the network connection set to bridged, but in this configuration you would get a UAC prompt saying that the machine was on a different network – possibly due to the VM being in a workgroup. I did not get it to work fully with any of the other networking options, but didn’t have time to follow up with the vendor.

image3

Hyper-V is an alternative VM option that I didn’t try, but as it is a Type 1 Hypervisor (bare metal) as opposed to Type 2 (Hosted) like VMware workstation I’m not sure if this would work on the same PC or if using Hyper-V with Advanced Installer would require you to connect to a HyperV instance on a server.

There is no separate junk cleaning step at the end of the capture stage as you would have with InstallShield Repackager before generating the .ISM, all editing happens within the main editor. This isn’t really much of a loss, it simplifies the workflow, but does mean you can’t go back to your original capture if you remove something by mistake. Having said this, there appeared to be issues with junk-cleaning registry later in the process, because of the way KeyPaths are allocated – as mentioned in the Registry section above.

One slight issue I experienced at the build stage was an error reporting that it could not find a file from C:\Windows\System32\config – this location is secured so the file could not be copied out & probably shouldn’t have been included anyway.

The capture approach seems to be a combination of single step snapshot & installation monitoring although there is a tick box to disable the latter.

Limitations:

Several times I found that building the resulting project failed because files that should have been excluded could not be located. This could probably be resolved by simply updating the folder exclusions list. On another occasion the build choked on a scheduled task it had captured (throwing an .MSI API error) and I had to exclude it from the project. Note: InstallShield Repackager did not pick up this scheduled task at all.

New:

  • If a default install is required, you can ask Advanced Installer to automate the GUI Accept License agreement, Next, Next etc steps through the installer for you.
  • A “System Noise Recording” can be carried out before the capture begins to help minimise Junk Cleaning. A previously saved “noise” recording can also be used.

System Search

The System Search functionality appears to be broadly similar to InstallShield.

Launch Conditions

Extensive launch condition capability is provided.

Features

Features can be added nested and shared with multiple features. Components are added to a feature via drag & drop.

Condidions

An advanced condition builder is provided with a wide range of pre-defined conditions available, making the need to remember condition syntax largely a thing of the past.

ICE Validation

ICE Validation is supported as part of the build sequence, but cannot be run on it’s own No .CUB files are included with the software and manual configuration is required to enable this functionality and specify the path to the .CUB file you wish to use. The documentation recommends you install the most recent version of msival2 from the Windows SDK.

New: Probably the most important thing to say about ICE validation is that after the build is completed and the list of errors is displayed, automatic fixes can be applied for many issues on an individual basis or by selecting a group of errors. This is a useful time-saver and eliminates human error.

Note: The actual ICE number is not shown in the list of errors at this point although it is included in a log window during the build.

Alternatives: Both Insted and Orca support ICE validation

Conversion of InstallScript Packages

InstallShield includes additional functionality to support the conversion of InstallScript Packages. This technology would not be available to Caphyon as Installscript comes from the same Flexera stable as InstallShield, but I suspect this functionality is little used anyway.

Alternatives:
Scripted install.

Merge Modules

It appears Merge Modules are not supplied out of the box, but can be added from sources such as Visual Studio.  In practice Microsoft appear in recent years to have stepped back from creating new merge modules other than for Visual C++.

Summary/Conclusions

After using InstallShield for a long time, Advanced Installer is a breath of fresh air. Although it uses a similar 3 pane layout to InstallShield, it feels much more modern and assumes less background knowledge on the part of the Packager. Some Windows Installer features that are obscure with Installshield (to the point that few would use them) are placed front & centre in Advanced Installer and prompt the user to consider a more advanced approach, implemented with point & click ease.

Caphyon deliver regular updates to the product and the company has a good reputation for support.

Performance in use is excellent and should improve repackaging times, although as noted the one component per resource approach will have some impact on time to install for large packages. Issues that prevent an unreserved recommendation to purchase and that may require further analysis and testing are:

  • The impact of registry KeyPath chaining.
  • The implications of reduced use of the COM tables.
  • The repackaging problems experienced with VMware although it’s possible the Hyper-V option may be a good alternative.

In the final analysis it must be noted that the core InstallShield interface/approach has hardly changed in years and Advanced Installer, despite one or two rough edges achieves the unexpected victory of making InstallShield look something of a dinosaur by comparison.

Note: This review was carried out using version 12.5. Caphyon have made various changes to the product since. I have included a link to the version history below.

Useful Links:

Advanced Installer features by edition
Advanced Installer features
Advanced Installer version history
2015 Review
2013 Short Review

Advanced Installer download page

Merging Transforms with Insted

Insted

Insted is a really useful tool for working with .MSI transforms, but reading the documentation here:
http://www.instedit.com/workingwithtransforms.html
There is no direct reference to merging transforms (at the time of publishing anyway) and initially I thought this functionality was not present. I did know however that that Insted allows you to apply multiple transforms, although the default view you see after applying multiple transforms is the (highlighted) changes made by the last transform to be applied, so you could be forgiven for believing the last transform simply replaces the previous one.

The documentation explains how to change this to a combined view so you can see changes merged from all the transforms:

Transform Base
“By default, InstEd will hightlight the changes that the last transform makes. From version 1.5.5.13 on, it is possible to change the transform base (Transform->Change Transform Base…). This will change the point in the chain that marks the base file for highlighting changes. For example, if three transforms are applied in the chain, changing the transform base to the original msi will highlight all changes made by all transforms.”

Note our 2nd transform does not appear in the screenshot of this step below, as it is the last item in the chain and would not be a valid choice.

Change BaseSo now we see the changes that will appear in our merged transform and confirm it is what we require. If there are overlapping changes in the transforms, what we see will depend on the order the transforms were applied.

Saving Combined Transform
In order to create our merged transform all we now simply select File -> Save As and get presented with the confirmation screen shown below.
Save Merged TransformClick [Yes] to proceed and save/create the merged transform.

.OSD Files revert to old versions when APP-V 4.6 sequence is installed via .MSI

Recently I was testing a sequence in standalone mode and needed to link it with another package via DSC. I edited the .OSD files in the normal manner and installed both packages.

To make sure DSC was working I launched a shortcut and opened the App-V client GUI. The parent package was shown as In Use(100%), but the dependency was still listed as Idle(0%), so it was clear that DSC linking was not working.  Next I looked in the OSD Cache “C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache” and noticed when I opened the .OSD file that it was an old version without the DSC information!

It turns out that App-V stores a copy of the .OSD file(s) in an embedded #Package.cab file (also the .ICO icon files and the .XML Manifest file) and it uses these instead of the one(s) in the folder.  The good news is that this is fairly eady to fix using the free InstEd tool (InstEd download page).

Open the .MSI with Insted, then go to the Media table and right click on the row containing the .CAB file as shown:

Selecting Insted cabinet building options from context menu

The highlighted options for working with cabs are described here.

If you select Show ddf it will give you an indication if it can find the files it needs to do the rebuild –
e.g. “Failed to find file key 00000004.osd at location:
C:\Packages\MyPackage\Package\MyApp 5.3.osd”

I had to create the “Package” folder then copy the files into it from MyPackage. If InstEd can locate all the files it needs to generate the cab, selecting this option shows you the MakeCab Directive file that it will generate. You are now ready to select the Rebuild selected CABs option and complete the fix.

I know APP-V 4.6 and .OSD files are on the way out, but I think they will be with us for a while yet and this technique is useful for any .MSI with an embedded .cab file you wish to update.

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

CGcomConflict

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
–>
<COM Mode=”Integrated”>
<IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”false” />
</COM>

<!–
Objects
–>
<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:

AVEObjExcl

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.

Repackaging Quicktime 7.7.5 on Windows 8.1

I would like to share some lessons learnt while packaging Quicktime 7.7.5 under Windows 8.1, hopefully this will save some of you out there going through the same hoops.

So the requirements I want to deal with are:

1. Turn off Content Guide at Startup (We don’t really want our users browsing Movies etc on the Internet right)
2. Turn off Automatic Updates
3. .MOV files should launch with Quicktime not Windows Media Player by default
These defaults should apply to all users on the computer

The first 2 points are easy enough to apply via the UI the first is in Edit, Preferences, Player Preferences and the 2nd is in Quicktime Preferences.

We perform our capture of the changes and find that 2 files have been updated QTPlayerSession.xml and Quicktime.qtp, but hang on a second they are in the user profile. What’s the point in disabling automatic updates if you only disable them for 1 user that should be a per machine setting right, OK at home you might want the Content Guide setting to be individual but here we want it set as a default.

So applying Windows standards we move the files to the equivalent ProgramData folder to apply to all users, but Quicktime ignores them here…

The Answer (and another problem)

It turns out that the installer has a custom action AddQTPFileUserProfile that contains a script to copy both files from ProgramData\Apple Computer\Quicktime to the user profile, so we add our 2 captured files to the package in this location. We then test our application as an ordinary user and find our 2nd Gotcha – none of our settings have been applied! What happened, well the custom action copied the files to the user profile of the Admin account you installed under during the install, but there doesn’t seem to be any Self Repair or Active Setup mechanism in the package to deal with these for any new user that logs onto the PC.

The shortcut is advertised but as far as Windows Installer knows, nothing is missing from the user profile and repair does not run. Also because Apple have not followed .MSI standards which expect you to author the filetypes into the correct tables rather than just using the registry table, self-repair is not active when launched say by clicking on a .mov file and how many people launch Quicktime Player from the shortcut…?

So we need to add Active Setup to the package,this triggers a repair & Apple’s custom action copies the files from ProgramData. NB Active Setup ran silently & at first I thought it had failed, but when I checked the files had been copied to the user profile. Be aware also that in a 64bit environment the Active Setup keys get created under WOW6432Node.

.MOV File Type Association in Windows 8.1

Now to dealing with our 3rd requirement. If you check the registry for .MOV under HKCR you will find that the default is set as “QuickTime.mov” so everything seems fine, or maybe not.

When you try to open a .MOV file you get the following prompt:

ss

It seems like Windows wants to remind you that you can now open .mov files with Windows Media Player and is saying are you sure? My personal experience is that WMP fails to work with .mov files from my old camera, I get a message “Windows Media Player cannot play the file” the message also suggests it might not support the codec used (I believe more recent .mov files use a different codec).

If you choose QuickTime at this point the file association is completed and the icon on .mov files changes to a QuickTime icon. This isn’t the turnkey behaviour we want in our package however

It turns out Microsoft have made some big changes in this area – see this Technet Blog One advantage of these changes on a shared PC seems to be that different users could have different preferences for their file extensions. In a home environment for example there could be different preferences for .jpg files.

So far I have not managed to find a way round this and from a Packager’s perspective it seems to be one more reason to avoid Windows 8, but please submit a comment if you know better.

 

GlidePoint Touchpad Drivers Preventing Hibernation

I have a Cirque SmatCat touchpad that I use mainly because of the improvements in scrolling it gives me via the Powerscroll capability. This is the closest I have found to the Synaptics “Coasting” feature that I can use on a desktop PC. One of the things that is better with the Synaptics devices is that you lift the finger when you start the coasting and then tap when you want scrolling to stop. PowerScroll scrolls  till you lift your finger which puts more strain on your wrist.

Having said that I tried Coasting on a Lenovo Thinkpad T410 with a Synaptics touchpad recently and I couldn’t get it to work at all, it would only “coast” for about an inch.

But I digress, we were going to talk hibernation. After I installed the Glidepoint 3.7 drivers on my Windows 7 Professional (64bit) system, I found that I could no longer hibernate my computer – it would just wake again immediately. Here’s how I fixed the problem.

Right click on Computer and select Manage, then open Device Manager and expand the keyboard and mouse devices:

HIDDevices

You may not think your Touchpad has a keyboard, but if you look at the properties on the HID Keyboard device(s) you have listed, you will find one marked with a Location of  “on GlidePoint 3.7 USB Smart Cat (Pinnacle AG)”.

HID KB Properties

You now need to switch to the Power Management tab and untick the option to “Allow this Device to wake the computer”.

AllowWake

Repeat the process for “HID Compliant Mouse” (with the same Location info) and you are done.

A quick update on this article to advise that I have just experienced similar issues with a Lenovo Thinkpad USB Keyboard with Ultranav, with similar resolution.