RalphT

vor 17 Stunden schrieb daabm:

"Etwas aus dem Lot" @NilsK ist da die zutreffende Formulierung, aber bisher kam vom TO nichts dazu

Stimmt. Denn der hat sich die 2 Tage bei gutem Wetter eine Auszeit gegönnt.

Ich war heute kurz vor Ort und habe die beiden DCs neu gestartet. Es war beiden tatsächlich ein Update vom Virenscanner (Panda) noch nicht fertig.

Nach dem Neustart merkte man sofort, dass die beiden Geräte wieder wesentlich flotter auf Eingaben reagieren. Mir war auch so, dass ein DC erst mal so nicht viel an Resourcen benötigt. Das war damals bei Novell auch so.

Das tückische hierbei war, dass der Virenschutz einen benötigten Neustart nicht angezeigt hatte.

Anschließend habe ich das gleiche Verfahren auf beiden DCs wieder ausprobiert. Läuft!

Beim Klick auf OK reagiert das Menü sofort. Das war vorher nicht der Fall. Man sah richtig, wie das manchmal klemmte.

Jetzt habe ich zum Schluss aber trotzdem noch eine Frage:

Wenn ich auf dem DC 1 den GPO-Editor öffne und dort etwas verändere, dann werden die Änderung ja auf dem SYSVOL geschrieben.

Wird dann in diesem Fall auf dem SYSVOL vom DC 1 geschrieben? Also auf seine Festplatte? Oder kann man das gar nicht so genau sagen? Die Änderung ist doch auf allen DCs sofort verfügbar oder liege ich da falsch?

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

vor 1 Stunde schrieb Nobbyaushb:

Auf jedem DC ein CMD als Administrator aufmachen

repadmin /syncall /force

Und das bitte auf allen 4 DC´s

In der Ausgabe stehen eventuelle Probleme, meist mit einem Hinweis

Wie hoch ist die Latenz zwischen den Standorten?

Ein Forrest und ein AD?

Darüber hatte ich auch schon nachgedacht. Habe es aber aus einem anderen Grund erstmal verworfen.

Mir ist aufgefallen, dass die beiden DCs hier recht lahme Krücken sind. Ein STRG-ALT ENTF dauert bestimmt 5 bis 10 Sekunden, bis mal der Bildinhalt zu sehen ist. RAM haben die jeweils 16G, der ist nur zu 30% ausgelastet. Die Prozessorleistung ist ständig bei 30% ausgelastet. Das kam mir recht viel vor. Ich habe noch andere Server, ähnlicher Bauart. Das sind z.B. einfache Fileserver usw. Die regieren wesentlich flotter. Bei denen ist die Dauerlast vom Prozessor bei mal gerade 5%.

Die Prozessorlast kommt bei den DCs vom Virenschutz. Jetzt hatte ich heute noch gesehen, dass der Virenschutz überall einen Neustart erfordert.

Ich werde daher jetzt als aller erstes die Rechner alle neustarten. Danach sehe ich mir nochmal die Prozessorlast auf den beiden DCs an.

Ich hatte letzt den Exchange 5 oder 6 mal booten müssen, bis alle Windows-Updates und Virenschutzupdates zufrieden waren. Daher war vorhin noch meine Vermutung, dass das vielleicht die Fehlerursache sein könnte.

Anschließend werde ich mal wie du geschrieben hattest die Replikation anschubsen.

Zwischenzeitlich hatte ich vorhin mit einer Test-GPO rumgespielt. Mir einen Wert ausgesucht, z. B. "Anmelden am Dienst verweigern" und dann immer einen Nutzer nach dem anderen im Sekundentakt reingebracht und wieder entfernt. Mal gehts zwei mal, und dann wieder 2 oder 3 mal nicht.

Die Latenz? Hm, ich glaube ein Ping hat so eine Antwortzeit von 10 - 15 ms. Bin mir da aber nicht so genau sicher.

vor einer Stunde schrieb Nobbyaushb:

Liest sich wie ein Sync-Problem im AD

Habe ich auch schon gerade im Verdacht. Ich bin ja immer noch in der Findungsphase.

Ich habe hier 2 DCs und woanders auch 2 DCs stehen. Der DC mit den FSMO-Rollen steht hier. Verbunden über eine gute Leitung, über VPN und Firewalls.

Jetzt hatte ich gerade von der Zweigstelle das gleiche Verfahren auf einem der DCs probiert. Also die gleiche GPO editiert. Dort nach Belieben etwas verändert. Funktionierte super schnell und einwandfrei. Dann dachte ich schon daran, das das Phänomen nur auf einer Seite besteht.

Nein, denn ein Nachfolgeversuch auf der Gegenseite war anschließend nicht erfolgreich.

Wenn man den Editor öffnet und dort etwas einstellt und anschließend auf OK oder Übernehmen klickt, dann geht das mal superschnell und im Fehlerfall "klemmt" es richtig. Der blaue Mauskreis dreht sich ca. 2 Sekunden.

Was mich so stutzig macht:

Warum funktionert es bei einem großen Teil der Werte und bei bestimmten Zweigen nicht? es wird doch die gleiche Datei beschrieben. Oder denke ich falsch?

Ich habe nochmal etwas rumprobiert.

Eine neues GPO erstellt.

Im Zweig Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Zuweisen von Benutzerrechten

einiges an Werten verändert.

Mal gehts sofort, im gleichen Augenblick danach kann man die Gruppe nicht mehr entfernen. Dann wieder und wieder probieren zu entfernen. Auf einmal funktioniert es. Sieht mir so nach einem Zufallsprinzip aus.

Andere Zweige, wie z.B. Computerkonfiguration/Administrative Vorlagen, da gibt es anscheinend keine Probleme. Hier kann man nach Belieben Werte aktivieren und wieder deaktivieren.

Das Problem scheint nur in den oberen System-GPOs zu liegen.

Jetzt könnte ich natürlich bei der neuen GPO solange probieren, bis alle Einträge sitzen. Das würde dann wahrscheinlich auch später wohl funktionieren. Denn die Einträge in der GptTmpl.inf sind ja korrekt.

Die Sicherung aller GPOs hat natürlich auch ohne Fehlermeldungen funktioniert, da ich das GPO mit den unbekannten SIDs bereinigt hatte.

Habe ich gemacht. Funktioniert leider teilweise. Entfernen der unbekannten SIDs hat funktioniert. Allerdings fehlten bei machen Einträgen bestimmte Gruppen. Das hatte ich mit einem funktionierenden DC verglichen. Viele Einträge ließen sich komplett so wiederherstellen, wie es sein soll.

Allerdings sind so ca. 5 Einträge vorhanden, wo ich die SIDs herauslöschen konnte. Jedoch die fehlenden Gruppen ließen sich nicht hinzufügen.

Es erscheint dann gleiche Fehlermeldung wie im ersten Post. Es kann die Datei GptTmpl.inf nicht beschrieben werden.

Irgendwie seltsam:

Ganz oben ist "Ändern der Systemzeit". Hier kann ich z.B. die Gruppe Druck-Operatoren hinzufügen und auch wieder entfernen.

Bei dem Eintrag "Laden und entfernen von Gerätetreibern" funktioniert das nicht.

Es wird irgendwie immer kurioser:

Jetzt war ich beim Eintrag "Lokal anmelden zulassen". Da fehlten auch 3 oder 4 Gruppen. Nach ca. 10 Minuten konnte ich dann doch eine weitere Gruppe hinzufügen. Anschließend hatte ich dann eine weitere Gruppe hinzugefügt. Auch das funktionierte.

Zum Schluss fehlte noch die Gruppe "Server Operatoren". Nach dem Klick auf OK sieht man auch, dass der Schreibvorgang irgendwie länger dauert. Anschließend erscheint die bekannte Fehlermeldung.

Dann hatte ich wieder ca. 10 Minuten verstreichen lassen. Auf einmal ließ sich dann auch noch die letzte fehlende Gruppe dort hinzufügen.

Beim Sichern der GPOs ist mir dann folgendes aufgefallen:

In der Standard-GPO "Default Domain Controllers Policy" ist mir aufgefallen, dass dort nicht auflösebare SIDs enthalten sind. Siehe Anhang.

Diese hatte ich allerdings nie verändert.

Moin,

ich erstelle ein neues GPO. In den Computereinstellungen stelle ich z.B. im Pfad ..\Lokale Richtlien etwas ein.

Nachdem ich dann auf OK klicke, erscheint folgende Fehlermeldung.

Das ist aber nicht in allen Werten so. Stelle ich z.B. etwas bei der Firewall eine Regel ein, dann funktioniert das. Auch in den Administrativen Vorlagen habe ich stichpunktartig rumprobiert. Dort war auch kein Fehler feststellbar.

Die Datei GptTmpl.inf wurde tatsächlich nicht richtig verändert. Der Wert steht zwar in der Datei, jedoch nicht der angegebene User. Die GPO habe ich hier auf einem zentralen Store.

Die Ereignisanzeige ist sauber. DCDIAG und repladmin sind auch ohne Fehler.

Ich kann mir jetzt nicht so direkt vorstellen, dass bestimmte ADMX-Vorlagen defekt sind.

Hat einer eine Idee, wo der Fehler liegen könnte? Wer weiß, wie lange dieser Fehler schon präsent ist, da das ja nur bei bestimmten Werte in einer GPO auffällt.

Habs gefunden. Danke dir.

Moin,

ich hatte in einer AD-Umgebung noch mit dem alten LAPS gearbeitet und wollte dort jetzt das neue LAPS nutzen. Damals hatte ich den Befehl

	
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Clients,DC=firma,DC=de"

Find-LapsADExtendedRights -Identity LapsTestOU

vor 5 Minuten schrieb Nobbyaushb:

Gute Wahl - welche Edition werdet ihr nehmen?

 

Ehrlich gesagt - ich bin mir noch nicht sicher. Eigentlich reicht mir die Protection Version. Aber ich habe gesehen, dass es etwas für Disclaimer gibt. Ich muss mir das nochmal in Ruhe durchlesen. Die Sache mit dem Disclaimer finde ich garnicht so verkehrt. Ich habe das hier ja mit Bordmitteln im Exchange realisiert. Das hat natürlich so seine Schönheitsfehler.

Ich muss mir das nächste Woche mal alles in Ruhe ansehen.

vor 1 Minute schrieb NorbertFe:

Von welchem Produkt gibts denn bitte keine Trial mit der man in Ruhe testen kann? Also das Argument is jetzt irgendwie hinfällig. Und nein, das ist keine Aussage meinerseits zur Qualität von nospamproxy. ;)

Dann kam das falsch rüber. Ich habe nicht das Produkt gewählt, weil man es testen kann. Hatte einen Bekannten gefragt, der nutzt das auch und ist sehr zufrieden. Daher die Entscheidung.

Erst mal vielen Dank für die Tipps.

Ich werde das wie folgt machen:

Erst einmal den Reverse-DNS und SPF-Eintrag erstellen/ändern.

Um den Popconnector abzulösen, habe ich mich für das folgende Produkt entschieden. Dort gibt es eine 30 Tage Version, wo ich in Ruhe testen kann.

https://docs.nospamproxy.com/Server/14/Suite/de-de/Content/intro/Home.htm

vor 8 Minuten schrieb Nobbyaushb:

Aus meiner Sicht gibt es einige Lösungen - über wieviel Mailboxen und gesamt-Bestand reden wir?

 

Kleinere Kunden sind mittlerweile in der Cloud bei MS O365 oder einem der anderen Anbieter in der Regel gut aufgehoben

Ich habe einige durchaus kleinere Kunden die aus bestimmten Gründen keine Cloud-Lösung wollen

 

Man kann das alles prima On-Premises lösen, aber dazu muss man heute lesier ein bisschen Aufwand treiben und auch Geld in die Hand nehmen

Fängt mit Spamfilter an, der natürlich dem Exchange vorgelagert ist usw.

Aber das geht in Richtung Consulting, und damit verdiene ich mein Geld...

 

Wir haben so ca. 50 Teilnehmer. Cloud kommt nicht in Frage.

Den Exchange kann ich ja so nicht einfach ohne Spam-Filter, etc. einfach per https von extern erreichbar machen. Kann schon, wäre aber tödlich. Nun ist es so, dass ich das jetzt mal eben nicht entscheiden kann und dieses Thema natürlich vorher hier besprochen werden muss, da das ja auch mit Kosten verbunden ist.

Jetzt stellt sich daher für mich die Frage:

Kann ich ab dem o.g Stichdatum diese Konstellation noch so nutzen? Wenn ja, wie? Wir hatten dieses Thema ja schon auf dem Plan, nur das ist recht kurzfristig. Daher wäre mir eine Zwischenlösung erst einmal recht, um dann im Laufe 2024 das richtig zu machen.

vor 46 Minuten schrieb Nobbyaushb:

Moin,

 

Gegenfrage - wie kommen denn die Mails von IONOS zu deinem Exchange (schon über ein Upgrade nachgedacht? 2016 ist aus dem Main.Support raus...)

Ja das Thema ist bekannt. Derzeit noch mit einem POP-Abholer. Das soll aber mit dem Update geändert werden.

vor 46 Minuten schrieb Nobbyaushb:

Wenn du direkt sendest, wird das nicht klappen wenn der PTR und Reverse-DNS nicht auf eure (hoffentlich feste) IP zeigen

Ja das stimmt. Reverse DNS ist auch nicht eingerichtet, da ja die Mail bei IONOS landen. Feste-IP ist vorhanden.

vor 46 Minuten schrieb Nobbyaushb:

Aber ja, kann man auch weiterhin so machen, aber das ist alles andere als optimal - meiner Meinung nach...

Ich habe zu dieser Smarthostlösung keine Idee. Was müsste ich den ändern, damit ich das noch so nutzen könnte?

Moin,

ich habe einen Exchange 2016 CU23, der seine externen Mails über einen Smarthost zu IONOS versendet.
Gestern bekam ich folgende Mail (siehe Anhang)

Ich habe für die Authentifizierung für den Smarthost bei IONOS eine extra Mailadresse, nur für diesen Sendeconnector angelegt.
Derzeit habe ich jetzt keine Idee, wie ich weiterhin den Smarthost von IONOS nutzen könnte.
Gibt es ab dem Stichtag eine Möglichkeit das weiter so zu nutzen?

Falls nicht, dann war meine Idee, ich nutze einen Sendeconnector, der direkt in der Internet sendet. Ich habe das mal eben schnell probehalber durchgeführt.
Die externe Mail kam auch sofort beim Empfänger an.
Was mich allerdings stutzig macht, ist ein Blick in die LOGs:

2023-11-30T06:07:53.335Z,Internet-Send,08DBE65BD4EA1B65,1,,212.227.15.41:25,*,,attempting to connect
2023-11-30T06:07:54.364Z,Internet-Send,08DBE65BD4EA1B65,2,,212.227.15.41:25,*,,"Failed to connect. Winsock error code: 10061, Win32 error code: 10061, Destination domain: externe-person.de, Error Message: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 212.227.15.41:25."
2023-11-30T06:07:54.378Z,Internet-Send,08DBE65BD4EA1B66,0,,217.72.192.67:25,*,SendRoutingHeaders,Set Session Permissions

Hier werden noch weitere Server von IONOS ausprobiert, mit dem gleichen Ergebnis.

Jetzt frage ich mich, wieso kam die Mail, aber dazu diese Fehlermeldungen?

Ich habe derzeit zwei Sendeconnectoren, wobei nur einer aktiviert ist. Wenn ich den anderen nutzen möchte, muss ich nach dem Deaktivieren/Aktivieren den Transportdienst neu starten?

Gut, dann warte ich.

Moin,

ich habe bei einem Exchange 2016 in einer universalen Verteilergruppe Mitglieder entfernt/hinzugefügt. Allerdigs dauert es einige Zeit, bis die Änderung am Nutzer ankommt.

Kann man das per PS oder anders beschleunigen?

Na gut, dann lege ich das Thema mal zu den Akten.

Hatte ich auch schon gelesen - Leider. Ist dann eben nur eine kleine Hürde für den Angreifer.

Moin,

ich wollte gerne in unserer Umgebung das Ausführen fremder PS-Scripte unterbinden. Dazu habe ich ein GPO mit der Ausführungsrichtinie für die Scripte mit "AllSigned" erstellt.
Danach zeigte sich in der Ereignisanzeige vom Exchange 2016 folgende Fehlermeldung:

Einstellungen: Fehler beim Laden der Formatdatendatei:
Microsoft.Exchange.Management.PowerShell.E2010, , C:\Program Files\Microsoft\Exchange Server\V15\bin\Exchange.format.ps1xml: Die Datei wurde wegen folgender Validierungsausnahme übersprungen: Fehler bei der AuthorizationManager-Überprüfung..
 

Details:
    ExceptionClass=RuntimeException
    ErrorCategory=NotSpecified
    ErrorId=ErrorsUpdatingFormats
    ErrorMessage=Fehler beim Laden der Formatdatendatei:
Microsoft.Exchange.Management.PowerShell.E2010, , C:\Program Files\Microsoft\Exchange Server\V15\bin\Exchange.format.ps1xml: Die Datei wurde wegen folgender Validierungsausnahme übersprungen: Fehler bei der AuthorizationManager-Überprüfung..

Dann habe ich mir die Eigenschaften der Datei "Exchange.format.ps1xml" anzeigen lassen. Diese, wie viele andere PS-Scripte sind alle digital signiert.
Das Zertifikat ist von Microsoft ausgestellt, jedoch ist der Gültigkeitszeitraum überschritten. Da jedoch auch ein Zeitstempel dort vorhanden ist,
bin ich der Meinung, dass alle diese Scripte noch ausgeführt werden sollten.

Ich könnte jetzt die Scripte mit der hauseigenen PKI neu signieren. Nur das wolllte ich erst einmal nicht machen, da es bei den vielen Scripten sehr aufwändig ist.
Eigentlich könnte ich doch die vorhandene Signierung nutzen?

Meine Frage ist jetzt, was kann man da machen? Sollte ich für den Exchange Server eine Ausnahme erstellen, sodass dieser Server von der GPO nicht betroffen ist?

Das wäre natürlich etwas unsicherer.

vor 19 Stunden schrieb MurdocX:

Das ist normal, weil der Benutzer sein Passwort ändern muss und dieser Dialog die Möglichkeit nicht bietet. Demnach wird die Anmeldung abgelehnt. Soweit, so normal. Einmal am PC anmelden, Passwort ändern und fertig. 

Danke dir für Info. Ich hatte mir das schon fast gedacht, nur erklären konnte ich mir es nicht.

Moin,

ich habe mal eine Frage zur Passworteingabe bei Outlook mit Exchange. Ich habe Exchange 2016 und Office 2016. Wenn auf einem Client das Outlook das erste Mal eingrichtet wird, findet Autodiscover sofort die Einstellungen und Outlook funktioniert.
Wenn der Nutzer das nächste Mal sein Outlook startet, dann fragt Outlook nach dem Passwort. Das ist aber nicht immer so.

Wenn aber z.B. in der AD eingestellt wird, dass der Nutzer bei der nächsten Anmeldung sein Passwort ändern muss, dann erscheint das Fenster mit dem Passwort.
Das passiert auch, wenn das Windows-Passwort kurz vor dem Ablauf ist. Der Nutzer meldet sich mit dem alten Passwort an, möchte es aber noch nicht ändern. Dann verlangt Outlook nach einem Passwort.
In diesem Fall kann man das noch alte, gültige Passwort eingeben, was Outlook aber nicht akzeptiert.
Der Nutzer muss erst sein Passwort ändern, dann ist auch bei Outlook Ruhe.

Ansonsten erscheint nie das Passwortfenster. Autodiscover läuft fehlerfrei.

Ist das normal?

Am 7.2.2023 um 17:35 schrieb daabm:

Nur um noch mal darauf hinzuweisen: Das heißt NICHT, daß der Client sich nicht mehr in der Domäne wähnt. Das heißt nur, daß der Client sich gegen die Domäne nicht authentifizieren konnte und daß es deshalb keinen Secure Channel gibt und danach alles mögliche andere auch noch schief geht. Es MUSS in so einem Fall vorhergehende andere Fehler geben.

Ja, das dachte ich mir schon. Aber jetzt haste mich neugierig gemacht. Ich habe gerade beobachtet, dass so mancher gerne zum Feierabend sein Gerät nicht herunterfährt, sondern einfach nur den Bildschim sperrt.

Wie würde sich denn dieser Fehler im Betrieb bemerkbar machen? Würde z.B. der Zugriff auf Laufwerke fehlen? Oder ist das eher ein stiller Fehler?

vor 10 Stunden schrieb Nobbyaushb:

Moin,

kann aber ggf. noch die Ursache mit dem LAN sein, das wir hier schon ein paar mal hatten

Wenn das nochmal vorkommt, gucken ob der PC wirklich mit dem Domänen-Netzwerk verbunden ist oder ob da öffentliches LAN steht

 

Hatten wir einige Zeit und war irgendwann weg

Und ja, bei uns gab es eine GPO „aufs Netzwerk warten…“

 

My2Cents

Moin,

ja das Problem hatte ich schon mal, dass das Netzwerk auf öffentlich stand. Meine Idee war ja am Anfang, dass der Client nicht mit dem DC kommunizieren konnte. Aber selbst wenn der Client keinen Kontakt zum DC hätte, dürfte doch diese Meldung nicht erscheinen. Wenn ich das richtig verstanden habe, dann meckert der Client nur, wenn sein Computerpasswort nicht mit dem hinterlegten Computerpasswort auf dem DC übereinstimmt. Hat er keine Verbindung, kann er auch keinen Unterscheid feststellen - oder?

Auch diese GPO hatte ich Anfangs vergessen. Die ist aber jetzt vorhanden.

Zitat

Und wegen 2 Geräten - wenn's mit nem Neustart behoben ist - ok, beobachten, aber "aktiv" würde ich da noch nicht werden.

Eigentlich hast du Recht. Aber da die ganzen Jahre der Fehler nie aufkam, hatte ich Anfangs schon Bedenken, dass ich bei der Neuinstallation einen Fehler gemacht habe.

Hallo Nils,

danke für Info.

Ja, das könnte vielleicht so gewesen sein. Bei einem Client war zum besagten Zeitpunkt sehr viel rot in der Ereignisanzeige. Da habe ich jetzt auch nicht weiter geforscht.

Der andere Client hatte kaum rote Einträge oder Warnungen die mir verdächtig vorkamen. Hier standen z.B. diese Meldung:

Beim Starten der Sitzung "Microsoft.Windows.Remediation" ist der folgende Fehler aufgetreten: 0xC0000035.

Der Dienst Gruppenrichtlinienclient konnte nach dem Empfang eines Preshutdown-Steuerelements nicht richtig heruntergefahren werden.

Vielleicht war das der Grund. Ich werde das mal weiter im Auge behalten. Derzeit sind es hier ca. 50 Clients und viele Server und bei 2 Geräten ist das bislang aufgetreten.