NilsK

Moin, okay, und wann wolltest du uns sagen, was "funktioniert nicht" nun heißt? Übrigens ist "Remote Utilities" kein RDP, wenn ich das nicht gründlich missverstehe. Also bitte mal ernsthaft jetzt, sonst können wir uns das sparen. Gruß, Nils

Moin, wenn du nur den CA-Server löschst oder abschaltest, bleiben die Einträge dazu im AD erhalten. Daher der Verweis auf die Anleitungen. Eine Enterprise CA ist in der AD-Konfiguration eingetragen. Edit: Natürlich ist vor dem Löschen zu prüfen, ob die ausgestellten Zertifikate tatsächlich nicht mehr gebraucht werden. Siehe Norberts Hinweis und das, was ich dazu schrob. "Zum Großteil" finde ich da eine etwas unvollständige Einschätzung. Bevor du auf der Basis Schaden anrichtest, hol dir lieber jemanden, der das mit dir migriert bzw. ein Vorgehen zur Ablösung entwirft. Gruß, Nils

Moin, wenn die DC-Zertifikate die einzigen sind, die dort ausgestellt wurden, kannst du die CA im Prinzip einfach löschen. Domänencontroller besorgen sich automatisch Zertifikate von einer Enterprise CA, sobald sie diese im AD finden. In dem Fall solltest du natürlich die betreffenden Zertifikate von den DCs löschen, bevor du die CA entfernst, denn sonst werden die DCs Fehler melden, weil sie die Gültigkeit der Zertifikate nicht überprüfen können. Im Hinblick auf diverse Sicherheitseinstellungen im eigenen Netzwerk, insbesondere für DCs, könnte es allerdings sinnvoll sein, auch künftig eine PKI zu betreiben. Es gibt ja möglicherweise auch interne Web-Applikationen, die per TLS abzusichern wären (und seien es nur Adminzugänge). Dann allerdings rate ich dazu, eine PKI nach Best Practice zu entwerfen und aufzubauen, bevor die alte entfernt wird. Eine Migration der alten CA sehe ich als unnötig an, wenn sie wirklich nur die oben genannten Zertifikate ausgestellt hat. Zum Entfernen der Alt-PKI beachte, dass diese auch aus dem AD gelöscht werden sollte, Anleitungen dazu findest du im Web. Vorsichtshalber sei noch mal ausdrücklich erwähnt, dass man eine CA nicht auf einem DC installiert. Gruß, Nils PS. wie viele DCs habt ihr denn, dass da laufend neue Zertifikate ausgestellt werden?

Moin, was genau heißt denn "Leider funktioniert RDP nicht"? Da du ja in der IT arbeitest, weißt du vielleicht, dass so eine Fehlerbeschreibung ... nicht besonders erschöpfend ist. Gruß, Nils

Moin, aus den Angaben lässt sich in der Tat wenig ablesen. Meiner Kenntnis nach sind typischerweise weder SFirm noch Zeiterfassungssysteme performancekritisch, sondern laufen meist so nebenbei mit. Aus dem Bauch würde ich dann irgendwelche Optimierungen oder Wartungen an den Indizes als unnötig ansehen. Es kann aber sein, dass das nicht passt. Hingegen ist der Hinweis der drei Kollegen korrekt, dass man da mal den Hersteller fragen sollte. Allgemein zum Thema Backup, weil das in kleinen Umgebungen fast immer falsch gemacht wird: https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Dort vor allem den letzten Abschnitt - aber um den verstehen zu können, ist der Rest des Artikels schon sinnvoll. (Dazu hab ich ihn ja schließlich auch geschrieben.) Gruß, Nils

Moin, "das kommt darauf an". Gerade Datenbankserver werden sehr unterschiedlich genutzt. Was für Server A unabdingbar ist, kann für Server B total übertrieben sein. Bei einem "typischen Admin-SQL-Server" kann man auf alle Tasks verzichten und wird vielleicht nur manuell einen Auftrag zum Full Database Backup einrichten. Bei einer ERP-Datenbank will man hingegen vielleicht sogar alle vorgeschlagenen Tasks verwenden. Was sind denn in deinem Fall die Anforderungen? Gruß, Nils

Moin, was heißt "16 logische Prozessoren"? Zwar ist es, wie der eine Norbert schon richtig sagt, eher unwahrscheinlich, dass zwei VMs die Ressourcen auslasten. Trotzdem sollte man nicht nach dem Motto vorgehen "viel hilft viel", das passt nämlich so gut wie nie. Ohne nähere Kenntnis der Anforderungen kann man kein Sizing betreiben. In einer kleinen Umgebung würde ich auch bei einem Terminalserver nicht oberhalb von 4 vCPUs anfangen. Es kann sein, dass das in der konkreten Situation doch nicht reicht, dann eben mehr. Aber: Gerade bei Terminalservern kann es durchaus sein, dass die Skalierung "nach oben" nur begrenzt funktioniert und es sinnvoller ist, mehrere moderat ausgestattete Server parallel zu betreiben. Aber das kann man nur anhand konkreter Beobachtungen und Messungen feststellen, nicht vorab oder pauschal. 8 vCPU (wie vom anderen Norbert genannt) können in einer großen Umgebung, deren Parameter gut bekannt sind, auch als Vorgabe für Terminalserver passen, aber das würde ich nicht als Basis "für alle" sehen. Im Wesentlichen trifft dies hier immer noch zu: [Hyper-V-Sizing: Virtuelle und echte CPUs | faq-o-matic.net] https://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/ Und dies auch: [Wie viele Cores braucht mein VM-Host? | faq-o-matic.net] https://www.faq-o-matic.net/2019/10/22/wie-viele-cores-braucht-mein-vm-host/ Gruß, Nils

Moin, In der beschriebenen Situation ist es doch völlig egal, um welche Schadsoftware es sich jetzt handelt. Wichtig ist, dass man die Integrität der Backups zuverlässig prüft, genau wie das, was von der Umgebung ohne Recovery weiter laufen muss. Da wäre es auch nicht verkehrt, jemanden dabei zu haben, der Erfahrung mit sowas hat. Gruß, Nils

Moin, Ich denke auch, dass die Virtualisierung hier nahezu keinen Einfluss hat. Hingegen scheinen mir an anderer Stelle die Grundlagen noch nicht gefestigt zu sein. Natürlich ist der Router das Gateway, was denn sonst? Gruß, Nils

Moin, Für die Aufgabe aber sehr hoch gegriffen. Da finde ich ein Skript auch günstiger. Gruß, Nils

Moin, Nein, das angesprochene Problem lässt sich so nicht lösen. Dafür wird man einen separaten Rechner brauchen, typischerweise einen Admin-Client. Wäre auch deutlich sauberer gelöst. Gruß, Nils

Moin, Norbert, deine ersten beiden Sätze verstehe ich nicht. Der Hinweis auf die 111.1 scheint mir aber richtig. Entweder fehlt der in der Liste, oder das ist der Fehler. Gruß, Nils

Moin, das PowerShell-Skript ist nicht von mir. Die Grundidee hatte ich per Batch umgesetzt. Ich bin mir nicht sicher, ob so ein Skript wirklich so dauerhaft laufen und seine Daten in ein OneDrive schreiben sollte. Gedacht ist der Ansatz für kurze Prüfungen. Aber für eine Zeit kann man das vielleicht auch durchgehend tun. Deine Zusatzanforderung würde ich einfach über einen Zähler abbilden. Momentan dürfte das Skript einmal pro Sekunde pingen. Man könnte also in jeder Ausführung einen Zähler um 1 hochsetzen und dann bei 3600 eine Statusmeldung ins Log schreiben und den Zähler zurücksetzen. Sofern die Auflösung des Skripts nicht sekündlich sein soll, wäre noch eine Wartezeit pro Durchlauf denkbar, dann müsste man natürlich den Zähler anpassen. Gruß, Nils

Moin, ein wesentlicher Fehler in deinem ursprünglichen Code dürfte gewesen sein, dass %PingCheckA% keinen Wert hat. Damit verlangst du eine ungültige Dateioperation. Sowas passiert, wenn man Variablennamen nur an einer Stelle ändert ... Gruß, Nils

Moin, Sowas hab ich mal gebaut: https://www.faq-o-matic.net/2016/06/22/testskript-ist-der-reboot-schon-durch/ Gruß, Nils

Moin, dann verstehe ich nicht, was du vorhast. Wie sollen denn die Clients die Server erreichen, wenn es kein lokales Routing gibt? Und gerade an kleinen Standorten stellt sich für mich dann immer die Sinnfrage. Gruß, Nils

Moin, Und der Durchsatz der Red-Geräte reicht für den internen Traffic aus? Das wäre sehr untypisch. Gruß, Nils

Moin, Fangen wir doch erst mal vorne an: was ist das Ziel des Ganzen? Und: sollen die Firewalls das interne Routing übernehmen? Gruß, Nils

Moin, ja, und dann? Was soll damit geschehen? Was ist die Anforderung? Mir erscheint der ganze Ansatz ziemlich umständlich. Vielleicht gibt es aber einen Grund dafür. Sonst würde ich dir raten, das gar nicht per PowerShell zu machen, sondern z.B. mit adfind. Gruß, Nils PS. in einem Forum gehört ein bisschen mehr Sorgfalt beim Tippen zur Höflichkeit. Beim Scripting geht es gar nicht ohne. Und wenn du Fragen zu deinem Code stellst, dann bitte mit exaktem Code (und auch als Code formatiert) - sonst raten wir hier nur rum. Danke.

Moin, also, zunächst solltest du natürlich Tippfehler vermeiden. "Struktur" ist nicht dasselbe wie "Strucktur". Das Wort "Gruop" wird die PowerShell auch nicht kennen. Dann ist es auch keine gute Idee, eine Variable "true" zu nennen, das ist ein reseviertes Schlüsselwort. Das ist technisch an der Stelle zwar (leider) zulässig, aber es erschwert das Verständnis deines Codes. Und schließlich wäre noch mal zu prüfen, was du überhaupt willst. Dein Code, wenn er funktionierte, würde wohl alle User der OU durchgehen und dann versuchen, diejenigen, die in der Gruppe sind, in eine Variable zu schreiben. Ist es so gedacht? (Funktionieren wird es schon deshalb nicht, weil die Logik immer nur die Daten des letzten abgefragten Users in der Variable ablegen würde ...) Abgesehen davon, dass der Code noch einige Fehler hat: Warum machst du das so? Was soll mit den Werten hinterher geschehen? Was ist das übergeordnete Ziel? Gruß, Nils

Moin, ich würde eher die Frage stellen, ob dein Aufbau überhaupt OCSP braucht. Wenn du Probleme damit hast, macht Stapling es nicht besser. Entweder löst du also die eigentlichen Probleme - oder du prüfst, ob du nicht ganz auf OCSP verzichten kannst. Das Protokoll wird meist völlig missverstanden, es ist nicht nur nicht nötig, sondern in vielen Implementierungen sogar von Nachteil. Gruß, Nils

Moin, ich werfe noch mal in die Runde, dass man sich gerade bei DCs durchaus die Sinnfrage einer Netztrennung stellen darf. Praktisch alle relevanten Funktionen eines DCs müssen für User und für Admins gleichermaßen erreichbar sein und werden dann über Berechtigungen usw. voneinander getrennt. Anders als bei manchen anderen Serverdiensten gibt es keine Aufteilung in Nutz- und Admintraffic. Es braucht also schon gute Gründe und gute Beherrschung des Netzwerks, um so eine Separation sinnvoll umzusetzen. Kann man das nicht gewährleisten, dann ist es die falsche Baustelle. Gruß, Nils

Moin, Ich werde deine Logs jetzt hier nicht in Detail lesen. Relevant sind nur Fehler - werden welche genannt? Die ursprüngliche Fehlermeldung bezieht sich nicht auf die Betriebsmaster der Domäne, sondern der DNS-Partition. Ich vermute mal, dass es zum das Phänomen geht, das hier ausführlich beschrieben ist: https://blogs.msmvps.com/ulfbsimonweidner/2008/07/31/how-many-infrastructure-masters-do-you-have/ Wenn das also das einzige Problem ist, kannst du es ignorieren, es jetzt lösen oder es später lösen. Gruß, Nils

Moin, der Meldung nach könnte es sein, dass der Betriebsmaster für die DNS-Datenpartition nicht gültig eingetragen ist. Das wäre in deiner Situation evtl. aber kein wesentliches Problem, wenn der Rest funktioniert. Was sagen denn die Eventlogs der "anderen" beiden DCs? (Habe ich es richtig verstanden, dass es aktuell drei DCs gibt?) Was sagt die Ausgabe von dcdiag /E > c:\Pfad\dcdiag-result.txt? Gruß, Nils

Moin, Der ganze Ansatz ist doch unsinnig. Wenn der User das Kennwort für den Admin hat, dann ist er Admin. Das Versteckspiel kannst du dir sparen. Gruß, Nils