u/YellowOnline

daffy.duck@acme.org complained that all of his mails are forwarded to bugs.bunny@acme.org.

There are no forwarding rules active on Exchange, neither ForwardingAddress nor ForwardingSmtpAddress. There are no server-side mailbox rules, also no hidden ones. I even checked with MFC MAPI Tool. There are no client-side mailbox rules on his computer. There are also no other clients except an iPhone, which is the only thing where I can't check myself if some kind of forwarding is configured, as that's a private device.

They use the CodeTwo signature tool which can do forwarding, but no forwarding is configured in there. I also checked the mail flow rules, and there is no relevant rule.

What could still be causing this forwarding, except the iPhone? From the way it is forwarded, I know it's a client-side forwarding, as Bugs receives Daffy as a sender and not the original sender.

Update1:

1. iPhone account was removed, problem persists
2. Moving mailbox to another DB

Update2: Solved! Thank you u/ScottSchnoll!

The last days I saw several phishing attempts with an URL like the following:

Careful, active phishing website, no hyperlink

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?state=test@test.com&scope=openid&prompt=none&client_id=8c73402b-669c-4bfd-9fcb-911cdd1b0430

This resolves into

Careful, active phishing website, no hyperlink

https://account.compliance.vu/configurations.html?reviews=test@test.com

Sadly, I don't know enough about OAuth to understand how this is done with these parameters:

state=test@test.com
scope=openid
prompt=none
client_id=8c73402b-669c-4bfd-9fcb-911cdd1b0430

I can imagine the client_id being where some kind of injection takes place, but I would like someone else's opinion.

The page https://admin.teams.microsoft.com/users/{some_userid}/activity shows a good overview of the Teams meetings a user has had in the past. It shows organizer, participants, date/time and duration (though not subject it seems). I would like to integrate this in the time management tool, but for that I need the data programmatically. I've been playing around with MsGraph, but I'm not sure how to find the data in there. I think I need a course only on MS Graph.

All other suggestions I find online talk about scavenging the mailboxes, but 1) the users have no connected EXO, and 2) apparently the Teams admin page can show the data. Copilot isn't helpful. I thought, for once I can use AI, but it just suggested me to do an invoke-webrequest...

So, if anyone has an idea how to get this data through power shell, I would be very happy.

An unknown 21-year-old Canadian finds himself in Seattle alongside a trio of world-class Belgian goalkeepers and gets the chance to face shots from stars such as De Bruyne, Lukaku and Doku.

His name: Max Anchor, third-choice goalkeeper at Seattle Sounders – the club that is making its facilities available to the Red Devils this week.

Also part of the collaboration: the American club is ‘loaning’ an extra goalkeeper to the Belgians. National coach Rudi Garcia likes to have four goalkeepers at his disposal, so that no keeper is ever left ‘out of work’ watching from the sidelines during training matches.

Normally, the role of stand-in would have gone to Maarten Vandevoordt, but his club RB Leipzig ultimately decided not to release the keeper during the World Cup. This is because our compatriot has an important role to play heading into next season.

Anchor is therefore a welcome alternative – normally, other Sounders goalkeepers will get their chance in the coming weeks.

For the young Canadian, it is undoubtedly a great learning experience. All the more so because Anchor has hardly any experience at the highest level. He has played just one match in the MLS for the Vancouver Whitecaps.

With the last old devices gone (NT4!), this forest is running fully on Win10/11 and Server 2019/2022 now.

There was an audit from an external security company, and I should set the minimum password length to 16 instead of 14.

The problem is that the maximum value of "Minimum password length" on 2019 servers is 14 - an all DCs are 2019. I'm already happy I went from functional level 2003 to 2016 this year. I get no budget to buy a few thousand 2022 or 2025 CALs this year.

From a 2022 server I went into the GPO management to turn "Relax minimum password length limits" on, but now I am unsure how this replicates. It is not visible on the 2019 servers - I expected at least an error because of a missing admx or so.

Also, I'm unsure whether this Relax etc. policy belongs in the Default Domain Policy with the password policy, or in the Default Domain Controller Policy, as the setting is probably only relevant for DCs anyway.

Thank you for your opinions.

I have 4 Exchange servers in 4 geographical locations, each behind its own firewall, half Sophos SG and half Fortigate (ongoing migration from Sophos to Forti). On all 4 of them, I cannot connect to the Mitigation service.

[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\Test-MitigationServiceConnectivity.ps1
WARNING: Exception calling "FetchMitigations" with "0" argument(s): "One or more errors occurred."
WARNING: One or more errors occurred.
WARNING: Object reference not set to an instance of an object.
Result: Failed.
Message: Unable to connect to the Mitigation Service endpoint from this computer.
To learn about connectivity requirements, see https://aka.ms/HelpConnectivityEEMS

Firewall teams says they don't block anything from the Exchanges to the WWW, nor do SSL inspection. nslookup, ping, invoke-webexpression, ... it all answers the way it should.

Confusingly, the mitigation log shows this:

2026-05-20T15:01:17.777Z,MAILSERVER01,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
2026-05-20T15:01:17.777Z,MAILSERVER01,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
2026-05-20T15:01:17.909Z,MAILSERVER01,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
2026-05-20T15:01:17.909Z,MAILSERVER01,ParseMitigation,S:LogLevel=Information;S:Message=The applicability check for mitigations M1.* failed. Skipping mitigations
2026-05-20T15:01:17.909Z,MAILSERVER01,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation PING1 is currently applied
2026-05-20T15:01:17.930Z,MAILSERVER01,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation M2.1.0 is currently applied

I'd have expected some kind of error here.

From the firewall logs, manually connecting to https://officeclient.microsoft.com/getexchangemitigations works, but it shows no traffic when executing Get-Mitigations or Test-MitigationServiceConnectivity. So it seems the problem is local.

Finally I looked at Microsoft's script and went through it line by line

[PS] C:\>$mcs = $mcsfType.GetMethod('CreateService').Invoke($null,  Microsoft.Exchange.Mitigation.Service.Common.ServiceType]::CloudServiceV2)
[PS] C:\>$mitigations = $mcs.FetchMitigations()

Exception calling "FetchMitigations" with "0" argument(s): "One or more errors occurred."
At line:1 char:1
+ $mitigations = $mcs.FetchMitigations()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : AggregateException

Diving deeper:

[PS] C:\>$error[0].exception.tostring()
System.Management.Automation.MethodInvocationException: Exception calling "FetchMitigations" with "0" argument(s): "One or more errors occurred." ---> System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Exchange.Mitigation.Service.Common.Utils.PrepareRequest(X509Certificate clientAuthCert)
   at Microsoft.Exchange.Mitigation.Service.Common.Utils.<GetHttpUrlResponseAsync>d__4.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchMitigationsFromUrl[T](String url, X509Certificate clientAuthCert, Boolean isResponseJson)
   at Microsoft.Exchange.Mitigation.Service.MitigationCloudServiceV2.FetchMitigations()
   at CallSite.Target(Closure , CallSite , Object )
   --- End of inner exception stack trace ---
   at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo)
   at CallSite.Target(Closure , CallSite , Object )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
   at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

EDIT for future reference (relevant XKCD): apparently it is not enough to be able to reach the address, it also needs to be pingable. As soon as we allowed ping to WAN, and restarted the console, it worked.

Here I am migrating Skype for Business 2015 to 2019. In 2026. They bought the licenses dirt cheap, €1 000 for 5 000. The same in Teams would be €200 000/year.