Devices, posture and access

Before you begin

This page assumes the API and portal are deployed and at least one device is Active. Analysts need the Highwind.Operator role; administration tasks need Highwind.Admin or an Access assignment that grants the permission.

Ask devices and run queries

The portal can ask one device a question, or ask many devices the same question at once, and shows the answers in the browser. Both need the Highwind.Operator role and an agent at 3.7.0 or later.

How quickly answers arrive

There is no push channel to devices. The management service never opens a connection to an endpoint; each agent asks the service for work. So a question waits until the device next checks in:

• Request polling every FleetRequestPollIntervalSeconds (default 60 s). Most answers appear within a minute.
• Expiry: an unanswered question expires after 5 minutes. An offline device shows Expired; ask again when it is back.
• Check in now (device page) asks the device for its health and waits for the answer. An online device answers within about a minute; the answer proves it is alive and running the agent.
• Full posture sync (device page, or Full posture sync (all devices) on Posture) has the device collect every posture answer at its next check-in, instead of waiting for the scheduled refresh. It does not wake a device that is off: devices only ever call out.

Ask one device

1. Open Devices, select an Active device.
2. Under Ask this device, pick a question and select Ask.
3. The page waits up to 90 seconds and shows the answer as readable fields and tables, with the raw JSON underneath. If the device has not answered yet, select Check again.

Run a query across devices

1. Open Queries. Pick a question (a built-in one, one of your saved queries, or a custom query) and a scope: every device that can answer, devices tagged X (see device groups), or only the devices I tick (up to 100; open Pick devices and filter by name).
2. Optionally type a name in Save as to keep the question and its tag for next time. Saved queries appear in the Saved list with Use and Delete; an operator can delete only their own.
3. Select Run. The result page counts answered, failed, expired and outstanding devices while the query runs, and you can Cancel it.
4. When it finishes, the grid shows one row per device with the key values as columns. View opens the full answer in a full-width row under the device. Download CSV gives one row per device; for answers that are lists (installed software, ASR rules, App Control policies, firewall profiles, custom queries) Download CSV (one row per …) gives one row per device per item, with the device’s values repeated on each row so it filters and pivots cleanly in Excel.
5. History on the Queries page lists the last 50 queries in the tenant: what was asked, of which devices, by whom, when, and how many answered. Every query is also in the API audit log.

What you can ask

These are the only questions an agent will answer. Each is a fixed, read-only collector on the device; the service cannot send a script or a command. Only custom queries carry a definition, and the agent re-validates it against its own compiled rules. Every question and every read of an answer is written to the API’s audit log.

Posture baselines

The fleet majority is a good start, but it cannot tell you the majority is wrong. A baseline says what every device should report.

The portal compares each device’s effective state against it, whatever set the value: Intune, Group Policy, a script or a local administrator, and lists every difference on Posture with the severity you chose.

A setting in the baseline replaces fleet-majority drift for that setting; settings you leave out still fall back to the majority.

1. Open Admin → Baselines (/admin/baselines). Everyone can read it; editing needs Highwind.Admin or the Baselines permission.
2. The first tab is the Default baseline, used for every device. Settings are grouped by area. Each row shows Fleet today (the three most common values and how many devices report each) and Match (how many devices already meet the value you pick).
3. Pick an expected value and a severity (High, Medium, Low) per row. Leave a row at “—” to keep using the fleet majority for it. Fill empty rows from fleet majority pre-fills every empty row where at least 60% of devices agree; review it, then Save baseline.
4. Saving is versioned: if another administrator saved since you opened the page, your save is refused with a message and nothing is overwritten. Reload and apply your change again.

Different baselines for different devices

Servers, kiosks, labs and a pilot ring rarely share one standard. A tag baseline applies to devices carrying a tag and adds to the default for those devices: they are checked on every default setting plus the tag’s settings, and the tag’s value wins where both set one. Set only what differs for the group.

1. On Admin → Baselines, type or pick a tag in New tag baseline… and select Open. The list offers the tags devices actually report.
2. Set every expectation for that tag baseline (for example ASR: Block credential stealing = Audit on lab), then Save baseline. Fleet today and Match now count only devices with that tag.
3. A device uses the baseline for its device tag, else its org unit, else its environment, on top of the default. Tags match case-insensitively. Only one tag baseline applies to a device.
4. Delete on a tag tab removes that baseline; its devices are then checked on the default alone. Up to 100 tag baselines per tenant.

Baselines are stored in the service (GET /fleet/posture/baselines, PUT | DELETE /fleet/posture/baseline, at most 500 settings each) and every save and delete is audited with who made it. A baseline judges; it does not enforce. Nothing on these pages changes a device; fix differences with the tool that owns the setting (Intune, Group Policy, Defender for Endpoint).

Client configuration

Choose which reports devices send without touching Group Policy. Where the portal sets a report, its value wins over local ADMX; reports you leave on Not set stay under local policy.

1. Open Admin → Client configuration (/admin/client-configuration). Only Highwind.Admin can open it.
2. The first tab, All devices, applies to every device. To scope a change, type or pick a tag in New tag… and select Open. A tag (device tag, organisational unit or environment) overrides All devices for devices that carry it; the device tag wins over organisational unit, which wins over environment.
3. For each report pick Not set, On or Off, then Save. On a tag tab the All devices column shows what the default says. Delete removes a tag’s configuration.
4. Devices pick the change up at their next heartbeat and restart their session about 5 seconds later. Offline devices keep their last values.

Needs the ManagementRound43 database migration, the updated API and portal, and agent 3.7.0 or later on devices.

Device groups, Access and Admin

Group devices with the tags you already use for Highwind reporting, then give each Entra group exactly the devices and actions it needs. Everything administrative lives under Admin, at the far right of the navigation.

1. Tag devices

Set Device tag, organizational unit and environment (ADMX Highwind → Device Tagging), or the registry values DeviceTag, OrgUnit and Environment (REG_SZ) under HKLM\SOFTWARE\Policies\Highwind. Restart HighwindFleetAgent; the agent reports them when it registers. Values longer than 64 characters are ignored.

• Devices shows a Tags column, a tag filter and a sort (name, last seen, agent version, tag, registered). A tag matches the device tag, org unit or environment.
• Queries can target Devices tagged X; Posture can filter to one tag; tag baselines set a different standard per tag.
• Matching follows the database collation: case-insensitive on Azure SQL’s default.

2. The Admin area

Admin (/admin) shows a tile for each area the signed-in person may manage, and nothing else; someone with no administration permission sees a short note instead. Each page opens with an Admin › … trail back to it.

Old addresses (/settings/scopes, /enrollment, /device-identity, /posture/baseline, /queries/checks) still work. The portal hides what you cannot do, but the API decides: every permission is checked again by the service on every call.

3. Create the standard groups

So every tenant looks the same, create one Entra security group per role with New-HighwindFleetGroups.ps1. It creates any missing group (you become owner), gives it its app role on the API, and, with -ApiBaseUrl, adds its Access assignment for every device. Re-running it changes nothing that exists. Use -WhatIf to preview.

Download New-HighwindFleetGroups.ps1

.\New-HighwindFleetGroups.ps1 -Cloud AzureUSGovernment
# or also create the Access assignments (needs Highwind.Admin and the Azure CLI pre-authorized, see Verify step 2)
.\New-HighwindFleetGroups.ps1 -Cloud AzureUSGovernment -ApiBaseUrl "https://$apiApp.$webSuffix"

Needs Groups Administrator (or User Administrator) and Application Administrator. Assigning an app role to a group needs Entra ID P1 or P2; without it the script warns and you assign people directly. To limit a group to some devices, edit its row in Admin → Access and list tags. Use -GroupPrefix for a different naming standard.

4. Give a group access

1. Open Admin → Access.
2. Who: start typing a name in Search Entra users and groups and pick a result; the object ID and name fill in. Without the Graph permissions below, paste the object ID of a security group (or a user) and a display name.
3. Devices: open the device drop-down and tick the tags this group manages, or tick none for All devices. A tag no device reports yet can be typed in the box under the list.
4. Role: pick a preset and every permission it gives is ticked below (grouped as Devices, Administration and App Control), so you see exactly what you are granting. Change any tick and the role becomes Custom. Save. Edit on a row loads it back into the form; Remove deletes it. Changes apply within 30 seconds.
5. Check my permissions (account menu, or /account#permissions) lists every permission, whether you have it and where: every device, the tags it is limited to, or tenant-wide. Anyone signed in can open it.

# Lets the API's managed identity find users and security groups by name. Read-only; nothing is stored.
$graphSpId = az ad sp show --id 00000003-0000-0000-c000-000000000000 --query id -o tsv
$apiMi = az webapp identity show -g $rg -n $apiApp --query principalId -o tsv
# User.ReadBasic.All
Invoke-Graph POST "servicePrincipals/$apiMi/appRoleAssignments" @{ principalId = $apiMi; resourceId = $graphSpId; appRoleId = "97235f07-e226-4f63-ace3-39588e11d3a1" }
# GroupMember.Read.All
Invoke-Graph POST "servicePrincipals/$apiMi/appRoleAssignments" @{ principalId = $apiMi; resourceId = $graphSpId; appRoleId = "98830695-27a2-44f7-8c18-0c3ebc9698f6" }

The search runs in the API with its own identity, only for Highwind.Admin (GET /api/v1/fleet/scopes/directory?q=), and reads only the API’s home tenant. Without these permissions the search box says so and you paste the object ID as before.

• Several assignments add up. A person matched by their own assignment and their groups’ gets the union of the permissions and the union of the devices. An assignment for all devices covers everything.
• Unassigned operators keep what they had before 3.7.0: View and Run queries on every device. Choose see no devices and Apply to make an assignment mandatory.
• Highwind.Admin is never limited, and only it manages Access. Members of an assigned group still need the Highwind.Operator app role to sign in.

5. Your name, tenant and role in the header

The top-right corner shows who is signed in, the tenant name and a role pill: Full admin, the preset name (for example Device manager), Custom access or No access. Hover the pill for the exact permissions and devices in scope.

The tenant name comes from the fleet database; set or correct it in Admin → Access → Tenant name (PUT /api/v1/fleet/scopes/tenant-name, Highwind.Admin, audited as TenantSettingsChanged). Until it is set, the header shows the start of the tenant ID.

6. Activity log: who did what

Admin → Activity log (/admin/activity, Highwind.Admin only) is the tenant’s audit trail in plain words, newest first: the person (by name), what they did, the device, the outcome and any error code.

• Filter. Choose People (portal and API actions), Devices (registration, check-ins, answers), Service (schedules, snapshots, expiry) or All, then narrow by person, action, outcome (allowed or refused), device name or dates.
• Export CSV downloads up to 100,000 rows with the same filters.
• Names are taken from each person’s own sign-in, so they appear from the first action after this release. Older rows show the object ID.
• Reading or exporting the log is itself audited (AuditLogRead, AuditLogExported).

7. Minting secrets is accountable

Minting an enrollment secret now asks for a justification (10–500 characters, for example a change number). The secret list shows Minted by and the justification, and both are written to the EnrollmentTokenIssued audit event. A mint without a justification is refused with 400.

What a tag is, and is not. Tags are reported by the device, and a local administrator on a device can change them. Tag-limited access separates operators from each other’s devices; it is not a boundary against the device’s own administrator. Use Entra role assignment and Conditional Access to control who is an operator at all.