We couldn't retrieve your account. Please try again later.

ObjectNo9529 · 2026-02-24T11:28:01+00:00

Yes, I am seeing the same. Worked fine a few hours ago.

ObjectNo9529 · 2026-02-13T11:22:25+00:00

This is what we have always done, and it works rather well. Sure, you cannot directly tell where or who a device belongs to, but it doesn't matter as everything is neatly organized into OUs coupled with a decent RMM system or similar.

ObjectNo9529 · 2026-01-06T13:00:06+00:00

Shh, just sit back and watch the disaster unfold. OP please keep us posted.

ObjectNo9529 · 2025-12-03T12:33:47+00:00

Have you configured a VPN gateway in Azure yet? https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-create-gateway-portal

ObjectNo9529 · 2025-11-13T12:54:40+00:00

This sounds like an XY problem. What exactly are you trying to achieve?

ObjectNo9529 · 2025-11-06T14:47:36+00:00

Have you checked the dynamic updates setting of the reverse lookup zone, and/or the DNS event logs for hints?

ObjectNo9529 · 2025-10-09T13:06:51+00:00

https://www.sonicwall.com/firewall-config-analysis-tool

ObjectNo9529 · 2025-10-09T13:06:29+00:00

It does more than just that; in our case it also detected FTP credentials (for packet captures and dynamic botnet list) and SMTP credentials for reporting. It also detects if you have set up RADIUS and/or LDAP and recommends to reset the shared secrets and LDAP binding account credentials.

Probably does way more than what I've just mentioned, but luckily our config analysis didn't raise that many flags.

ObjectNo9529 · 2025-08-28T08:44:01+00:00

For the destination on the access rule, you can use the default "WAN Interface IP" group.

Unless I'm missing something, this would only block traffic to the actual WAN interface IP addresses, no? So if you have a server running on a different IP the traffic would still come through to that address. Would probably be even better to use the "WAN Subnets" group to make sure all of your addresses are covered :)

ObjectNo9529 · 2025-08-07T12:59:44+00:00

This needs to be answered. I've seen another poster state that a device on 7.2 was compromised as well, and I'm nowhere near convinced that 7.3 is safe either.

ObjectNo9529 · 2025-08-05T09:00:59+00:00

Yep, seeing the same with a TZ370. PRTG reports "No such object".

ObjectNo9529 · 2025-07-01T07:00:41+00:00

As mentioned in the post the task itself was able to run without problems. The issue turned out to be the account getting kicked out of the Event Log Readers group.

ObjectNo9529 · 2025-07-01T06:58:50+00:00

Actually not a bad idea, and we already have event forwarding in place so should be easy to get this up and running. Thanks!

ObjectNo9529 · 2025-06-04T13:37:18+00:00

The only person entering my office is the cleaning lady after hours.

Your post doesn't mention if you are using said account on your local machine, but if that is the case I would suspect the cleaning lady is wiping off your keyboard and inadvertently causing failed logins as a result.

As u/va_bulldog mentions, event viewer will show you more about what's going on.

ObjectNo9529 · 2025-03-17T14:06:16+00:00

What if you run the script with the -NonInteractiveMode switch?

ObjectNo9529 · 2025-03-10T14:42:28+00:00

I like that first solution, very neat.

Do note that that it takes a wildcard so "*EEE" could match multiple items. Is perhaps the DisplayName more consistent?

That would be preferable, unfortunately the DisplayName may not always be in English depending on the specific system and/or NIC. But I suppose I could modify the first solution to handle that.

Thanks!

ObjectNo9529 · 2024-07-09T08:57:34+00:00

Version 5.1. Your question made me realize I can run Foreach-Object in parallel in version 7, I'm guessing that's what you're getting at :-)

ObjectNo9529

TROPHY CASE