In FlexApp Packaging Console 6.9.5 GA and 6.9.5 HF1, any operation
that saves a FlexApp package and uploads it to a storage destination can strip the package's
.fa1
companion file. What remains at the destination holds no package payload, so the package can no
longer be edited, cloned again, or played back. This article describes the affected workflows, how
to confirm whether a package is affected, the configuration change that prevents further loss, and
the recovery procedure for packages that still have an extractable FlexApp One. The defect is fixed
in 6.9.5 HF2.
📄 Contents
Back to ContentsStatus
| Issue Status | FIX IN PROGRESS |
| Fix Version | FlexApp Packaging Console 6.9.5 HF2 — in validation, not yet released |
| Workaround Available | Yes — disable FlexApp One conversion on every affected console |
.fa1
is stripped, no file remains at the destination that carries the package payload. Recovery depends
on the package's FlexApp One, which is created by default unless that option was unchecked during
packaging. Apply the workaround before saving, editing, or cloning any further packages.
Back to ContentsAffected Configurations
The defect is in the FlexApp Packaging Console upload path. It is not present in the ProfileUnity console or the client. Both 6.9.5 releases carry it:
FlexApp Packaging Console 6.9.5 (GA) FlexApp Packaging Console 6.9.5 HF1
Every workflow that merges the child disk (a package save) and then uploads the result is exposed:
| Workflow | When it strips the file |
|---|---|
| Create New Package | Package is saved to a cloud storage location |
| Clone Package | Clone destination is a cloud storage location |
| Edit and save an existing package | Any change is saved back to the storage location, including a package that was working before the edit |
| Import Cloud Package | Source package already contains a .fa1
|
| Extend Package | Extended package is saved to a cloud storage location |
The behavior was reported against Azure Blob Storage, but the destination type is not the
determining factor. CIFS destinations and manual uploads performed outside the console — with
Azure Storage Explorer, for example — are affected in the same way, because the
.fa1
is already stripped during the save that prepares the upload.
Back to ContentsSymptoms
- A FlexApp in cloud storage can be cloned, but the clone cannot be edited or cloned again.
- A package that edited and cloned normally as a
.vhdxbecomes a.fa1once cloned, and the console then reports a missing VHD when you open it for editing. - The clone completes and mounts, so the failure is not visible until an edit or a second clone is attempted.
- The storage destination is missing the
.fa1: only the FlexApp One executable and the.xml,.ico, andpack.verfiles remain. - Playback and deployment fail for users assigned an affected package.
- Editing an application that was working breaks it, because the save that follows the edit is what strips the file.
fa1
in the console while the object at the destination is a FlexApp One executable with no companion
file behind it. Confirm against the destination file listing instead.
Back to ContentsCause
When FlexApp One conversion is enabled through
EnableConvertToFaOne,
or when a package exceeds 4 GB, the console produces a FlexApp One executable together with a
.fa1
companion file that carries the package data. The two files share a base name and have to stay in
the same directory.
A package save merges the child disk into the parent and then uploads the result. The stale-disk
cleanup that runs at the end of that upload was scoped too broadly: rather than removing only
.vhd
and
.vhdx
remnants, it removed every non-primary file at the destination — deleting the
.fa1
that had just been uploaded alongside it.
On playback the client looks for a
.fa1
matching the package name and falls back to legacy
.vhdx
handling when it does not find one. After the strip, neither file is present, so neither path has
anything to open. That is why the package fails to edit and fails to play rather than falling back
cleanly.
Back to ContentsHow to Confirm a Package Is Affected
Check 1 — List the files at the package destination
A complete FlexApp One package written to a storage location holds five files:
PackageName.exe PackageName.fa1 PackageName.xml PackageName.ico pack.ver
A missing
.fa1
means the package is affected. No
.vhdx
should be present at the destination for a converted package; it is consumed during the merge.
Check 2 — Open the package for editing in the console
An affected package fails to open and reports a missing VHD. A package that opens for editing normally still has its payload.
Check 3 — Determine whether the console is still exposed
Open the console configuration file:
C:\Program Files (x86)\Liquidware Labs\FlexApp Packaging Console\FlexApp Packaging Console.exe.config.xml
If
EnableConvertToFaOne
is set to
true,
every package this console saves is still at risk. Apply the workaround below.
Back to ContentsWorkaround
Turning off FlexApp One conversion makes the console upload a standard FlexApp payload —
.vhdx,
.xml,
and
.ico
— which avoids the conversion and cleanup path entirely. Apply this on every console used
against affected storage locations, and leave it in place until 6.9.5 HF2 is installed.
Disable FlexApp One conversion
Step 1 — Close the FlexApp Packaging Console
Edits made while the console is running can be overwritten when it exits.
Step 2 — Set EnableConvertToFaOne to false
Edit the console configuration file and save it:
C:\Program Files (x86)\Liquidware Labs\FlexApp Packaging Console\FlexApp Packaging Console.exe.config.xml
Change the
EnableConvertToFaOne
value from
true
to
false.
Step 3 — Reopen the console and save a test package to the storage location
The destination should now receive a
.vhdx
with its
.xml
and
.ico,
with no conversion step and no upload errors. Open the package for editing to confirm it is
usable.
.vhd
and
.vhdx
files explicitly. After 6.9.5 HF2 is installed,
EnableConvertToFaOne
can be set back to
true.
Contact Liquidware Support for the current availability of the hotfix.
Back to ContentsRecovering an Affected Package
A package that has already lost its companion file can still be rebuilt if the package's FlexApp One exists. A FlexApp One is created for every package by default, so it normally does — it is missing only where the option to create one was intentionally unchecked during packaging. The procedure below was tested on FlexApp Packaging Console 6.9.5 GA and 6.9.5 HF1 and used to recover packages in a customer environment. Where no FlexApp One exists, or the extraction does not produce a usable disk, the package has to be repackaged from the source installer.
Step 1 — Apply the workaround first
Complete Disable FlexApp One conversion before starting. Re-importing and re-cloning with conversion still enabled puts the rebuilt package straight back into the defect.
Step 2 — Extract the FlexApp One package
The FlexApp One and the executable written during packaging both end in
.exe
and both take their filename from the package name. The FlexApp One is the one with no packaging
timestamp appended to that name. Run it with the extract switch:
flexappone.exe --extract
Confirm three output files:
.vhdx,
.ico,
and
.xml.
If all three are not produced, the package cannot be recovered this way.
Step 3 — Import the extracted files into the console
Import them as a standard FlexApp package and confirm the package appears in the console inventory.
Step 4 — Clone the imported package back to storage
Clone it to the storage location and wait for the clone to complete. Open the clone for editing to confirm the payload survived, then reassign it to users.
| Product | Liquidware FlexApp Packaging Console |
| Applies To | FlexApp Packaging Console 6.9.5 GA and 6.9.5 HF1; cloud and CIFS storage destinations |
| Updated | July 30, 2026 |