wznutzer

So, nun klappt das. Mal wieder ein klarer Fall von: "Kaum macht man es richtig, geht es." Ich habe die Einstellungen direkt im IIS geändert, das mag der Exchange wohl nicht. Man muss es im Exchange machen. Merker: Fummel nicht am IIS rum, wenn es dafür eine Option im Exchange selber gibt!

Genaugenommen gibt es kein Problem, außer das mit dem Anmelden, da forsche ich noch. Ich will nur verstehen was, warum, wie und wieso genau so und nicht anders.

Vielen Dank. Ich habe noch ein lokales Relay das nach O365 sendet, weil es noch ein paar alte Drucker/Scanner/Gerätschaften gibt die Mails versenden sollen, aber teilweise noch nicht einmal eine Authentifizierung oder nur TLS 1.0 können. Schönen Abend noch...

Guten Abend, um einen Exchange 2016 der noch auf W2K12R2 läuft wegzukriegen, soll ein Exchange 2016 nach 2019 migriert werden. Wobei migrieren falsch ist, der Exchange hat ja keine Postfächer mehr, liegen alle bei O365. Der Exchange 2019 soll nur zur Verwaltung der AD-Attribute verwendet werden. Der Exchange 2016 soll nicht einfach abgeschaltet, sondern ordentlich deinstalliert werden. Nun gibt es da aber noch die Systempostfächer in der DB des Exchange 2016. Ist es richtig, dass die Systempostfächer in die DB des neu installierten Exchange 2019 verschoben werden müssen. So lange die noch da sind, kann der Exchange 2016 nicht deinstalliert werden. Im Prinzip also wie eine "normale" Migration, nur dass es nur die Systempostfächer gibt. Liege ich hier richtig? Grüße und ein schönes Wochenende

Ja, da bin ich jetzt in die völlig falsche Richtung abgebogen. Aber bei Default (ist ja an 443 gebunden) ist Windows-Authentifizierung per default nicht aktiv, aber wenn ich das aktiviere, geht es auch nicht. Das Zertifikat ist es auch nicht, das war auf dem anderen Server auch nur Remote ein Problem. Default bei einen frisch installierten Exchange sieht das so aus: Default Web Site/ecp | Anonyme Authentifizierung aktiviert Default Web Site/ecp | Standardauthentifizierung aktiviert (alles andere deaktiviert) Default Web Site/owa | Standardauthentifizierung aktiviert (alles andere deaktiviert) /ecp leitet bei einem Exchange 2019 nach /owa um. Ich dachte Windows-Authentifizierung aktivieren bringt mir den Erfolg, dass ich mich auf dem Exchange selber nicht nochmals einloggen muss, aber da fehlt mir noch was. Ich muss weiter schauen. Für den Fall, dass ich da falsch denke. Um den Exchange zu verwalten ruft Ihr auch https://exchange/ecp auf, oder?

Im IIS heißt das Exchange Back End Ich habe noch weitere IIS, da funktioniert das so. In einem anderen Forum schreibt einer ohne nähere Angabe man müsse Delegierungen für das Computerobjekt einrichten. Aber das gibt es auch beim alten Exchange nicht. Ich verwalte da den Exchange, lege User an usw. die dann zu Azure sychronisiert werden. Die Powershell ist mir da etwas unbequem. Machst Du alles per Powershell? Oh nein, Kopf wie Sieb. Da hat es auch nicht mit einem selbstsignierten Zertifikat funktioniert, sondern erst nach dem ich mir ein Zertifikat von der lokalen CA ausgestellt und zugewiesen habe. Muss ich probieren.

Ich stehe auf der Leitung. Für "Exchange Back End/ecp" ist die Formularauthentifizierung deaktivert Für "Exchange Back End/ecp" ist die Windows-Authentifizierung aktiviert (HTTP 401 - Abfrage) Windows-Authentifizierung Anbieter sind Negotiate, NTLM (in dieser Reihenfolge) Die Webseite https://exchange ist in "Lokales Intranet" zugeordnet Die verstärkte Sicherheitskonfiguration ist deaktiviert (sonst lässt sich HCW nicht ausführen) Habe ich was falsch verstanden?

Guten Abend, wie kann ich erreichen, dass ich bei einem Exchange 2019 beim Aufruf des EAC auf dem Server selber mich nicht nochmals authentifizieren muss. Der angemeldete User hat bereits die notwendigen Rechte. Ich meine beim Exchange 2016 irgendwas separat gemacht zu haben, aber leider war die Doku damals so eher mittelgut . Für einen kleinen Schubs in die richtige Richtung wäre ich dankbar.

Herzlichen Dank für die Infos. So hatte ich das bisher. Dann kann man den HCW nach der Stelle an der man die kostenlose Lizenz abholen kann abbrechen.

Hallo, wenn ich einen Exchange lokal nur noch zur Verwaltung der AD-Attribute nutze, weil alle Postfächer in der Cloud sind (für alte Drucker noch ein Relay), muss man bei der Installation trotzdem den Hybrid Wizard ausführen, aber warum? Was macht der? Ich benötige ja keinerlei Routing (Minimal Hybrid, Modern Topologie) und die AD-Attribute werden durch den Azure-Sync übertragen. Auch die Migration ist schon länger her. Evtl. hat mir jemand von euch einen Link zum Nachlesen?

Bezüglich des Problems des Hängenbleibens: Nachdem ich die Vorlage und das Register Kryptografie einmalig ohne Netzwerkverbindung angewählt habe, ist das Problem verschwunden. Seltsam, aber der Rest scheint zu funktionieren. Aber bei Gelegenheit komplett neu machen um dann ganz sicher nie wieder dran denken zu müssen ist bestimmt besser.

Ich weiß . Das seltsame ist ja, dass fast alle Zertifikate munter erneuert werden, aber niemandem bewusst ist, dass das verwendet wird. Ich bin selber dabei und ich weiß ganz genau, dass ich das nicht verwende .

Das wird wohl das Beste sein. Die DCs holen sich ja automatisch Zertifikate. Lassen sich die EFS-Zertifikate der Nutzer übernehmen, wobei alle mit denen ich gesprochen habe, ist nicht bewusst, dass sie jemals eine Verschlüsselung verwendet haben.

Oh shit... Ich habe mich darauf verlassen und das eher als Empfehlung gesehen https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/move-certification-authority-to-another-server

Die CA heißt noch gleich, aber der Server auf dem die CA läuft hat einen anderen Namen. Weil Microsoft das so beschrieben hat, dachte ich, das sei kein Problem Das ist Plan B um den IIS schnell zum Laufen zu bringen. Aber eine kaputte CA will ich auch nicht dauerhaft haben. Es sind halt EFS-Zertifikate ausgestellt, deswegen habe ich die migriert und nicht einfach weggeworfen.

Ja, aber wäre der Ablauf anders als bei der Übernahme vom W2K12R2? Zertifizierungsstelle sichern inkl. privatem Schlüssel und Zertifizierungsstellenzertifikat Registry-Key sichern: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration hier beschrieben: https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/move-certification-authority-to-another-server Zertifizierungsstelle deinstallieren Dann Zertifizierungsstelle wieder installieren (jetzt auf dem gleichen Server, bei der Migration auf einem neuen) Zertifikatedienst beenden Registry-Key importieren (hat sich der Name geändert CaServerName vorher anpassen) Nun mit der Assistent das Backup wiederherstellen Server neu starten Müsste ich irgendwas anders machen? Danke

Hallo, für einen ausschließlich intern von Domänen-Clients genutzten IIS wollte ich ein Zertifikat ausstellen. Das klappt soweit auch, nur hat das Zertifikat der Standardvorlage (Webserver) eine Schlüssellänge von nur 1024. Das mögen nun die Browser nicht. Die Zertifizierungsstelle wurde immer wieder migriert. Wenn ich nun das Template dupliziere um Anpassungen vorzunehmen hängt sich die ganze MMC auf, sobald ich beim duplizierten Template das Register Kryptografie anwähle. Auch nach einer Wartezeit von über einer Stunde ändert sich nicht. In den Eventlogs wird nichts protokolliert. Auffällig ist noch, dass der Dienst Zertifikatverteilung (CertPropSvc) sich nicht beenden / neu starten lässt. In meiner Testumgebung geht das. Kenn das jemand von euch? Danke

Nutzt Du die Standardrichtlinien oder Strikt? Ablehnen müsstest Du ja explizit eingestellt haben, bei einigen Optionen geht das gar nicht. Falls Du eigene hast (wie ich) sind diese stark unterschiedlich zu den Standardregeln (Konfigurationsanalyse)? Ich habe jeden Tag 100-150 in Quarantäne und gebe so 1-3 frei. Ich habe schon einiges damit rumgespielt. Mit den Standardregeln sind z. B. fast alle Mails mit der OneNote-Links-Masche zum Nutzer durch. Oder auch die Bank-Phishing-Mails gehen auf einer Stufe <4 (maximal aggressiv) immer mal wieder durch. Mit Stufe 4 ist das dicht. Jetzt geht bei mir nichts mehr durch was nicht gewollt ist, aber so 1-3 am Tag landen halt in der Quarantäne und sollten nicht. Die User bekommen einen Quarantänebericht und fordern die Freigabe an.

Funktioniert das zuverlässig? Ich nutze das ähnlich, aber es gibt das Problem, dass Emails die von der Exchange-Online-Protection in die Quarantäne sortiert werden, nach Freigabe nicht in das Journalpostfach zugestellt werden. Der Microsoft-Support hat das bestätigt, aber ist wohl by Design und das Journalpostfach wird als Featurecomplete angesehen und es ist mit keiner Änderung zu rechnen. Im Archiv fehlen somit alle Emails die mal in der Quarantäne waren und von da aus freigegeben wurden.

Da war ich aber schön falsch abgebogen . Danke!

Hi, so ein bisserl b***d muss ich jetzt doch noch fragen. Wenn ich das über eine Gruppenrichtlinie oder auch lokale Richtlinie konfiguriere sehe ich die Konfiguration nicht im Registry-Key: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters Bei der Abfrage mit w32tm /query /status wird aber die korrekte Zeitquelle angezeigt. Wenn ich die Zeitquelle direkt mit w32tm (z. B. w32tm /config /manualpeerlist: “meine Zeitquelle”) konfiguriere sehe ich das in der Registry. Funktionieren tut es immer, nur für mein Verständnis. Warum sehe ich das in der Registry nicht? Ich dachte mal ich hätte das mit den GPOs und dem Tattooing verstanden . Danke und Grüße

Guten Tag, in meinem AD ist die Uhrzeit falsch. Also nicht unterschiedliche Zeiten im AD, sondern das AD komplett. Nach der Migration des DC mit der Rolle PDC-Emulator wurde einfach nicht darauf geachtet, diesen nach extern zu synchronisieren: w32tm /query /status Sprungindikator: 0(keine Warnung) Stratum: 1 (Primärreferenz - synchron. über Funkuhr) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 10.0000000s Referenz-ID: 0x4C4F434C (Quellname: "LOCL") Letzte erfolgr. Synchronisierungszeit: 10.09.2023 15:52:08 Quelle: Free-running System Clock Abrufintervall: 6 (64s) Die Zeit ist ungefähr 3 Minuten voraus. D. h. wenn ich jetzt das korrekt konfiguriere habe ich im Netzwerk beim Generieren von Timestamps evtl. 2x die gleiche Zeit. Ich meine irgendwo mal gelesen zu haben (weiß aber nicht mehr wo) dass das kein Problem ist, weil Windows nicht einfach die Zeit umstellt, sondern bis zum Erreichen der korrekten Zeit die Zeit etwas schneller oder langsamer laufen lässt (im AD). Liege ich hier richtig oder falsch? Danke und Grüße

Ich bin grundsätzlich für neu machen. Allerdings schaue ich mir das immer selber an und verlasse mich nicht auf die Aussage von Kollegen. Gerade solche Meldungen wie AV ist ausgefallen, man solle diese oder jenes tun, waren bei mir schon harmlose Browser-Benachrichtigungen und keine Erweiterungen oder sonstiges Software die ausgeführt wurde (wenn es bei der Benachrichtigung geblieben ist und die "Ratschläge" nicht befolgt wurden). Man fängt sich das ja nicht einfach so ein. Da hat der User schon was dafür gemacht. Ist es aber tatsächlich ein Stück Software das ausgeführt wurde ==> neu.

Vielen Dank für eure Beiträge. Generell hoffe ich, dass ich das gar nie brauche, wie wahrscheinlich alle die das machen. Ich sehe, dass das Fullbackup (-allCritical) gerade mal 6 GB mehr braucht. Da stelle ich dann doch lieber auf Fullbackup um. Es lohnt sich doch immer mal wieder Gewohntes in Frage zu stellen und mal nachzufragen . Danke und schönen Tag

Guten Morgen, neben Veeam mache ich ein Backup eines DC (GC, alle FSMO-Rollen) per Windows-Backup (wbadmin) und zwar "nur" den Systemstate. Ich habe den Restore schon probiert und war der Meinung alles ist gut. Nun habe ich zufällig hier (https://www.msxfaq.de/windows/dc_backuprestore.htm) gelesen, dass man in neueren Versionen >2008 das Backup mit der Option Bare metal recovery machen sollte. Es heißt "Eine Sicherung des "System State" alleine ist nicht ausreichend!" Das widerspricht meiner Erfahrung. Aber ich lerne gerne dazu. Sollte das AD grundsätzlich per "Bare metal recovery" gesichert werden oder reicht wie bisher angenommen der Systemstate? Für einen Tipp, Link oder Erfahrungsbericht wie das bei euch üblich ist, würde ich mich freuen.