NorbertFe

Na das is ja mal wieder klasse. :/ Ich nutze die eigenen Transport rules nicht, deswegen auch nix festgestellt. Nerv….

vor 20 Stunden schrieb Nobbyaushb:

Bugs, Hints?

Bisher keine bemerkt. Habs gestern auf insgesamt 5 Exchange 2019 installiert (Edge, DAG) und bisher keine Probleme gesehen. Kollege hatte es auf einem Exchange 2016 installiert und auch keine Probleme gemeldet.

Kenn ich noch aus Röhrenzeiten. Da war zwar nix verzerrt, aber die Elemente der Programme haben nicht auf den Bildschirm gepasst. ;)

Ich komme mit einem großen Monitor deutlich schlechter zurecht, als mit 2 etwas kleineren. Grundsätzlich kann ich mit 2x24" sehr gut arbeiten. Leider gabs nie wirklich highDPI in der Größe (zumindest nicht von Dell). :)

Warum nicht einfach ne .reg Datei die jeder Nutzer anklickt, statt so eines langen scripts, welches ja entweder ein Admin oder localsystem ausführen muss?

Und wenn’s um Outlook for iOS/android geht ist auch klar, warum das beim zweiten Handy einfach ging. Denn da landet nichts mehr im Exchange, denn der unterhält sich ja jetzt mit der Cloud und nicht mit deinem Handy. Zumindest ist das mein aktueller Wissensstand.

Bisher nur auf einem Edge. Leider keine Zeit heute. Mal schauen heute Abend im Hotel evtl.

Moin,

Ms hat die neuen SU für Exchange 2019 und 2016 veröffentlicht.

https://techcommunity.microsoft.com/blog/exchange/released-november-2024-exchange-server-security-updates/4293125

Das ist total toll und super sbs2003 Like  mach weiter so. ;)👏 

vor 6 Minuten schrieb zahni:

Drucker mindestens über einen Printserver

Steht jedenfalls oben, dass er das tut.

Gerade eben schrieb rt1970:

also den Domain-Admin aus meiner Mitgliedschaft gelöscht, aber ich erhalte immer noch Fehler 500.

Weil du nicht den Artikel gelesen hast, in dem sicherlich steht, dass man danach noch die Vererbung auf deinem Konto wieder aktivieren muss. :/

vor 6 Minuten schrieb rt1970:

Ähhm... Jaaa.... Wieso?

Ähhm... Jaaa... Wieso könnte das nur keine gute Idee an sich sein, so dass MS da eine gewisse Sperre (namentlich den genannten AdminSDHolder) vorgeschaltet hat?

Am 7.11.2024 um 08:07 schrieb tesso:

mit Cola Zero

Das Zeug schmeckt nicht. :)

vor einer Stunde schrieb Squire:

naja, was macht denn z.B. eine kleine Arztpraxis, die nur einen Server als Praxisserver hat .

Die patchen im allgemeinen sowieso nicht. ;)

vor 2 Minuten schrieb MurdocX:

Sollte die Verbindung zum WSUS verschlüsselt ablaufen, dann lohnt sich ein Blick auf das Zertifikat. Es könnte abgelaufen sein.

Dann hätte man aber ganz andere Fehlermeldungen. Sowohl in der Konsole als auch an allen Clients.

Lösche mal einen Client aus der wsus Konsole. Dann mal am Client triggern und prüfen ob es funktioniert.

Gerade eben schrieb msdtp:

dauerhaft per SMS

Gar nicht. Das ist von MS nicht mehr vorgesehen und nur noch für Password Selfservice vorgesehen (und selbst da bin ich mir grad nicht mehr ganz sicher).

Ja das hat afair schon immer so funktioniert. Ist ja eigentlich auch logisch. Denn ob ich eine Zone alias.example.local nach dem Server frage oder ob ich einen host Server.alias in der Zone example.local suche ist erstmal egal. Den Unterschied zwischen Zone und Host/alias kann man für dieses einfache Beispiel mal vernachlässigen.

vor 19 Stunden schrieb DerSeppo:

Das manuelle Zuordnen der SIDs in der Transaltionstabelle war mir doch zu mühsam.

Wieviele SIDs waren das denn in Summe? Hab grad mal was ähnliches durch und da waren es 8 Stück und einer mehr für die Domaincontrollers. ;) Das ist natürlich ne unheimliche Menge an Arbeit. ;)

Die Hälfte füllt der Migrationstabelleneditor ja sogar direkt aus der VOrlage aus, so dass man nur noch die deutschen Namen dahinterschreiben muss.

Aber ok, mit englischsprachigem OS hat man diese Arbeit dann nicht. Dafür muss man es aber erstmal installieren. ;)

vor 2 Stunden schrieb clgies:

Soweit meine Vermutung.

 

Die Vermutung ist falsch und hat genau nichts mit der Konvertierung der VM zu tun. Wie ich schon schrieb und per Screenshot zeigte ist da normalerweise KEIN DNS eingetragen, und der Exchange nutzt in diesem Fall einfach die Resolver, die auf den Netzwerkkarten eingetragen sind. Das ist normalerweise auch vollkommen ok und nur dann anders zu konfigurieren, wenn der Exchange eben ANDERE Server nutzen soll/muss als die die auf den Netzwerkverbindungen eingetragen sind. Also wird es auch funktionieren, wenn du den Standard wiederherstellst und dann beim nächsten Mal nicht so ein Problem hast.

vor 17 Minuten schrieb clgies:

Hinterlegung des neuen DNS Servers auf alle Netzwerkadapter löste das Problem :)

 

Normalerweise stellt man da gar nichts ein (es sei denn man weiß was man tut und hat entsprechende Anforderungen). Sprich das war vorher schon falsch konfiguriert und ich würde dort an deiner Stelle einfach alles leer lassen:

vor 6 Minuten schrieb Weingeist:

Selbst bei Tape-Loadern.

Deswegen empfiehlt man ja auch bei Tape-Loadern explizit die regelmässige Auslagerung der entsprechenden Medien. Was im Schrank liegt kann zwar geklaut aber nicht überschrieben werden. ;)

vor 13 Stunden schrieb clgies:

Den einzigen Anhaltspunkt den ich habe, ist das der Test-Mailflow scheitert.

 

Der hat aber dann nix mit der DNS Zone zu tun, wenn wir hier wirklich über SMTP sprechen. ;) Da hilft dann ein Blick in die entsprechenden SMTP Logfiles der Sende-/Empfangsconnectoren.

vor einer Stunde schrieb clgies:

empfängt die Mails über ein SMTP Relay

Das was du da zeigst ist der Sendeconnector und der ist wie der Name schon sagt für den Versand zuständig und nicht für den Empfang. In deinem Logfile fehlt irgendwie der Punkt, der die Mail dann als angenommen bestätigt. Sowas wie "queued for delivery" oder ähnlich.

Und wenn du sagst, dass der Versand auch nicht funktioniert, dann schau auch ins Versendelog (ggf. vorher aktivieren).

Bye

Norbert

vor 1 Stunde schrieb clgies:

turing\3                   SmtpDeliv... Retry  192          0        Normal    0              mailbox database 19575...

Sieht aus, als wenn das ein internes Problem auf deinem Exchange ist. Der stellt die Mails nicht an die Datenbank zu. Ich vermute entweder Datenbank down oder voll oder die Platte auf der die SMTP Queue liegt ist "zu voll".

vor 17 Minuten schrieb clgies:

Trotz der obigen Zone (domain.de) ist ein  (internes/externes) Senden/Empfangen von Outlook Clients über Exchange 2016 nicht mehr möglich

Sondern? Fehler? Irgendwas? Geht nicht ist noch nie besonders hilfreich gewesen. ;)

vor 17 Minuten schrieb clgies:

Vor der Migration existierte diese Domain auf dem alten DNS Server und der Exchange lief korrekt.

Warum hast du sie dann nicht mitmigriert? Bzw. Wie ist die verloren gegangen. 

vor 50 Minuten schrieb clgies:

Was kann ich hierunter verstehen ?

Du kannst im Netz nicht www.domain.de aufrufen. Und auch sonst nix, was da liegt. Das kann man vermeiden mit der oben beschriebenen Methode.

vor 51 Minuten schrieb clgies:

OWA ist beispielweise auch intern erreichbar und zwar unter der externen URL !

Die steht ja auch in der Zone. :/

Sieht zumindest recht vernünftig aus das Schreiben des obigen Posts hat vermutlich länger gedauert, als einfach die Zone anzulegen und zu testen. ;) Ob man die komplette externe Zone oder nur die zwei Hosts für Exchange anlegt, wäre zu überlegen. Also bspw. Zone outlook.domain.de mit leerem Hostnamen und der IP 192.168.110.47 und das Gleiche noch mal für autodiscover.domain.de auf 192.168.110.47. Denn bei deiner Variante kommt man von intern nicht mehr auf die externen Webseiten usw.

Bye

Norbert

PS: Ein wenig kürzer hätte der Threadtitel auch sein dürfen. Schreibst du auch immer alles in den Betreff einer Mail? ;)