Application Management Platform | Application Packages - Beyond Applications
Customer-owned storage means that the decision to change platforms, renegotiate terms, or manage a service interruption does not leave the organisation’s application assets in an uncertain state.
When a platform builds your application packages, it is creating assets that matter. Not just to the deployment to your compliance posture, your audit trail, your vendor independence, and in regulated sectors, your legal obligations.
The question of where those packages live is not a technical detail. It is a sovereignty question. And most organisations do not ask it until they have already accepted an answer they would not have chosen.
What a Package Actually Contains
An application package is not just a compressed installer. By the time ALICE has processed an application through its pipeline, a package contains:
- The compiled installer in .Intune win format, ready for Intune Win32 LOB deployment
- The PSADT wrapper with install, uninstall, and repair logic configured to enterprise standards
- Silent switch configuration, MSI property settings, and deployment mode selections
- Detection rules and Intune upload configuration
- Version metadata and packaging history
For an enterprise estate with 186 managed application families each potentially across multiple versions these packages represent a significant body of work. They encode enterprise packaging standards, deployment decisions, and configuration that took time and expertise to establish.
The question of who holds custody of those assets is consequential.
The Risk of Vendor-Hosted Package Storage
When an application management platform stores packages in its own infrastructure, several risk categories emerge that are not immediately visible during procurement.
Access dependency. If access to the platform is interrupted for any reason, including commercial dispute, service outage, or contract termination the packages stored in that infrastructure may not be immediately accessible. For an organisation mid-migration or mid-deployment, that dependency is a programme risk.
Audit limitations. Regulated organisations must be able to demonstrate who has had access to their application assets, under what controls, and in which jurisdictions. When packages are stored in a vendor’s infrastructure, the organisation’s ability to evidence this independently of the vendor is limited.
Data sovereignty exposure. For organisations in Defence, central government, or financial services, the location of application assets matters. Packages may contain proprietary software, licensing artefacts, or configuration that reflects security-sensitive deployment decisions. Vendor-hosted storage may place those assets outside the organisation’s jurisdictional control.
Portability constraint. If the organisation decides to change platforms, the packages stored in a vendor’s infrastructure may not be portable in a format directly usable elsewhere. The decision to leave becomes more expensive than it appeared at the outset.
ALICE's Bring Your Own Storage Model
ALICE takes the opposite approach. Every package created through ALICE’s pipeline is stored in the customer’s own Azure Blob Storage account not in ALICE’s infrastructure.
The configuration is straightforward: a Tenant Administrator provides the storage account name, container name, and connection string through the ALICE settings interface. ALICE validates the connection and stores the configuration at tenant level. From that point, every package ALICE creates PSADT folders, .intunewin files, version artefacts is written to the customer’s own container.
ALICE writes to the customer’s storage. The customer owns what is written.
What this means in practice
Full access, always. The customer can access, audit, download, back up, or migrate their packages at any time, independently of ALICE. The packages are in Azure Blob Storage under the customer’s own subscription, subject to the customer’s own access controls and retention policies.
No vendor custody. ALICE does not hold a copy. The customer’s Azure Blob container is the source of truth. If the customer’s ALICE subscription ends, the packages remain in their storage, accessible and usable.
Tenant-consistent. The storage configuration applies at tenant level, meaning all users within the same ALICE tenant write packages to the same container. Packaging work by any team member lands in the same location, under the same access policies.
Auditability: Evidence That Does Not Require a Vendor Request
One of the practical consequences of customer-owned storage is that audit evidence for application package provenance does not require contacting ALICE’s support team, raising a data access request, or waiting for a vendor response.
Every package in the customer’s Azure Blob container has a timestamp, a version reference, and the configuration applied at time of creation. The audit trail for what was packaged, when, and with what configuration is in the customer’s own infrastructure available on demand, under their own access controls.
For organisations that have experienced the friction of requesting audit evidence from a vendor in the middle of a compliance audit, the difference is significant.
Independence: What Happens if the Relationship Changes
Customer-owned storage means that the decision to change platforms, renegotiate terms, or manage a service interruption does not leave the organisation’s application assets in an uncertain state.
The packages ALICE creates are standard .intunewin files compatible with Intune’s Win32 LOB app upload process, and PSADT packages using the published PSADT v4 framework. They are not proprietary formats. They are deployable directly through Intune without ALICE, by any competent IT operations team.
This is the correct baseline for any platform that creates assets on behalf of regulated enterprise customers.
What's Your Reaction?
Like
0
Dislike
0
Love
0
Funny
0
Angry
0
Sad
0
Wow
0
