Community-shared tools & configurations for AppSense Environment Manager, Application Manager and Performance Manager
AppSenseExchange

Setting Up AppSense Environment Manager For Office 365

A well-designed AppSense Environment Manager deployment can make Microsoft 365 feel consistent across shared desktops, laptops, virtual sessions, and remote work locations. It can control user settings, streamline application personalisation, reduce unwanted profile changes, and give support teams a repeatable way to manage Outlook, Teams, OneDrive, Word and Excel.

The most reliable approach is to treat the project as a user-experience design exercise rather than a collection of registry tweaks. Australian organisations often support a mix of office workers in Sydney or Melbourne, regional staff on variable connections, and remote users working from Brisbane, Perth or Canberra. That variety makes careful policy scope, testing and rollback especially important.

Area AppSense Environment Manager focus Office 365 outcome
User settings Personalisation groups and policy actions Familiar preferences across sessions
Application control Process conditions and application groups Predictable Office behaviour
Profile data Selective capture and exclusions Smaller, healthier user profiles
OneDrive Folder redirection and sync considerations Reliable access to user files
Outlook Profile handling and cached data boundaries Faster sign-in and fewer profile conflicts
Operations Logging, testing and staged deployment Easier support and safer changes

Map The Microsoft 365 User Experience

Start by documenting how users access Microsoft 365 today. Record whether they use physical Windows devices, pooled or persistent virtual desktops, published applications, or a combination of these models. Note the sign-in method, Microsoft Entra ID configuration, device management platform, network path to Microsoft services and any existing profile technology.

The Office installation also needs to be recorded. Microsoft 365 Apps for enterprise may be installed through Click-to-Run, with update channels and add-ins varying between departments. Outlook, Teams and OneDrive have different storage and caching behaviours, so a single “capture everything” policy is likely to create unnecessary profile growth. Establish which settings need to follow the user and which should remain local to the device.

Pay attention to working hours and regional access patterns. A team in Perth may sign in several hours apart from colleagues in Melbourne, while a call centre in Brisbane may rely on shared machines and rapid user changes. Documenting these patterns helps determine whether policies should apply at logon, when an application starts, or only when a user connects to a particular device group.

Prepare The AppSense Foundation

Confirm that the installed Environment Manager console and client agents are supported with the Windows builds and AppSense or Ivanti User Workspace Manager release in use. Keep the management console, agent package and configuration backup aligned. A version mismatch can make a policy appear correct in the console while producing unexpected results on endpoints.

Create a small pilot group before changing the production configuration. Include a standard user, a power user, an executive assistant who relies heavily on Outlook, and at least one user with a non-standard Office add-in. Include devices from different locations if possible. An Australian rollout should test both a well-connected Sydney office and a regional or home connection where latency may expose logon or sync problems.

Separate the configuration into logical areas: computer startup, user logon, application start, personalisation, shortcuts, and maintenance. Use clear names such as “M365 Outlook Baseline” or “OneDrive Known Folder Policy”. Consistent naming makes future troubleshooting much quicker, especially when several administrators share responsibility across an internal IT team and a managed service provider.

Before building new actions, review the community tools library for relevant configurations, utilities and examples. Treat shared resources as starting points rather than production-ready imports: inspect conditions, paths, permissions, version assumptions and dependencies before adding anything to a live policy.

Build Policies For Office Applications

Use Environment Manager conditions to apply actions only when the relevant application or user context exists. For example, Outlook-specific settings should be tied to Outlook rather than applied to every logon. This reduces unnecessary processing and avoids writing Office values for users who never open the application.

Personalisation should be selective. Capture settings that improve continuity, such as selected Office preferences, trusted locations where appropriate, and carefully chosen interface options. Avoid capturing temporary data, large caches, diagnostic files or volatile paths. These items can increase logon times and may restore stale information after a device rebuild.

Office policies should respect Microsoft’s supported configuration model. If a setting is managed by Microsoft 365 policy, Group Policy, Intune or the Office cloud policy service, decide which platform owns it. Two systems writing the same value can cause confusing results, with the last process to run appearing to “win”. Define ownership in the design document and keep AppSense focused on user-environment actions that it can reliably control.

Use application start triggers for tasks that need Office to be available. A policy can set a user preference when Outlook launches, map a resource for a finance application, or apply a setting for a particular department. Avoid long chains of synchronous actions at logon. Delaying the desktop while multiple applications and network resources initialise is a common cause of complaints.

Handle OneDrive Teams And Outlook

OneDrive requires a clear division between synchronised user files and profile personalisation. If Known Folder Move is enabled, Desktop, Documents and Pictures are managed by OneDrive and should not also be captured wholesale by Environment Manager. Duplicate handling can create conflicts, large profiles and confusing file locations. Test first with a small set of users and confirm the expected folder paths after sign-in.

Teams behaviour depends on the client generation and deployment model. Avoid roaming the entire Teams cache unless a documented design specifically requires it. Large caches can slow sign-in and recreate obsolete content. Focus instead on the settings users genuinely need, while allowing Teams to rebuild temporary data locally when appropriate. Test audio, video, notifications, meeting join links and sign-out behaviour on both persistent and non-persistent desktops.

Outlook deserves separate treatment because the profile, OST file, add-ins and search index can all affect performance. Decide whether Outlook profiles are created automatically, managed through another platform, or personalised by Environment Manager. Cached Exchange Mode settings should match the organisation’s storage and connectivity design; retaining excessive mail locally can be especially costly on shared or virtual machines.

Consider Australian network and data requirements during testing. Microsoft 365 tenants may use Australian data locations, but traffic still passes through corporate security controls, proxies and internet links. Check that users in Perth, Adelaide and regional New South Wales receive comparable sign-in and sync behaviour. Validate any compliance or retention requirement with the organisation’s security and legal teams rather than assuming a local tenant region answers every data-handling question.

Test Troubleshoot And Govern

Testing should measure more than whether Office opens. Capture baseline logon duration, application launch time, profile size, OneDrive sync status, Outlook startup, Teams readiness and user sign-out time. Compare a device with the policy disabled against one with the pilot configuration enabled. Record results by device type and location so a problem affecting remote users is not hidden by good results in a central office.

Use Environment Manager logging at a level that supports diagnosis without creating excessive noise. When a policy fails, check the condition, action order, permissions, process name and timing. Confirm that a registry or file action is being applied in the user context intended. Also check whether another management system changes the same setting later in the session.

Logon delays often come from several small actions rather than one obvious failure. Network drives, printer mapping, profile captures, Office add-ins, security scans and cloud storage initialisation can combine into a slow sign-in. The logon delay guide provides a useful troubleshooting reference when the desktop takes too long to become usable.

Create a rollback method before expanding the pilot. Export the current configuration, document the previous policy version and identify how to disable a problematic node without removing unrelated settings. Establish a change window that suits the business. For a national organisation, a staged release across AEST, ACST and AWST can reduce the chance that one fault affects every office at once.

Security governance also needs to be explicit. Limit who can edit production configurations, protect sensitive policy files, review captured data, and retain administrative records. Australian organisations may need to align the design with the Privacy Act, sector-specific rules, contractual controls or internal data-residency standards. AppSense should support those controls, not replace a formal security assessment.

Roll Out With Local Support

A practical handover makes the deployment easier to operate after the project team moves on. Give service desk staff a short runbook explaining where logs are stored, how to identify the active configuration, which policies affect Outlook and OneDrive, and how to collect useful evidence from a user. Include screenshots and examples based on the organisation’s actual Windows build.

Before broad deployment, check these readiness items:

After the pilot, review user feedback alongside technical data. A policy that looks efficient in a lab may be frustrating for a user on a shared desktop in a busy Brisbane branch. Likewise, an Outlook setting that helps a small finance team may create unnecessary profile activity for mobile staff. Use feedback to refine scope instead of adding exceptions indefinitely.

For ongoing administration, keep these operating habits in place:

Once the results are stable, expand in measured groups rather than enabling every department at once. Start with users whose workflows are well understood, then include more complex roles and shared-device scenarios. Publish a clear support message that explains what is changing, when it will happen and how users can report an issue.

Use AppSense Environment Manager as one part of a broader Microsoft 365 workplace design. When policies are selective, ownership is clear and performance is measured, users get familiar Office settings without carrying unnecessary cache and profile data between sessions. Build the pilot, validate it with real Australian working conditions, and promote the configuration only after support staff can diagnose and reverse it confidently.