Configuring AppSense with Remote Desktop Services: a hands-on guide

Remote Desktop Services sits at the heart of many Australian IT estates, from hospitals in Queensland to mining camps in the Pilbara and banks in the Sydney CBD. When the workforce is scattered across time zones that range from Perth's AWST to Brisbane's AEST, a session-based delivery model often makes more sense than equipping every user with a high-end laptop. AppSense brings policy-driven control to those RDS hosts, turning a generic desktop farm into something tailored, consistent and easier to audit. For organisations still running Windows Server with RDS, that combination remains a sensible path forward.

The Exchange community exists to make that path shorter. Members share configuration files, policy templates, scripts and war stories, and they tap into forums moderated by experienced AppSense advisors. Before diving into the technical walkthrough, it helps to spend a few minutes getting your bearings and understanding which product version matches your Server build.

Mapping AppSense features onto RDS roles

AppSense DesktopNow and the related policy modules were designed with terminal services in mind, long before the product line settled into its current shape. The architecture treats every RDS session as a transient container, applying personalisation, application control and environment policy as the user logs in. Because the user profile never really lives on the RDS host, administrators need a way to make persistence feel seamless, and that is exactly what AppSense's user environment virtualisation handles.

For Australian IT teams, the value of this approach is amplified by geography. A clinician working from a regional clinic outside Cairns, a financial analyst dialling in from a home office in Adelaide and a contractor in a Kalgoorlie dongas all deserve the same desktop experience when they hit a session host in Perth or Melbourne. The data sovereignty conversation matters here too. AppSense policies can be written to enforce that sensitive files never leave the session host, which keeps the conversation with the OAIC and the ASD Essential Eight controls much more straightforward.

It is worth distinguishing between personalisation and environment policy before you start writing rules. Personalisation covers the bits the user sees and customises: desktop wallpaper, mapped printers, application settings. Environment policy covers what the user can do: drive mappings, application whitelists, registry and file system permissions. Mixing the two leads to policies that are hard to debug, and you will end up reopening them every time a new application is added to the menu.

Preparing the environment before you install

RDS farms in Australia are often constrained by uplink capacity, particularly in regional areas where fibre has only recently arrived. Before installing AppSense, run a proper inventory of your session hosts and your shared storage. Confirm that the farm is homogeneous: same Windows Server build, same cumulative update level, same RDS CAL counts. AppSense configuration is usually replicated through group policy, so any drift between hosts shows up immediately as inconsistent user experiences.

Account preparation is another area where shortcuts cause pain later. Service accounts for the AppSense database, the file share that holds user data and the policy cache should all be created ahead of time, with sensible passwords and proper OU placement. Time zone handling deserves explicit attention. With users spread across AEST, ACST and AWST, an RDS session that defaults to the server's time zone can cause meeting clashes and confused log entries. Configure the AppSense environment policy to set the session time zone based on the user's home location, or push a GPO that does the same. The same applies to regional settings: currency, date format and number separators should follow the user's profile, not the host's default.

Pre-deployment planning is where most Australian RDS projects succeed or fail. The level of detail that goes into a proper staging plan is similar to the discipline shown in field projects like this island expedition guide, where every supply and contingency is documented before departure. Treat the rollout the same way: define the pilot group, write the rollback plan, schedule the change window, and rehearse the cutover on a non-production farm first.

Core configuration steps for a working deployment

Start by deploying the AppSense management server and the database, then point the console at the right SQL instance. On the RDS side, the management agent is installed on each session host and registered with the configuration server. A common mistake is to forget the firewall rules between the session hosts and the management server, which leads to agents that appear to be online but never receive policy updates.

Once the plumbing is in place, the next job is to author your first environment policy. Begin with a small, safe rule set: redirect Documents, Desktop and Application Data to a network share, enforce a standard set of printers based on the user's group membership, and lock down a handful of high-risk file paths. Test the policy against a single OU containing pilot users, ideally a mix of in-office staff in Melbourne and remote workers in Darwin, so you see how it behaves across connection speeds and authentication paths.

Application control comes next, and this is where most Australian admins start to feel the pressure. The temptation is to whitelist every executable the business uses, but that creates an unwieldy policy file that takes minutes to compile. Instead, use publisher rules for signed Microsoft and Adobe binaries, and rely on path rules for internal line-of-business apps. The Exchange site hosts a number of starter policies contributed by other members, and the forums are worth searching for templates tailored to healthcare, education or financial services workloads.

Personalisation is often the last piece, and it is the one users notice first. Configure the personalisation server to store user data on a high-availability file share, ideally with DFS Replication if you have session hosts in more than one data centre. Set the cache size to something realistic for a typical RDS user profile: 2 to 4 GB is common in Australian deployments, and going much higher tends to mask problems with bloated user profiles.

Troubleshooting and getting unstuck

When policies fail to apply, the first thing to check is the agent log on the session host. AppSense writes detailed logs to a configurable path, and the most common cause of a silent failure is a permissions issue on the policy share. Australian teams running mixed Windows Server versions sometimes find that an SMB signing or encryption mismatch prevents the agent from reading its configuration. Disabling SMBv1 across the farm is a good housekeeping step that often clears up these ghost issues.

User-specific problems usually trace back to the personalisation database. If a user reports that their settings keep reverting after every logoff, check that their personalisation archive is not corrupted. The management console has a repair option, and a recent backup of the user data share is invaluable. Always test the repair on a single user before rolling it out, because the process rewrites large parts of the user's profile.

When in-house knowledge runs out, the Exchange community is the next stop. The forums are organised by product and version, so it is usually quick to find a thread about the exact version of AppSense and the exact build of Windows Server you are running. For day-to-day account issues, the password reset page is the right starting point. If you are chasing a particularly obscure problem, the community advisors can be tagged in for a more detailed response.

Optimising for Australian conditions

Bandwidth and latency are the two variables that shape almost every AppSense decision in an Australian context. International links to the US or Europe carry more latency than domestic paths, so consider hosting the management server and personalisation shares in-region. A session host in Sydney serving users in Hobart or Canberra will perform well over the existing backbone, but the same host serving users in Perth will introduce hundreds of milliseconds of latency. The answer is not to throw bandwidth at the problem but to architect the farm around it.

Logging and monitoring deserve a regional tweak. Centralise AppSense logs in a SIEM that is aware of Australian time zones, and configure alerts to wake the on-call engineer at sensible hours. A misconfigured policy that breaks 200 users at 3am in Sydney is a serious incident; the same break at 3am in Perth is even worse, because the engineer is still finishing their day. Build a rotation that respects AEST, ACST and AWST, and document handover windows so nothing falls through the cracks.

Finally, plan for the long term. AppSense deployments tend to grow quietly as more applications are added to the policy stack, and a clean configuration today can turn into a tangled one within two years. Schedule an annual review where the policy tree is pruned, dead rules are removed and the user community is asked for feedback. Australian IT teams that do this consistently tend to run the smoothest RDS farms, and they are the ones who post the most useful guides back to the Exchange community.

If you are about to start a new AppSense deployment on RDS, or you are wrestling with an existing one, the Exchange community is ready to help. Browse the community forums for configuration templates, troubleshooting threads and product advice, and contribute your own findings once you have a working setup to share. The collective knowledge on the Exchange site is built by practitioners who have already wrestled with the same challenges, and adding your own notes makes the next deployment easier for everyone.