FSLogix Cloud Cache and Application Masking
Standard FSLogix profile containers depend on a single storage location. Cloud Cache adds a local cache layer with async replication to multiple providers for high availability and faster sign-in. Application masking lets you show or hide applications per user group without installing or removing them.
What is Cloud Cache?
Think of Cloud Cache as a local photocopy of your locker, with automatic backup to multiple safes.
With standard FSLogix, your profile locker sits on one shelf in one room. If that room floods, your locker is gone. Cloud Cache keeps a photocopy in your pocket (the local session host) and automatically sends copies to multiple safes in different buildings. You always work from the pocket copy (fast), and changes sync to the safes in the background. If one safe breaks, the others still have your data.
Standard Profile Container vs Cloud Cache
| Feature | Standard (VHDLocations) | Cloud Cache (CCDLocations) |
|---|---|---|
| How profile mounts | Direct mount from network share | Downloaded to local cache, then mounted locally |
| Read/write speed | Depends on network latency to share | Local disk speed (fast) |
| Sign-in time | Depends on network + profile size | Faster — local cache is pre-warmed after first use |
| Storage providers | One share (with failover order) | Multiple simultaneous providers |
| High availability | Limited — single share dependency | Built-in — multiple providers replicated |
| Disaster recovery | Manual — replicate shares yourself | Automatic — writes to all providers |
| Local disk usage | Minimal | Needs local disk space for cache |
| Network impact | Constant during session (reads/writes go to share) | Burst at sign-in/sign-out, async during session |
| Configuration key | VHDLocations | CCDLocations |
| Best for | Single-region deployments with reliable storage | Multi-region, HA requirements, or latency-sensitive |
How Cloud Cache works — step by step
- Sign-in: Cloud Cache downloads the latest VHD(X) from the highest-priority healthy provider to the local cache
- During session: User reads/writes against the local cached copy (fast)
- Async write-back: Changes are continuously written back to ALL configured providers in the background
- Sign-out: Final changes are flushed to all providers before the session ends
- Next sign-in: If the local cache still exists (same session host), only delta changes are downloaded
🏢 Raj’s multi-region setup: “TerraStack has offices in Sydney and Auckland. We configured Cloud Cache with Azure Files shares in both Australia East and Australia Southeast. If the Sydney region has an outage, users in Auckland automatically get profiles from the other share. Dmitri tested a failover scenario — users didn’t even notice.”
Configuring Cloud Cache
Cloud Cache uses the CCDLocations registry key instead of VHDLocations. They are mutually exclusive — you use one or the other.
The CCDLocations value uses a specific format with provider types:
| Provider Type | Format | Example |
|---|---|---|
| SMB share | type=smb,connectionString=UNC_path | type=smb,connectionString=\\server\share |
| Azure page blob | type=azure,connectionString=blob_connection_string | type=azure,connectionString=DefaultEndpointsProtocol=https;AccountName=... |
Multiple providers are separated by semicolons in the CCDLocations value.
Key Cloud Cache settings
| Registry Value | Type | What It Does |
|---|---|---|
| CCDLocations | REG_SZ | Provider connection strings (replaces VHDLocations) |
| ClearCacheOnLogoff | DWORD | Delete local cache at sign-out (saves disk, slower next sign-in) |
| HealthyProvidersRequiredForRegister | DWORD | Minimum healthy providers before allowing sign-in |
Exam tip: VHDLocations vs CCDLocations
These two settings are mutually exclusive. If you set CCDLocations, VHDLocations is ignored for Cloud Cache-enabled containers. The exam may try to trick you with an answer that sets both — only one should be configured.
Remember: VHDLocations = direct mount (simple, single location). CCDLocations = Cloud Cache (local cache + multi-provider sync).
HealthyProvidersRequiredForRegister
This setting controls how many storage providers must be reachable before FSLogix allows a user to sign in:
| Value | Behaviour |
|---|---|
| 0 | Sign-in proceeds even if no providers are healthy (local cache only) |
| 1 (default) | At least one provider must be healthy |
| 2+ | That many providers must be healthy before sign-in is allowed |
Setting this too high can cause sign-in failures. If you have 2 providers, setting this to 2 means BOTH must be up for anyone to log in — reducing the HA benefit.
Local disk requirements
Cloud Cache needs local disk space on each session host for the cache files. Plan for:
- Cache size = largest expected profile (if a user has a 20 GB profile, you need 20 GB free local disk)
- Use Premium SSD or Ephemeral OS disks for best performance
- Monitor local disk usage — a full disk causes profile failures
Application Masking — show and hide apps
Think of application masking as making apps invisible to certain people.
Imagine a shared kitchen. All the appliances are there — coffee machine, blender, oven, microwave. Application masking is like putting an invisibility cloak over the oven for people who are not allowed to cook. They literally cannot see or use it, even though it is physically there. Different people see different appliances based on their role.
How application masking works
- Install all apps on the golden image (all departments’ apps in one image)
- Create masking rules using the FSLogix Rule Editor tool
- Rules define which users/groups/computers can see which applications
- At sign-in, FSLogix applies the rules — hidden apps become completely invisible (not in Start menu, not in file system, registry entries masked)
Rule Editor — creating masking rules
The FSLogix Rule Editor (a Windows GUI tool) creates rule sets that control visibility:
| Rule Criteria | What It Matches |
|---|---|
| User | Specific user account |
| Group | AD or Entra ID security group |
| Computer | Specific session host name |
| OU | Active Directory Organisational Unit |
| Process | Parent process that launched the app |
Rules define what to hide and then assignments define who to apply the rule to.
🎧 Mia’s department masking: “Our radiology department needs PACS viewer software. Our admin team needs billing software. Both groups share the same pooled host pool. With application masking, radiologists see PACS but not billing. Admin staff see billing but not PACS. One image, two experiences. Dr. Patel stops accidentally opening the billing system.”
Deep dive: How masking actually works under the hood
Application masking works at the file system and registry level using a minifilter driver. When a masking rule hides an application:
- File system: The app’s EXE, DLLs, and data files are hidden from directory listings and cannot be accessed
- Registry: The app’s registry keys (HKLM\Software, uninstall entries) are hidden
- Start menu: Shortcuts are hidden
- File associations: File type associations for the masked app are removed
The app is never uninstalled — it remains on disk. The minifilter simply makes it invisible to the masked user. This is faster and more reliable than installing/uninstalling apps per user.
Application masking vs other methods
| Method | How It Works | Pros | Cons |
|---|---|---|---|
| Application masking | Hide installed apps per user/group | Fast, no app install needed, instant | Apps must be in image |
| App attach | Mount apps from VHD at sign-in | Apps outside image, easy updates | More complex setup |
| Multiple images | Different images per department | Complete isolation | More images to maintain |
Raj needs FSLogix profiles to survive an Azure region outage. TerraStack has Azure Files shares in Australia East and Australia Southeast. What should Raj configure?
Mia needs to give radiologists access to PACS viewer and admin staff access to billing software on the same pooled host pool. She does not want to maintain separate images. What is the best approach?
Raj sets HealthyProvidersRequiredForRegister to 2 with two Cloud Cache providers. What happens if one provider goes offline?
🎬 Video coming soon
FSLogix Cloud Cache and Application Masking
Next up: AVD Clients: Choose and Deploy — explore the Windows App, web client, and legacy clients, then learn deployment strategies for any device platform.