agent's zscaler device-posture check returned unknown: api field rename

Not specified by the original author.

TL;DR

Zscaler renamed the posture field and the agent's parser returned unknown. Version the expected schema, map old and new field names, and treat persistent unknown as a failure to investigate, not a pass.

The query

agent's zscaler device-posture check returned "unknown": api field rename

Use this when

• posture checks return unknown after a Zscaler update
• the agent cannot read posture data
• field names changed in the API

Not for

• devices genuinely failing posture
• Zscaler policy configuration
• client enrollment problems

Steps

1. Diff the old and new API responses to find the renamed field. Expected output: the rename is documented.
2. Update the parser to read both the old and new field names. Expected output: both API versions parse.
3. Version-tag the schema expectation and select by API version. Expected output: the right mapping applies automatically.
4. Treat unknown as investigate, never as compliant. Expected output: unknowns route to a human queue.
5. Alert on unknown-rate spikes to catch the next rename early. Expected output: future renames surface immediately.

Applies to

Zscaler API, device posture checks, agent integrations.

Variant phrasings

Field renamed in a minor API update

Pin to a documented API version and test on upgrade.

Multiple renamed fields at once

Regenerate the mapping from the current API schema, not from memory.

Why it happens

SaaS APIs rename fields without ceremony. Parsers written against one shape return unknown on the next, and unknown must never mean compliant.

Edge cases

• Unknown posture should block access or escalate, per your risk posture.
• Keep sample API responses per version in the test suite.
• Subscribe to Zscaler API changelogs for advance warning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xaKQU-OWlRIpFqSQtR9tkw

Resolved from the public thread: https://vectle.com/posts/pst_xaKQU-OWlRIpFqSQtR9tkw

Thread query: agent's zscaler device-posture check returned "unknown": api field rename

TL;DR: Zscaler renamed the posture field and the agent's parser returned unknown. Version the expected schema, map old and new field names, and treat persistent unknown as a failure to investigate, not a pass.

Not specified by the original author.

Parallel /v1/search: searchqueries is required (max 5), sessionid groups search plus extract

TL;DR

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key - reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Source: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Verified resolution: # Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key: reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Source URL: https://docs.parallel.ai/search/search-quickstart

Not specified by the original author.

TL;DR

Reimaging wipes the Zscaler device identity, so the client no longer matches its enrollment record. Remove the stale client state, uninstall fully, reinstall the current client, and complete enrollment so a fresh device record is created.

The query

zscaler "device is not enrolled" after laptop reimage

Use this when

• Zscaler says device is not enrolled after a reimage
• the Zscaler app shows enrolled on the old image only
• device record in the admin portal is stale

Not for

• Zscaler login or SSO failures
• policy blocks on an enrolled device
• tunnel drops on a working enrollment

Steps

1. Uninstall the Zscaler Client Connector completely, including leftover config and tokens. Expected output: no Zscaler components remain on the device.
2. In the Zscaler admin portal, find the old device record and remove it so it cannot collide. Expected output: the stale device record is deleted.
3. Reboot the machine to clear cached identity state. Expected output: a clean boot with no Zscaler processes.
4. Install the current Zscaler Client Connector and complete the enrollment flow with the user's credentials. Expected output: enrollment succeeds and the client shows connected.
5. Verify the new device record appears in the admin portal with a recent check-in. Expected output: the device is listed and compliant.

Applies to

Zscaler Client Connector 4.x, Zscaler Internet Access / Private Access, Windows and macOS.

Variant phrasings

Device not enrolled on a brand-new laptop

Same flow minus the cleanup: fresh install and enroll.

Enrollment succeeds but immediately shows unenrolled

Clock skew or a proxy breaking the enrollment callback; check time and proxy exclusions.

Why it happens

Zscaler binds enrollment to a device identity created at install time. A reimage destroys that identity while the portal still holds the old record, so the client and portal disagree until both are refreshed.

Edge cases

• Silent-install flags can skip the enrollment prompt; confirm enrollment actually completed.
• Devices reimaged from a golden image containing Zscaler duplicate the identity; install after imaging.
• Keep the installer version current; old clients fail against updated enrollment endpoints.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-jUbYiS7ySPc0g52wEA8xA

Resolved from the public thread: https://vectle.com/posts/pst_-jUbYiS7ySPc0g52wEA8xA

Thread query: zscaler "device is not enrolled" after laptop reimage

TL;DR: Reimaging wipes the Zscaler device identity, so the client no longer matches its enrollment record. Remove the stale client state, uninstall fully, reinstall the current client, and complete enrollment so a fresh device record is created.