Capture Client Management site communications issues persist
mangonacre
Newbie ✭
Apparently, I've been posting in the wrong forum, so posting again here. Apologies for the duplication.
Although the management site and everything I've clicked on does come up now, there seems to be a major communications issue between the clients and the management servers. I have numerous systems which are currently online (including my desktop and laptop), yet the Capture Client icon shows Offline. If I open the client app on those systems, Device Status shows as Connecting...
Worse, I'm still trying to complete our rollout of SWCC, and I can't get it installed due to the new installation not registering with the server and completing installation of the Sentinel One client.
After a half hour of waiting for a support rep to get on the phone, I finally get through, and then get hung up on!
At this point, this seems like one of the biggest mistakes I've made in my professional career, trusting SonicWall with our endpoint security.
PLEASE FIX THIS!!!!!
Answers
Hello @mangonacre, I'm sorry to hear about this inconvenience. Can you PM your case number to me so that I can escalate? BTW I have removed the duplicate post that you are referring to. No problem at all.
Kind Regards,
@micah - SonicWall's Self-Service Sr. Manager
Hi Micah,
I never did get a case number. The call connection broke when I was trying to get the case started. I called again and waited on hold for another long while. During that time, the client I was trying to get installed finally registered with the server and I was able to complete the installation. So I hung up.
At this time, the site seems to be responding for the most part, and some of the client systems that were showing CC was offline are now showing online. But there remain several of them that are currently up and running (for instance, my laptop) and still showing last contact from the client was hours ago. This is not the first time I've seen this, either. I'm not going to try any other installations until I see proper communication from all clients, so I hope it clears up soon.
I believe I was/am having a similar issue. Some clients show as "Online" but mine at the moment shows as "Connecting". Here is a snippet from the debug log.
2/15/2021 10:54:41 AM ses[5184:21980] Debug the client has started to register
12/15/2021 10:54:41 AM ses[5184:21980] Debug GatherInfo start
12/15/2021 10:54:41 AM ses[5184:21980] Debug GatherInfo before AD
12/15/2021 10:54:41 AM ses[5184:21980] Debug GatherInfo end
12/15/2021 10:54:41 AM ses[5184:21980] Info Client data has gathered successfully for registering
12/15/2021 10:54:41 AM ses[5184:21980] Debug Dumping 'registerClient' data request to: 'C:\Program Files (x86)\SonicWall\Capture Client\tmp\clientData.json'
12/15/2021 10:54:41 AM ses[5184:21980] Debug Posting data to 'registerClient'
12/15/2021 10:54:41 AM ses[5184:5920] Debug prepare pending online check
12/15/2021 10:54:41 AM ses[5184:5920] Debug Scheduled in a new online check task
12/15/2021 10:54:41 AM ses[5184:5924] Debug start online check
12/15/2021 10:54:41 AM ses[5184:5924] Debug Unmonitoring Telemetry SDK version 2.0.1
12/15/2021 10:54:41 AM ses[5184:21980] Debug APICurlPerf took '93' ms
12/15/2021 10:54:41 AM ses[5184:21980] Debug API 'registerClient' took '97' ms
12/15/2021 10:54:41 AM ses[5184:21980] Debug Call to 'registerClient' failed with server code '403'
Response = </BODY></HTML>
12/15/2021 10:54:41 AM ses[5184:21980] Debug Dumping 'registerClient' data request to: 'C:\Program Files (x86)\SonicWall\Capture Client\tmp\clientData.json_error'
12/15/2021 10:54:41 AM ses[5184:21980] Debug JSON received from previous API call is not a valid object
12/15/2021 10:54:41 AM ses[5184:21980] Debug Received the following error msg: '</BODY></HTML>'
12/15/2021 10:54:41 AM ses[5184:21980] Info The client was unable to register
12/15/2021 10:54:41 AM ses[5184:21980] Debug Failed to start telemetry monitoring error '403'
Yes, I'm getting pretty much the same in the affected client debug logs as you, ASchultz. This is affecting at least a half-dozen of our clients currently.
I've pretty much lost all confidence in this product, and regret the purchase. It may be an "inconvenience" today, but the fact that this seems to repeatedly happen with their systems raises serious questions as to how we would be able to manage or remediate an active threat, especially one that affected a server.
Going backwards here. Now we have a dozen clients showing SentinelOne online, but CC is offline...
Appears things are back to "normal" now. Only have powered off devices showing as offline.
Same issue with my installation. Even after rebooting, the client continues to display Connecting... in Device Status.
The CC is offline:
The S1 is online:
it is quite cumbersome to solve.
Have you a solution to have this issue solved!
Hi Enzino78,
My experience was similar to ASchultz's above, where the next morning, all affected clients were finally communicating properly with the servers and downloading SentinelOne updates. I haven't had a problem since Dec 16. What you're experiencing now might be due to a regional issue that's not hitting me (yet).
That said, I did open a case for it on Dec 15 which has not been addressed at all by SonicWall support. Combine that with the fact that when you go to the Support section in MySonicWall, you can only create an email-based case, and it is automatically assigned a severity of 3 with no way for you to change that. You can still find the support number through Google, but back on Dec 15, I spent a half hour on hold before someone picked up, and then was suddenly disconnected before the case could be created. I tried calling back, but was again stuck on hold for over 30 mints. And of course, nothing posted here by any SonicWall representative even acknowledging a problem occurred.
But they were certain to make sure I received Bill Conner's "thanks for being a
suckercustomer" email today!After I have reinstalled the client it works... I will see until it keeps working.
the only difference is the client installed todayis version 3.6.34 rather than the previous 3.6.30, even if the applied policy is set differently:
?
Yeah, so far, communication seems to have been working for me since Dec 16, but not holding my breath.
Not sure why the client upgraded for you even though you have the policy set to a lower version. I've not had that issue. But I do want to make sure you're aware that 3.6.30 consumes a good bit of CPU cycles when the Content Filter is active: "High CPU due to system process swcfdrv64.sys+0x998c after update to CC 3.6.30." I rolled back to the "General Release" of 3.6.24 until they get that bug worked out. Supposedly it was resolved in 3.6.31, but it's back to listed under Known Issues for 3.6.33. (And there isn't even a Release Notes updates for 3.6.34... )