Alright, let me add another entry to my ever-growing list of "platforms that promise seamless third-party integration until you actually try to do it." I’ve been tasked—again—with getting our endpoint security posture validated before allowing network access, and Versa’s Secure Access posture check is, predictably, causing migraines. We’re not using one of the big, out-of-the-box AV solutions; we have a custom-built agent that’s been humming along fine for years. According to the documentation, we should be able to make this work with a custom compliance script. Spoiler alert: it doesn’t.
The theory is straightforward: you drop a script on the endpoint (Windows, in our case), the Secure Access client executes it, and based on the exit code or output, it grants or denies access. We’ve followed the template, we’ve mimicked the structure of the example scripts for known AVs, and we’ve verified the script runs perfectly locally with admin rights. Yet, the Secure Access client either times out, misinterprets the output, or simply reports “Check Failed” with the most useless generic log entry on the controller.
Here’s a condensed version of our ordeal and what we’ve tried:
* **Script Logic:** The script checks for our AV process, verifies its service status, confirms definition age, and returns `0` with a JSON string `{ "status": "COMPLIANT" }` on success, or a non-zero exit code with `{ "status": "NON_COMPLIANT" }` on failure. Locally, it’s bulletproof.
* **Versa Controller Configuration:** We’ve defined the custom check with the correct path to the script (`C:Program FilesVersaSecureAccessCompliancecustom_av_check.ps1`). We’ve tried both “Script” and “Executable” check types. We’ve set every conceivable timeout value from 30 seconds to 120.
* **Permissions:** The script is in the Versa directory, which the Secure Access client should have rights to. We’ve even tried the nuclear option of granting “Everyone” full control on the script file. No change.
* **Logging:** The controller logs are a black box of ambiguity. The most we get is `Posture check execution failed for device`. The client-side logs on the endpoint are equally unhelpful, showing a successful policy fetch but no detail on the script execution failure.
So, my question to the room—has anyone actually successfully implemented a *custom* posture check script with Versa Secure Access, particularly on Windows endpoints? I’m looking for the kind of gritty, not-in-the-manual details that you only learn after a week of pain, like:
* Is there a specific user context the script runs under that we need to explicitly grant permissions for in the registry or filesystem?
* Does the output JSON need to be written to a specific stream or location? We’re just writing to stdout.
* Are there hidden character or encoding issues with the script that the parser chokes on?
* Is there some secret sauce in the controller policy configuration beyond the basic “path and timeout” that they don’t tell you about?
I’m on the verge of telling management we need to bolt on a commercial AV just for this check, which would be a spectacular waste of money and a win for checkbox security over actual security. I’d rather not add that to my annual CRM-style platform failure post-mortem document.
Ugh, I feel your pain. That "Check Failed" with generic logs is the worst part, isn't it? It's like the system just gives up and shrugs.
I hit something similar last month. For me, the culprit was the script execution timeout being way too low in the Secure Access policy. The default is brutal for anything that does more than a basic registry check. Try cranking that timeout way up, even to something silly like 90 seconds, just as a test.
Also, double-check the script's *output format* exactly. I've found their parser can be weirdly picky about trailing spaces or newlines. Maybe echo your output to a file and compare it byte-for-byte with a working example script.
Beta tester at heart
Increasing the timeout is a good first step, but it's a resource band-aid. If your script needs 90 seconds to verify AV status, that's a problem in itself. You're adding significant latency to every connection attempt.
The format issue is real. Their script engine often runs in a restricted shell. I've seen it fail on simple PowerShell `Write-Output` because it expects plain text from stdout. Redirect to a file and use `type` or `cat` to output.
Check the service account permissions for the Secure Access client. It might not have execute rights on your script's directory.
cost per transaction is the only metric
Your experience with the generic "Check Failed" log is a classic symptom of the posture agent's failure to properly execute or parse the script's runtime context. The key isn't just script correctness, it's the environment isolation. The Secure Access client typically runs scripts under a non-interactive, constrained session that strips many environmental variables and limits module imports.
First, confirm the agent's execution engine. If it's using Windows Script Host versus PowerShell, you'll face different constraints. I'd instrument your script to dump the entire runtime environment - `$env:PSModulePath`, `$env:PATH`, current identity - to a known file *before* any logic. Compare that output from a manual admin run to the agent's run. The disparity is usually there.
Second, the output format is stricter than documented. It's often not enough to match the example; the agent might be capturing both STDOUT and STDERR streams. Ensure your compliance status is written to the standard output stream only, and that any verbose logging or errors are explicitly redirected to null or a separate log file. A stray debug line can invalidate the entire check.
—BJ
It's easy to get stuck in that cycle of perfect local tests but cryptic platform failures. Everyone's suggestions are spot-on, particularly the environmental differences.
I'd just add one specific angle: check if your script is relying on any long-running Windows services that might be in a "start pending" state when the agent runs. The script might see the service as registered and think it's okay, but the agent's own health check could fail if it expects a specific responsive state.
Also, have you raised this with Versa support yet? Sometimes these integrations hinge on an undocumented requirement, like a specific file encoding for the script. If you have a ticket number, posting it here can help others track the same issue.
Keep it constructive.