AppSense best practices for multiple user sessions

AppSense best practices for handling multiple user sessions on a single machine begin with the operating environment, not with a cleanup script. A Windows workstation used by one person, a hot desk switched between employees, and a remote desktop server hosting several active users create different event patterns. AppSense can enrich application decisions with user and device context, but it cannot make every endpoint behave like a purpose-built multi-user terminal.

That distinction matters in Australia, where shared desks are common in Sydney and Melbourne CBD offices and support teams can span Perth, Adelaide and Brisbane. A machine may be used for a morning contact-centre shift, a locked team huddle and an after-hours administrator session. The aim is to preserve each person’s context while preventing files, credentials and notifications from leaking into the next session.

Map every session type

First, distinguish sequential sessions created by Windows Fast User Switching from genuinely concurrent sessions on RDS or VDI infrastructure. Logging off one user may leave background applications, mapped drives or queued print jobs active, while disconnecting an RDP session usually retains its working state. Record whether the endpoint is physical or virtual, the operating system build, the AppSense version, and whether the service runs on the host, in the guest or alongside a published desktop.

Observe normal sign-in, application launch, lock, disconnect, sign-out and shutdown events before changing configuration. Note which actions AppSense associates with the initiating user and which are visible only as machine-wide events. This avoids a common mistake: treating every logoff as a full reset. A shared laptop still running Teams or a print spooler is not equivalent to an idle kiosk that can be cleaned safely.

Useful script examples can be compared with the community collection at Bruins Extra, but validate them in a non-production environment. Check the operating system, AppSense release and execution context before reusing anything. The goal is a verified event map for each device class, not a universal cleanup routine that assumes every sign-out means the same thing.

Build policy around verified user context

Use stable identifiers such as the directory identity, security identifier and profile path. Display names are unsuitable because “Alex” may be shared by several accounts, and a recycled device can briefly carry stale profile data. Where concurrent sessions are supported, confirm that the AppSense component can distinguish session-scoped events from host-level events; otherwise route administrative work through a dedicated management path instead of guessing from process ownership.

Create separate policies for shared workstations, hot desks, kiosks, developer devices and virtual desktops. Trigger on the narrowest reliable event, such as user logon, application start, idle threshold or logoff, and avoid broad triggers that modify every process. Test whether scripts execute as the signed-in user, the AppSense service account or Local System, because that choice determines access to profile folders, network shares and encrypted credentials.

Keep application delivery rules and session hygiene rules separate so troubleshooting remains clear. One configuration pack can preserve user-specific settings while another removes temporary internet files after the user context has genuinely ended. Include conditions for locked screens and disconnected sessions, and make destructive actions conditional on identity, device state and the intended session type. Clear audit logs should identify the rule, target and result without exposing sensitive file contents.

Protect data, credentials and privacy

AppSense can control applications, yet shared-state risks extend beyond it. Clipboards, browser profiles, mapped drives, USB devices, notification previews and print queues can all cross a user boundary. Apply Windows and AppSense controls together: deny clipboard sharing where appropriate, redirect or encrypt downloads, use per-user temporary directories, clear browser data at sign-out and require the screen to lock during short absences. Purpose-built kiosk mode is safer than expecting a general workstation policy to emulate one.

Never delete an entire profile or shared folder merely because one user signs out. Target the known user identifier, verify that the session is no longer interactive, and exclude files belonging to another active session. Credential Manager entries, VPN profiles and cached browser secrets deserve special care because indiscriminate removal can interrupt service accounts or a second remote user. Give repair staff a separate, time-limited procedure for approved maintenance.

For organisations covered by the Privacy Act 1988, session logs can contain personal information even when the original task does not. Apply the Australian Privacy Principles, minimise what is collected and restrict access to AppSense and operating-system telemetry. Keep retention periods defined, avoid capturing typed content, and ensure support bundles use synthetic accounts or redacted samples. Compliance with the Australian Signals Directorate’s Essential Eight also depends on strong application allow-listing and administrative privilege controls, not endpoint scripts alone.

Keep collaboration working across offices

Real-time communication adds moving parts to a shared endpoint. The AppSense Exchange review of Teams and AppSense provides useful context for pairing presence and application delivery with network conditions. Teams and its background services can survive a sign-out or appear as machine processes, so use explicit user and process rules rather than interpreting their presence as proof that somebody is still signed in.

Test calls in every supported session: local sign-in, Fast User Switching, locked screen, RDP reconnect and VDI. Verify microphone and camera selection, screen sharing, notification suppression, bandwidth decisions and file access. A notification from the previous user can disclose a meeting name; a session rule that blocks all background media can instead break an active Teams call. Scope the restriction to the inactive session and preserve expected service behaviour.

Australian teams often operate across states with different daylight-saving rules, while Queensland does not change its clocks. Place time-sensitive tests in local time and confirm how AppSense schedules idle actions, maintenance windows and escalation. Avoid tying policy to a fixed “office IP” when hybrid staff connect through a VPN or cloud gateway. Identify the network path, device posture and user role instead, then have a yarn with network and service-desk teams before rolling the rule out nationally.

Test the complete session lifecycle

Use a matrix built from real workflows, including an application that stays open after sign-out, a locked device, an interrupted download, a failed profile mount, a disconnected remote session and two active VDI users. Include Windows updates and AppSense service restarts, because a rule that works before an update can fail after a component change. Test standard, elevated and service accounts so execution privilege does not hide a defect.

Compare AppSense events with Event Viewer, endpoint telemetry and application logs. Capture the timestamp, session identifier, rule result and expected outcome, then remove test data before sharing. Run a small pilot in one controlled office—such as Brisbane—before attempting a broad rollout across Sydney or Melbourne. A staged release gives support staff time to spot false positives, while a documented rollback prevents a bad condition from blocking a shift.

Monitor rule hits, script duration and failed actions after deployment. High-frequency triggers can create performance pressure on a busy endpoint, especially when each session change scans large profile directories. Alert on script failures and unusual repetition rather than harmless event volume. Record the exact AppSense version, configuration package and Windows build with each support case; that context turns a vague “it stopped working” report into a reproducible investigation.

Operationalise sharing and change control

Treat every AppSense tool and configuration as operational code. Give it an owner, purpose, supported product versions, dependencies, test status and rollback instructions. Store release packages in a controlled library, review changes through the normal service-management process and prevent untested uploads from reaching production. In a large Australian deployment, licensing, support terms and maintenance windows should also be documented in AUD, with GST treatment and tender requirements confirmed for public-sector buyers.

Before publishing a script or uploading a package to AppSense Exchange, read the community terms, remove credentials and personal data, and confirm that the material is safe to redistribute. Use the Exchange’s product and version filters to find compatible resources, and state the tested build in the description. Forum questions should include sanitised logs and reproduction steps, never an employee’s browsing history or document names.

Community advice is valuable because it exposes edge cases that a local pilot may miss, but it remains evidence to assess rather than configuration to paste blindly. Ask community advisors for clarification, compare suggested changes with vendor guidance, and validate them under your own support model. Schedule ownership for Australian business hours, arrange an on-call path for critical incidents and keep all related policy decisions in one searchable source of truth.

The quickest path is to build a session inventory, select one shared-device profile and test three sequences: fast user switch, remote reconnect and clean sign-out. Record the AppSense events, expected user isolation and any Windows controls that must accompany the rule. Pilot that package with a small group and publish the tested version back to the community with clear version details.

AppSense Exchange members can turn the pilot into a repeatable standard: browse compatible resources, contribute a sanitised configuration and use the forums to settle any remaining edge cases. Build the standard once, test it locally, and give every Australian team a shared machine that is predictable, private and supportable.