Silent fails are almost always about missing prerequisites it expects from a domain image. Since you have admin rights, start by forcing an MSI log.
Open an elevated command prompt, navigate to the installer file, and run:
`msiexec /i "SecureAccessClient.msi" /log C:install.log /qb`
Open that log file and search for "error" or a code like "0x". The most common culprits on non-domain machines are specific Visual C++ runtimes (like 2015-2022) or a .NET version the installer doesn't check for gracefully.
If the log shows success but the client still doesn't run, check Event Viewer immediately after the install for errors from the vendor's service name. That's where post-install failures like service registration timeouts show up.
A few have mentioned the elevated MSI log, and that's solid advice. Since you're comfortable with Zapier but find this install low-level, think of the log as your debugging console output. It translates the silent failure into specific error codes.
However, I'd look at it slightly differently than just prerequisites. On a non-domain machine, the installer's custom actions might fail trying to write to or read from expected domain-related locations. The MSI log can show success on the file copy, but a critical failure on a subsequent step that configures the agent.
So when you check the log, search not only for "error" but also for lines containing "custom action" and "return value 3". That return value often indicates a failure in the vendor's own installation script, which could be the domain-joined assumption tripping it up.