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 (build 6.9.5.9721), released
August 14, 2026.
📄 Contents
Back to ContentsStatus
| Issue Status | RESOLVED |
| Fix Version | FlexApp Packaging Console 6.9.5 HF2 (6.9.5.9721) — released August 14, 2026 |
| Recommended Action |
Upgrade every packaging console to 6.9.5 HF2, then set
EnableConvertToFaOne
back to
true
|
| Workaround Available | Yes — disable FlexApp One conversion. Needed only on consoles not yet upgraded to HF2. |
.fa1
that was already 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. See Recovering an Affected Package below.
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 before HF2 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 was exposed:
| Workflow | When it stripped 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. Manual uploads performed outside the
console — with
Azure Storage Explorer, for example — were affected in the same way, because
the
.fa1
is already stripped during the save that prepares the upload.
Back to ContentsSymptoms
On a console still running 6.9.5 GA or HF1, or on packages already damaged by one, you may observe any of the following:
- 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.
In 6.9.5 GA and HF1 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 an affected 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
A console running 6.9.5 HF2 or later is not exposed. On a console still running 6.9.5 GA or HF1, open the 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 that console saves is still at risk. Upgrade to HF2, or apply
the workaround below in the meantime.
Back to ContentsResolution
Upgrade the FlexApp Packaging Console to 6.9.5 HF2. The upload
no longer deletes the companion file it just wrote, and stale-disk cleanup
now targets
.vhd
and
.vhdx
files explicitly. Downloads are on the
ProfileUnity Hot Fix List.
Upgrade every console that writes to the affected storage locations, including the packaging console bundled with the ProfileUnity Management Console. A console left on GA or HF1 will keep stripping the companion file even after the others are upgraded.
EnableConvertToFaOne
to
false
as a workaround, set it back to
true
once the console is on 6.9.5 HF2. Leaving it disabled is safe but means packages
over 4 GB and any workflow that expects a FlexApp One will not get one.
Back to ContentsWorkaround (Consoles Not Yet on HF2)
Upgrading to 6.9.5 HF2 is the fix. Where a console cannot be upgraded straight
away, turning off FlexApp One conversion makes it 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.
Back to ContentsRecovering an Affected Package
Upgrading to 6.9.5 HF2 prevents further loss but does not repair packages already damaged. A package that has 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 — Upgrade to HF2, or apply the workaround, first
Get the console onto 6.9.5 HF2, or complete Disable FlexApp One conversion, before starting. Re-importing and re-cloning on an un-upgraded console 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 | August 14, 2026 |