NorbertFe

Die Vorstellung ist aber falsch. ;)

OK, dann sind vermutlich fast alle hier im Thread der selben Meinung. Es lohnt sich einfach nicht bei wenigen Namen im Zertifikat irgendwas zu basteln.

Ja bestimmt. Millionen. ;) und vor allem jederzeit weltweit sobald ein neuer Kunde kommt. :p und vor allem gibts bei san Einträgen afair auch ein Limit.

Und? Dafür gibts ja powershell.

Wie bindet man denn zwei Zertifikate im exchange an den iis?

Ich kanns nicht, aber Code sollte man als Code formatiert hier einstellen. So wirds schnell unübersichtlich.

Woher soll ich das wissen? :) Du müßtest doch recht einfach rausfinden können, welche User du hast. Das ist der LegacyExchangeDN eines deiner User. Welcher, kannst du ja nachschauen. :)

Na dann setz Maximum Allowed Sessions Per User mal höher auf 50 bspw.

Üblicherweise ein "Problem" am Server. Da solltest du korrespondierende Meldungen im Eventlog finden können. https://docs.microsoft.com/en-us/exchange/architecture/mailbox-servers/managed-store/managed-store-limits?view=exchserver-2019

Ich stimme Nils da zu. Der DHCP Failover ist zwar "nett", aber eben leider wie bei MS typisch irgendwie anders als man es erwartet. Wer nicht die BEsonderheiten (änderungen werden nicht automatisch repliziert, Last Writer wins usw.) kennt und sie berücksichtigt, hat schneller als erwartet eher weniger als mehr Verfügbarkeit. (dafür aber mehr Aufwand). ;) (Danke an Nils für den Hinweis) Bye Norbert

Dazu sollte man wissen, warum die Frage kommt. ;) Man kann die auch mit NEIN beantworten. Das kommt auf die Konfiguration an. Ich habe mir inzwischen angewöhnt im Normalfall mit Nein zu bestätigen und nur das interne Selfsigned Zertifikat zu binden. Die externen Connectoren erhalten dann direkt das öffentliche Zertifikat zugewiesen. Bye Norbert Ja vor allem wenn man MTA-STS konfiguriert hat. ;) Wer gibt seinem MX denn auch einen Namen der nicht im Zertifikat auftaucht?

Vielleicht kein lokaler Admin. Dann gibts die Buttons auch nicht (zumindest nicht per Remote).

Man könnte auch fragen, ob Windows 2008R2 nach seinem Lifecycle an der STelle fürs Troubleshooting die beste Basis darstellt. Aber das muss der TO entscheiden.

Bei sowas hilft es, wenn du mal die beteiligten IP Kreise (Client, Server, Ziel-LAN) angeben würdest. Oder sollen wir raten? ;)

Ich hab dich mal konkretisiert ;)

Naja, nur wenn man nicht weiß, warum was so ist wie es ist. X-400 sind bei meinen Kunden schon seit Jahren weg und auch die .local Adressen oder generell die internen Domains eben maximal noch in der Default Address policy drin und alles andere mit eigenen Richtlinien abgefrühstückt. Gibt für sowas auch nette Skripte, die einem beim Entfernen von x400, MS-Mail oder alten/überflüssigen Domains. Bye Norbert

Die war noch nie notwendig, sondern wie angedeutet eben einfach da, weil beim setup die Active Directory Domain als default Domain gesetzt wird. Kann man einfach löschen, und mit der richtigen Domain ersetzen.

Nein, dazu müßte die Security Group Mailaktiviert sein (dann würde sie normalerweise auch sinnvollerweise eine Universal Group). Und wenn sie mailaktiviert ist, könnte man sie direkt adressieren, aber dann kann man sie auch in den Verteiler packen.

Sollte Security ausreichen. Natürlich siehst du die dann nicht in Outlook, weils ja kein Exchange Objekt ist. Per Powershell sollte das aber korrekt zu sehen sein.

Nö. Und wenn, was hilft dir das? Wie wärs mit PS im Server, oder hat der nur ne halbe CPU? Na dann ist das Thema hier beendet. Ja, dass man Exchange nicht entlasten muss und der Hersteller seit Jahren von der Verwendung öffentlicher Ordner abrät. Sagt halt viel über die Kunden und deren Verwendungszwecke aus. Bye Norbert

Das belastet einen Server? Ja, denn Boardmittel gibts ja keine. Oder hast welche gefunden? ;)

Meine Server sind nicht belastet. :) Wie groß denn? Ansonsten such dir eine Archivlösung, wo public folder explizit als Archivquelle definiert ist. Bye Norbert

Welches hast du denn, bzw. welches schwebt dir denn so vor?

Na dann gut Ausschau halten. ;)

Der Built-In Admin wird nicht gesperrt. Wäre fatal, ginge das. Aus genau dem Grund soll man mit dem auch nicht arbeiten. ;) Du kannst das auch mit dem Netlogon.log versuchen. Evtl. sieht man da ein wenig mehr. http://realit1.blogspot.com/2012/04/troubleshooting-active-directory.html