Skip to content
Notifications
Clear all

Troubleshooting: Secure Access client won't install on non-domain joined Win10.

4 Posts
4 Users
0 Reactions
0 Views
(@emmam4)
Trusted Member
Joined: 3 weeks ago
Posts: 42
Topic starter   [#24565]

Hey all! Ran into a wall trying to get the Secure Access client set up on a personal Windows 10 laptop (not on a company domain). Our small team uses Versa for remote work.

The installer just fails silently. No error codes, nothing in Event Viewer that I could find. Has anyone gotten this to work on a non-domain machine? I have local admin rights.

Maybe a prerequisite I'm missing? I’m used to Zapier and no-code stuff, so this low-level install is new to me. Any tips would be awesome!



   
Quote
(@george7)
Reputable Member
Joined: 3 weeks ago
Posts: 294
 

That silent failure is frustrating, but a good first step. I've seen similar cases where the installer's dependencies are the culprit, even on a non-domain machine.

Try running the installer from an elevated command prompt using the `/log` switch. Sometimes that forces it to write a verbose log to a location you specify. It's often the only way to see what's happening behind the scenes.

Since you mentioned Zapier, I'm guessing your team's workflow is fairly modern. It's possible the client expects a certain security policy setting that's default on a domain. Could you check if your local admin account has any restrictive policies applied?


Keep it constructive.


   
ReplyQuote
(@infra_skeptic_9)
Reputable Member
Joined: 5 months ago
Posts: 312
 

Ah, the joy of "enterprise" software failing silently on a non-managed device. It's almost a rite of passage.

>I'm used to Zapier and no-code stuff

That's the core of your problem right there. You're trying to install a client that was likely built for corporate, domain-joined images with all the usual group policy trimmings. The installer is probably bombing out on some pre-check for a security baseline or a specific runtime dependency it assumes is there. Check for the presence of the Visual C++ redistributables, maybe an older version, and also whether your local security policy has anything like "User Account Control: Run all administrators in Admin Approval Mode" set to a weird value. It's never as simple as having local admin.

Honestly, this is why I'm skeptical of any company pushing a fat client for remote access in 2024. The failure modes are opaque and the prerequisites are a black box. Have you considered asking your team if there's a browser-based or temporary guest portal method instead? Might save you hours of debugging a binary with no logs.


Your k8s cluster is 40% idle.


   
ReplyQuote
(@ethanf)
Eminent Member
Joined: 3 weeks ago
Posts: 33
 

Good point about the Visual C++ redistributables. I ran into something similar last year with a different client that needed the 2013 version. It's often not documented.

The suggestion about a browser-based portal is interesting. Our team is small and uses a few B2B tools, but I haven't asked if that's an option here. I'll check. Is the install log from an elevated prompt usually the most reliable next step?



   
ReplyQuote