CaptureClient 3.1 - how to easily upgrade?
I'am running CC 3.0.11 on a couple of clients and this morning I changed my CC policies to use 3.1 and the TP policies to use 4.1.x. This was around 6 hours ago, but no new version got updated, on any client?
Isn't this the recommonded way to do upgrades?
On the other hand, my personal endpoint is marked as offline for around a month, but the local client window shows online and compliant, but last policy update is a month ago. Maybe something got messed up when my high CPU core usage problem got fixed at the backend?
07/13/2020 01:55:20 PM ses[180:1813] Warning Michael Failed to get Firewall SN or tenantID telemetry
07/13/2020 01:55:20 PM ses[180:1813] Error Michael Failed to init telemetry error '22'
07/13/2020 01:55:20 PM ses[180:1813] Info Michael Did not get a response to firewall discovery
07/13/2020 01:55:20 PM ses[180:1813] Warning Michael Failed to set IsBehindEnforcedUtm to false error '11', msg 'database disk image is malformed'
To put it mildly, smooth operation is defined differntly.
Hi Michael @BWC ,
I can confirm your first statement, updating the policy is the recommended way to push new updates to the clients part of the policy.
Regarding your personal endpoint, it seems like there may be an issue there or duplicate Device ID communicating to the backend - the client believe it's correctly communicating but the Console doesn't get messages from the client.
It might also be that the first and second issues are related but this would require our Support to troubleshoot further logs and everything else so my suggestion would be to open a new case.
will do, nothing is more pleasing to create a ticket right after installing a new release, or trying to update. This time 2 out of 5 endpoints having update trouble, could be worse. W2K12 server is online and compliant and Last active date shows less than a minute ago, but Default Policy with 3.1 not deployed.
BTW, what does "07/13/2020 01:17:07 PM ses[2276:124] Warning DEFAULT_USER Not updating policy - no current console user" mean? Will a policy modification not be deployed when no user is logged in? This happens on servers quite often and it would be great if they got the latest policy as well. In my specific case I logged into the system to refresh policy manually without success.
short update, after 3 days (Jun 16th) the W2K12 server magically decided to use the latest policy (last modified Jun 13th). I've heard of viruses which disappear magically someday, but this also counts for Capture Clients updates as well it seems.
07/16/2020 05:57:44 PM ses[2200:4496] Info MYDOMAIN\administrator Updated Policy:'Default Policy'
My personal macOS Client is still outdated, but it seems that some local configuration databases got messed up, Support is on it, TSR is provided.
end of story, support recommended to uninstall the client, because I can't do this from the management console I have to do it manually on the endpoint itself. No big cake in my scenario, but nothing I wanna face at a customer deployment.
UPDATE: uninstallation does not go smoothly, AuthorizationPassword is not accepted, currently checking with support if I can do just a re-install instead uninstall and fresh install. :(
The client is reporting back to the backend, I can see all kind of Bluetooth and USB events, even the ApplicationRisk seems to be somewhat current, but management connection got lost in progress.
things are getting spicy, the CC isn't uninstallable, either manually from the terminal or via CSC. The config.db sqlite database seems to be corrupt which cause the uninstall trouble.
Hopefully the support team steps up a bit, because the pace of resolving this isn't going to break any records, if you get my drift.
Will update in case anyone else faces that kind of dilemma.
While 3.1.1 is on the horizon and will be released in the next days, Support is still struggling to give me an answer for over a week now how to safely remove the uninstallable CaptureClient from my system. The Backend Team is more of a Slowend Team on this one I can tell.
Oh my, while having a few endpoints still working with CC, an upgrade to the latest CC and S1 engine ended in this: "Attempting to download and install 'SentinelOne 18.104.22.168 ' on the 5th retry" - now I have to figure out what that means, every new update, new surprises.
UPDATE: another endpoint (at another location, different firewall) is struggling as well, trying to update S1.
Update to 3.1.1 seems to go through, but S1 update stuck.
Anyone already had this resolved?
The S1 packages seem to be incorrectly named, or whatever. Is anyone really using this product?
08/03/2020 01:54:41 PM ses[5516:4752] Warning DOMAIN\administrator Attempting to download and install 'SentinelOne 22.214.171.124 ' on the 2nd retry
08/03/2020 01:54:41 PM ses[5516:4752] Error DOMAIN\administrator failed to download '22'
08/03/2020 01:54:41 PM ses[5516:4752] Error DOMAIN\administrator curl failed: http error 404 (The server has not found anything matching the Request-URI).: 'The requested URL returned error: 404 Not Found'
And no, I will not create another ticket, unless I finally get paid as a guinea pig.
In this particular case, it looks like a human oversight where the package was uploaded to the incorrect repo. This is the first of such an instance and I am sorry you had to experience this. We'll get it sorted ASAP.
Btw, due credit to users like yourself who want to stay at the bleeding edge and provide instant constructive feedback on every observation.
it seems that at least for one endpoint the update of the S1 engine worked, thanks for fixing this.
But one endpoint is "deeply insulted" and needs to be motivated to update, because of: "Will not attempt to retry download and install 'SentinelOne 126.96.36.199 ' because the client has exceeded its max retry limit" :) - this could be accomplished by restarting the endpoint, a simple policy refresh did not do the trick.
just to let you know because it was not possible to uninstall a rogue CC 3.0.1 on macOS the Support Team provided me a "tailored" uninstaller executable to get rid of the CC installation. This app scratched the CC and S1 files from my system. I decommissioned and deleted the endpoint from the Management and redeployed.
So whenever you cannot uninstall your CC with the uninstall password, you're probably out of luck and need an uninstaller :) Maybe this is something you can tell the support team to speed things up. Case #43407647 (last interactions).
Thank you for the feedback Michael, we continue to work on improving user experience with Capture Client. Agent install and uninstall should be a seamless process, your case was an exception and related to CC DB corruption, hence we had to build a CleanerUtility tool for your Macbook.