Jump to content

James_Eric

Newbie
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

1 Neutral

About James_Eric

  • Rank
    Newbie
  1. Liebe Mitkämpfer, ich habe in ein abgeschirmtes Netzwerk ein SSL-Zertifikat importiert und den darin befindlichen Replikat-WSUS auch daran binden können. Wenn ich die Konsole für den Replikat-WSUS verbinden will, sagt das System, dass der Server für das Zertifikat nicht überprüft werden kann und das Zertifikat selbst wird mit dem Hinweis versehen, das es nicht bis zu einer Zertifizierungsstelle verifiziert werden kann. Is klar, die ist ja auch in einem anderen Netz. Was kann ich machen, das dieses Zertifikat in diesem abgeschirmten Netz nicht angezweifelt, sondern als gegeben akzeptiert wird? Dank und Gruß James_Eric Nachtrag: ich habe zwar schon auf dem Zertifikat den Hinweis gefunden, dass ich es in den Speicher vertrauenswürdiger Stammzertifizierungsstellen installieren soll, aber ich finde nicht die Möglichkeit, wie es gehen soll.
  2. Das neumachen soll auch wirklich nur der letzte Ausweg sein.
  3. @SandyB Hallo Sandy, danke für Deinen Tip. Das Tool gibt eine schöne Übersicht her. @NilsK Sorry, wenn meine Beschreibung zu Verwirrung führt, das war nicht meine Absicht. Es ist quasi ein Mischbetrieb von bisher "ungeregelten" Clients (etwa 300), die bisher ohne Domäne vor sich hin gewerkelt haben, und der neuen Situation, die als Folge haben soll, das diese Clients zukünfig zentral von der Domäne aus gesteuert werden können sollen (Firewallkonfiguration etc.). Diese Clients nehme ich zur Zeit pöapö (weiß nicht wie man das richtig schreibt :) in die Domäne auf (aktuell wie gesagt 77). Dadurch, das die Clients zur Erfüllung ihrer Aufgabe nicht umbeding auf die Domäne angewiesen sind, sind sie vom aktuellen Problem nur indirekt betroffen. Die Benutzer arbeiteten bisher mit lokalen Konten auf den Clients, zukünftig soll aber verstärkt auf Domänenkontos umgestellt werden. Deswegen hatte ich es "Teststatus" genannt. Der Teststatus soll fließend in den Wirkbetrieb übergehen. Und bis vor 3 Wochen sah es so aus, als würde alles reibungslos funktionieren. Mein aktueller Plan sieht jetzt folgender Maßen aus: Ich konzentriere mich erst mal auf Weihnachten, dann orientiere ich mich verstärkt an Euren Vorschlägen und werde (nach dem Jahreswechsel) einen zweiten DC in der Domäne aufsetzen und schauen, ob dann das Problem weiterhin besteht. Falls die Probleme weiterhin auftreten sollten, werde ich die Domäne komplett neu machen (dann am liebsten aber direkt unter Server 2019) und die 77 Clients müssen dann eben nochmal neu eingebunden werden. Ich danke Euch bis dahin für Eure Hilfe und wünsche Euch allen an dieser Stelle schon mal frohe Feiertage und einen schönen Jahreswechsel James
  4. @NilsK Ok, jetzt verstehe ich, was Du meinst. Der Fehler wird also nicht durch die 77 Clients verursacht, wenn ich Euch richtig verstehe, sondern, weil irgenwo etwas verbogen ist. Das beruhigt mich, da das ja auch meine ursprüngliche Vermutung war. Mein Projekt ist immer noch im Teststatus, wo ein Ausfall noch nicht tragisch ist, deshalb konnte ich bisher auf eine Redundaz verzichten. Für die Zukunft wird es dann aber doch wichtig für mich jetzt herauszufinden, was ich aktuell falsch mache, oder noch wichtiger: in der Vergangenheit falsch gemacht habe und jetzt möglicherweise seine Wirkung zeigt. Ich vermute nämlich, dass ich irgendwelche Leichen in meinem System rumschleppe (siehe DFSREvent im DCDIAG.txt), die im Laufe der letzten 3 Jahre entstanden sind, als ich anfing, mich mit Domänen und AD zu befassen. Das aktuelle System ist anfänglich aus einem Server 2008 gewachsen, und dann über Server 2012 letztendlich auf Server 2016 gelandet, wobei die ursprüngliche Domäne von einem System auf das nächste umgezogen ist. Dabei ist das System PDC-und FSMO-mäßig geschwenkt worden, war auf verschiedenen Rechnern, hatte zwischenzeitlich auch mal einen zweiten DC, den ich dann aber wegen Replikationsproblemen wieder wegfallen ließ. Und jetzt werden meine Leichen scheinbar lebendig . . . ganz schön gruselig, nicht wahr? 8-) ich brauche jetzt einen Van Helsing, der mein System wieder bereinigt! jetzt aber wieder ernsthaft: Ich werde die Logfiles weiter durchsuchen. Grüße James
  5. Danke Euch für Eure Anregungen. Hallo Nobby, auf dem DC ist als AV Trend Micro OfficeScan XG installiert, wobei er auch die Aufgabe des OfficeScan Servers bekleidet, das heißt , die Clients holen sich bei ihm ihre neuen Virensignaturen. Windows-Update-mäßig ist er aktuell. Seine Updates bezieht er von einem WSUS-Server, der wiederum ein Domänenmitglied ist. Auf den Clients läuft Windows 10 Pro 64. Das hätte ich nicht gedacht, das so ein Domänencontroller so schnell an seiner Leistungsgrenze ist. Wenn ich (jetzt mal laienhaft, was ja auch noch zutrifft ) dem seinen Taskmanager im Leistungsfenster so betrachte: der macht den ganzen Tag nix! Prozessorlast immer unten, die 16 GB RAM nur bis 3GB ausgelastet. Wie kann der sich überlastet fühlen? Die Logs bin ich jetzt am durchforsten. Das Ergebnis vom DCDIAG liefere ich Euch aber schon mal. Grüße James dcdiag.txt
  6. Hallo Nils, aktuell sind es 77 Clients. Später sollen es bis etwa 300 werden. Kannst Du mir genauer sagen, in welchem Eventlog die entsprechenden Einträge hinterlegt werden? Dank und Gruß James
  7. Hallo miteinander, ich betreibe seit einem Jahr einen Windows Server 2016 Standard als alleinigen Domänencontroller. Seit etwa 3 Wochen besteht das Problem, das die Domänenbenutzer (oder auch DomänenAdmins) sich an ihren Client-PCs morgens nicht mehr anmelden können. Die Fehlermeldung lautet dann etwa, das die Domäne nicht zur Verfügung steht. Meine derzeitige Problemlösung sieht so aus, das ich dann an den Server gehe und den Dienst "NTDS" beende und neu starte . Danach funktioniert die Anmeldung bis zum Feierabend. Am nächsten Morgen dann wieder das gleiche Problem und die gleiche Prozedur. Kennt jemand dieses Fehlverhalten und weiß wo der Fehler zu suchen ist? Domänenfunktionsebene ist Windows Server 2016. Ich danke für jede Hilfe James
  8. Hallo, ich habe das Problem, das ich nicht das Gruppenrichtlinienobjekt finde, aus dem die Kennwortrichtlinien geholt werden (habe meiner Meinung nach schon alle durchsucht). Mit dem Befehl "net accounts /domain" kann ich zwar sehen, was drin steht, aber nicht wo. Habt Ihr da einen Tip für mich? Dank und Gruß James
  9. Ich möchte mich an dieser Stelle erst nochmal bei Euch für Eure Unterstützung bedanken, denn durch Euch bin ich schon ein ganzes Stück weiter gekommen. Grüße James
  10. @tesso "Betreuen" definiere ich in diesem Fall wie folgt: Der DC (Server2016, winver 1607) soll in die Lage versetzt werden, alle Einstellmöglichkeiten, die an einem Client (mit winver 1809) einstellbar sind, auszuführen (obwohl einige Möglichkeiten oder Dienste, die es erst ab 1809 gibt, die in winver 1607 noch nicht zur Verfügung standen). @NilsK Hallo Nils, danke für Deine Anregung. Trotzdem, das ich Deine Aussage noch nicht verstanden habe, habe ich schon mal angefangen sie umzusetzen (hört sich verrückt an, is aber so :) ich versuche ja möglichst alle Eure Anregungen umzusetzen, oder zumindest geistig nachzuvollziehen). Deshalb habe ich jetzt einen Rechner parat gemacht, der die Rolle der Admin-Workstation übernehmen soll. In der Praxis der Admin-Workstation bin ich absolut ungeübt, denn tatsächlich habe ich bisher alle Einstellungen direkt am DC selbst durchgeführt. Das hieß, das ich mich am DC angemeldet habe, und dort z.b. OUs eingerichtet habe und denen dann Gruppenrichtlinienobjekte zugewiesen habe, durch die dann bei den Clients beispielsweise gewisse Dienste deaktiviert wurden. Aktuell fehlt mir die Vorstellungskraft, wie ein Server, der nur winver 1607 "kennt", dann Clients mit winver 1809 komplett mit allen 1809er Möglichkeiten "betreuen" kann. Weil mir in diesem Bereich noch soviel Wissen fehlt, beschäftigt mich noch die Frage: Würden sich viele meiner Fragen automatisch lösen, indem ich auf Server 2019 umsteige?
  11. Habt Dank für Eure Geduld und Bemühungen. Jetzt bin ich in der Lage auf dem Client (Domänenmitglied) GPMC.msc zu starten. Um mir aber mehr Klarheit zu verschaffen, ob ich überhaupt auf dem richtigen Kurs bin, oder ob ich mir vielleicht viel zu viele Gedanken mache, möchte ich Euch folgende Frage zum Thema Servervorbereitung stellen: Welche Schritte sind Eurer Meinung nach zu tun, wenn Ihr einen quasi frisch aufgesetzten DC (DNS usw. sind erledigt), auf Basis Server 2016 (winver. 1607) habt, damit der zukünftig Windows-10-Clients mit winver 1809 optimal betreuen kann?
  12. Nun, ich habe auf dem Client "GPEDIT.msc" gestartet . .. .. . Ist das, das was Ihr meint?
  13. @NorbertFe @Dukel Hallo Norbert, hallo Dukel nun, ich habe auf dem Client "GPEDIT.msc" (was ich im Zusammenhang mit GPMC gefunden habe) gestartet. Dort fand ich dann den Punkt "Liste exportieren". Das Resultat von "Liste exportieren" war dann ein Textfile mit 3 Wörten: "Name", "Computerkonfiguration" und "Benutzerkonfiguration". Mehr stand da leider in diesem Textfile nicht drin. Von daher hat sich mir da bisher noch nicht mehr erschlossen. Meint Ihr denn mit GPMC dieses GPEDIT.msc?
  14. @daabm Hallo Martin, einen Central Store habe ich noch nicht eingerichtet. Nachdem mir von dukel und zahni (s. oben) empfohlen wurde, diese Dateien lieber von einem Windows-10-Client zu holen anstatt bei Microsoft downzuloaden, habe ich das folgenderweise gemacht: Vom Client aus "C:\Windows\PolicyDefinitions" den Inhalt komplett auf den Server in "C:\Windows\PolicyDefinitions" kopiert (vorher hatte ich beim Server den Inhalt von "C:\Windows\PolicyDefinitions" komplett gelöscht, damit dort nichts altes übrig bleibt. So ist aktuell der Stand der Dinge. War das bis dahin richtig, was ich gemacht habe? Wie mir die GPMC auf dem Client dabei hilft, hat sich mir noch nicht erschlossen. Grüße James
  15. Ja, habe ich auch schon wie oben beschrieben zwischenzeitlich gemacht, aber den neuen Dienst sehe ich im Gruppenrichtlinienverwaltungs-Editor trotzdem noch nicht.
×
×
  • Create New...