Configure Roaming for Internet Explorer Favorites with AppSense
Internet Explorer may be retired on many Australian desktops, yet it remains relevant in legacy line-of-business applications, intranet portals and compatibility-mode workflows. When users move between a Brisbane office, a Melbourne branch or a remote session hosted in Sydney, their browser favourites should follow them without creating duplicate files or slow logons.
AppSense Environment Manager can help you roam Internet Explorer favourites by redirecting the relevant profile folder, capturing it through personalisation, or combining both approaches with suitable exclusions. The right design depends on whether your organisation uses a file server, AppSense Personalization Server, Citrix or Remote Desktop Services, and how much control users need over their bookmark collection.
Identify the Favourite Storage Model
Classic Internet Explorer stores favourites as files and folders in the user profile, normally under:
%USERPROFILE%\Favorites
Each favourite is generally an .url file, while subfolders represent the organisation users see in the Favorites menu. A folder such as Links may also exist. Before creating an AppSense configuration, sign in as a test user, add a temporary favourite, and confirm where the file is created. Profile customisation, folder redirection and older Windows builds can alter the result.
The storage location matters because roaming the visible browser settings is different from roaming the files that represent those settings. Capturing only registry values will not reliably move the actual favourites. Likewise, redirecting the entire user profile can bring unnecessary browser cache, temporary files and compatibility problems into the roaming process.
Document the expected behaviour before deploying the policy. Decide whether a user should see the same favourites on every managed desktop, whether favourites should be available offline, and whether a shared kiosk or pooled virtual desktop should retain changes after sign-out. A short test record can include the user name, device, session type, favourite path, logon time and sign-out result. A profile documentation example can help illustrate the value of recording paths and ownership clearly, even when the final AppSense policy is specific to your environment.
Choose Redirection or Personalisation
Folder redirection is usually the simplest option when users have dependable access to a central Windows file share. In Environment Manager, create a policy action that redirects the Favorites folder to a user-specific network location. A typical destination might resemble:
\\fileserver\UserData\%USERNAME%\Favorites
Use a unique path for every account and avoid pointing multiple users at the same folder. Apply permissions so the user has the access required to create and modify favourites, while other users cannot browse the content. If the organisation operates across Canberra, Perth and regional offices, consider DFS namespaces or geographically appropriate file services so that the policy does not send every logon across a high-latency link.
Personalisation is more suitable when the desktop is non-persistent, the user moves between virtual machines, or the organisation already operates AppSense Personalization Server. In that model, Environment Manager captures selected user settings and synchronises them according to the configured management group and application definitions. The exact console names can vary by AppSense release, so use the product version and templates available in your installation rather than copying settings from an unrelated build.
Avoid enabling both mechanisms for the same folder without a clear design. If the Favorites folder is redirected to a share and also captured by personalisation, two authorities may attempt to manage the same files. That can cause duplicate data, stale copies, merge conflicts or longer logons. Select one primary roaming method and document it in the policy description.
Build the Environment Manager Policy
Start with a dedicated configuration node for Internet Explorer favourites rather than changing a broad “roam all profile data” rule. In a redirection design, create the destination folder before the shell or browser requires it, then apply the folder mapping during user logon. Use environment variables such as %USERNAME% or %USER_SID% only when they resolve consistently across your domain and file services.
For a personalisation design, configure the relevant user application group and include the Favorites folder as a managed location. If your version supports application-specific configuration, associate the folder with Internet Explorer while keeping the data scope narrow. Do not include Temporary Internet Files, browser cache, download staging folders or other transient content unless there is a documented business requirement.
Ordering is important. The folder should be available before Internet Explorer starts, and the policy should not depend on a drive letter that may be unavailable in a remote session. Use a UNC path or a stable namespace where possible. If folder redirection is being applied through another management system, establish which system runs first and remove overlapping actions.
The AppSense Exchange community provides product-specific configurations and discussions that can help when your console labels differ from an older guide. Treat downloaded configurations as starting points: inspect actions, conditions, paths and exclusions before importing them into production.
Protect Performance and Data Integrity
Favourites are small, but poor policy design can still affect logon performance. A personalisation agent may need to compare local and central copies, while a redirected path can pause the shell if the file server is slow or unavailable. Keep the scope limited to the Favorites directory and avoid synchronising large profile areas under the same rule.
Use exclusions for files that are not required to roam. Temporary .tmp files, browser cache content, crash data and site-specific working files should not be captured as favourites. If users save downloaded HTML files or documents inside the Favorites folder, decide whether those objects are business data or accidental clutter. A quota or file-screening policy can prevent one profile from expanding indefinitely.
Network permissions deserve equal attention. The user needs modify access to their own folder, but administrators should retain a controlled support path. If a share is hosted in a different Australian state, test how the policy behaves when the WAN is unavailable. You may prefer local caching, asynchronous personalisation or a fail-open approach that allows the desktop to load with locally available favourites.
Monitor agent activity during a representative morning rather than testing only on an idle workstation. In a large Melbourne contact centre, hundreds of concurrent logons can expose file-server or agent bottlenecks that a single administrator session will never reveal. If the agent shows unexpected resource consumption, review this CPU usage investigation for useful troubleshooting context.
| Design choice | Best fit | Main benefit | Main risk |
|---|---|---|---|
| Folder redirection | Persistent desktops with reliable file services | Simple, transparent file storage | Dependence on share availability and network latency |
| Personalisation | Non-persistent VDI, RDS or pooled desktops | Centralised capture across sessions | Synchronisation conflicts and agent overhead |
| Local profile only | Fixed workstation with no roaming need | Fastest and least complex logon | Favourites remain tied to one device |
| Hybrid with controlled exclusions | Mixed desktop estate and staged migration | Supports different user groups | Overlapping policies can create duplicate data |
Test Across Sessions and Versions
Use a pilot group that reflects real working patterns. Include a user with a large, folder-based collection; a user who creates favourites during the session; and a user who deletes or renames them. Test on a physical desktop, a virtual desktop and a remote session if all three are in service.
The core test is straightforward. Create a favourite on device A, sign out fully, then sign in to device B and confirm that the item appears in the expected folder. Rename a folder, move a favourite, delete another item and create a nested folder. Repeat the process in reverse. Check that Internet Explorer opens the links and that no duplicate entries appear after several sign-in cycles.
Test offline and degraded conditions as well. Disconnect the client from the file service, delay network availability at logon, and simulate a temporarily unavailable personalisation service. Confirm whether the selected failover behaviour matches the business requirement. A user in a regional Queensland office should receive a predictable experience during a short connectivity interruption, not a blank profile or a repeated policy error.
Include migration testing for users moving from Windows 10 to a newer desktop platform. Internet Explorer favourites may be imported into Microsoft Edge, but the import process can create a separate copy rather than a synchronised live view. If compatibility mode is still required, define which browser owns the authoritative bookmark set and communicate that clearly through your service desk.
Diagnose Common Roaming Failures
A favourite that appears on one device but not another usually points to one of four causes: the policy did not apply, the path differs between machines, the user lacks share permissions, or a second management tool overwrote the result. Begin with the Environment Manager agent log and policy result for the affected user. Confirm the resolved path rather than relying on the path shown in the policy editor.
Duplicate folders often indicate that Internet Explorer created a local Favorites directory before redirection completed, or that personalisation restored a copy after the folder was mapped. Close Internet Explorer, compare timestamps and locations, then decide which copy is authoritative. Do not merge files blindly if users have made different changes on different machines.
Slow sign-in requires measurement. Compare logon duration with the policy disabled, then examine share latency, file counts, agent processing and antivirus scanning. Exclude only what is demonstrably unnecessary, and coordinate any antivirus exclusions with your security team. A quick policy change that hides a performance issue can create a larger audit or malware risk.
For release-specific behaviour, seek advice from experienced practitioners through the community advisors. Include the AppSense or Ivanti version, Windows build, session platform, resolved path, policy action and relevant log entries. Remove usernames, server names and other sensitive details before posting.
Operate and Maintain the Configuration
Treat the roaming rule as a managed service rather than a one-time desktop tweak. Record the policy owner, destination namespace, permissions, exclusions, supported browser versions and rollback procedure. Review the configuration when file services, domain structures or desktop platforms change. Australian organisations with offices in multiple time zones should also state who monitors failures outside the primary support window.
Back up centralised favourites according to your organisation’s retention policy, especially when they contain links to critical clinical, financial or operational systems. A backup is different from a roaming copy: roaming keeps the user experience consistent, while backup protects against deletion, corruption and accidental policy changes.
Keep the policy narrow as Internet Explorer usage declines. Some organisations may eventually move users to Edge, where favourites are managed through a different profile and synchronisation model. Maintain the AppSense rule for the legacy population, place it behind a clear user or device condition, and remove it only after compatibility applications and business owners have approved the change.
A clean implementation gives users the same working links wherever their managed session runs, without dragging an entire profile across the network. Build the policy in a pilot environment, validate permissions and timing, test both normal and disrupted connectivity, then publish the approved configuration through your change process. Browse the available AppSense resources, compare version-specific approaches and apply the method that best fits your desktop estate.