VMblog spoke with Jake Mosey, Chief Product Officer at Recast, about a problem most IT teams feel but rarely name. People sign in on a device that passed every check, then find the application settings they rely on are gone. Recast’s answer is App Settings in Application Workspace 4.5, one piece of a broader User Profile Management story.
VMblog: Let’s start simple. What are you actually trying to solve here?
Jake Mosey: The gap between the device being ready and the user being ready. As an industry, we have gotten good at enrolling devices fast and installing apps across more environments than ever. But readiness is what the user feels first, and that part is still rough. Someone picks up a replacement machine, opens the application they practically live in and finds the toolbars, preferences, and template folders are gone. The device passed every check. The person still cannot work. That is the moment we are focused on.
VMblog: You call that the reset tax. What do you mean by it?
Jake Mosey: It is never one big outage. It is a thousand small resets. A clinician moves between shared workstations and re-picks the same settings at the start of every shift. Someone else bounces between a laptop, a virtual desktop, and a published app, and the experience starts over each time. None of that takes the network down. It does cost people time, and it sends the help desk a steady trickle of “my app looks different again” tickets that no deployment dashboard will ever show you.
VMblog: Roaming profiles have been around for years. Why has this not been solved already?
Jake Mosey: Older approaches were built to roam more, not to carry only what matters. Classic roaming profiles and profile containers move the user’s whole world at sign-in and sign-out. Profiles grow. Everything ties to logon and logoff, so settings can go stale between sessions. The model also gets harder to run cleanly on cloud-managed or Entra-joined devices, where the old infrastructure assumptions no longer hold. Moving everything is exactly what slows the whole thing down.
VMblog: So what does App Settings do differently in Application Workspace 4.5?
Jake Mosey: We flipped the model. Instead of roaming the entire profile, App Settings captures and restores only the settings that matter for each application, and it works at application launch and application close rather than only at logon and logoff. A user opens an application and their saved settings come back. When the monitored processes close, the updated settings are captured again in the background. No sync step, no pop-up. The test we want leadership to hold us to is a short one: same user, different device, same result.
VMblog: What kinds of settings can an administrator preserve?
Jake Mosey: Folder trees, folders, and individual files, plus registry trees, registry keys, and registry values. Admins include or exclude specific items, so they control exactly what gets captured and restored, and wildcards in file paths cover varying file structures without defining every path by hand. That precision is the point. Usually, a small set of preferences is all that makes an application feel ready, so there is no reason to move an entire profile to get them.
VMblog: How much control does the administrator keep?
Jake Mosey: IT decides what roams and what does not. App Settings entries link to packages through an Initialize AppSetting action. One entry can map to several packages, and a package can use several entries, so teams reuse configurations instead of rebuilding them for every package. We also added administrator access policy privileges for creating, viewing, modifying, and removing App Settings and their content, giving organizations more control over who can access and manage them based on their role.
VMblog: Where does all of that settings data live?
Jake Mosey: You choose. App Settings content is stored through a server-side storage provider. A network share fits on-premises deployments well. Azure Blob storage fits teams that want fast access across regions, and because that traffic can travel over the internet, settings can follow the user without depending on a traditional file share or the corporate network.
VMblog: Security teams are going to ask about governance and auditing. What is there?
Jake Mosey: You can see which packages are affected on the Auditing and Packages pages, so scope is never a guess. When something needs a closer look, relevant actions and errors are written to local log files for both the Agent and the UserHost, which makes troubleshooting a lot more direct than treating the process as a black box. Continuity should stay governed and supportable. A smooth experience for the user should not cost the administrator control.
VMblog: Is App Settings meant to replace endpoint management platforms like Intune or Configuration Manager?
Jake Mosey: No. It sits at the application layer and enhances what those tools already do. Intune, Configuration Manager, and VDI keep handling the device, the policy, and the estate. Application Workspace focuses on getting the right application to the right user, with the right settings, at the point of use. Device management answers whether the device is enrolled, configured, and compliant. App Settings helps answer whether the person can open the application and find what they need to do their work.
VMblog: How does App Settings fit into Recast’s broader User Profile Management direction?
Jake Mosey: App Settings is one component of it. The near-term focus is application-specific continuity, preserving the settings that matter for one application without roaming an entire profile. That model fits local devices, shared devices, and virtual environments equally well.
The longer play is helping IT treat user readiness as its own part of workspace modernization. Deploying the device and installing the application are table stakes. The work is not finished until the person can start working without rebuilding what they had yesterday.
VMblog: What is your advice for teams who want to try it?
Jake Mosey: Start narrow. Pick one high-friction spot, a shared-device workflow or a nonpersistent VDI pool, and a small set of applications where the reset tax hurts most. Validate application behavior, storage needs, and your own settings definitions in a controlled environment before you widen it. Then change the metric you watch. Stop measuring only whether the install ran and start measuring time to ready after a device change and the drop in “my settings are gone” tickets.
VMblog: Where can readers learn more?
Jake Mosey: We put the thinking behind this into a short read called Device Ready. User Not Ready. It walks through why user continuity is still broken and what a better model looks like. If any of this sounds familiar from your own help desk queue, that is the place to start.
Closing the readiness gap
Modern workspace readiness cannot stop at a configured device and an installed application. By preserving the settings people rely on, IT can reduce repeat friction and help users get productive faster across physical, shared, and virtual environments. Explore Device Ready. User Not Ready. to see how Recast is approaching the gap between device readiness and user readiness.
