This is part 3 of a 3-part series on private employee desktops on ZCP. Part 1 covers what we built and why, and part 2 has the full cost breakdown against Windows 365. Testing produced a rollout checklist. Identify what belongs on the employee’s local device, what belongs in the controlled desktop, and which operating controls must exist before expansion.
What worked well
We tested a full desktop, a browser with several open tabs, and a working terminal session. The employee can keep meetings and routine work on a Chromebook, Chromebox, or laptop, then open the remote desktop for backend systems that need controlled access.
The deployment pattern worked for each new employee in our test. The desktop provides a full working environment rather than a bare browser window. Deleting the desktop does not remove files from the shared drive because the desktop does not store those files. The business can end a BYOD employee’s managed workspace without recovering the personal device. Deleting the cloud desktop does not erase files copied earlier to that device.
Offboarding needs one more step beyond deleting the desktop, because deleting the desktop does not revoke the employee’s own device from the mesh. If they ever registered a personal laptop to reach their desktop remotely, this registration survives the desktop’s deletion and keeps working until someone expires it on the mesh server directly. We have not yet published a tested, step-by-step procedure for that part of offboarding. Treat it as a known gap to close before you rely on this for a real offboarding process. Do not treat it as something already covered in the tutorial series below.
Separating data from the desktop makes backup a single task. Back up the shared drive, and every file saved there is covered. Each desktop still needs a separate policy for files saved outside the shared mount. The shared drive must be the enforced default save location.
What did not work as a production default
Video calls do not perform well inside the remote desktop. We tested a workaround that runs the camera and call application on the employee’s laptop while they share the remote desktop screen for work. We have not built or tested a native fix.
Network path matters as much as which desktop size a business buys. A connection relayed through an intermediate server, used when a direct path is not available, measured 221 to 1,054 milliseconds round trip in testing. A direct, same-region connection measured 2 to 31 milliseconds. At the closest points in those two ranges, that is roughly 7 times faster. At the widest, several hundred times faster. This gap comes from network topology, not the desktop’s compute. Test it against a distributed team’s real locations. Do not assume it away.
Shared storage is exactly what it sounds like: shared by default, and more exposed than a typical office drive. Every employee’s desktop gets the same underlying filesystem identity unless a business changes it. By default, any employee can overwrite or delete any other employee’s files, beyond reading them. Giving each desktop a unique identity prevents accidental collisions between well-behaved desktops. It is not a security boundary: the storage protocol trusts whatever identity a connecting machine presents, so a compromised desktop, or a user with local admin rights, can still present another employee’s identity and act as them on the share. It does not make files private to read either: the share’s default permissions still leave files readable by anyone else with access to it. A business needing a real security boundary between employees should add server-enforced identity or per-employee isolation on top of a unique UID. We set this up on request. It does not come by default.
From evaluation to delivery
The deployment path is repeatable:
- Size the shared infrastructure and the first desktop template against the team’s actual workload, not a generic default.
- Deploy it inside a single ZCP account and put one employee on it, so the first judgment is a real desktop, not a demo.
- Test the actual client network paths and backend systems. Confirm that the remote endpoint does not bypass client network policy.
- Test identity, MFA, access policies, logging, clipboard and local-drive restrictions, plus any scoped data-loss-prevention rules. This series does not claim these controls are enabled or tested by default.
- Record cost, onboarding time, network latency from each connecting location, and any gaps against the numbers in this report.
- Confirm that offboarding revokes both the managed desktop and the employee device’s mesh access before relying on it for departures.
- Repeat the same deployment pattern for every employee after that, with the cost model from part 2 as the budget baseline from day one.
For the developer implementation, our technical tutorial series documents the four deployment stages tested in this series (network, storage, desktop, and connecting the two) step by step, including how to give each employee’s desktop its own identity on shared storage. Running a team on this day to day (backups, mesh offboarding, ongoing operations) is real work. We have not finished publishing a tested guide for it yet.
The product is a controlled private-cloud workspace. Ubuntu Desktop is only one component. The value comes from combining backend access, data handling, and operating controls in one place. Decide whether to adopt it based on the business workflow and the figures in this series.
Get started
This is part 3 of a 3-part series. Part 1 covers what we built and why, and part 2 has the full cost breakdown against Windows 365.
Talk to us to define a small pilot and its operating controls, or walk through the technical tutorial series to see every tested step.