AppSense and OneDrive: Syncing Known Folders Within Policy

AppSense and OneDrive can give staff familiar folders while keeping business files governed, but they solve different parts of the problem. AppSense prepares the application environment; OneDrive synchronises selected cloud storage. Known folder redirection connects them by pointing Windows locations such as Desktop and Documents at a managed OneDrive location. This can follow users across devices, but can also move active data into a path an app, support process or retention rule cannot handle.

A safe design starts with policy, not a registry value. This guide offers a practical approach for Australian organisations using AppSense Environment Manager with Microsoft 365, including virtual desktops and remote access. It distinguishes synchronisation from backup, defines where AppSense should intervene, and sets tests for convenience and control. The aim is familiar working locations without unmanaged copies, conflicting redirects or compliance gaps.

Define the policy boundary

Begin by defining the policy boundary. Record which Windows known folders may be redirected, which must remain local, and which are governed by another system. Desktop and Documents are common candidates, while Downloads, Pictures, Music and Videos may need narrower treatment. Some folders contain regulatory records, active database files, installation media or application data; moving those can break workflows even when the cloud copy appears healthy.

Give each data class one authoritative home. If an application store writes to a redirected Desktop, the file can reach SharePoint and external recipients through normal sharing controls. If a records team expects a file share, OneDrive becomes an unauthorised repository. AppSense application policies, Microsoft 365 retention, departmental file-share rules and contractual storage requirements must be reconciled before deployment. Where rules conflict, escalate the exception rather than hiding it in a client setting.

Australian context makes this visible. Hybrid teams in Sydney, Melbourne and Brisbane often move between an office, home and a Microsoft 365 virtual desktop. Regional and Pilbara-based staff may rely on intermittent links. A rule that works on a wired office network can expose sync conflicts, unavailable placeholders or slow recovery when connectivity drops. Base the policy on supported working patterns, including low-bandwidth and offline periods, rather than assuming constant connectivity.

Map folders, applications and recovery

Map the user journey before changing paths. Known folder redirection is not simply “copying Desktop to OneDrive”. On an eligible Windows device, OneDrive relocates or redirects the known-folder location, then synchronises files with the tenant. Existing content must be handled deliberately. With Files On-Demand, an icon can appear while the file remains online-only, so its presence does not prove availability to a legacy application.

Create a path matrix for each significant application. Record whether it writes through Windows APIs, uses a hard-coded path, expects a local profile or opens files from a prior session. For Remote Desktop, establish whether creation occurs on the client, session host or both. For browser-based Microsoft 365 apps, check that co-authoring, shared links and sensitivity labels survive redirection. This prevents broad redirection from becoming an indiscriminate application exclusion.

Separate three expectations that are often conflated. Synchronisation propagates changes; version history helps recover an earlier state; backup creates a protected recovery copy with a defined retention period. OneDrive can support the first two, but it is not automatically the organisation’s backup for every redirected folder. The policy should identify the authoritative service, version-history period, ransomware recovery process and any legal or records hold that overrides normal deletion.

Prepare identity, devices and Australian data controls

Prepare identity, device and storage before packaging the client. Each user needs the correct Microsoft 365 account, access to the designated OneDrive tenant and a compatible OneDrive deployment. Managed devices need the AppSense client, correct Environment Manager policy and any prerequisite applications. Check supported Windows, OneDrive and AppSense versions against the estate; older configuration packages may not recognise newer redirection behaviour or authentication changes.

Account linking and device compliance also need deliberate rules. Decide whether users may link a business OneDrive account to AppSense-managed personal devices, whether access depends on Conditional Access, and what happens when an unmanaged device is lost. Avoid using administrator accounts for redirection because Windows known folder redirection behaves differently for administrators. Confirm that the account can reach the intended OneDrive location from Australian offices, home connections and session hosts.

Confirm where Australian tenant data resides and which controls apply. Eligible Microsoft 365 tenants can use Australian data-location options, but administrators should verify current service coverage and tenant configuration rather than infer residency from a subscription. Where the Privacy Act 1988 applies, document how personal information is handled, accessed and protected. Financial entities may also have obligations under APRA CPS 230, while state recordkeeping and contractual rules can impose independent retention requirements.

Configure AppSense and Microsoft 365

Build the deployment in Environment Manager with clear ownership. The community’s Environment Manager setup guide provides a useful foundation for preparing Office 365 applications, prerequisites and user assignments. Treat the OneDrive client as a managed application, associate it with the appropriate deployment groups and test package order. Keep cloud enforcement in Microsoft 365 or endpoint management, and reserve AppSense for application readiness, sequencing and environment-specific behaviour.

Apply known folder redirection through one supported Microsoft management route, such as Intune, Group Policy or Microsoft 365 Apps administration, rather than duplicating settings through several tools. Microsoft policies should define the eligible known folders and user exemptions. AppSense can then ensure OneDrive is present before the first business application starts. Document which component controls each setting; overlapping policies can leave a user with two redirection states after a profile refresh or support intervention.

Choose file availability deliberately. Keep frequently used working documents available locally where an application cannot tolerate placeholders, while allowing larger libraries to remain online-only. Review the effect of corporate retention labels, encryption and regional processing before enabling automatic folder relocation. Exclude folders containing application state or regulated exports only after identifying a tested local destination. An exclusion is safer than a broken application, but it should have an owner and review date.

Validate local, remote and offline paths

Test the complete route, not just sign-in. For AppSense-managed virtual desktops, use the remote desktop configuration guide as the baseline for reviewing client drives, application launch and session data. Remember that Remote Desktop drive redirection and OneDrive known folder redirection are different mechanisms: mapping a client drive does not synchronise it to OneDrive. Confirm that application files are created in the intended location and that session cleanup does not delete or detach the business OneDrive.

Run a representative pilot across office laptops, home devices and remote-access clients. Include a Windows account with a local profile, a profile redirected by AppSense and an account whose OneDrive is already synchronised. Exercise document creation, renaming, large-file transfer, PDF output, Office co-authoring, external sharing and offline opening. Test long file names, locked files, multiple versions and signing out during a sync. Capture the expected path, visible status and recovery method for each scenario.

Monitor the pilot for synchronisation errors, AppSense deployment failures, unexpected sign-ins and files left online-only. Review OneDrive and AppSense logs according to privacy requirements without collecting users’ document content. A failed test is valuable when it identifies the policy owner or missing prerequisite. Repeat the matrix after major Windows, Microsoft 365, AppSense or Remote Desktop changes because a previously successful configuration can still alter path resolution.

Protect access, sharing and recoverability

Layer security controls around redirected folders rather than exempting them wholesale. OneDrive sharing controls, sensitivity labels, Data Loss Prevention, conditional access and Defender integration remain relevant when a file appears under Desktop. Keep multifactor authentication and device compliance active, and use named sharing groups rather than public links where internal collaboration is intended. Apply an approved malware-scanning configuration that preserves detection; a blanket scanning exclusion for an entire OneDrive root creates avoidable risk.

Set sharing boundaries for each audience. A Sydney finance team and a Melbourne sales team may have different external-partner rules, while a regional support team may need restricted access after working offline. Train staff to identify sensitivity labels and verify recipients before sharing. Review external sharing reports and guest access, then align them with Australian privacy duties, client confidentiality terms and sector requirements. Where a file must not leave the organisation, prevent broad sharing rather than relying on user discretion.

Plan recovery as carefully as deployment. Confirm recycle-bin retention, version-history limits, restore rights and legal holds for each workload. Test restoration to a managed device after accidental deletion, ransomware encryption and OneDrive unlinking. Keep authoritative copies of installers, database files and operational exports outside the redirected location when the application requires it. The goal is not a second uncontrolled replica, but a documented recovery path that matches the data classification and retention policy.

Roll out with evidence and support

Roll out in waves with a reversible decision at each stage. Start with a pilot group that includes office-based users, remote workers and an application owner, not only technically confident volunteers. Provide a plain-English notice showing where files will appear, what happens to existing content, how to make a file available offline and where to seek help. Record explicit acceptance criteria for path continuity, synchronisation completion, permissions and recovery before expanding to the next group.

Maintain a support runbook with exact reset steps, approved settings and escalation contacts. Avoid telling staff to delete files or unlink OneDrive without checking for unsynced changes, because the local location may be empty while a placeholder or pending upload still exists. Review error trends, open support cases and policy exceptions after each wave. Tested fixes and configuration packages can then be published through AppSense Exchange so the wider community benefits without relying on undocumented local scripts.

Start the approved pilot now: nominate the identity group, record the current folder paths, assign policy owners and schedule the full local, remote and offline test matrix. Publish the support route before changing any user profile, and approve wider deployment only when file continuity and recovery tests pass. That sequence lets AppSense and OneDrive coexist under a single, auditable policy instead of producing conflicting synchronisation behaviour.