NorbertFe

Die patchen im allgemeinen sowieso nicht. ;)

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.

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.

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. ;)

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.

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:

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. ;)

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. 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 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".

Sondern? Fehler? Irgendwas? Geht nicht ist noch nie besonders hilfreich gewesen. ;) Warum hast du sie dann nicht mitmigriert? Bzw. Wie ist die verloren gegangen. 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. 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? ;)

Und wo ist das Problem? Man schaut in die Tabelle welche SID angemeckert wird und schaut, welcher Displayname im deutschen AD/OS dafür verwendet wird: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers The well-known SIDs are listed in the following table:

Und sogar schon über das vlsc (das nicht mehr so heißt).

An Halloween bin ich üblicherweise zu Hause. Ich muss ja die Kinder erschrecken ;)

Ich glaub du hast den Punkt auf den ich hinauswollte nicht gesehen. Da fehlt ein l ;)

Wär mir auch egal. Wer will schon so'n Pfusch ;)

Nein, um Transaktionslogs. ;) Und nein das ist eben nicht für jede Mail. Es sei denn du hast nen anderen Exchange als ich. Aber da das nichs mit deinem Problem zu tun hat, ist es fast egal. Die Frage nach dem Virenschutz hast du gekonnt übergangen. Ansonsten wäre noch interessant, welchen Patchstand denn der SBS hinsichtlich Exchange hat.

Das wäre aber nur so, wenn jede Mail genau 1MB groß wäre. ;) Also ich bezweifle, dass man da einen Zusammenhang zwischen der Anzahl der Mails und der Anzahl der Logfiles herstellen kann. Eine richtige Idee hab ich aber auch nicht. Ist das nur mit dem Adminpostfach so, oder auch mit einem Testpostfach oder einem der User?

Da liegen sie ja voll im Zeitplan bei MS. ;)

Man könnte in diesem Fall ja auch einfach utc definieren, dann spart man sich den Mist. Ist bei Exchange Logs ja nicht anders. ;)

Gucken doch inzwischen alle nur noch aufs Handy. ;) Oder welche Uhr außer Herd und microwelle stellt man heutzutage noch um?

Aha und bis du sie evtl. Mal brauchst machst du lieber Verrenkungen mit einem Client os? Das dürfte vermutlich sogar teurer werden als den rds Host zu aktivieren und ne rds cal.

Und die praxissoftware läuft nicht unter Server 2022?