This is a SentinelOne blocked installer story, except the installer never told me anything had been blocked. I ran the same DBSafer agent installer on two Windows servers. One worked. On the other, the installer simply ended, with no error and no service.
Same Installer, Two Servers
Both servers needed the same server-side DBSafer agent, so I ran the same installer on each.
| Server A | Server B | |
|---|---|---|
| Installer | Completed normally | Exited without any error message |
| DBSafer service in Windows Services | Registered normally | Did not register normally |
An installer that closes quietly looks like a successful installation. The missing service was the only sign on Server B that it wasn’t.
Comparing Instead of Reinstalling
The obvious next step on Server B was to run the installer again. I didn’t, because the same installer had just worked on Server A. If the package itself were the problem, it should have failed on both servers, so my suspicion moved away from the installer and toward something specific to Server B.
I compared the two environments. The meaningful difference I found was that Server B was running SentinelOne.
What the SentinelOne Log Showed
I went through the SentinelOne logs for Server B. They recorded a failure tied to a DBSafer-related executable. I’m not quoting the entry or naming the executable or its path, and I can no longer pull the original log to check the exact wording.
What I took from it was this. The activity SentinelOne was interfering with was the installation of the DBSafer agent on the server. That was the evidence the installer never gave me: it had no error to show, and the endpoint security log was where the failure had been recorded.
Why We Didn’t Add an Exception
The usual fix for a blocked installer is a SentinelOne exception followed by another attempt. We didn’t do that.
The environment’s policy didn’t require the agent to be installed, so there was a quicker path that didn’t depend on getting the installer past SentinelOne. SentinelOne was also due to be retired soon, so there wasn’t much point building a workaround around it.
Agent Registration vs. Manual Registration
We registered Server B manually through DBSafer instead of through the agent.
| Agent registration | Manual registration | |
|---|---|---|
| Who starts the communication | The agent on the server connects to the DBSafer management server | The management server connects to the server |
| What you do | Install the agent on the target server | Enter the server’s information on the management server |
| What happens next | The agent reports in | The management server tries to reach the server, then starts a health check |
Why the Manual Route Worked
SentinelOne was blocking one specific action: installing the DBSafer agent on the database server. Entering the server’s information on the DBSafer management console is a different action, and SentinelOne doesn’t control it. Nothing had to be installed on Server B for the registration to go through, so there was nothing for SentinelOne to block.
The registration completed, though not the way I had planned it.
What I Took From This
- A silent installer exit is not a successful installation. Check that the service actually exists.
- When identical software behaves differently on two servers, compare the environments before reinstalling. A reinstall would have repeated the same blocked attempt.
- Endpoint security logs can explain failures that installers and application logs don’t expose.
- Check whether the original deployment method is actually required. Here it wasn’t, and the manual route got the server registered without fighting the security product.
Related reading: The Agent Was Running. Rapid7 Said It Was Offline. is another case where an agent looked fine on the server and wasn’t.
FAQ
Can SentinelOne block an installer without showing an error?
The installer may end with no message at all. In this case the only visible symptom was a service that never registered, and the failure appeared only in the SentinelOne log.
What should I do when an agent installs on one server but not another?
Compare the two servers before reinstalling, especially any endpoint security software that only one of them runs, and check that product’s logs.
Is a security exception always the right fix for a blocked installation?
Not necessarily. If the product offers another registration or deployment method and the agent isn’t required, that can be the faster route.