AppSense best practices for non-persistent virtual desktops
Non-persistent virtual desktops offer Australian organisations a practical way to deliver consistent Windows workspaces at scale. Each session starts from a clean image, which can reduce drift, simplify patching and support rapid recovery when a machine becomes unstable. The trade-off is that user settings, application state and troubleshooting evidence can disappear when the desktop is discarded.
AppSense, now commonly associated with user environment management capabilities within the Ivanti ecosystem, can address that gap by separating the user’s working experience from the virtual machine itself. A sound design captures the right settings, restores them at logon and avoids turning every temporary desktop into a permanent storage problem.
Design around the user experience
The first priority is to define what must follow the user. Personal settings, mapped resources, application preferences, browser configuration and selected file associations often belong in the user environment layer. Temporary caches, installer files and machine-specific artefacts generally do not. This distinction keeps logons fast and prevents unnecessary data from being copied between sessions.
Begin with a small inventory of applications and user groups. A finance worker in Sydney may require different Excel add-ins and network locations from a contact-centre operator in Brisbane. A clinical or public-sector environment may have stricter controls around profile data, while a university lab in Melbourne may need a highly disposable desktop with very little personalisation.
Use AppSense Environment Manager policies to build predictable conditions rather than recreating a full physical PC. Capture settings at logoff only when they have clear value, and restore them at logon in a controlled order. This approach makes the desktop feel familiar without allowing years of accumulated configuration to grow inside the virtual session.
Keep the golden image deliberately simple
A non-persistent desktop performs best when the base image contains a stable operating system, approved applications, security controls and essential device integrations. Avoid placing individual preferences, departmental shortcuts or user-specific workarounds into the image. Those items create image sprawl and make every update harder to test.
Application layering, profile management and endpoint security tools must be assessed together. Two products that work well separately can compete for file access, logon timing or process injection. Test antivirus exclusions, application hooks and AppSense agents with the same policies that will be used in production. Record changes in a version-controlled knowledge base so that a replacement administrator can understand why each setting exists.
Image maintenance should follow a repeatable release cycle. Build a new version, apply current patches, validate core applications, test logon and logoff, then publish it to a limited group before broad deployment. Organisations supporting users across Perth, Adelaide and remote regional locations should also test latency and access to shared services, not just performance in the primary data centre.
When upgrading the platform, consult migration guidance and check policy compatibility before changing the image. Version transitions can affect configuration paths, agent behaviour and management console workflows.
Build resilient profile and policy management
The main purpose of user environment management in a disposable desktop is to preserve useful personalisation without importing instability. Start with a small set of proven settings, then add applications one at a time. If an application causes slow logons or corrupted preferences, the source of the problem is easier to identify when the policy scope is narrow.
Separate policy logic by user group, device type and session context. A policy for a pooled desktop should not automatically apply to a persistent workstation. Use conditions such as operating system version, delivery group, security group, client type and network location. This helps distinguish a managed office session in Canberra from a home connection using a personal device.
Folder redirection and profile data require careful storage planning. Place user data on storage designed for the workload, with suitable permissions, backup policies and recovery objectives. Do not redirect every folder by default. Large browser caches, application temp directories and collaboration downloads can create excessive read and write activity, especially during the morning logon surge.
The personality settings guide provides useful context for deciding which user preferences should be captured and which should remain transient. Treat the guidance as a starting point, then validate each setting against application behaviour in your own environment.
Use a clear persistence model
A useful persistence model defines three categories: settings that must follow the user, data that belongs in a managed repository, and disposable session content. This prevents the common mistake of using profile tooling as a substitute for proper document storage or application lifecycle management.
| User or system item | Recommended treatment | Reason |
|---|---|---|
| Windows and application preferences | Capture selectively with AppSense policy | Preserves familiarity without copying the whole profile |
| Documents and business files | Store in approved file services or cloud repositories | Provides governance, backup and access control |
| Browser cache and temporary files | Keep local to the session or clean at logoff | Reduces profile size and logon delay |
| Printers and mapped drives | Apply dynamically by location or group | Avoids stale connections and irrelevant resources |
| Application licensing state | Follow vendor guidance and use shared licensing where supported | Prevents activation failures in disposable machines |
| Certificates and secure tokens | Use approved identity or device integration methods | Protects secrets and supports compliance |
| Troubleshooting logs | Send selected events to central monitoring | Keeps evidence after the desktop is destroyed |
The model should account for applications that store configuration in unusual locations. Some programs write to registry keys, local app data, roaming app data or proprietary databases. Monitor the application during a test session, identify the actual changes and capture only what is needed. Broad registry and file-system capture can introduce conflicts and significantly increase profile processing time.
Shared resources also need ownership rules. A user’s files should not be stored in a location that disappears with the virtual machine, while machine-level configuration should not be captured as if it were personal preference. Clear ownership makes incident response and access reviews much easier.
Improve logon, logoff and session reliability
Logon performance is a major measure of success in a pooled virtual desktop service. Users may tolerate a short delay after a planned image update, but repeated waits every morning quickly damage confidence. Measure each stage: authentication, profile processing, policy evaluation, drive mapping, printer creation, application launch and shell readiness.
Avoid running every action synchronously. Where safe, use asynchronous processing for tasks that do not need to complete before the desktop becomes usable. Remove obsolete logon scripts, duplicate group policy actions and mappings to unavailable locations. A policy that waits for a disconnected file server can make a healthy virtual desktop appear broken.
Logoff deserves equal attention. Capture only changed settings, close applications cleanly and remove temporary data according to policy. If sessions are frequently disconnected rather than logged off, define how stale profiles and abandoned processes will be handled. A reliable cleanup process protects storage capacity and reduces the chance that the next user inherits residual state.
Operational teams should monitor logon duration by site, device type and user group. Averages can hide poor experiences, so track high-percentile results as well. For an organisation with users travelling between Sydney and Newcastle offices, compare performance across connection paths rather than assuming the desktop pool is the only cause of delay.
Secure the environment without damaging usability
Security controls must be compatible with the disposable desktop lifecycle. Confirm that endpoint protection receives current signatures, that tamper protection remains active and that security events leave the machine before it is destroyed. Centralised logging is especially important because local evidence may vanish at reset.
Apply least privilege to both the virtual machine and the user environment. Users should not receive administrative rights simply because an application has been packaged poorly. Where a legacy application needs elevation, use a controlled application control rule or a modern replacement path. Document exceptions, assign owners and set review dates.
Password and account recovery also need a defined process. A forgotten credential should not lead to ad hoc administrator intervention or unsafe temporary passwords. Keep the password reset workflow visible to service desk staff and align it with the organisation’s identity provider, multifactor authentication and verification requirements.
URL filtering, application allow-listing and browser policy should be tested against realistic business activity. Use sanctioned destinations and test accounts rather than relying on production browsing. A test register can include an approved external reference such as the 4Sucres test site where appropriate, while ensuring that security teams have reviewed the destination first.
Test, monitor and support the service
A non-persistent desktop should be tested as a complete service, not just as an image that boots. Build test cases for first logon, repeat logon, application launch, printing, drive access, Teams or collaboration features, profile restoration, session disconnect, logoff and machine refresh. Include both standard users and groups with complex application requirements.
Use pilot rings to control risk. A small technical group can validate an image, followed by representative business users and then a broader production cohort. Capture feedback in a shared forum or knowledge repository so that recurring fixes become reusable resources rather than private notes held by one administrator.
Monitoring should cover user experience and platform health. Useful measures include logon duration, profile size, policy failures, application crashes, machine reset rates, storage latency and help-desk incidents by pool. Correlate these metrics with image versions and policy changes. If logons deteriorate after a new application is introduced, the timeline should make that relationship visible.
Support documentation should explain what survives a reset and what does not. Users in Australian offices may work across standard business hours, early-morning shifts or after-hours maintenance windows, so clear communication reduces avoidable calls. If a user knows that documents must be saved to an approved repository, a desktop refresh is far less disruptive.
Govern changes and share proven resources
Good governance prevents a working configuration from becoming an undocumented dependency. Assign ownership for the image, AppSense policies, application packaging, storage, identity integration and monitoring. Every production change should have a reason, test evidence, rollback method and review date.
Community resources can accelerate troubleshooting, especially when an issue affects a particular product version or integration. Before downloading a configuration or utility, verify its source, supported release, permissions and expected side effects. Test it in an isolated pool, inspect the contents and record any local modifications.
External references should also be handled carefully. A useful bookmark or test destination, such as the FM2012 archive, should never be added to an enterprise allow-list simply because it works in a lab. Classify destinations, obtain security approval and remove temporary exceptions after validation. This discipline keeps experimentation separate from production policy.
Finally, review the environment after major business or technology changes. A merger, new office, revised security standard, cloud migration or application replacement can make old policies unnecessary. Regular housekeeping keeps the non-persistent platform fast, understandable and aligned with the way Australian users actually work.
Adopt these practices as a living operating standard for your AppSense environment. Start with one desktop pool, document the persistence model, measure the user experience and share tested configurations through AppSense Exchange so other administrators can build on reliable work rather than repeat the same investigation.