AppSense and PowerShell: automating user environment diagnostics

For Australian IT teams, combining AppSense telemetry with a repeatable endpoint inventory can significantly improve support diagnostics. Instead of relying on a help desk user’s description of a failed login, slow application launch or missing software, a support analyst can collect a consistent snapshot containing the Windows build, AppSense client version, relevant services, installed applications, policy-related events and recent application errors. That snapshot shortens triage while preserving the context needed to determine whether the cause lies with the device, the user’s session, an application deployment or the management platform.

Automation is particularly valuable in a country where teams in Sydney, Melbourne, Brisbane and Perth operate across different time zones and many staff troubleshoot from shared home offices, hot desks and secured client sites. It also supports the Australian enterprise mix of Microsoft 365, Endpoint Manager and specialist desktop-management products. The objective is to give the next support step a defensible baseline. Any collection capable of identifying a person or device should follow the Privacy Act 1988 and the Australian Privacy Principles where applicable, including purpose limitation, security and controlled retention.

Capture a reliable diagnostic baseline

A useful diagnostic starts before remediation. Record whether the issue affects one user or many, the approximate start time, the application and version involved, whether it occurs after sign-in, VPN connection or application launch, and any recent desktop-management deployment. Include the AppSense product, client and policy versions in the metadata. These fields turn a collection into a repeatable baseline: two incidents labelled “Outlook won’t open” can have entirely different causes if one follows a policy refresh and the other occurs only over a home network.

Capture context in layers. The machine layer can contain the operating-system build, uptime, architecture, disk space, service state and relevant application registrations. The user layer can show mapped drives, profile path, group membership and per-user configuration. The AppSense layer should expose client health, policy or application events, and the result of the most recent policy evaluation where the installed version records it. Keep sensitive values out of the report: credentials, tokens, document contents, full process command lines and unrelated registry keys add risk without helping most first-line cases.

Time handling is a small but important detail for Australian operations. A workstation in Perth may run on UTC+8 while Sydney and Brisbane use UTC+10, or UTC+11 during daylight saving. Store raw event timestamps in UTC, retain the machine’s local offset, and display both in dashboards. A collector running during a morning support window can also save the current user’s sign-in time and the previous 30 minutes of Application event records, making it easier to reproduce a transient fault without asking the user to repeat a disruptive action.

Automate collection with safe PowerShell scripts

Start with a small, non-mutating collector that creates one JSON summary and one application inventory CSV. Run the user-scoped version in the affected session so that HKCU registrations and user context are visible. Run elevated or system-scoped checks only when client service state or machine-wide policy data requires them, and record which mode was used.

[CmdletBinding()]
param(
    [string]$OutputRoot = (Join-Path $env:TEMP 'AppSenseDiagnostics')
)

$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$outputDirectory = Join-Path $OutputRoot $stamp
New-Item -Path $outputDirectory -ItemType Directory -Force | Out-Null

$operatingSystem = Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OSArchitecture

$appSenseServices = Get-CimInstance Win32_Service |
    Where-Object {
        $_.Name -like '*AppSense*' -or
        $_.DisplayName -like '*AppSense*'
    } |
    Select-Object Name, DisplayName, State, StartMode, PathName

$installedApplications = Get-ItemProperty -Path @(
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
) -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName } |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate

$recentEvents = Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddHours(-4)
} -MaxEvents 500 -ErrorAction SilentlyContinue |
    Where-Object { $_.ProviderName -match 'AppSense|Ivanti' } |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

$summary = [pscustomobject]@{
    CollectedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
    LocalTime      = (Get-Date).ToString('o')
    LocalOffset    = [TimeZoneInfo]::Local.GetUtcOffset((Get-Date)).ToString()
    Computer       = $env:COMPUTERNAME
    User           = $env:USERNAME
    PowerShell     = $PSVersionTable.PSVersion.ToString()
    OperatingSystem = $operatingSystem
    AppSenseServices = @($appSenseServices)
}

$summary |
    ConvertTo-Json -Depth 6 |
    Set-Content -Path (Join-Path $outputDirectory 'summary.json') -Encoding UTF8

$installedApplications |
    Export-Csv -Path (Join-Path $outputDirectory 'applications.csv') -NoTypeInformation -Encoding UTF8

Write-Output $outputDirectory

The collector deliberately avoids changing policy, restarting a service or launching an application. A read-only result can still support safe next steps, such as confirming that the AppSense service is stopped, the application is absent from the inventory, or an event source changed after an update. Version-specific AppSense logs and registry locations should be added only after the baseline is working because hard-coded paths quickly become misleading. Package the approved script as a signed module, keep the output schema stable and pass the output location as a parameter rather than editing the file on each call.

Before a script, report template or diagnostic package is posted to AppSense Exchange, review the community publication terms and remove usernames, host names, email addresses and customer identifiers. The community’s version-based library is more useful when contributors label the product build, Windows requirements and privilege level clearly. A command that works in an unconstrained developer console may fail under an organisation’s application-control policy, so include tested execution conditions rather than implying that every endpoint will behave identically.

Turn diagnostic evidence into focused triage

Raw diagnostic data becomes useful when it answers three questions: Is the endpoint expected, what changed, and who needs to act? Normalise Windows build strings and AppSense versions, then group events by provider, event ID and severity. A useful triage view highlights a recently installed update, a service that changed from Running to Stopped, repeated policy-evaluation failures and applications installed for the machine but not registered for the current user. These signals are stronger than a generic high-resource alert because they connect device state to the user’s reported symptom.

The community article about third-party monitoring tools shows how external monitoring can share context with AppSense without creating two conflicting views of policy state. Correlation should use identifiers that remain consistent across systems, such as a support case reference, machine asset ID and AppSense client version. If the support console displays a policy failure while the monitoring platform reports a healthy client, the combined record can reveal whether the difference is caused by scope, timing or a recently completed installation.

Create severity bands rather than treating every anomaly as an incident. For example, classify a stopped client service as critical only when managed application launches are also failing; classify a missing optional application as low priority when the core AppSense service and policy evaluation remain healthy. Record both the signal and the reason for its severity, and retain a link to the original diagnostic package for auditability. This makes PowerShell automation an evidence-gathering layer while trained support staff retain responsibility for changes to production endpoints.

Build privacy, security and operational guardrails

Privacy and security controls belong in the script design, not in a later cleanup step. Where the Privacy Act 1988 applies, use the Australian Privacy Principles to define why diagnostic data is collected, restrict access to people who need it, keep it secure and delete it when no longer required. Employee information can also be affected by employment contracts, industrial instruments and applicable state or territory rules. A legal or privacy officer should determine the relevant obligations, particularly for employee monitoring, overseas support access and long-term storage of identifiable endpoint reports.

Technical controls can support those obligations. Use role-based access to the report directory, encrypt stored packages, avoid broad logging of user activity and apply short, documented retention periods. Redact at collection where practical rather than trusting every downstream tool to remove identifiers. Test scripts against the organisation’s endpoint controls, including Constrained Language mode, Windows Defender Application Control and PowerShell execution policy. Never use a collector to capture credentials or browse a user’s files, and never grant permanent elevation to a script that only needs to read service status.

A practical review checklist for each diagnostic workflow is:

• Minimise collection. Gather only fields tied to a named support case, and replace personal names with a case reference before a report leaves the controlled environment.
• Separate collection from change. Keep baseline scripts read-only; require a reviewed remediation command with rollback notes and a defined approver.
• Preserve evidence. Store an encrypted original package and a redacted working copy with timestamps, script version, endpoint build and operator identity.
• Automate expiry. Schedule verified deletion by retention date and audit access to diagnostic locations rather than relying on support staff to remember manual cleanup.

Operationalise the workflow and share proven results

Pilot the workflow on a small cohort across ordinary and high-risk environments: a managed office device, a remote laptop, a shared kiosk and a recently re-imaged endpoint. Measure time to first diagnosis, repeat-contact rate, false positives and the proportion of cases closed without a site visit. Publish the script, schema and examples in AppSense Exchange so members can search resources by product and version, download a tested baseline, or compare it with configurations uploaded by other organisations. Forum discussions can then focus on a sanitised failing event ID and expected result rather than repeatedly exchanging sensitive screenshots.

Useful automation also leaves a trail for the next analyst. Keep a changelog beside each script, record compatibility with Windows and AppSense releases, and include a short known-limitations field. The broader community troubleshooting notes can help connect local AppSense symptoms to wider endpoint and PowerShell practices, while the Exchange discussion forums provide a place to ask community advisors for version-specific guidance. Avoid pasting raw reports into a public thread; upload a sanitised package only after checking its contents and the publication rules.

Begin by running the read-only collector during one low-risk support case, reviewing the output with a senior analyst and refining the schema before introducing automation to the wider queue. Then publish the verified version with its test matrix, sample redacted output and clear ownership for future updates. That combination of repeatable collection, controlled evidence and practical community knowledge turns a one-off troubleshooting command into a dependable diagnostic service for Australian organisations.