Integrating AppSense with Microsoft Intune for Cloud-Hosted Endpoints
Microsoft Intune and AppSense solve adjacent parts of endpoint management. Intune handles enrolment, policy, compliance and packaged app deployment, while AppSense can shape the Windows workspace, publish approved software and reveal how applications are used. For cloud-hosted endpoints, the best design treats them as cooperating layers instead of overlapping management systems.
Most Australian organisations still manage a mixed estate: Windows 365 Cloud PCs, Azure Virtual Desktop session hosts and physical laptops used from home or regional offices. Integrators must account for variable WAN paths, privacy duties and support windows spanning Perth, Brisbane, Sydney and Melbourne, while confirming that management continues beyond the corporate network.
Set the integration boundary
A useful integration starts with ownership. Intune should remain the source of truth for device identity, compliance and the installation state of Win32 packages. AppSense should retain responsibility for the user experience, software presentation and AppSense-specific policy. This boundary prevents two consoles from attempting to repair the same client.
Three patterns are common. Intune can install and update the AppSense client while AppSense publishes software; a configuration service or supported connector can synchronise selected settings; or an administrator can use each product within a defined workflow. API-driven exchanges need authenticated, documented interfaces and error handling, not ad hoc calls to undocumented endpoints.
Package and volume behaviour deserves a separate test. The Exchange’s App Volumes integration walkthrough provides a concrete reference for tracing how software assets are presented and managed, helping teams avoid assumptions when a client connects to an AppSense server.
Prepare the endpoint estate
Check licensing and support before touching devices. The tenant needs eligible Microsoft Intune or endpoint-management entitlements, Entra ID administration, and an AppSense client and server combination listed in the vendor support matrix. Record required Windows editions, browser versions, certificate authorities and privileged admin accounts so deployment does not depend on tribal knowledge.
Define what “cloud-hosted endpoint” includes. On a Windows 365 Cloud PC or Azure Virtual Desktop session host, the AppSense client must run in the interactive Windows session; on a physical laptop, it runs on the device. Intune can manage the session host, but it does not automatically manage the customer-owned laptop used to reach it.
Test from each Australian connectivity pattern. A Sydney user on a broadband VPN, a Melbourne office behind a filtering proxy and a Perth branch on a constrained link may receive the same package but reach Intune and AppSense through different routes. Allow the required Microsoft and AppSense destinations, validate split-tunnel behaviour and record latency before a broad rollout.
Deploy AppSense through Intune
Package the AppSense client as a Win32 application, normally through an Intune app package in the .intunewin format. Use a detection rule based on a stable executable, installed file or Windows service, and make the install and uninstall scripts return the exit codes Intune expects. Test upgrade paths as well as clean installation.
Assign by rings rather than the whole tenant. Start with a small pilot, including one Windows 365 Cloud PC, one virtual desktop session and one physical device. Watch for required app detection, install success, client registration and AppSense logins for several days before expanding to production groups in Melbourne, Brisbane or Sydney.
Choose one configuration owner for each setting. Intune scripts, endpoint-management platform scripts and AppSense tools can all alter registry values or services, so concurrent writes can cause drift. Pass initial configuration through the packaged client where practical, then document any value that AppSense manages after installation.
Secure identity and network access
Treat identity and device state as part of the application design. Where the deployed AppSense version supports Microsoft Entra ID, use an approved service identity and least-privilege access; otherwise, isolate the required service account. Conditional Access should protect administrative workflows without accidentally blocking the AppSense client’s server communication.
Publish the AppSense management URL over HTTPS with a certificate trusted by every Windows image. Confirm the certificate chain, supported TLS settings, proxy discovery and outbound access. In a cloud session, verify that user logon, AppSense cache locations and machine-scoped configuration behave correctly when the profile changes.
Review Australian privacy requirements before enabling usage collection. Where the Privacy Act 1988 and Australian Privacy Principles apply, document the purpose, access controls, retention and any sensitive information collected. Also record where Microsoft and AppSense process data rather than assuming all workloads remain in Australia; the AppSense community forums can provide practical guidance before production certificates or collection settings change.
Publish software without duplication
Use AppSense Software Publisher for the user-facing layer: Start menu and desktop shortcuts, self-service application access, taskbar behaviour and controlled software entries. Intune can remain responsible for deploying and updating the underlying package. This separation supports consistent publishing across Cloud PCs, virtual desktops and physical endpoints without making users hunt through multiple catalogues.
Create a source-of-truth matrix for every application. Name the owner of installation, updates, shortcut creation, licensing and removal, and record which tool must act first during deployment. If both products detect or install the same package, disable the duplicate path and test that users retain a single shortcut and a single upgrade route.
Apply AppSense policies according to role and device context, then review usage data with the same care as other workforce telemetry. Look for blocked launches, abandoned deployments and applications users cannot discover. Feed recurring support cases back into publisher templates so the next release arrives with the correct entry point and dependency.
Validate the end-to-end experience
Build a repeatable test script before the pilot expands. Cover client installation, service health, server registration, application launch, shortcut visibility, update behaviour and restart recovery. Repeat each check from a home connection, a filtered corporate network and a pooled virtual desktop, because the same endpoint can follow different authentication and download paths.
Diagnose with timestamps. Compare Intune app reports and detection output with AppSense client logs, Windows Event Viewer entries and server-side records. Record the endpoint name, tenant, AppSense version and error code in the test notes, while removing user names, tokens and other sensitive data before sharing a case in a public forum.
Common failures include an incorrect detection rule, a blocked service URL, an untrusted certificate chain, duplicate shortcuts and a profile path unavailable to a cloud session. Teams often use reassuring local language such as “No worries, we’ll pick it up in the morning”, but the handoff still needs the exact time in AEST or AEDT and the next owner.
Roll out in measured stages
Move through discovery, pilot, controlled waves and business-as-usual operation. Each wave needs entry and exit criteria, such as successful registration, low install failures and no material change in application launch time. Keep an exception path for specialist devices and a rollback package so a faulty script can be withdrawn quickly.
Check how the service is bought in the Australian market. Some organisations use a managed service provider and existing Microsoft agreements; others procure AppSense support directly. Confirm tenant responsibilities, support tiers and included deployment effort in writing, so reseller or consultant boundaries do not leave the internal team with an unowned integration.
Maintain a runbook with version-specific steps, service accounts, certificate expiry dates, known issues and escalation routes. Align release windows with Australian business hours, daylight-saving changes and state public holidays. Review telemetry after each wave and assign a named owner for Intune configuration, AppSense publishing and the Microsoft service account.
| Area | Intune responsibility | AppSense responsibility | Shared checkpoint |
|---|---|---|---|
| Enrolment | Tenant enrolment, compliance and device assignment | Confirm the client can run and register | Healthy device and approved identity |
| Deployment | Win32 packaging, detection and assignment | Supply the supported client and settings | Clean installation and upgrade |
| Configuration | Initial scripts and compliance policy | Workspace and software settings | One owner for every setting |
| Software delivery | Underlying package deployment | Publishing and user access | No duplicate installs or shortcuts |
| Monitoring | Installation and compliance reporting | Client health and usage visibility | Correlated timestamps and escalation |
A sound AppSense and Intune integration gives the endpoint team one operating model rather than two disconnected consoles. It also leaves a clear audit trail for Australian privacy, support and change management, while giving users a consistent software workspace wherever they work.
Ready to move beyond a trial? register for AppSense Exchange, choose a mixed pilot estate and record the ownership decisions before deployment. Publish the tested configuration, monitor the first wave and turn the runbook into the standard for each subsequent rollout.