Best practices for AppSense Personality every admin should know
End-user personalisation has always sat in an awkward middle ground for Australian IT teams. Users want their desktop, mapped drives and application shortcuts to follow them between the office in Sydney and a home setup in Parramatta, while administrators want predictable, secure profiles that do not bloat the data centre. AppSense Personality is the layer that reconciles both worlds, and getting the configuration right is the difference between a smooth logon experience and a help-desk ticket storm on Monday morning.
Personalisation in AppSense DesktopNow is delivered through rules that the agent applies at logon, logoff and during the user session. Each Personality setting governs a specific slice of the user environment, from Start menu entries and Outlook signatures to mapped printers and registry values. Treating these settings as isolated toggles is a common mistake. The real value comes from building a coherent policy that reflects how the organisation actually works, including how staff in Melbourne or Brisbane cycle between company laptops, virtual desktops and shared kiosks.
Australian privacy obligations under the Privacy Act 1988 and the Australian Privacy Principles add another dimension to profile design. Personalised settings frequently capture user behaviour patterns, recently used files and even snippets of corporate data, so storage locations, retention policies and access controls need to align with internal data classification. Sydney-based finance and healthcare organisations often balance these considerations against APRA CPS 234 information-security requirements and the local Notifiable Data Breaches scheme.
A healthy Personalisation policy is rarely a static document. New application rollouts, shifts to hybrid work in regional centres like Geelong or the Sunshine Coast, and updates to the Windows 10 baseline all demand periodic reviews. The remainder of this article walks through the configuration patterns, folder strategies and troubleshooting habits that experienced AppSense practitioners rely on, and points to community resources where the rules can be kept current.
Understanding AppSense Personality settings and how they apply
Personality is a collection of agent-driven rules that capture, replicate and restore elements of the user environment. Items are stored in a Personalisation database, typically a SQL Server instance managed through the Environment Manager console, and synchronised using either roaming or managed mode. Roaming mode moves the entire user profile between machines, which suits senior staff who routinely jump between devices. Managed mode keeps a base profile on every endpoint and only layers personal changes on top, which suits locked-down retail terminals or clinical workstations.
The breadth of items Personality can handle is wider than many new administrators expect. Files and folders, registry keys, virtualised application data, COM components, mapped drives, printers, environment variables and printer drivers can all be governed by individual rules. Each item is configured with an action such as apply at logon, apply at logoff or both, and with a condition set that may filter by AD group, machine name, operating system build or client IP subnet.
For Australian organisations operating across multiple time zones, condition sets are particularly valuable. A regional bank with branches in Perth, Adelaide and Canberra can target rules per city using security groups, ensuring branch-specific printers and EFTPOS-related shortcuts only appear where they belong. The AppSense Exchange forum regularly hosts ready-made condition examples that can be imported directly into the Environment Manager console, which is a much faster way to start than building every filter by hand.
A practical first step is to document which items genuinely need personalisation and which should remain standard. Mapping out a typical knowledge worker in a Melbourne headquarters versus a field engineer on a remote site in the Pilbara will quickly reveal where shared desktops must lock down and where personalised flexibility is welcomed. This audit forms the backbone of a Personalisation policy that scales across the enterprise rather than dragging on individual logon times.
Configuring roaming and managed mode for consistent experiences
The choice between roaming and managed mode is the single most impactful decision in any Personality deployment. Roaming mode replicates the entire user store to whichever endpoint the user logs on to next, which produces a familiar feel but also means a full copy of every personalised file is held transiently on each device. Managed mode stores the base configuration centrally and only writes user changes back, capping profile size and shortening logon times.
For most Australian corporate networks, hybrid mode is the natural middle ground. Profile data sits on a central file share, typically replicated between data centres in Sydney and Melbourne for resilience, while the Personality database lives on a clustered SQL instance. Hybrid setups pair well with Distributed File System Replication, allowing users in regional Queensland offices to authenticate against the closest domain controller without waiting on a cross-country file pull.
Whichever mode is selected, set explicit exclusions for items that do not need personalising. Temp folders, browser caches, large Teams or OneDrive caches, and any application that re-creates its own data on first launch should always be excluded. The habit of adding broad exclusions first and tightening them only after observing real-world behaviour prevents the most common cause of bloated stores: silently caching multi-gigabyte Outlook OST files inside the Personalisation set.
Validate the configuration with a deliberate soak test before rolling to production. Pick a small test group of five or six volunteers from a Sydney pilot site and capture baseline logon times, profile sizes and any items they actually had to reconfigure. Anything they did not touch is a candidate for exclusion in the broader policy. Soak tests are also the right place to verify behaviour on metered connections, which matter for field engineers who log in from camps or client sites on rural 4G links.
Folder redirection and file system rules for resilient profiles
Folder redirection within Personality, sometimes confused with native Windows folder redirection, is the mechanism that moves Documents, Desktop, Application Data and similar folders into centrally managed paths. Done correctly, it shields user data from endpoint failure and gives the help desk a single authoritative location to restore from. Done poorly, it produces recursive folders, orphaned junctions and unexpected quota breaches.
Start by separating file data from application data. Documents, Desktop and any department-shared folders should target a tiered file service such as a Sydney primary share backed by a Melbourne replica, while per-application data such as Outlook, browser profiles and bespoke line-of-business tools should sit inside their own Personality items. Keeping these paths distinct makes it easier to apply storage quotas, run backup windows and report against the Notifiable Data Breaches scheme if a laptop is stolen in transit.
Apply hard size limits at the Personalisation layer, not only at the file share. AppSense can enforce per-item storage caps, which stop a runaway log file or an unsanctioned video folder from filling the underlying disk. In heavily regulated sectors, such as Australian hospitals bound by the My Health Records Act or banks subject to APRA prudential standards, predictable storage behaviour is part of the audit posture as much as it is a technical measure.
Periodic reconciliation between Personality rules and Active Directory home folder settings also reduces drift. When an account is migrated, renamed or deprovisioned, stale redirected folders can linger for months and balloon storage costs. A quarterly sweep, ideally scheduled around the Australian financial year-end in June or July, clears up old profiles and produces reliable numbers for the next storage capacity plan.
Application personalisation and shortcut management
Application personalisation is where AppSense Personality visibly earns its keep. Users expect their pinned shortcuts, file associations and per-application settings to be present wherever they sit down. Personality handles this through application-specific items that target the registry keys and folders a program reads on launch, without dragging the whole application down a virtualisation pathway.
Begin with the high-impact applications: Microsoft 365 apps, the corporate browser, VPN client, internal chat tools and the line-of-business suite used in your industry vertical. For each, capture only the keys the application actually reads rather than the entire HKCU hive. Veterinary clinics in suburban Melbourne often run a practice-management application that writes bulky patient notes under a single registry tree, and capturing only that subtree keeps the Personalisation store trim and recoveries quick.
Shortcut management deserves its own review. Pinned taskbar items, Start menu tiles and desktop shortcuts are recreated through Personality rules that point at the same network path every time, which insulates the user from renamed executables or accidentally removed installer shortcuts. Avoid capturing icons by reference to local paths; store the network source and let the item rehydrate on each endpoint, so a refresh of the application on the distribution server does not require touching Personalisation policy.
Align Personalisation rules with the corporate software deployment tool, whether that is Microsoft Intune, SCCM or an internal solution popular among mid-market Australian organisations. When both layers agree on which shortcuts and registry values belong to the user versus the machine, end users experience consistent logons from the boardroom in North Sydney to the regional office in Hobart, and administrators spend less time reconciling conflicting policies.
Troubleshooting and monitoring performance issues
Even well-tuned Personalisation environments occasionally run into trouble, and a structured approach saves hours of guessing. The first signal is usually a slow logon reported by an end user, often from a specific site or device group. Before changing any rules, capture a Personality trace from the Environment Manager console and look at which items take the longest to apply. Large file items, registry items with broad paths and excessive drive mappings are the usual suspects.
Short-term mitigations are useful during incident response but should not replace root-cause work. Disabling a problematic item for an affected security group, reprocessing the Personalisation database, or rolling back to a known-good backup are all legitimate moves. Australian IT teams that run shift-based support desks in Sydney, Perth and Brisbane often keep a runbook with these moves listed in order of reversibility, so on-call engineers can apply the safest change first.
Longer-term, build monitoring into day-to-day operation. Set alerts for Personalisation database growth, profile size outliers and recurring slow-logon events from particular sites. Pair these signals with this AppSense Exchange guide, which captures lessons from real deployments and is refreshed as new builds change the underlying behaviour.
Comparing the main Personality operating modes at a glance
| Mode | Profile storage behaviour | Best suited to | Typical logon impact |
|---|---|---|---|
| Roaming | Full user store follows the user between machines | Senior staff, executives, mobile knowledge workers | Higher initial sync, consistent experience on every endpoint |
| Managed | Base profile stored centrally, only user changes written | Shared kiosks, hot-desking floors, regulated workstations | Fastest baseline logon, predictable storage footprint |
| Hybrid | Centrally stored files with replicated database | Multi-site enterprises needing balance of speed and personalisation | Tunable, depends on replication topology and exclusions |
| Offline or cached | Personality items available without connectivity | Field engineers and remote staff on intermittent links | Slower first logon after reconnection, robust once cached |
Practices that consistently deliver smooth Personalisation
- Audit personalised items annually and prune anything users no longer touch.
- Exclude caches, temp folders and OST or PST files at the rule level, not the share level.
- Pair Personalisation rules with deployment tools so shortcuts and registry writes stay aligned.
- Run soak tests from a representative pilot site before every major Windows 10 build change.
Signs it is time to revisit your Personalisation policy
- Logon times creeping past 45 seconds for mainstream users.
- Personalisation database growth that no longer matches headcount.
- Frequent help-desk tickets about missing shortcuts or printers after a rollout.
- Audit findings from internal risk reviews referencing unclear data ownership.
Share your own configuration tips, ask follow-up questions in the AppSense Exchange forum, or upload the Personality rules you have refined so the wider Australian community can build on what works. Practical insight from a regional rollout, an unusual application capture or a tricky Windows 10 build is exactly the type of contribution that keeps the community knowledge base honest and useful.