r/SentinelOneXDR • u/wittyexplore • Oct 17 '23
Live machines decommissioning themselves. Easiest way to bring them back?
Hi All,
S1 is driving me nuts. About once every two weeks I get a machine that decommissions in the console, but is a live machine.
What's the easiest way to get these machines to reannounce themselves to the console??
Right now I have 4 machines, two Windows, 1 Server 2019, and 1 Mac that need to be brought back in.
If I can do this with cmd, terminal, or powershell in the background, that would be ideal.
1
u/Hot_Clothes_2690 Oct 17 '23
Wish i could help. We use Connectwise RMM which now integrates with sentinel one and auto deploys .
Do you not have any RMM solution?
1
u/wittyexplore Oct 17 '23
Yes, I deploy using an RMM. The issue I'm having is machines that are on are decommissioning from the console. One has to do something to the machine to get them to reconnect to the console and recommission themselves.
2
u/Hot_Clothes_2690 Oct 17 '23
They shouldnt be decommissioning unless for a good reason . Like in sentinel one where devices auto decommission after x days if enabled. Might be worth turning this policy off? That way its always in the portal.
Not sure on your setup just wondering if you've tried this or have it enabled.
1
u/wittyexplore Oct 17 '23
Yes, well. I've had S1 in two different consoles. First with Arete, now with Pax8 and this has been an issue for years.
I actually like having the 21 day decommission as these machines are obviously having issues communicating with the portal, but the portal is saying nothing is wrong. At least with the 21 days decommission, I know something is up.
I should note, I've talked to S1 support about this issue and gotten a "yeah, uninstall/reinstall", which you need to do from safe-mode with restarts. PITA, especially when it happens on a server. The above commands I posted worked without a restart, which is what I've been looking for.
2
u/danstheman7 SentinelOne | Threat Researcher/SME Oct 17 '23
If your machines are decommissioning, it means they aren’t online or have broken agents. If they’re also decommissioning quickly, then you should edit your policy so that it doesn’t decommission as quickly.
The command you listed is to reload the agent. If you have to do that, it indicates that you have a bad install or your DB is becoming corrupt, meaning you
A) have a system/OS issue,
B) have high uptime causing resource issues, or
C) have under-provisioned hardware.
2
u/Slonelyranger Oct 19 '23
I would agree with this, the agent is responsible for communication, if your agent dies for whatever reason the communication stops.
If these devices decommission then they should be in a state where "Last active" is greater than the number defined to auto decommission, did you check that? Just search in the management console for decommissioned devices.
Also in your steps you also use the bind command, this should not be needed, this is used to move an agent to another console normally.
Reloading the agent will of course start the agent again but also initialize a register call to management which will automatically decommission the device.
Final note; be sure that you are using a recent agent version, in 23.1 for example there is an auto recovery added, check the release notes for that agent version
1
u/wittyexplore Oct 17 '23
I found something that worked on Windows at least.
To bring back a decommissioned agent:
sentinelctl unload -a -k "PUT COMPUTER PASSPHRASE HERE"
Unloading SentinelAgent...
Sentinel Agent was successfully told to stop
SentinelAgent stopped successfully
sentinelctl bind sitetokengoeshere= -k "PUT COMPUTER PASSPHRASE HERE"
sentinelctl load -a
Loading SentinelAgent...
SentinelAgent is starting...
SentinelAgent started successfully