Jump to content

kaineanung

Members
  • Content Count

    389
  • Joined

  • Last visited

Everything posted by kaineanung

  1. @Dukel Ich frage deshalb weil es mir missfällt ständig unseren FW-Dienstleister zu bitten diesen oder jenen Port zu öffnen und diesen und jenen Port wieder zu schliessen. ABER; wenn ihr sagt daß man den PDC auch als Zeitgeber für Nicht-Domänen-Clients nutzen kann, dann habe ich tatsächlich keine Argumente dies nicht nur auf den PDC zu stellen. Das Einzige was mir noch einfallen würde, und was der Grund ist daß wir auf Linux-DNS und DHCP gewechselt sind: benötigt man CALs für den Zeitserver? Wenn ja: das ist der Grund warum ich dann doch auf diesem bestehenden Zeitserver im LAN setzen würde. Meinst du die der VM-Ware-Server / Hosts? Wie ich bereits gesagt habe sind beide DCs auf verschiedenen WMWare-Maschinen virtualisiert. 1.DC (mit den FSMO Rollen) ist auf einem ESX-Verbund an einer SAN mit VMWare-Essentials-Kit virtualisiert und dort bezieht sich der ESX-Server die Zeit von unserem internen NTP-Server. Der 2. DC ist auf einer 'normalen' (kostenfreien) Maschine virtualisiert (ESXi vSphere 6.7.0) und auch dieser ist auf den NTP-Server angebunden. Somit haben beide VMWare-Server diesen einen NTP-Server im LAN als Zeitgeber.
  2. Ja würde das statt mit dem Internet direkt mit dem bereits bestehenden NTP-Server im Netzwerk funktionieren? Und wie mache ich das? Gibt es da irgendwo eine schrittweise Anleitung? Meinst du anderen Clients ausserhalb der Domäne? Weil die Clients innerhalb der Domäne sind, wenn ich mich nciht täusche, bereits angebunden? Ich habe in der CMD w32tm /query /source benutzt und bekomme, auf den 3-4 Clients auf denen ich das getestet habe, immer den PDC-Server als Quelle. Somit muss ich bei den Domänen-Clients ja nichts mehr machen, richtig? Was mich aber wundert ist: Der 2. DC meldet mir ebenfalls das seine Zeitquelle der 1.DC ist (mit der PDC-Rolle). Wie kann es sein das im Ereignisprotokoll steht das es Zeitabweichungen zwischen DC1 und DC2 gab? Ich habe 2 Warnungen im Ereiignisprotokoll: 1. Meldung: Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist. Ereignis-ID: 142 Quelle: Time-Service 2. Meldung: Der Zeitdienst hat eine Zeitdifferenz von mehr als 5000 ms auf 900 Sekunden festgestellt. Die Zeitdifferenz wurde möglicherweise durch die Synchronisation mit einer ungenauen Zeitquelle oder durch schlechte Netzwerkbedingungen verursacht. Von nun an wird der Zeitdienst nicht mehr synchronisiert, die Zeit keinem weiteren Client mehr zur Verfügung gestellt und die Systemuhr nicht mehr synchronisiert. Sobald ein gültiger Zeitstempel von einem Zeitdienstanbieter empfangen wird, wird der Zeitdienst sich selbst korrigieren. Ereignis-ID: 50 Quelle: Time-Service Das war der eigentliche Grund um sich nun Gedanken zu machen beide Server an eine Zeitquelle zu binden. Da aber DC2 an DC1 angebunden zu sein scheint frage ich mich: was läuft dann schief? Dennoch würde ich Grundsätzlich gerne Sicherstellen das DC1 sich irgendwo die korrekte Zeit holt. Da wir bereits einen Port in der FW öffnen liessen, würde ich gerne diesen bereits eingerichteten Server als Zeitquelle für DC1 nehmen... (DC2 wäre mir auch lieb aber ob das geht bin ich mir nicht sicher). Ok, das ist das was ich mit w32tm /query /source geprüft hatte und es scheint so zu stimmen. Nur warum ich dann die o.g. Meldung im Ereignisprotokoll bekommen habe kann ich mir nicht erklären? Zeitunterschied zwischen DC1 und DC2 obwohl DC2 an DC1 angebunden ist was die Zeit angeht / synchronisiert. Nachtrag: ich bin nun ein paar Stunden zurück gegangen im Ereignisprotokoll des 2. DCs und habe was komisches gefunden von heute Nacht was erstmalig aufgetreten ist: >>Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "srv-dc1$" empfangen. Der verwendete Zielname war HTTP/srv-dc1.FIRMA.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (FIRMA.LOCAL) von der Clientdomäne (FIRMA.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.<< Ob das mit meinem Fehler von heute Morgen zusammenhängt? Die o.g. Warnungen sind gegen 8 Uhr aufgetreten. Diese Fehlermeldung hier aber bereits um 3:14 Uhr.
  3. Der DC ist selber aber an keinen externen Zeitserver angebunden und daher dient nur der lokale Zeitgeber als die einzig wahre Zeit. Die muss ja nicht unbedingt stimmen... Ausserdem: DC2 hatte eine Abweichung weshalb er sein Dienst eingestellt hatte?! Also muss ich die irgendwie dazu bringen die exakt gleiche Zeit zu haben. Am besten aber unabhängig voneinander da wenn einer Ausfällt der Andere trotzdem die korrekte Zeit inne hat. Das verstehe ich leider nicht? Übrigens: was ich vergessen hatte zu erwähnen: beide DCs sind unter VMWare-Server auf (unterschiedlicher Hardware) virtualisiert.
  4. Hallo Leute, ich habe hier mal wieder ein kleines Problemchen. Wir haben jetzt eine nagelneue Domäne (migriert von 2003 auf 2016), NETLOGON-Batch abgeschafft (alles auf GPO) und sogar einen 2. DC in der Domäne (davor Jahrelang nur 1 DC als physikalische Maschine betrieben). Jetzt ist alles besser und es wird noch besser... ;) Jetzt hatten wir ein kleines Problem mit folgender Geschichte: Einige User bekamen plötzlich keine Netzlaufwerke die wir per GPO erstellen. Ein Kollege (ich war noch nicht im Hause heute morgen) hat sich versucht auf den 2. DC-Server anzumelden und das wurde ebenfalls verweigert. Nach dem Neustart des 1.DC haben die User nach einem gpupdate jedoch wieder Netzlaufwerke bekommen und somit war alles erst mal gut bis zu meiner Ankunft um sich des Problems genauer anzunehmen. Nach ein wenig hin und her habe ich herausgefunden das sich der Anmeldedienst abgeschaltet hatte auf dem 2. DC mit der Begründung das es eine Zeitabweichung von mehr als 5000 ms zum 1. DC gab?!? Warum jedoch alles wieder ging nachdem der 1. DC neu gestartet wurde kann ich nicht sagen. Aber darum geht es hier jetzt gar nicht sondern das Problem mit dem Zeitunterschied. Wir haben ein NTP-Server in unserem Netzwerk stehen welcher mit einem Zeit-Serverpool im Internet verbunden ist. Z.B. nutzen wir ein 3rd-Party-Tool 'Nettime' um bei bestimmten Clients die Zeit mit diesem NTP-Server zu synchronisieren. Manche sind Domänen-Clients, manche nicht und daher brauchen wir diesen NTP-server auch weiterhin. Jetzt würde ich gerne meine beiden DCs an diesen Server anbinden damit ich kein weiteren Nettime-Port in der FW öffnen lassen muss. Daher habe ich dazu 3 Fragen: 1. Wie binde ich die beiden DCs an den NTP-Server (der übrigens unter UBUNTU läuft)? 2. Werden sich die Domänen-Clients automatisch mit den DCs synchronisieren? Wenn nein: was muss ich tun? Wenn ja: Kann ich das irgendwo prüfen? 3. Alternativ kann ich auch den DC direkt mit dem Serverpool im Internet synchronisieren. Das würde mir zwar widerstreben aber wenn es begründet besser ist kann ich das hier ja mal anstossen. Dabei ist aber die Frage: warum ist es besser und binde ich dann beide DCs direkt an diese Zeitserver an oder nur einen und der andere wird an den ersteren angebunden was den Zeitserver angeht? Also entweder DC1 -> Internet-Zeitpool & DC2 -> Internet-Zeitpool ODER DC1 -> Internet-Zeitpool & DC2 -> DC1 ? Im Moment ist ja so angedacht: DC1 -> srv-ntp -> Internet-Zeitpool & DC2 -> srv-ntp -> Internet-Zeitpool Ich danke euch shcon einmal im Voraus für eure Hilfe bzw. zumindest für das Lesen bis hierhin.
  5. Mir ist das jetzt schon klar. Aber das war ein kleiner Versuch von vor 10 Jahren mit der GPO irgendwas anzustellen. Und ich habe auch nur 3-4 Einstellungen gemacht bevor wir uns damals dazu entschieden hatten doch noch mit der Logon.bat zu verwalten. Und ich habe es zugegebenermaßen vergessen zu entfernen...... die 'Default Domain Policy' wird bei uns nur noch für die Kennwortrichtlinien verwendet. Alles andere wird auf die entsprechenden selbst erstellten GPOs verteilt. Aber zum Thema nochmals: Kann ich mit deiner Vorgehensweise irgendwas kaputt machen? Würde ich die Default Domain Policy neu erstellen können wenn diese kaputt gehen würde?
  6. Ok, habe ich verstanden und umgesetzt. Und jetzt kommt ein Mysterium: Ich habe Zugriff auf ''Default Domain Policy -> Benutzerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Internet Explorer-Wartung-> Verbindung -> Automatische Browserkonfiguration'. Aber die im Bericht angezeigten Einstellungen sind gar nicht gesetzt und hier im Editor sind die leer! Es sind 2 Hacken zu setzen und wenn man den unteren Haken setzt, muss man noch 3 Felder befüllen. In meinem Bericht steht: Automatische Ermittlung von Konfigurationseinstellungen -> Deaktiviert Automatische Browserkonfiguration -> Nicht konfiguriert Im Editor sind beide Haken nicht gesetzt. Somit erwarte ich nun das diese auch komplett rausfliegen. Dies tun sie aber nicht... Was kann ich machen das dieser Eintrag ganz aus meiner GPO verschwindet, es also nicht im Bericht / Einstellungen angezeigt wird. Es ist auch so das diese GPO Eben Computer UND Benutzereinstellungen beinhaltet. Das soll und darf man ja nicht machen wie ich das mit den Gruppenrichtlinien verstanden habe. Und wenn es auch macht was es soll, sieht es nicht gut aus. Daher würde ich schon wollen das nicht auf immer und ewig mitschleppen zu müssen sondern sauber zu entfernen. Würde mir in diesem Falle der Post von @daabm weiterhelfen auf der vorherigen Seite? Geht es denn nicht im GPO-Editor doch irgendwie?
  7. Wie meinst du das? Ich habe hier ein Server 2016 am laufen. Zwei sogar. Wie soll ich den 2008R2 nehmen? Soll ich einen Installieren? Der dürfte da doch gar nicht gehen da die Domänenstruktur auf 2016 angehoben wurde... oder? Ich habe eine Installations-ISO von 2008R2 rumliegen, also daran sollte es nicht scheitern. Ich kann das ja auch noch in der Testperiode ausführen. Aber das dürfte doch nicht gehen wegen der Domänenstruktur welche auf 2016 gesetzt wurde.
  8. @zahni Verstehe dein Post irgendwie gar nicht? Wir benutzen hier nahezu kein Windows 7 mehr. Und auf den Rechnern auf denen es noch vorhanden ist, wird bald auf Win 10 aktualisiert... ABER: der Eingangpost beschreibt einen Fehler den man wohl nur durch das Editieren der GPO 'Default Group Policy' von einem Windows 7-Client bereinigen kann. Das habe ich nun versucht und habe Windows 7 64-Bit installiert und wollte mir die RSAT-Tools installieren damit ich eben diese GPO editieren kann und die Einträge wegbekommen kann. Wäre das irgendeine GPO würde ich es lassen, eine neue erstellen und eben nur den Fehler rauslassen. Aber es handelt sich blöderweise um die 'Default Group Policy' und da traue ich mich nicht einfach so ran weil die Angst da ist diese zu verlieren. Und neu erstellen ist da wahrscheinlich auch nicht möglich oder nur schwer oder was-weiß-ich.
  9. Echt b***d das MS den Support für Windows 7 vor 2 Tagen eingestellt hat! Ich finde nirgends das RSAT-W2K16-Installationspaket für Windows 7 Clients! Das für Windows 10 will sich nicht installieren (falsche Betriebssystemversion wird korrekterweise gemeldet), das Win7-Tool RSAT welches ich irgendwo bei MS doch zum download gefunden habe (KB958830), besagt das es nur bis Server 2008 R2 gültig ist... Nach dem 'update' finde ich nur einen Hilfe-Eintrag unter 'Alle Programme'->'Verwaltung' welcher die Systemanforderungen anzeigt und das mit Server 2008 R2 besagt.... Kann mir jemand sagen wo ich das Tool noch finden kann? Was ich brauche ist also RSAT für W2K16 welches für Windows 7 gedacht ist. Ich würde gerne diesen Weg einschlagen um das Problem aus dem Eingangspost zu lösen da mir dieser einfacher erscheint als irgendwelche 'IEM-CSE aus den gPCUserExtensions'.. (sorry @daabm, lieber erstmal den einfacheren Weg wenn möglich. Sonst mache ich noch hier in der Domäne was kaputt...)
  10. Das wäre ja prima wenn das so gehen würde. Ich installiere eine Windows 7 VM, nehme sie in die Domäne auf, installiere RSAT-Tools, öffne auf dieser Maschine die 'Default Domain Policy' und ich finde da den entsprechenden Eintrag dann um ihn dann raus nehmen zu können (-> Nicht konfiguriert')? Habe ich das so richtig verstanden? Windows 7 kommt defaultmäßig mit IE9, oder? Also wenn ich Windows 7 nicht aktualisiere oder von Hand IE > 9 installiere dann sollte das so klappen?
  11. Ja, das dachte ich mir bereits so. Die Frage aller Frage ist aber: wie bekomme ich das wieder los? Die 'Default Domain Policy' hat bei uns lediglich die Sicherheitseinstellungen ('Kontorichlinien/Kennwortrichtlinien', 'Kontorichtlinien/Kerberos-Richtlinie', 'Lokale Richtlinien/Zuweisen von Benutzerrechten' und 'Lokale Richtlinien/Sicherheitsoptionen') und eben diese blöden 2 Einträge 'am laufen'. Alles andere ist in diverse GPOs aufgeteilt. Kann ich die 'Default Domain Policy' löschen und leer neu anlegen (so wird es empfohlen bei dem Problem mit dem Wegfall von Einstellungen in den GPOs wie ich gerade lese) und dann meien Kennwortrichtlinien einfügen? Gibt es denn keine Möglichkeit irgendwo mit einem Editor die 2 Einträge zu entfernen? Das ganze aber sicher und sauber?
  12. Hallo Leute, ich habe hier ein kleines Problemchen: Wir sind von einer W2K3 auf eine W2K16 Domäne migriert und ich implementiere einige GPOs und checke ob ich alte GPOs und GPPs nun nicht mehr brauche und diese dann lösche. Ich lasse mir alle gesetzten Einträge in der 'Gruppenrichtlinienverwaltung -> Default Domain Policy -> Reiter 'Einstellungen' auflisten und öffne dann den Gruppenrichtlinienverwaltungs-Editor um Einstellungen zu ändern. Ich habe in der 'Default Domain Policy' (welche ja so 1:1 vom W2K3-DC übernommen wurde) 2 Einträge die ich so nicht mehr brauche und wollte diese dannauf 'Nicht konfiguriert' setzen. Das Problem dabei ist aber: in den Eisntellungen der Gruppenrichtlinienverwaltung stehen 2 Einträge die im Editor so bzw. gar nicht nicht vorzufinden sind! Wie kann das sein? Es geht konkret um 2 Einträge die unter dem Pfad "Benutzerkonfiguration / Richtlinien / Windows-Einstellungen / Internet Explorer-Wartung / Verbindung/Automatische Browserkonfiguration" vorzufinden sind und wie folgt aussehen: Automatische Ermittlung von Konfigurationseinstellungen -> Deaktiviert Automatische Browserkonfiguration -> Nicht konfiguriert Diese finde ich jedoch überhaupt nicht im Editor. Schon der Knotenpunkt 'Internet Explorer-Wartung' fehlt. a) wieso ist das so? b) was kann ich machen um die 2 Einträge wegzubekommen? Fragt mich bitte nicht wieso das da drinnen überhaupt aktiviert wurde. Der W2K3-Server ist noch von vor meiner Zeit hier in der Firma und wer weiß schon wer das warum damals so aktiviert hat? Ich jedenfalls nicht und will diese nur deaktivieren....
  13. Das verstehe ich leider nicht ganz. Worauf soll ich da genau achten? Ist es vielleicht das was du meinst: Die Templates sind Teil vom Server-OS. Dieses wird aktualisiert und eventuell landen neuere Templates in dem lokalen PolicyDefinitions-Ordner (durch den MS-Update) vom W2K16-Server. Um diese nutzten zu können sollte ich nach jedem Update den lokalen PolicyDefinitions-Ornder auf den SYSVOL kopieren damit dieser ebenfalls aktuell bleibt?
  14. Ok, habe den kompletten Ordner \Windows\PolicyDefinitions nach SYSVOL kopiert und siehe da, es klappt! Danke!
  15. Hallo Leute, da wir am letzten WE von W2K3 auf W2K16 migriert sind, möchte ich nun GPOs für unser Netzwerk nutzen (bisher waren wir mit LOGON.BAT unterwegs). Wie gewohnt öffne ich den GPEdit und kann mich durchklicken und alles Wünschenswerte einstellen. Jetzt möchte ich ein GPO-Template in Form von ADMX-Datei nutzen, und, nach kurzer Recherche, habe ich das Template auf der SYSVOL des DCs abgelegt, GPEdit neu geöffnet und siehe da, meine Templates sind unter den Administrativen Vorlagen gelistet. Was ja erst einmal super wäre WENN nicht dafür alle anderen Vorlagen verschwunden wären! Benne ich den Ordner 'policyDefinitions' nach z.B. 'policyDefinitionsORG' um, so verschwinden die neuen Vorlagen und die alten sind wieder da. Gibt es einen Weg damit ich beide habe? Ich habe auch Office-Templates die ich nutze, diese liegen aber in ADM-Format vor und kann diese in die Administratove Vorlagen 'hinzufügen'. Ich würde gerne beides haben und nicht immer mit dem Ordner umbenennen hin und her springen müssen (einmal erstellte GPOs brauchen den Vorlageordner nämlich nicht mehr und daher wäre das eine Notlösung. Aber das muss doch auch anders gehen, oder?). Gibt es also die Möglichkeit in der zentralen SysVol die benötigten ADMX-Dateien abzulegen und von dort aus zu nutzen UND die Standard-Vorlagen mit nutzen zu können?
  16. Haha, ich habe es mir schon gedacht.. aber bei so einem sc*** gehe ich lieber auf Nummer sicher...;) Das Computerkonto ist nicht deaktiviert. Der Server war anno 2004 als DC UND Fileserver installiert. Jetzt ist es noch ein Fileserver bis ich in den nächsten Wochen auch diesen auf einen W2K16 migriere. Somit bleibt das Konto des ehemaligen DCs ja noch in der AD. Und wenn es anders wäre: Computer-Objekte in der AD darf man ja auch manuell löschen wenn man sicher ist daß diese nicht mehr benötigt werden (nach einem Crash eines Gerätes was die saubere Entfernung aus der AD nicht mehr möglich macht).
  17. Gut das du das ansprichst. Bei Gott, ich möchte hier keinen BER-Flughafen später haben... daher ist VORSICHT angesagt... Ich mach das jetzt mit dem Löschen... ja?
  18. Und zu dem Thema mit dem Löschen des alten Servers in den Standorten? Einfach markieren und löschen? Ich mach da nichts kaputt? Es bleiben nirgends weitere Datenleichen übrig? Ich meine es hätte ja sein können man darf das auf gar keinen Fall und mann muss unbedingt Tool XY verwenden weil dieses alles richtig und sauber macht und der Gleichen.... Aber so gefällt mir das natürlich noch mehr: ich darf also einfach markieren und löschen? DNS ist so was von sauber. GC hat sich ausgetragen und der alte Server dürfte nirgends mehr berücksichtigt werden ausser das er noch eine Zeitlang ein Fileserver bleibt. Ich warte noch eine Antwort ab und dann löschei ch das Ding aus der Liste...
  19. Also an dieserStelle einfach markeiren und löschen? Und das war es? Es bleiben nirgends irgendwelcher Müll zurück oder der Gleichen? Die meisten bei denen es nicht funktioniert haben in der Tat schnelle Festplatten... Ich werde wohl eine GPO erstellen die das Anmelden vor der Konnektivität verhindern soll aber nur bei Desktop-PCs. Kannst du mir zufällig gleich sagen wo ich diesen Eintrag finde? Andernfalls suche ich selber geschwind danach.. Danke für den Hinweis.
  20. Hallo Leute, wir haben die Migration am WE durchgezogen. Gott sei Dank hat alles gut geklappt. An der Stelle des Demoten des alten DC-Servers habe ich an einer Stelle geschwind geschwitzt da ich, anders als bei meinen unzähligen Testläufen, die Zugangsdaten eingeben musste weil der alte Server die neue Domäne nicht gefunden hat und der Gleichen. Aber danach hat alles wunderbar geklappt. Naja, fast alles. Da wir übergangsweise noch auf eine 'LOGON.BAT' setzen (GPO ist bereits erstellt. Muss diese nur noch einbinden und dann testen und Abteilungsweise umsteigen), bekomme ich bei einigen PCs nach der Anmeldung keine Netzlaufwerke (die diese LOGON.BAT u.a. erstellt) und andere Dinge. Sprich: die LOGON.BAT wird nicht immer ausgeführt. Meist löst sich das Problem auf indem man sich einmal neu anmeldet (ab- und anmeldet, NICHT Neustartet). Ich vermute das die Anmeldung zu schnell nach dem Start ausgeführt wird so die Netzwerkschnittstelle noch nicht initialisiert wurde. Aber ok, das ist ein Problem das sich bald sowieso mit dem Umstieg auf GPO erledigt haben müsste. Was mich mehr wurmt ist folgendes: In den 'AD-Standorte und Dienste' habe ich unter 'Sites->First-Site-Name->Servers' noch den alten DC aufgelistet OBWOHL ich diesen 'demotet' habe und obwohl ich davor darauf geachtet habe den Globalten Katalog zu entfernen! (Das war eigentlich der Grund warum ich in meiner Vorgehensweise vor dem Demoten den Globalen Katalog entferne da ich in meiner Testumgebung dies damit geschafft habe den alten DC aus dieser Liste weg zu bekommen!). In meinem DNS-Server (übrigens: nach wie vor Bind auf Linux und scheint alles sauber vonstatten gegangen zu sein) ist der alte DC wie gewünscht automatisch verschwunden. Also hat das mit dem GC entfernen ja auch gut geklappt. Die Frage ist: Wieso zum Teufel ist der Server hier noch gelistet ('Active Directory - Standorte und Dienste'->'Sites'->'Default-First-Site-Name'->'Servers')?? Und die noch wichtigere Frage: wie bekomme ich ihn von hier sauber wieder weg? Nur löschen wäre sicherlich nicht sauber, oder?
  21. Haha, der war echt gut! ;) Ist ja nicht so das ich nur an diesem Projekt arbeite... und lernen kostet ja auch Zeit... ;) Das die FSMO-Rollen im laufenden Betrieb übertragen werden weiß ich ja. Habe es in der Testumgebung ja breits x-mal gemacht. ABER ich habe einfach ANGST das nicht doch irgendwas schief geht und dafür würde ich sehr sehr gerne eine Sicherung des Servers haben für den SUPER-GAU, das 'worst case scenario'. Und was meinst du mit 'Systemstates'? Was ist 'GC'?
  22. Hallo Leute, gutes neues Jahr wünsche ich euch erst einmal. Ich möchte meine DC-Migration an einem der folgenden WE angehen. Ich bin mir mittlerweile sicher daß wenn alle DCs heruntergefahren sind es keine Probleme mit USN-Rollback oder der Gleichen geben kann wenn ich den alten Server (der mit allen FSMO-Rollen) mit einem offline-Tool wie Acronis oder Ghost sichere (imagen). Da kann es ja keine Datenabweichungen in der Datenbank geben da kein DC online ist. Daher mache ich das am WE wenn das ganze Netzwerk nicht benutzt wird und die DCs heruntergefahren werden können (ich habe seit neustem einen neuen DC und eben den alten als Rolleninhaber -> der neue wird nur heruntergefahren, der alte heruntergefahren und gesichert). Was ich mir noch Bestätigen lassen wollte ist die Reihenfolge die ich mir so vorgenommen habe: 1. 2. DC herunterfahren (neuer DC mit W2K16) 2. 1. DC herunterfahren (alter DC mit W2K3) 3. Von beiden BIND9-DNS-Server (UBUTNU) Snapshot erstellen (Master & Slave DNS Server) und sicherheitshalber die Zonendateien sichern 4. 1. DC sichern mit Acronis oder Ghost (Image erstellen auf externen Datenträger) 5. 2. DC Sichern mit Snapshot (läuft auf VMWare als vrituelle Maschine) 5. beide DCs wieder starten 6. FSMO-Rollen übertragen (NTDSUTIL -> Roles -> Connection -> Connect to Server 2.DC -> zurück zu Roles -> transfer der Rollen (Domain Naming Master (heisst bei W2K3 noch so statt nur Naming Master), Schema Master, RID Master, PDC und Infrastructure Master) 7. alten DC herunterfahren und prüfen ob Domain funktioniert (z.B. Client-PC in Domäne aufnehmen & entfernen UND/ODER neuen User anlegen und mit diesem anmelden) 8. alten DC wieder starten 9. Globalen Katalog auf dem alten DC deaktivieren 10. alten DC nun demoten (da bin ich mir nun nicht sicher ob man 'dcpromo.exe' eingeben soll (da ja noch alter W2K3-Server) oder man über 'Rolle deaktivieren' im Servermanager gehen muss?) 11. Testen ob Domäne noch funktioniert. 11.1 Domäne funktioniert: super! Ich muss dann nur noch die Domänen- und Gesamtstrukturfunktionsebene auf das höchst-mögliche heraufstufen (W2K16) und alles prima. 11.2 Nachtrag: SYSVOL-Migration bzw. FRS (File Replication Service) nach DFSR (Distributed File System Replication) migrieren 11.3 Domäne funktioniert nicht: 11.3.1 alten ehemaligen DC1 und DC2 herunterfahren 11.3.2 beide restoren (alter DC vom Image restoren, neuen DC per Snapshot wiederherstellen 11.3.3 DNS-Server restoren (ebenfalls vom Snapshot) Nochmals zu euren Bedenken: Wie ich das verstanden habe können USN-Rollback-Probleme mich doch gar nicht treffen wenn ich sicherstelle das meine Domäne komplett heruntergefahren wurde und ich die Dinger ausschliesslich offline sichere und zwar ohne zwischen drinnen einen der Server wieder zu starten. Beide Server heruntergefahren haben den gleichen Stand von dem gleichen Zeitpunkt. Wenn man das jetzt sichert gibt es keine Diskrepanzen... Ist meine ToDo-Liste so plausibel? Habe ich womöglich noch irgendwo was vergessen? Ich habe die Migration in meiner Testumgebung schon x-mal durchgespielt (nur das ich immer von W2K16 auf W2K16 migriert bin statt von W2K3 auf W2K16 (bis auf das erste mal vor paar Monaten)) und meine Testdomäne funktioniert nach wie vor.... Ich bin mir nur an einer stelle nicht mehr sicher ob dcprmo.exe oder über den Servermanager der W2K3-DC demotet wird.
  23. Das ist aber immer nötig wenn die Leute unterhalb dem Share nur ihre Ordner sehen sollen. Da der Share mit 'Domänen-Admin' - > 'Lesen' ausgestattet ist, muss hier die Vererbung unterbrochen werden und 'Domänen-Admins' entfernt. Denn ab hier sind die einzelnen Unterordner in dieser Ebene nur explizit für die entsprechenden AD-Gruppen freigegeben was ändern aber auch lesen angeht. Also habe ich das hier schon richtig verstanden gehabt? Share (Dom-User 'lesen') -> T3 (Unterordner des Team 3 -> Dom-User entfernen & T3 (AD-Gruppe) hinzufügen und auf 'ändern' setzen) Share (Dom-User 'lesen') -> T301 (Unterordner des Team 301 -> Dom-User entfernen & T301 (AD-Gruppe) hinzufügen und auf 'ändern' setzen) usw..
  24. @MurdocX Habe ich das dann so richtig verstanden: 1. Erweiterte Freigabe sollen 'Authentifizierte Benutzer' das Recht 'Ändern' bekommen. 2. NTFS sollen 'Authentifizierte Benutzer' das Recht 'Lesen' bekommen. 3. In allen Unterordnern soll dann 'Authentifizierter Benutzer' entfernt werden und hier greifen dann nur noch die explizit gesetzten Berechtigungen. Somit können alle User in die Share erst mal lesend 'reinspringen' und in jeglichen Unterordnern dann je nachdem was gesetzt wurde explizit für die Gruppen. ABER: das heisst jedoch daß ich tatsächlich die Vererbung an dieser Stelle für jegliche Unterordner (also direkt in der Share-Ebene) deaktivieren müsste (Kopieren der Berechtigungen statt zu löschen und dann 'Authentifizierte Benutzer' entfernen). Ist das richtig so? Denn genauso habei ch es verstanden und auch in meiner Testumgebung umgesetzt. Scheint gut zu funktionieren. Ich war mir lediglich nicht sicher weil ich die Vererbung da unterbrechen musste und Berechtigung entfernen musste für jeden Einzelnen Ordner in dieser Ebene.
×
×
  • Create New...