RalphT

Moin, ich habe oder besser gesagt, hatte hier folgendes Problem: Es gibt hier eine Domänenumgebung mit 2 DCs (2008 R2). Weiterhin gibt es hier einen KMS Server (2012 R2). Auf diesem KMS ist der Key für Windows-Server 2019 hinterlegt. Das lief lange Zeit ohne Fehler. Jetzt hatte ich bei beiden DCs die Netzwerkkarte getauscht. Nach dem Hochfahren der DCs stellte sich erst einmal heraus, dass bei beiden Geräten die CMOS-Batterie alle war. Also Batterie gewechselt und dann einzeln hochgefahren. Anschließend hat sich gezeigt, dass bei beiden DCs die Windows-Aktivierung weg war. Ich nehme an, dass der Wechsel der Netzwerkarten schuld daran war. Hier hatte sich wohl die Hardware zu stark verändert. Nun wurden beide Server nicht mehr vom KMS-Server aktivert. Ich konnte mir das erst einmal nicht erklären. Bis ich dann festgestellt hatte, dass der Threshold vom KMS-Server zurückgesetzt war. Er hatte also zu diesem Zeitpunkt nur 2 Anfragen. Das reicht ja nicht aus, er benötigt dafür 5. Und das verstehe ich derzeit nicht, warum wurde hier der Threshold zurückgesetzt? Dann ein weiteres Problem, welches ich derzeit nicht verstehe: Manche Clients können nicht mehr drucken. Der Drucker ist auf einem DC installiert und dort per Freigabe und GPO für die Clients bereitgestellt. Nachdem man dann bei den Clients ein GPUPDATE und Neustart durchgeführt hatte, funktionierte auch das wieder. Was könnte hier denn passiert sein?

Moin, ich habe hier einige Notebooks von DELL, die ich mit einem Fernseher verbinden möchte. Mit einigen Geräten funktioniert das problemlos, jedoch mit zwei Geräten nicht. Bei einem Gerät habe ich beiden Treiber (WLAN und Intel-Grafikadapter) auf den aktuellsten Stand gebracht. Das brachte aber keine Veränderung. Mit dxdiag habe ich mir auf einem Gerät, welches funktioniert und bei einem Gerät, wo es nicht funktioniert erstellt. Hier scheint aber zwischen in den wichtigsten Passagen kein Unterschied zu bestehen. Hier ein Ausschnitt: Miracast: Available, with HDCP Für den Intel Grafikadapter: Miracast: Supported Wenn man so nach Lösungen dazu sucht, dann können oft die falschen Treiber installiert sein. Seltsamerweise, bei den Notebooks, wo es funktioniert, sind tw. noch die alten Treiber von der Installation drauf. Mir ist bei der Fehlersuche aufgefallen, dass die Notebooks mit folgenden Versionen funktionieren: Windows 10, 1607 und 1703 Notebook mit den Windows Versionen 1803 und 1809 funktionieren nicht. Das kann natürlich Zufall sein. Leider sind die Notebooks von der Hardware auch nicht alle gleich. Hat noch jemand eine Idee, wo man noch suchen könnte?

Ja, das wars. Ich hatte wohl das richtige Zertifikat im IAS, jedoch war noch ein altes, falsches im Speicher. Und das Zertifikat war in der Richtlinie ausgewählt.

Da muss ich mal nachsehen. Ich werde dann Montag berichten.

Hallo, ich habe eine WLAN-Verbindung mit Zertifikaten aufgebaut. Das Notebook ist in der Domäne und bekommt seine WLAN-Einstellungen per GPO. Mit einer zweistufigen PKI habe ich dafür ein Zertifikat bereitgestellt. Das Notebook hat das dafür erstellte Zertifikat und ein Eintrag in den Stammzertifiierungstellen vom ROOT-Zertifikat ist auch vorhanden. Ich verbinde das Notebook mit dem WLAN. Jetzt erscheint die folgende Sicherheitsmeldung von Windows 10: Verbindung weiter herstellen? Wenn Sie "WLAN-Test" hier erwarten, können Sie bedenkenlos eine Verbindung herstellen. Andernfalls handelt es sich möglicherweise um ein anderes Netzwerk mit demselben Namen Zertifikatsdetails anzeigen Ich stimme dem zu, anschließend bin ich mit dem WLAN verbunden. Ist das normal, dass diese Meldung kommt oder ist hier noch was nicht richtig?

Moin, ja das dachte ich mir gestern auch noch. Denn von oben kommt auch DHCP und dann haben die Clients keine IP-Adresse mehr. Dann hat sich das eh alles erledigt. Ich habe in diesem Fall VRRP verworfen. Danke für Antwort.

Sorry für die schlechte Erklärung. Ich habe davon mal eben eine Skizze gemacht. Ich hoffe, dass das aussagekräftiger ist. Aber ich denke auch schon fast, was du geschrieben hast, dass VRRP für diesen Fall nicht so gedacht ist. Aber ich bin mir halt nicht so ganz sicher. Vielleicht nochmal die Frage: Wenn die beiden Leitungen ausfallen, dann hätte ich auf den Aruba kein Routing zwischen den VLANs mehr.

Moin, ich habe zwei HP Core-Switche, die im IRF-Verbund sind. Weiterhin habe ich zwei Aruba Switche, die mit jeweiligen Stackmodulen zu einem Stack verbunden sind. Zwei Leitungen (LACP) gehen vom IRF-Verbund zum Aruba-Stack. Demnach hätte ich hier ja nur 2 Switche zu betrachten, statt 4. Jetzt bin ich am überlegen, ob es hier Sinn macht, VRRP auf beiden Einheiten zu konfigurieren. Würden die beiden Leitungen zwischen den Einheiten wegfallen, dann wäre ja auf beiden Seiten zwischen den VLANs noch ein Routing möglich. Allerdings bezweifele ich, dass beide Leitungen gleichzeitig ausfallen könnten. Nun hatte ich VRRP auf beiden Seiten konfiguriert und auch getestet. So wie es aussieht, funktioniert das. Allerdings bin ich mir nicht sicher, ob das hier nur per Zufall funktioniert. Stutzig wurde ich, wenn ich mir beim HP-IRF-Verbund den Status von VRRP anzeigen lasse: Dort kann man den Zustand nicht vom Aruba-Stack sehen. Dort steht nur der Zustand vom HP-IRF-Verbund selber. Auch beim Arubastack: Hier sieht man auch nur den Zustand von dem Aruba-Stack selber. Hier findet zwischen dem IRF-Verbund und dem Aruba-Stack kein Zusammenspiel statt. Daher meine Frage: Macht man das überhaupt so? Kann das so funktionieren? Und wenn es funktionieren würde, macht es in diesem Fall Sinn? Auf dem beiden Core-Switchen hängen die Server und an dem Aruba-Stack eigentlich nur Clients und Drucker.

Moin, um zu überprüfen, ob der PDC-Emulator noch wirklich der PDC ist habe ich folgendes unternommen: netdom query fsmo Ok, die Ausgabe stimmte so noch. Dann auf allen DCs mit RSOP oder GPRESULT überprüft, ob die eine GPO (wo der WMI-Filter ist) auch wirkt oder eben nicht wirkt. Sie zog nur bei dem PDC. Dahe meine ich, dass das noch stimmt. Ist die Vorgehensweise richtig? Dann zu den REG-Einträgen: Auf dem PDC-Emulator selber stehen: Bei dem Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters steht bei Ntpserver: time.windows.com,0x9 und bei Type: NT5DS. Unter HKEY_LOCAL_MACHINE\SYSTEM\SOTWARE\Policies\Microsoft\W32TIME\Parameters steht bei NtpServer: 192.53.103.108 und unter Type: NTP

Nein, die sind alle auf Bleche. Jetzt habe ich mal etwas mit verschiedenen NTP-Servern experimentiert. Ich hatte bisher immer nur die IPs: 192.53.103.103 und 192.53.103.104 verwendet. Jetzt habe ich mal die 192.53.103.108 ausprobiert. Jetzt hat sich das geändert: Bei w32tm /query /source kommt: 192.53.103.108 bei w32tm /query /peers kommt: Anzahl Peers: 1 Peer: 192.53.103.108 Status: aktiv Verbleibende Zeit: 866.0000s Modus: 1 (Symmetrisch aktiv) Stratum: 1 (Primärreferenz - synchron. über Funkuhr) PeersAbrufintervall: 10 (1024s) HostAbrufintervall: 10 (1024s) Wieder zurück auf eine alte IP, gabs den o.g. Fehler. Die Uhr tickt auch wieder genau. Allerdings brauchte sie ein paar Minuten, bis die Uhr wieder richtig lief. So ganz verstehe ich das allerdings nicht.

Moin, bei w32tm /query /source kommt: Local CMOS Clock bei w32tm /query /peers kommt: Anzahl Peers: 1 Peer: 192.53.103.103 Status: aktiv Verbleibende Zeit: 991.0000s Modus: 1 (Symmetrisch aktiv) Stratum: 0 (nicht angegeben) PeersAbrufintervall: 0 (nicht angegeben) HostAbrufintervall: 10 (1024s) WMI ist aktiv. In der GPO habe ich ja auch nichts verändert. Der PDC-Emulator selber bekommt seine Zeit nicht vom NTP-Server. Testweise habe ich mal auf dem PDC die Uhrzeit wieder richtig eingestellt. Anschließend ziehen alle anderen Mitglieder auch wieder die Zeit vom PDC. Das scheint noch so zu funktionieren. Beim Befehl w32tm /resync kommt die Meldung: Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.

Hallo, ich habe derzeit ein Problem mit der Zeitsynchronisierung per GPO. Die GPO habe ich damals nach dieser Anleitung eingerichtet: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Das lief auch über die Jahre sehr gut. Jetzt geht die Uhr vom PDC etwas vor. Sieht so aus, als wenn er seine Zeit vom CMOS-Chip bezieht. Ein Neustart des Zeitdienstes vom PDC brachte nichts. In der Firewall wurde auch nichts verändert. Hatte mal testweise einen Arbeitsgruppenrechner direkt mit dem NTP-Server synchronisiert. Das funktioniert einwandfrei. In der GPO habe ich als Zeitserverver 192.53.103.103 oder auch mal pool.ntp.org eingetragen. Hat jemand eine Idee wo man noch suchen könnte?

Dann bedanke ich mich für eure Antworten. Dann kann ich das Thema ja als gelöst markieren.

Stimmt. Da nichts gesperrt wurde, gab es auch keine Einträge.

Ok, dann kann (sollten) die Einträge ja erhalten bleiben. Nun war ich doch etwas schneller und habe im LDAP die beiden Sperrlisten gelöscht. Ich war in diesem Pfad: CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration Auch in dem Pfad, wo die Zertifikate und Sperrlisten für http stehen habe ich bereinigt. Jetzt wird mir in der MMC jeweils bei den beiden Sperrlisten ein Fehler angezeigt. Das ist jetzt nicht weiter tragisch, da sich das hier um eine Testumgebung handelt. Ich meine diesen Fehler bekommt man wieder weg, indem man wieder das ZertifizierungsstellenZertifikat erneuert. Was ich bisher nicht wusste, dass man die alten Sperrlisten noch aufbewahren sollte, damit die Sperrinformationen von den älteren Zertifikaten weiterhin überprüft werden kann. Ich bin bislang davon ausgegangen, dass alles in einer Sperrliste vorhanden ist.

Nein, das ist nicht möglich. Nicht dass wir aneinander vorbeireden: Ich bin in der MMC unter Gesperrte Zertifikate - Eigenschaften - Reiter "Zertifikatsperrliste anzeigen" ENTF geht nicht und ein Kontextmenü ist auch nicht vorhanden.

Danke dir. Kannst du mir noch sagen, wie man die Sperrlisten löschen kann, bzw. wo man das macht?

Hallo, ich habe eine Verständnisfrage zu einer zweistufigen PKI. Wenn ich von der SUB-CA das ZertifizierungsstellenZertifikat erneuere, dann habe ich eine weitere Sperrliste in der SUB-CA. Zu sehen in der MMC unter Gesperrte Zertifikate - Eigenschaften - Reiter "Zertifikatsperrliste anzeigen". Dann stehen dort zwei oder mehr Sperrlisten. Einmal für den Schlüsselindex 0 und dann weiter forlaufend. Auch die CRL-Dateien unter C:\Windows\System32\CertSrv\CertEnroll sind dann entsprechend vorhanden. Meine Frage ist jetzt: Kann man die alten Sperrlisten und auch Deltasperrlisten löschen? Für mich ist das eigentlich nur ein "optisches" Problem. Sie stören ja nicht.

Stimmt. Aber in diesem Fall gibt es nur einen. Naja, eigentlich wollte ich ja gestern die Finger von dem Problem lassen, da aber gestern genug Zeit war, hatte ich doch noch mal etwas weiter geforscht. Auf einen Memberserver hatte ich das Zertifikat gelöscht. Anschließend dann den Netzwerkstecker aus dem Gerät gezogen. Neustart gemacht, Zertifikat war sofort da. Das hatte ich mal testweise auch mit einem anderen Memberserver gemacht. Auch hier das gleiche Ergebnis.

Naja, wie auch. Ich weiß es selber ja nicht. Den DC hatte ich damals soweit fertiggestellt, dass auf diesem PC ein DC installiert wurde. Bevor ich eine CA installiert hatte, hatte ich ein Images vom DC gemacht. Aber du hast Recht, eigentlich ist es sinnlos das weiter zu verfolgen, da es nicht in der Praxis vorkommen wird und der Zeitaufwand hier einfach höher ist.

Moin, ich habe hier eine Testumgebung und einer 2-stufen PKI und vieles mit Zertifikaten ausprobiert. Die Testumgebung besteht aus einem DC und vier Mitgliedservern. Auf einem Mitgliedserver habe ich die SUB-CA installiert. Die offline-Root-CA ist noch extra und nicht der Domäne. Irgendwann wollte ich mal wieder von vorne anfangen und habe alle Server mit einem Image (nur Windows) wieder bespielt. Der Zeitpunkt, wo das Image erstellt worden ist, war ohne CA. Allerdings habe ich einen Memberserver nicht erneut mit dem Image bespielt. (War mir zuviel Arbeit) Auf diesen Server habe ich die Rolle der CA entfernt, aus dem lokalen Speicher alle Zertifkate entfernt und aus der Domäne entfernt. Nachdem alles wieder betriebsbereit war, habe ich den einen Member Server wieder ind die neue Domäne gesetzt und dort auch wieder eine SUB-CA installiert. Jetzt habe ich den kleinen Schönheitsfehler, dass auf allen Memberservern sich ein altes Zertifikat in ihren lokalen Speicher installiert. Das hatte ich dann auf allen Servern wieder gelöscht und mit gpupdate probiert, ob es auch nicht mehr wieder erscheint. Das war soweit in Ordnung. Allerdings viele Stunden später ist es doch wieder auf jeden Server verfügbar. Das ist jetzt nicht wichtig, da es ja nur eine Testumgebung ist. Aber interessiert mich trotzdem, wie man das alte Zertifkat endgültig löschen kann. In der MMC pkiview habe ich schon nachgesehen, ob dort noch ein alter Eintrag von der alten CA vorhanden ist. Das ist aber alles sauber. Wo könnte das alte Zertifkat immer wieder herkommen? Als einzige Möglichkeit kann ich mir nur vorstellen, dass das von dem Memberserver kommen kann, den ich damals nicht neu erstellt habe. Aber das ist nur eine Vermutung.

Ja, wurden sie auch vorher. Ich hatte, nachdem ich oben den Thread eröffnet hatte, eine Abfrage durchgeführt. Dabei hatte ich festgestellt, dass die Systempostfächer nur auf der alten Datenbank hinterlegt waren. Jetzt habe ich einfach die Postfächer auf die neue Datenbank verschoben und die Systempostfächer werden jetzt nur auf dem neuen Server angezeigt.

Ich bin vorher davon ausgegangen, dass der neue Server auch Systempostfächer angelegt hatte. Daher wusste ich nicht, ob man die einfach überschrieben kann oder nicht überschreiben darf. Da ich das aber erst später das überprüft hatte und dabei festgestellt hatte, dass da keine vorhanden sind, hat sich das Problem damit erledigt.

Hallo, ja, so dachte ich mir das auch. In der Zwischenzeit, habe ich mal eben eine Abfrage Get-Mailbox -Arbitration -Server <alter Exchange> auf beiden Datenbanken gemacht. Dabei kam heraus, dass der neue 2010 gar keine Systempostfächer hat. Dann kann/muss ich diese ja verschieben. Ich bin davon ausgegangen, dass bei der zweiten, neuen Installation auch jeweils welche angelegt werden.

Moin, ich habe ein Frage zum Umzug auf einen anderen Server: Nachdem ich die Postfächer auf die neue Hardware verschoben habe, muss ich die Systempostfächer auch verschieben? Da finde ich momentan keine Lösung. Die Systempostfächer werden ja per default auch bei der neuen Installation angelegt.