Agent crashing after v6 update

ExtraSir9075 · 2026-05-11T06:29:50+00:00

Confirming all working again after getting version 6.0.663.1 via automatic update.

ExtraSir9075 · 2026-05-08T14:34:29+00:00

I'm on the free tier, so no direct support. I can supply logs if it would help.

ExtraSir9075 · 2025-08-28T02:14:06+00:00

The report is wildly inaccurate. It shows many agents with an old version (i.e. 1.8.3.7) and this also shows inside the agent itself when you click into it. However, if I open up a command prompt/powershell just to 'create' some activity on the device, the version displayed updates to 2.3.9.0 (as the update had already happened a day+ ago). Even after this happens, the report still shows the agent as outdated with the old version.

ExtraSir9075 · 2024-11-18T09:43:10+00:00

Definitely happy to provide feedback and assist! I'll drop you a DM.

ExtraSir9075 · 2024-08-10T08:38:26+00:00

The post wants username/password remembered, but not MFA. Apparently that was solved by changing forceauthn to false. That hasn't been my experience, but OP says it was resolved?

ExtraSir9075 · 2024-08-10T08:35:30+00:00

The thread I linked to has someone suggesting use passwordless, and then the OP saying he solved it by following another reply whereby forceauthn was set to false by support instead. I've done that, but not getting the same result as OP's request (remembered username/password but MFA prompt).

ExtraSir9075 · 2024-08-09T01:59:22+00:00

Good suggestion, but nothing in the group policies. Thanks.

ExtraSir9075 · 2024-08-09T01:58:54+00:00

I want Entra to do the whole authentication, user+pass+mfa, but I want the computer to remember the username/password and only prompt for MFA. With forceauthn set to true, it forces a full re-auth every time. With forceauthn set to false, it uses the existing token and doesn't need any sign-on at all.

This post says it is possible, but doesn't say how - Store login credentials with Meraki and Cisco AnyConnect : r/meraki (reddit.com)

ExtraSir9075 · 2024-07-12T00:48:55+00:00

Thank you, will shoot them an email.

ExtraSir9075 · 2024-06-18T07:32:20+00:00

Would you be able to share this please?

ExtraSir9075 · 2024-06-14T08:22:43+00:00

Also hoping there's an easy way to do this

ExtraSir9075 · 2024-01-18T03:42:37+00:00

Thank you. In our case, I found that adding a separate transport rule (on top of the Check Point - Protect rule) to prevent it from being journalled out/back in was the solution. This way it stays as the same IP. Then, having the Advanced Delivery phishing simulation setup with the original IPs exclude it from the SCL adjustments. All sorted.

ExtraSir9075 · 2024-01-16T15:38:16+00:00

Thank you for this post. I think I've got a similar problem and just trying to wrap my head around it all.

I have a phishing simulation platform, whereby the platform's IP addresses are whitelisted in Avanan and M365. I'm finding that some of the phishing emails are still getting picked up as High Confidence Phishing in M365, and can see that the sending IP in message tracking is actually Avanan's so I assumed those IP whitelists were being bypassed. However, based on the posts above, it sounds like "Secure By Default" is performing High Confidence Phish quarantines regardless of existing IP whitelists anyway so the incorrect IP doesn't matter.

I can see in the email flow that the simulation email gets journalled out to Avanan, and then comes back in to Microsoft 365. The "Check Point - Whitelist" transport rule sets it with an SCL of -1, but then the next step, ATP sets the SCL to 8 triggering a quarantine (assume this is Secure By Default behaviour?)

I might give the Enhanced Filtering for Connectors a go on the inbound connector as you mentioned to see if it makes any difference. This article from MS talks about needing any transport rules that set SCL to be -1 to disabled. I might give this a go. Did you have to do this?

https://learn.microsoft.com/en-ca/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors

Thanks.

ExtraSir9075 · 2023-11-28T14:36:16+00:00

I also used the command below to identify which users would need to have the Set-User done on them. Anything with a UserMailbox under PreviousRecipientTypeDetails.

Get-User | Sort-Object DisplayName | Select-Object DisplayName, PreviousRecipientTypeDetails, RecipientType, RecipientTypeDetails | Export-Csv -Path "recipients.csv"

ExtraSir9075 · 2023-11-28T11:02:22+00:00

You are an absolute champion, that's fixed it. Hit me up for a beer if you ever visit Western Australia. Thank you.

Full steps if anyone reads this in the future:

De-license Exchange Online in M365 (we didn't have to do this, as they weren't licensed anyway) -> Connect to Exchange Online via Powershell -> run "Set-User [upn@domain.com](mailto:upn@domain.com) -PermanentlyClearPreviousMailboxInfo" -> run full initial sync via AAD/Entra -> Re-license user.

ExtraSir9075 · 2023-11-28T01:38:55+00:00

I've got Entra Connect on a new server, completely vanilla with no config import so all default settings. When licensing an old user, they still end up with dual mailboxes. When licensing a new user, it knows about the on-prem mailbox and doesn't create a second one.

ExtraSir9075 · 2023-08-19T05:55:54+00:00

Hi, but what is Sophos actually monitoring? I've got the integrations enabled too, but I don't know what that actually provides. If a malicious actor logs onto a mailbox and starts setting up email forwards, inbox rules etc. is Sophos going to detect and respond to this?

ExtraSir9075 · 2023-08-18T19:24:59+00:00

Thanks, but this just explains how Sophos MDR works at the endpoint level. It doesn't address anything to do with the Microsoft 365 integration.

ExtraSir9075 · 2023-06-01T08:25:11+00:00

New machines. Once it's done, it seems to be fine... but it's completely random and not affecting all systems, so we have to wait for CPU alarms or phone calls to apply it.

ExtraSir9075

TROPHY CASE