Migrating User Settings Across AppSense Environment Manager Versions

Moving user settings between AppSense Environment Manager versions is rarely a matter of copying one file across. A configuration that appears unchanged can depend on policy names, conditions, script paths, certificates and profile data introduced or reorganised in the destination release. Migrations also tend to combine technical work with a business question: which settings should follow people, and which should be rebuilt for the new environment?

The safest approach treats the move as a controlled change with a traceable source, a tested destination and a rollback path. That matters in Australian organisations where staff may move between Sydney, Melbourne and Brisbane offices, regional sites and home offices while business systems keep running. Begin with the settings’ purpose, not merely their current technical form.

Why version changes can break user settings

Environment Manager stores and applies more than visible desktop preferences. Configuration variables, conditions, file and registry operations, application launches, deployment settings and profile-managed data can all form part of a person’s working environment. Between releases, rule definitions, supported actions and import or export behaviour may change. A direct copy may therefore produce a package that imports cleanly but behaves differently once it reaches a workstation.

Settings also live in different places. Some belong to a configuration assigned to a group; others are captured in an AppSense User Profile and restored during a session. A mapped printer, Outlook profile or application preference may be user data, while an application executable, policy condition or mapped drive may be administrator-controlled. Treating these as one bundle makes it easy to migrate the wrong item or overwrite a deliberate local change.

Another complication is the user journey. An employee on a managed Windows device, a kiosk, a Citrix session and a VMware Horizon desktop may not receive the same settings through the same route. Server, console and managed-device components may also be upgraded on different schedules, creating a mismatch between policy and agent behaviour. A newer Environment Manager release can change the sequence in which profile restoration, policy evaluation and scheduled tasks run. Migration should preserve the intended outcome rather than assume that identical-looking policy names guarantee identical behaviour.

Prepare a safe migration package

Begin with an inventory that separates settings owned by the service desk from settings owned by individual users. Record where each value is stored, which group receives it, whether it must work offline, and which operating system or application versions depend on it. Pay particular attention to paths, registry keys, machine names and account names that may differ between the source and destination platforms.

Record the settings that need particular attention:

• Configuration variables and group assignments
• User profile content, including application preferences, registry values and files
• Environment-specific items such as printers, mapped drives and application paths
• Scheduled tasks or scripts that refer to old policy names, shares or script locations

Turn that inventory into a controlled evidence pack that can support both technical recovery and an internal change record:

• Backups of the Environment Manager configuration, its database and relevant certificates
• The source and destination version numbers, including any intermediate release required
• Exports or screenshots showing important settings before and after the change
• Test results, known exceptions and a named rollback owner

Do not edit Environment Manager’s internal tables to force an import, and do not assume a profile folder copied from one release can be consumed by another. Check the vendor’s support and upgrade documentation for the exact version combination. If no supported path exists for a particular setting, document that limitation and plan a replacement instead of hiding it in a custom script.

Build a repeatable migration workflow

Work on a representative test group first: a standard office user, a power user with many applications, a remote worker and a service-desk account with elevated local access. Capture their baseline applications, mapped resources, profile size and login experience. Keep test users out of production policy groups until the new packages and scripts have passed the agreed checks. This creates a practical comparison without disrupting everyday operations.

Migrate in small batches. Export from the source where the supported workflow allows it, then recreate equivalent rules in the destination Configuration Editor rather than copying opaque database records. Test the package on one site, correct the differences, and only then extend the pattern. Preserve naming conventions where possible, but make each migrated rule explainable: what it does, where it came from and who approved it.

Identity and trust boundaries need particular attention. A national organisation may operate separate Active Directory domains for head-office staff, distribution centres and franchise partners. The multi-domain deployment advice published in the AppSense Exchange community is useful context for those arrangements. It also reinforces why permissions, group scopes and file-system access should be verified in the destination rather than inherited on the assumption that a cross-domain relationship will behave as before.

Validate profiles, policies and virtual sessions

A successful import is only the start. Test a fresh sign-in, an existing session, a disconnected network and a second sign-in after the first. Check that application settings are restored, files open, printers appear and no duplicate shortcuts or obsolete entries are introduced. User profile data that contains recently used documents can grow unexpectedly; give the destination enough capacity and confirm that exclusion lists and folder redirections still match the user’s work.

Test under the conditions people actually encounter. On an Australian office network, a managed workstation may have access to internal file servers and deployment tools, while a home connection in regional Victoria may have slower broadband and different access rules. Local logon scripts, drive mappings and applications that depend on domain connectivity must still fail safely. The VMware Horizon integration advice collected by AppSense Exchange offers relevant community experience for environments where profile and policy behaviour can differ between physical and virtual desktops.

Also validate security boundaries. Review who can download or publish configuration, whether service accounts retain the minimum required access, and whether temporary migration credentials have been removed. For organisations covered by the Privacy Act 1988, the Australian Privacy Principles set expectations for the collection, limited use and security of personal information. Settings may include email addresses, application identifiers or browsing preferences even when they do not look like traditional personal records, so protect test exports accordingly.

Roll out across Australian organisations

Plan the rollout around local support capacity and business rhythms. Australian government and enterprise change calendars often tighten around the June financial year-end, while universities and retailers may have different peak periods. A city-based IT team may support regional branches during business hours, leaving after-hours sign-in failures without an immediate escalation path. A staged schedule, clear runbook and local contact can prevent a small profile issue from becoming a site-wide queue.

The local technology mix also affects testing. A common Australian enterprise mix includes Microsoft 365 alongside VMware Horizon or Citrix, and some organisations still maintain distinct Windows estates for specialist applications. Test settings against the applications and virtualisation platforms actually deployed, not an idealised reference image. Account for timezone differences across Australia: Sydney and Melbourne change their clocks together, while Brisbane remains on Eastern Standard Time, so scheduled jobs, support windows and log timestamps should be checked before they are migrated.

Housekeeping is part of the migration. Remove obsolete tasks, duplicate rules and references to retired scripts instead of carrying them into a new structure. The same discipline appears in stale task cleanup guidance, which is worth reading alongside the AppSense documentation when reviewing which scheduled tasks and editing rules still have a purpose. State and territory obligations may also apply in addition to federal privacy law, including the Privacy and Personal Information Protection Act 1998 in New South Wales and the Privacy and Data Protection Act 2014 in Victoria. Keep the resulting records within each organisation’s access and retention requirements.

Use AppSense Exchange to turn the next step into a shared one. Download a tested configuration and supporting guidance, compare it with the inventory, and publish a concise migration note recording supported version combinations, known exceptions and rollback steps. Community discussions can help resolve version-specific questions, while peer feedback can spare another organisation from repeating a failed import. Once the package is proven, deploy it in stages and update the support runbook with the exact validation and recovery instructions.