undefined

points

[-]

> When we ran our own mail servers, "some fuckery with client's Exchange server config" was good 90% of mail problems we had.

As an Exchange admin (and Postfix, Sendmail, qmail, exim) that was my experience, too. I think the popularity of the product, questionable defaults, and the low barrier to entry for admins (read: lacking in experience and knowledge) contributed to that.

by treebeard9012 hours ago|

prev|

[-]

Managing it in small and large corporate enviornments for over a decade led me to believe that when it was working, Exchange was very stable and reliable.. But when things would break, they would break in a way that required extensive knowledge of all the areas to fix. Which was a form of job security so Im not complaining.

I guess past reliability might be irrelevent here if an AI slop patch for AI discovered exploits caused the outage. Just speculation though. Since exchange has so many moving parts and so much legacy code, with even more bolted on to make it a cloud service, I could see how an AI exploit fix would not have all the context needed.

There is no information that it was caused by Exchange either, guess we have to wait on those answers. It is just a reasonable assumption.

by InsidiousWombat1 hours ago|

parent|

[-]

Open source options tend to require a bunch of knowledge to set up but after that you generally are equipped with that knowledge to solve any configration issue. I wrote "configuration issue" because aside from "ran out of disk space" none of them really "broke", so it was never "fixing the thing", just the usual mail server admin stuff of figuring out why this or that server didn't like us.

by EvanAnderson1 hours ago|

parent|

[-]

A lot of the bad situations I helped bail other contractors out of, when it came to Exchange, related to disk full conditions, a lack of understanding how transaction logging in the database worked, and database inconsistencies brought on by hardware RAID controller issues or hard power-offs. Very nearly all of my ugly ESEUTIL and ISINTEG experience came from people not respecting the product's storage needs.

Sysadmins who were used to running file servers and thought Exchange was the same thing were the problem. A DBA was actually more apt to understand the product's storage needs because it wasn't wholly dissimilar from the RDBMS they supported.