FlexApp stores app containers on multiple back ends (SMB, Azure Files/Blob, AWS S3 and GCP Cloud Storage). At runtime it picks the fastest path per block, caches the predictive blocks needed to open apps immediately, and prioritizes any new block the moment the user requests it. Stale blocks purge after 180 days. Delivery options include On Boot (with Cloaking), Parallel at Login, On-Demand Click-to-Layer, and an upcoming Isolation mode for side-by-side versions.

Multiple storage back ends. FlexApp containers can live on:

  • SMB file shares (including Azure Files)
  • Azure Blob Storage
  • AWS S3
  • Google Cloud Storage

Cloud-resident containers are compressed to reduce both storage and egress costs.

Latency-based path selection & built-in failover. If you configure secondary paths, FlexApp measures latency on the first block request and promotes the best path to primary. The slower path becomes secondary for automatic failover. If any block can’t be retrieved during caching, it’s fetched inline from the secondary path no user disruption.

Predictive block caching (fast app open). FlexApp records the blocks needed to launch and operate an app. On activation, those predictive blocks are fetched first so the app opens quickly and feels near native.

Smart prioritization while you work. If a user requests a block that isn’t yet local, FlexApp pauses background downloads and prioritizes the requested block immediately. After that, background caching resumes (handy for offline experiences).

Automatic space recovery. Any block not used for 180 days is purged to free disk space. The same applies when a user’s entitlement is removed or when you replace an older FlexApp version with a new one.

Immediate delivery with Intune + the FlexApp agent

You can use Microsoft Intune to deploy the FlexApp agent. Once installed, FlexApp delivery is immediate not “eventual consistency.” In other words, policies and apps are applied right away rather than waiting for periodic device check-ins. Result: the user logs in and their apps are just… there.

Delivery options (all compatible with block caching)

  1. On Boot (with optional Cloaking).
    Apps are layered at boot so they’re ready for anyone who signs in. With FlexApp Cloaking, you can hide on-boot apps from users. Then at login, entitlements “uncloak” instantly, and in most cases predictive blocks are already local.
  2. Parallel to the Login (default).
    FlexApps do not block the login. Activation runs in parallel so users can begin working immediately.
  3. On-Demand Click-to-Layer.
    Users see the shortcut immediately. Activation + caching occurs when they first click it great for rarely used apps. After the first run, most blocks are local, and subsequent launches will be near native.
  4. Isolation (coming soon).
    An upcoming option to run two versions of the same app side-by-side. More details soon.

What problems this solves

  • Fewer base images & pools (simpler lifecycle, less image and pool sprawl)
  • Faster first-run experience (predictive blocks + prioritization)
  • Resilient delivery (latency-based primary/secondary with inline failover)
  • Lower cloud TCO (compressed containers reduce storage + egress)
  • Offline usability (background caching fills in remaining blocks)

Where to start

  • Target a few large apps to showcase first-run speed gains over streaming FlexApp’s.
  • Configure secondary paths to prove latency-based selection.
  • Use Intune for agent deployment; verify immediate delivery at first sign-in.
  • Roll out Click-to-Layer for low-usage apps.
  • Enable Cloaking on shared machines so non-entitled users never see apps.

Are you Ready to modernize app delivery without multiplying base images and pools or solve the traveling / remote user with offline FlexApp’s?