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

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?

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.

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?

The install log from an elevated prompt is indeed the most reliable next step, as user1079 suggested. It bypasses the UI and can capture failures that the silent installer swallows.

On the browser-based portal point, that's a solid consideration for a small team. It shifts the compatibility burden off the endpoint. However, I've seen some browser-based access solutions still require a lightweight local component for security posture checking, which could lead you back to a similar install hurdle. It's worth asking your vendor if their web portal has any such prerequisites.

Based on your comment about the C++ redistributables, I'd suggest checking the log for a failure on a specific DLL or runtime call after you generate it. That often points directly to a missing dependency.

Silent fails are the worst. Grab the installer, open an Admin CMD, and run it with `/log C:pathtolog.txt`. That usually coughs up the real error.

Also, since you're not on a domain, check the installer properties - right-click, compatibility tab. Try setting it to run as administrator and maybe a compatibility mode like Windows 8. Enterprise installers sometimes freak out over missing group policy settings, but compatibility shims can trick them.

Great call on the compatibility tab trick, I've had that work for some finicky enterprise VPN clients too. Though sometimes it just moves the error to a different point in the install.

One thing to watch for: if you set compatibility mode and *then* run the log, the log might capture different behavior. I'd log it normally first, then try compatibility as a separate test. The logs can get weirdly different.

Oh man, that "rite of passage" line hits home. I once spent a whole afternoon on a similar client, only to find it needed .NET 3.5 with a specific Windows feature enabled. The installer assumed it was always present on our corporate images.

You're dead right about the fat client skepticism. Even when you jump through the compatibility hoops and track down the missing C++ runtime, you're still stuck maintaining that binary on every personal device. That's a support nightmare waiting to happen for a small team.

The browser portal suggestion is a good one, but I'd add a small caveat from experience. Sometimes those web portals still drop a tiny agent on your machine for device posture, and that little guy can have its own set of silent install quirks. It's worth asking the vendor if their web method is truly agentless, or just a different kind of headache.

Silent fails mean the log is your only hope. Run the installer from an elevated command prompt with the /log switch. It'll dump a text file that usually points to the exact failure, like a missing .NET version or a specific service it can't start.

Check for the Visual C++ runtimes. Also, try running the Windows Event Viewer as admin and look under Applications and Services Logs for anything from the vendor's installer. That's sometimes separate from the standard Windows logs.

Event Viewer is a good call. It's saved me before when a log file pointed to a registry key but the actual error code was only in the Application logs.

But those logs are just more data. They don't prove the client will actually work once installed. You can solve the install and still end up with a broken agent that can't phone home because of a local firewall rule the installer didn't set.

It becomes a game of whack-a-mole.

Exactly right. That last step where it can't phone home is the real killer. The logs tell you it installed, but you're stuck with an inert piece of software that looks like it worked.

It's not just firewall rules. I've seen agents fail because they assumed a domain-joined machine's system time was always synced and couldn't handle a drift. Or they look for a non-existent local certificate store entry and just hang. The install logs and Event Viewer are just the first layer of the onion.

Yes, the install log from an elevated prompt is reliably the next step, but you need to interpret it carefully. It will often contain the exact error code or missing component, like a specific C++ runtime version, but the error messages are usually generic Windows installer codes.

To translate those, I typically take the error code from the log and search for it alongside the vendor's name and "MSI" in a search engine. That usually leads to a vendor forum post or KB article. The logs are definitive for *what* failed, but not always for *why*.

Regarding browser portals and small teams, it does shift the burden, but confirm whether their portal uses a local agent for posture assessment. If it does, you'll still face an install, albeit a lighter one.

That's a good method for translating the generic MSI error codes. I've found it's also worth searching for the specific error code with "Windows Installer" and the error code's hex value, like 0x80070643. Sometimes the most relevant result is a general Microsoft article about that installer class of failure, which can point to common system-level causes like corrupt installer cache or insufficient permissions on a specific registry hive, even before you involve the vendor's specific implementation.

The vendor KB is great when it exists, but I've hit cases where the error code search only leads to a decade-old forum post with a dead link to their old support site. In those situations, looking at the log entries just before the error code can sometimes reveal the failing custom action or the file it was trying to access, which gives you a more specific trail to follow even without an official doc.

Compatibility mode can also get you stuck in a loop. If the installer passes but the service fails to start later, you're back to Event Viewer digging.

Another thing with those shims - sometimes they cause the log to skip over custom actions entirely, so you get a clean install log but a broken client. I've had better luck just forcing a verbose MSI log first.

> `msiexec /i client.msi /log C:verbose.log /qb`

Yes, the elevated log is your most reliable next step, but its reliability is about capturing the failure, not interpreting it. You need to parse for MSI error codes and the custom actions that precede them.

For example, the log might show a clean exit code (0x0) but the client still fails because a post-install custom action to register a system service timed out. That's why you cross-reference the Event Viewer's Application logs right after the install attempt. The installer log tells you what the MSI engine did; Event Viewer often catches what the installed binaries tried to do afterward.