Experiment with https://mail.firma.de.... does not work on both, whereby I have no idea where the LB sends me, in the worst case I am at the same node twice.
You can quickly check this from a client with a customized host file. Or you can take the respective real server on the Kemp offline.
However, the host variant has the advantage that these changes only affect you and not all users.
Autodiscover already pointed to the new environment, correct?
Yes, otherwise there would be no coexistence. All client connections are terminated on the new virtual service on the Kemp, which has the two hosts behind it.
Hosts file is an idea, I'll try it right away...
I tested it from the DC: Host1 does not work, Host2 does not work.
Account on the old DAG: goes from both.
phew... the high ports between the Exchange nodes and DCs between the data center and the customer's network? I'm slowly running out of ideas. Is there any Wan Optimizer (Riverbed or similar) involved? They like to "optimize the traffic too much.
If necessary, check with Fiddler/Wireshark who is involved in a 403 call (which DC).
If necessary, "lash" the DC for the DAG node to the one in the DC.
The DC fits. This should actually be regulated by the location in the AD.
I had a look at Fiddler, I can't really see anything, but I don't really know the program either.
I would rather have a netizen do TCP dumps, but at some point we will have no other choice.
Do you have the option of rolling out another (single) EX2016 server that is not in the data center? Then you can migrate one of the mailboxes there and check whether it's due to the location.
It's like shooting from a cannon, I know. Apart from debugging the (SSL) traffic or sending a ticket to M$, I can't think of much more, it's all remote diagnostics anyway. Maybe NorbertFE knows more.
Greetings,
Ralf
No, unfortunately no idea, but I don't use the function either. I don't think a ticket with MS is very useful for this problem. Unless you like "lots of log files" and lots of "Indian English". :)
No, unfortunately no idea, but I don't use the function either. I don't think a ticket with MS is very useful for this problem. Unless you like "lots of log files" and lots of "Indian English". :)
unfortunately true... For a quick solution you need at least a Premier Support Case, otherwise it can take months.
We are SPLA partners and I have not yet managed to work my way through the MS support pages to the point where I could even open a support case...
but if it "only" fails because of the possibility to change AR for the users, it would almost be cheaper to do this with a third-party tool (e.g. CodeTwo Exchange Rules/Pro or similar).
Hello,
We also had the same problem. After we just installed the May 2022 SU for 2016 CU22 with downstream PrepareAllDomains, the error was gone.
Best regards
Stefan Ulbrich
We also had the same problem. After we just installed the May 2022 SU for 2016 CU22 with downstream PrepareAllDomains, the error was gone.
good advice. /PrepareDomain + /preparealldomains pulls a lot of missing/corrupt authorizations, among other things.
I also had to do this on the PDC for the current CU12 for EX2019, as otherwise the installation "bumped" in our environment.
Greetings,
Ralf
