We’re trying to set up Perimeter 81 to secure access to our on-prem Windows file server, but the connector installation keeps failing. The server is running Windows Server 2019, sits in a DMZ, and has outbound HTTPS allowed to the internet.
I’ve followed the standard deployment guide, but the connector service won’t start. The installer runs, but then the service status shows “Stopped” and manual start attempts fail. Event Viewer shows a vague error: “Service cannot be started.”
Has anyone deployed this successfully on a similar setup? I’m looking for specific troubleshooting steps—maybe a port conflict, a local policy block, or a prerequisite I’ve missed. Our setup details:
- Static outbound proxy is NOT used.
- Windows Firewall is temporarily disabled for testing.
- The server has .NET Framework 4.8 installed.
- We’re using the latest connector version from the P81 dashboard.
So far I’ve tried:
- Reinstalling as Administrator.
- Checking for conflicting services on port 443 (none found).
- Verifying the network route to `*.perimeter81.com` is open.
Any logs or config locations I should check beyond the standard `ProgramDataPerimeter 81` folder? If you’ve solved this, what was the root cause in your case?
terraform and chill
Had the same headache on Server 2016. The Event Viewer error is useless. You need the connector's own logs.
Look in `C:ProgramDataPerimeter 81LogsConnector`. The `service.log` and `connector.log` files usually show the real crash reason. For me, it was a missing Visual C++ redistributable, even though the installer didn't flag it.
Also, double-check the service account. If you installed as a domain admin but the service runs as LOCAL SYSTEM, it might not have the right perms for the ProgramData folder. Try setting the service logon to your admin account temporarily just to test.
One more thing: the DMZ outbound HTTPS rule might be too narrow. Some connectors need specific subdomains, not just the wildcard. Can you test from a command prompt on the server? `curl -v https://api.perimeter81.com` to see if it's truly a clean TLS handshake.
Prompt engineering is the new debugging.
Yes, the connector logs are the right next step. I've seen the same pattern - the Windows event is just a wrapper.
> double-check the service account
This is often the culprit. On domain-joined servers, the LOCAL SYSTEM account might not have network credentials for certain resource lookups, even with outbound internet access. I'd also verify the service has "Log on as a service" right; sometimes group policy strips it.
On the subdomain point: our deployment needed `*.gw-api.perimeter81.com` in the allow list, not just the main API domain. A quick `Test-NetConnection` in PowerShell for a few of their documented endpoints can rule out a proxy or firewall hairpin.