48
SBS2003 Migrieren auf MS W2K16 DC - ohne SBS nicht lauffähig!
Hallo Leute,
ich habe da mal wieder ein Problem:
Ich habe die Aufgabe bekommen von unserem kleinen Tochterunternehmen die IT (kurzzeitig) zu übernehmen und die Migration von SBS2003 auf MS Windows 2016 als DC zu machen (SBS wird abgeschaltet).
So, da ich erst kürzlich eine Migration von einer Domäne mit einem DC mit W2K3 auf 2 DC mit W2K16 erfolgreich durchgeführt habe, dachte ich: cool, wird ein Kinderspiel..
Denkste!
Ich habe folgendes gemacht:
Ich habe einen virtuellen W2K16 erstellt und ihm die AD DC Rolle installiert.
Ich habe ihn zum weiteren DC in der aktuellen Domäne hinzugefügt und dann die FSMO-Rollen übertragen. Auf dem neuen DC konnte ich auch Benutzer einsehen und auch anlegen (sind nur nicht gleich strukturiert wie in einer 'normalen' Domäne sonden unter User -> MyBusiness -> usw. statt alle User in Root.. aber ok, kann man rüberschieben...).
Hat also alles augenscheinlich geklappt.
DANN aber habe ich den SBS heruntergefahren und siehe da: gar nichts mehr klappt. Im Netzwerk kann kein DC gefunden werden OBWOHL im DNS der neue DC korrekt eingetragen wurde bezüglich aller Netzwerkdienste (Stichwort: _msdcs).
Ich dachte zuerst irgendwas ist im DNS schiefgegangen. Ich traue auch dem alten DNS-Server im SBS nicht so recht über den Weg (haben ein par IT-'Versierte' im Unternehmen 'betrieben') und habe die DNS-Geschichte auf einen Bind9-Server transferiert (wie in unserem Unternehmen auch) um dort 'mehr kontrolle' über die Einträge zu haben (ich kenne mich nunmal besser mit dem Bind9 als DNS aus).
Ein weiterer Anlauf hat aber wieder nichts gebracht. Ohne SBS läuft die Domäne nicht. Habe FSMO-Rollen wieder zurückübertragen da er mir nach 2 Tagen angefangen hat grundlos sich auszuschalten (nach einer Recherche passiert das bei einem SBS aber erst nach 3 Wochen und nicht 2 Tagen aber ok).
Habe mich auf die Recherche begegeben und finde unterschiedliche Informationen, auch hier bei Administrator.de. Die Einen sagen SBS Migration auf eine 'normale' Domäne ist anders als 'normale' Domäne auf neuere 'normale' Domäne. Die Anderen sagen dies wäre gleich (was ich eben so nicht bestätigen kann).
Bevor mir jemand sagt dein DNS-Server ist fehlerhaft: dem sei gesagt das zumindest das Tool 'dnslint' widerspricht. Dieses zeigt alles grün an. Mit SBS läuft ja auch alles korrekt.
So, kann mir jemand sagen inwieweit sich die Migration eines SBS auf 'normalen' DC unterscheidet zu dem 'normalen' DC auf 'normalen' DC?
Gibt es dafür irgendwo Anleitungen, HowTos, Schritt-für-Schritt-Anleitungen die mich durch dieses Problem navigieren können?
Ich muss auch sagen das ich bisher noch NIE mit einem SBS in Berührung kam. Sah auf ersten Blick eben aus wie unser alter DC W2K3 und da dachte ich daß ich damit klar komme...
Ich bedanke mich schon einmal im Voraus für eure Hilfe oder zumindest für das Lesen bis hierhin.
ich habe da mal wieder ein Problem:
Ich habe die Aufgabe bekommen von unserem kleinen Tochterunternehmen die IT (kurzzeitig) zu übernehmen und die Migration von SBS2003 auf MS Windows 2016 als DC zu machen (SBS wird abgeschaltet).
So, da ich erst kürzlich eine Migration von einer Domäne mit einem DC mit W2K3 auf 2 DC mit W2K16 erfolgreich durchgeführt habe, dachte ich: cool, wird ein Kinderspiel..
Denkste!
Ich habe folgendes gemacht:
Ich habe einen virtuellen W2K16 erstellt und ihm die AD DC Rolle installiert.
Ich habe ihn zum weiteren DC in der aktuellen Domäne hinzugefügt und dann die FSMO-Rollen übertragen. Auf dem neuen DC konnte ich auch Benutzer einsehen und auch anlegen (sind nur nicht gleich strukturiert wie in einer 'normalen' Domäne sonden unter User -> MyBusiness -> usw. statt alle User in Root.. aber ok, kann man rüberschieben...).
Hat also alles augenscheinlich geklappt.
DANN aber habe ich den SBS heruntergefahren und siehe da: gar nichts mehr klappt. Im Netzwerk kann kein DC gefunden werden OBWOHL im DNS der neue DC korrekt eingetragen wurde bezüglich aller Netzwerkdienste (Stichwort: _msdcs).
Ich dachte zuerst irgendwas ist im DNS schiefgegangen. Ich traue auch dem alten DNS-Server im SBS nicht so recht über den Weg (haben ein par IT-'Versierte' im Unternehmen 'betrieben') und habe die DNS-Geschichte auf einen Bind9-Server transferiert (wie in unserem Unternehmen auch) um dort 'mehr kontrolle' über die Einträge zu haben (ich kenne mich nunmal besser mit dem Bind9 als DNS aus).
Ein weiterer Anlauf hat aber wieder nichts gebracht. Ohne SBS läuft die Domäne nicht. Habe FSMO-Rollen wieder zurückübertragen da er mir nach 2 Tagen angefangen hat grundlos sich auszuschalten (nach einer Recherche passiert das bei einem SBS aber erst nach 3 Wochen und nicht 2 Tagen aber ok).
Habe mich auf die Recherche begegeben und finde unterschiedliche Informationen, auch hier bei Administrator.de. Die Einen sagen SBS Migration auf eine 'normale' Domäne ist anders als 'normale' Domäne auf neuere 'normale' Domäne. Die Anderen sagen dies wäre gleich (was ich eben so nicht bestätigen kann).
Bevor mir jemand sagt dein DNS-Server ist fehlerhaft: dem sei gesagt das zumindest das Tool 'dnslint' widerspricht. Dieses zeigt alles grün an. Mit SBS läuft ja auch alles korrekt.
So, kann mir jemand sagen inwieweit sich die Migration eines SBS auf 'normalen' DC unterscheidet zu dem 'normalen' DC auf 'normalen' DC?
Gibt es dafür irgendwo Anleitungen, HowTos, Schritt-für-Schritt-Anleitungen die mich durch dieses Problem navigieren können?
Ich muss auch sagen das ich bisher noch NIE mit einem SBS in Berührung kam. Sah auf ersten Blick eben aus wie unser alter DC W2K3 und da dachte ich daß ich damit klar komme...
Ich bedanke mich schon einmal im Voraus für eure Hilfe oder zumindest für das Lesen bis hierhin.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 563394
Url: https://administrator.de/contentid/563394
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
48 Kommentare
Neuester Kommentar
moin...
fangen wir mal klein an, und schiebe den DNS auf den 2k16!
und dann schau doch mal im ereignisprotokoll nach den fehlern und berichte...
Frank
fangen wir mal klein an, und schiebe den DNS auf den 2k16!
und dann schau doch mal im ereignisprotokoll nach den fehlern und berichte...
Frank
Du scheinst mit dem oder den Projekten wie die Jungfrau zum Kunde zu kommen.
Wenn nach dem Abschalten nichts mehr klappt muss das nicht der DNS sein, aber nichts geht mehr ist wohl auch sehr..naja sowas hören wir von unseren Endbenutzern als Fehlermeldung.
Also entweder konkrete Fehlermeldungen oder eure Admins hin zu ziehen.
Christian
certifiedit.net
Wenn nach dem Abschalten nichts mehr klappt muss das nicht der DNS sein, aber nichts geht mehr ist wohl auch sehr..naja sowas hören wir von unseren Endbenutzern als Fehlermeldung.
Also entweder konkrete Fehlermeldungen oder eure Admins hin zu ziehen.
Christian
certifiedit.net
Hallo
Würd ich auch mal als erstes sagen.
In einer Windows Domain braucht vor allem der DC mehr Kontrolle über den DNS und nicht du.
Würd ich auch mal als erstes sagen.
In einer Windows Domain braucht vor allem der DC mehr Kontrolle über den DNS und nicht du.
Kennen die Clients alle den neuen DNS-Server und nutzen diesen als primären DNS-Server? Ist eventuell auf dem SBS noch eine DHCP-Rolle aktiv, die du vergessen und/oder nicht angepasst hast?
Wie @tikayevent schon sagt, DHCP-Server war dringende Empfehlung beim SBS bzw. sogar erforderlich, da Du die Rolle nicht erwähnt hast, wird sie jetzt fehlen.
HG
Mark
HG
Mark
Ist aber beim alten System vermutlich fehlt was ganz anderes beim neuen. Ansonsten ggf. Neu aufstellen? Aber müsste man sich wohl am system Anschauen
Servus,
perönlich würde ich von einer Migration Abstand nehmen. Insbesondere wenn es sich um ein SBS Produkt handelt.
Ich habe auch mal versucht einen SBS2008 zu migrieren, im Endeffekt war mir nach diversen Problemen die Zeit (für diesen Rotz) zu schade und ich habe die Domäne (ws2019) inkl. 30 User und einer leckeren RBAC neu nach BP erstellt.
Beste Entscheidung ever.
perönlich würde ich von einer Migration Abstand nehmen. Insbesondere wenn es sich um ein SBS Produkt handelt.
Ich habe auch mal versucht einen SBS2008 zu migrieren, im Endeffekt war mir nach diversen Problemen die Zeit (für diesen Rotz) zu schade und ich habe die Domäne (ws2019) inkl. 30 User und einer leckeren RBAC neu nach BP erstellt.
Beste Entscheidung ever.
Hallo,
bei einem Kunden habe ich mal per Gruppenrichtlinie verteilte Firewallregeln gefunden, die DNS nur in Richtung DC erlauben.
Sprich: Es kann alles Mögliche sein.
Gruß,
Jörg
bei einem Kunden habe ich mal per Gruppenrichtlinie verteilte Firewallregeln gefunden, die DNS nur in Richtung DC erlauben.
Sprich: Es kann alles Mögliche sein.
Gruß,
Jörg
Äh, ich bin ein wenig irritiert. Das Domänen und Gesamtstruktur Funktionslevel eines 2003 Servers unterstützt doch gar keine 2016 als Betriebssystem für einen DC?! Hast du das hochgestuft und wenn ja auf welches Level?
SBS Migration habe ich schon mehrfach hinter mir, bisher habe ich den SBS mind. 3 Tage nebenher laufen lassen um sicherzugehen das auch wirklich alle Funktionen korrekt repliziert worden sind. Mit dem oben genannten Punkt und unter Beachtung der Kompatibilität der Funktionslevel hatte ich nie große Probleme.
Der SBS schaltet sich nicht grundlos ab, sobald du die FSMO Rollen überträgst startet die sogenannte Grace Period. Wenn diese abläuft geht der SBS in einen Neustart Loop über bis er aus der Domäne entfernt wurde oder die FSMO Rollen wieder bekommt. Hast du den SBS mit DCPROMO aus der Domäne entfernt?
SBS Migration habe ich schon mehrfach hinter mir, bisher habe ich den SBS mind. 3 Tage nebenher laufen lassen um sicherzugehen das auch wirklich alle Funktionen korrekt repliziert worden sind. Mit dem oben genannten Punkt und unter Beachtung der Kompatibilität der Funktionslevel hatte ich nie große Probleme.
Der SBS schaltet sich nicht grundlos ab, sobald du die FSMO Rollen überträgst startet die sogenannte Grace Period. Wenn diese abläuft geht der SBS in einen Neustart Loop über bis er aus der Domäne entfernt wurde oder die FSMO Rollen wieder bekommt. Hast du den SBS mit DCPROMO aus der Domäne entfernt?
Ich habe bisher mit vielen daneren Problemen gekämpft und widme mich wieder diesem Thema. Sorry für den Verzug. Der Chefe entscheidet über die Prios und dehr..
Ok, zurück zu diesme Thema das jetzt wieder Priorität 1 hat.
Ich habe den DNS auf dem W2K16 gleich wieder installiert und aktiviert gehabt. Hat sich auch replziert udn sieht aus wie der DNS auf dem SBS.
Ich habe ZUSÄTZLICH auch einen Slave-DNS-Server (BIND9 Linux) aufgesetzt nur so zur sicherheit. Ist ja auch nur ein Slave und repliziert somit nur in eine Richtung (vom SBS auf diesen).
Ich habe das Ereignisprotokoll jetzt noch nicht angeschaut. Fakt ist aber: fahre ich den SBS herunter, kann sich im Netzwerk niemand anmelden ausser seine Credentials sind lokal auf den Workstations gespeichert.
Auch das Hinzufügen eines neuen Clients in die Domäne funktioniert nicht wenn der SBS down ist. Der neue DC ist im Netz vorhanden, kann auch AD verwalten WENN SBS online ist (ansonsten funktioniert auch das nicht) aber das war es auch schon. Als ob er gar nicht da wäre -> es funktioniert nichts bezüglich Domäne.
Ok, zurück zu diesme Thema das jetzt wieder Priorität 1 hat.
Ich habe den DNS auf dem W2K16 gleich wieder installiert und aktiviert gehabt. Hat sich auch replziert udn sieht aus wie der DNS auf dem SBS.
Ich habe ZUSÄTZLICH auch einen Slave-DNS-Server (BIND9 Linux) aufgesetzt nur so zur sicherheit. Ist ja auch nur ein Slave und repliziert somit nur in eine Richtung (vom SBS auf diesen).
Ich habe das Ereignisprotokoll jetzt noch nicht angeschaut. Fakt ist aber: fahre ich den SBS herunter, kann sich im Netzwerk niemand anmelden ausser seine Credentials sind lokal auf den Workstations gespeichert.
Auch das Hinzufügen eines neuen Clients in die Domäne funktioniert nicht wenn der SBS down ist. Der neue DC ist im Netz vorhanden, kann auch AD verwalten WENN SBS online ist (ansonsten funktioniert auch das nicht) aber das war es auch schon. Als ob er gar nicht da wäre -> es funktioniert nichts bezüglich Domäne.
Hallo,
ich denke die Fehlermeldung sagt ja schon alles da es ja nicht konkret um eine Sache handelt die in den Domänendiensten nicht funktionieren sondern alle.
Wenn der SBS down ist und der 'neue DC' mit W2K16 als Sekundärer DC online, dann sollte die Domäne funktionieren wie gewohnt.
Sprich: Anmeldungen, Benutzer und Computerverwaltung, Clients neu hinzufügen, Benutzer neu hinzufügen usw..
Bei mir ist der Fall aber so: Ist der SBS down und der neue DC up funktioniert einfach gar nichts von den o.g. Dingen.
User können sich nicht mehr anmelden an Clients (an denen sie zuvor nie angemeldet waren -> lokal gespeicherte Credentials sind also nicht vorhanden), Computer können nicht in die Domäne hinzugefügt werden (aus der Systemsteuerung des Clients heraus) und die AD Verwaltung ("Benutzer und Computer AD Verwaltung" aber auch alle anderen auch) kann nicht einmal gestartet werden da eine Fehlermeldung kommt daß der AD-Server nicht vorhanden wäre (und das auf dem DC selber!).
Also was soll ich dazu sagen als 'nichts funktioniert mehr'? Ok, da gehe ich davon aus das jeder versteht das damit die Domänendienste gemeint sind.
ich denke die Fehlermeldung sagt ja schon alles da es ja nicht konkret um eine Sache handelt die in den Domänendiensten nicht funktionieren sondern alle.
Wenn der SBS down ist und der 'neue DC' mit W2K16 als Sekundärer DC online, dann sollte die Domäne funktionieren wie gewohnt.
Sprich: Anmeldungen, Benutzer und Computerverwaltung, Clients neu hinzufügen, Benutzer neu hinzufügen usw..
Bei mir ist der Fall aber so: Ist der SBS down und der neue DC up funktioniert einfach gar nichts von den o.g. Dingen.
User können sich nicht mehr anmelden an Clients (an denen sie zuvor nie angemeldet waren -> lokal gespeicherte Credentials sind also nicht vorhanden), Computer können nicht in die Domäne hinzugefügt werden (aus der Systemsteuerung des Clients heraus) und die AD Verwaltung ("Benutzer und Computer AD Verwaltung" aber auch alle anderen auch) kann nicht einmal gestartet werden da eine Fehlermeldung kommt daß der AD-Server nicht vorhanden wäre (und das auf dem DC selber!).
Also was soll ich dazu sagen als 'nichts funktioniert mehr'? Ok, da gehe ich davon aus das jeder versteht das damit die Domänendienste gemeint sind.
In unserer Hauptfirma (und da bin ich in der IT) betreiben wir auch ausschliesslich BIND9-DNS-Server (Master & Slave).
Funktioniert seit Jahren schon einwandfrei und ich habe da auch irgendwie eine bessere Übersicht über alles. Die DC haben keine integrierte DNS-Rolle mehr und fungieren auch nicht als Master-DNS für die BIND9-Server so daß die Einträge dann lediglich übertragen werden sondern sind tatsächlich selber die Master / SOA (jedenfalls der Master-DNS. Der Slave-DNS ist lediglich angebunden und dient als Ausfallserver wenn der erste gewartet wird o.ä. Funktioniert einwandfrei und die Domänen-Dienste sind auch korrekt enthalten.
Da ich vermutet hatte das der DNS-Server falsch betrieben wurde von dem 'User der sich als Admin versucht hat', wollte ich einfach sichergehen und daher einen eigenen separaten DNS-server zu betreiben. Das wird auch das langfristige Ziel sein DNS auf Bind9 zu betreiben.
Funktioniert seit Jahren schon einwandfrei und ich habe da auch irgendwie eine bessere Übersicht über alles. Die DC haben keine integrierte DNS-Rolle mehr und fungieren auch nicht als Master-DNS für die BIND9-Server so daß die Einträge dann lediglich übertragen werden sondern sind tatsächlich selber die Master / SOA (jedenfalls der Master-DNS. Der Slave-DNS ist lediglich angebunden und dient als Ausfallserver wenn der erste gewartet wird o.ä. Funktioniert einwandfrei und die Domänen-Dienste sind auch korrekt enthalten.
Da ich vermutet hatte das der DNS-Server falsch betrieben wurde von dem 'User der sich als Admin versucht hat', wollte ich einfach sichergehen und daher einen eigenen separaten DNS-server zu betreiben. Das wird auch das langfristige Ziel sein DNS auf Bind9 zu betreiben.
Zitat von @tikayevent:
Kennen die Clients alle den neuen DNS-Server und nutzen diesen als primären DNS-Server? Ist eventuell auf dem SBS noch eine DHCP-Rolle aktiv, die du vergessen und/oder nicht angepasst hast?
Kennen die Clients alle den neuen DNS-Server und nutzen diesen als primären DNS-Server? Ist eventuell auf dem SBS noch eine DHCP-Rolle aktiv, die du vergessen und/oder nicht angepasst hast?
Alle werden den sicher nicht kennen da bei der Firma alles so schlimm aufgesetzt ist das ein Teil fixe IPs hat, ein anderer bekommt sie per DHCP usw..
Aber bei meinem Test hatten alle Beteiligten die Info des aktiven DNS-Servers. Ich habe diesen manuell gesetzt gehabt.
Übrigens: Mittlerweile habe ich DHCP auch erfolgreich auf eine Linux-Server-Maschine migriert. ISC-DHCP-Server der das Netzwerk nun korrekt mit allem versorgt. Wir haben auch einen großteil der Clients nun manuell auf DHCP gesetzt und alles funktioniert prima. Somit sollten die Clients nun schnell mit neuen DNS-Servern versorgt werden sobald wir irgendwas umstellen.
Zitat von @broecker:
Wie @tikayevent schon sagt, DHCP-Server war dringende Empfehlung beim SBS bzw. sogar erforderlich, da Du die Rolle nicht erwähnt hast, wird sie jetzt fehlen.
HG
Mark
Wie @tikayevent schon sagt, DHCP-Server war dringende Empfehlung beim SBS bzw. sogar erforderlich, da Du die Rolle nicht erwähnt hast, wird sie jetzt fehlen.
HG
Mark
Der DHCP ist auf einem Bind9-Linux-Server und der DHCP-Dienst des SBS deaktivert. Das war das Erste was ich ausgeführt habe.
Ok, da werde ich mal nachschauen. Danke für en Tipp.
Auch wenn ich selber Denke das der User/Administrator von GPO keinen Gebraucht gemacht hat.
Auch wenn ich selber Denke das der User/Administrator von GPO keinen Gebraucht gemacht hat.
Zitat von @Komabaer:
Äh, ich bin ein wenig irritiert. Das Domänen und Gesamtstruktur Funktionslevel eines 2003 Servers unterstützt doch gar keine 2016 als Betriebssystem für einen DC?! Hast du das hochgestuft und wenn ja auf welches Level?
Äh, ich bin ein wenig irritiert. Das Domänen und Gesamtstruktur Funktionslevel eines 2003 Servers unterstützt doch gar keine 2016 als Betriebssystem für einen DC?! Hast du das hochgestuft und wenn ja auf welches Level?
SBS lief auf dem Funktionslevel 2000 auf der Domänen- und Gesamtstruktur. Ich habe beides auf 2003 hochgestuft und dann den neuen DC hinzugefügt. Das Level weiter hochsetzen geht nicht solange der SBS 2003 als DC vorhanden ist.
SBS Migration habe ich schon mehrfach hinter mir, bisher habe ich den SBS mind. 3 Tage nebenher laufen lassen um sicherzugehen das auch wirklich alle Funktionen korrekt repliziert worden sind. Mit dem oben genannten Punkt und unter Beachtung der Kompatibilität der Funktionslevel hatte ich nie große Probleme.
Ich glaube es nicht.
Der SBS schaltet sich nicht grundlos ab, sobald du die FSMO Rollen überträgst startet die sogenannte Grace Period. Wenn diese abläuft geht der SBS in einen Neustart Loop über bis er aus der Domäne entfernt wurde oder die FSMO Rollen wieder bekommt. Hast du den SBS mit DCPROMO aus der Domäne entfernt?
Wie irgendwo bereits berichtet: ich habe die FSMO-Rollen mitterweile wieder zurück transferiert. Das mit der Graceperiod habe ich nicht gewusst (ist mein erster SBS von dem ich migriere) Aber irgendwo stand daß die Periode 3 Woche ist und nicht ein paar Stunden. Aber seit ich die FSMO zurückübertragen habe läuft alles wieder.. Somit ist das erstmal safe...
SBS wurde nicht demotet: Das mache ich als aller aller letzten Schritt nachdem sichergestellt wurde daß der neue DC vollumfänglich funktioniert und Herr über der Domäne ist.
Hallo,
mal ins Blaue geschossen. Der Globale Katalog vom Active Directory?
Eine Windows Domain nur mit nem Linux DNS zu betreiben find ich trotzdem als Riesen Rotz.
mal ins Blaue geschossen. Der Globale Katalog vom Active Directory?
Eine Windows Domain nur mit nem Linux DNS zu betreiben find ich trotzdem als Riesen Rotz.
Zitat von @wiesi200:
Hallo,
mal ins Blaue geschossen. Der Globale Katalog vom Active Directory?
Eine Windows Domain nur mit nem Linux DNS zu betreiben find ich trotzdem als Riesen Rotz.
Hallo,
mal ins Blaue geschossen. Der Globale Katalog vom Active Directory?
Eine Windows Domain nur mit nem Linux DNS zu betreiben find ich trotzdem als Riesen Rotz.
Ich denke ich habe den Fehler gefunden. Zumindest ist es ein schwerwiegender Fehler und wahrscheinlich hat dieser auch die misslungene Migration verursacht:
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis.
Ich habe alles nun erfolgreich Rückgängig gemacht und werde jetzt versuchen das SYSVOL-Verzeichnis zu reparieren.
Ich muss jetzt aber erstmal suchen nach Anleitungen oder jemand beantwortet es mir ja gleich hier? Wenn nicht kann ich auch ein neues Thema diesbezüglich aufmachen..
Aber was ich noch dazu sagen wollte ist bezogen auf Linux-Basierenden DNS:
ich würde es nie wieder anders haben wollen. Ich kann nach herzenslust suchen, ändern, manipulieren usw.. Ich habe alles viel besser im Griff und kann auch ausserhalb der GUI-Schranken Dinge setzen. Aber ok, das könnte alles Geschmackssache sein und vielleicht kann man auch in Windows in der DNS-GUI mehr machen als ich es momentan weiß (ich kenne mich da nur rudimentär aus).
ABER, und das war der Grund warum wir im Geschäft auf Linux umgestiegen sind, Lizenzierung und Zugriffsrechte!
Wir haben selbstverständlich genügend CALs für unsere MS2016 Server in der Firma (daher bleiben wir auch noch auf 2016 und gehen nicht auf 2019), aber eben nur unsere Geräte / Benutzer. Wir haben auch immer wieder größere Gruppen von Gästen die bei uns in der Firma sind und die dann mit ihren Smartphones, Notebooks und Tables ins Internet über unser Netzwerk gehen und da auch eine IP vom DHCP-Server zugewiesen bekommen. Und da diese rein rechtlich auch eine CAL benötigen müssten, haben wir das auf Linux umgesetzt und das Problem ist gelöst. Und das funktioniert auch schon seit vielen Jahren so und wir hatten niemals Probleme damit.
Auch das Sichern der IP-Leasing-Tabellen und auch der DNS-Tabellen gestaltet sich dort so einfach -> Text wegkopieren und ab damit aufs Band o.ä. Das ist alles nicht von der Hand zu weisen.
Also 1. rechtlich wegen fehlender CALS für x-beliebig viele 'Nicht-Firmen-User' und 2. wegen der einfacheren Handhabung ist das schon bombastisch mit dem BIND9 und ISC-DHCP-SERVER. Und wenn das im Verbund mit der Windows-Domäne alles klappt und jeder hält sich an die Norm -> warum nicht?
Hallo,
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
Zitat von @117471:
Hallo,
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
Stimmt, an den Spaß hab ich nicht mehr gedacht, hab das vor 3-4 Wochen auch erst umgesetzt.Hallo,
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
Zitat von @kaineanung:
Also 1. rechtlich wegen fehlender CALS für x-beliebig viele 'Nicht-Firmen-User' und 2. wegen der einfacheren Handhabung ist das schon bombastisch mit dem BIND9 und ISC-DHCP-SERVER. Und wenn das im Verbund mit der Windows-Domäne alles klappt und jeder hält sich an die Norm -> warum nicht?
Also 1. rechtlich wegen fehlender CALS für x-beliebig viele 'Nicht-Firmen-User' und 2. wegen der einfacheren Handhabung ist das schon bombastisch mit dem BIND9 und ISC-DHCP-SERVER. Und wenn das im Verbund mit der Windows-Domäne alles klappt und jeder hält sich an die Norm -> warum nicht?
Sei mir jetzt nicht böse aber da unterstell ich dir jetzt auch nen Fehler. "Nicht-Firmen-User" haben auch nichts im Firmennetz zu suchen. Wie eben der Name schon sagt.
Bei mir läuft das in extra V-Lan's (1x Gastnetzwerk, 1x Mitarbeiternetzwerker für Privatgeräte) sauber getrennt und hier wird auf Linux gesetzt.
Zitat von @wiesi200:
Sei mir jetzt nicht böse aber da unterstell ich dir jetzt auch nen Fehler. "Nicht-Firmen-User" haben auch nichts im Firmennetz zu suchen. Wie eben der Name schon sagt.
Bei mir läuft das in extra V-Lan's (1x Gastnetzwerk, 1x Mitarbeiternetzwerker für Privatgeräte) sauber getrennt und hier wird auf Linux gesetzt.
Zitat von @kaineanung:
Also 1. rechtlich wegen fehlender CALS für x-beliebig viele 'Nicht-Firmen-User' und 2. wegen der einfacheren Handhabung ist das schon bombastisch mit dem BIND9 und ISC-DHCP-SERVER. Und wenn das im Verbund mit der Windows-Domäne alles klappt und jeder hält sich an die Norm -> warum nicht?
Also 1. rechtlich wegen fehlender CALS für x-beliebig viele 'Nicht-Firmen-User' und 2. wegen der einfacheren Handhabung ist das schon bombastisch mit dem BIND9 und ISC-DHCP-SERVER. Und wenn das im Verbund mit der Windows-Domäne alles klappt und jeder hält sich an die Norm -> warum nicht?
Sei mir jetzt nicht böse aber da unterstell ich dir jetzt auch nen Fehler. "Nicht-Firmen-User" haben auch nichts im Firmennetz zu suchen. Wie eben der Name schon sagt.
Bei mir läuft das in extra V-Lan's (1x Gastnetzwerk, 1x Mitarbeiternetzwerker für Privatgeräte) sauber getrennt und hier wird auf Linux gesetzt.
Ja ok, das stimmt. Die externen Gäste die gar nicht zur Firma gehören, bekommen auch IPs vom separaten Gast-Netz (AP) und sind nicht im internen Netz.
Die Aussendienster, und wir haben weltweit viele davon, sind ab und an in der Firma, zu besondernen Terminen auch alle auf einmal (jährliche Startveranstaltung z.B.) und für die sparen wir uns einfach die CALs. Die sind im Firmennetz, greifen nicht auf die Fileserver zu oder sonstigen MS-Diensten und sind auch nicht Mitglied der Domäne, nutzen aber u.a. die Linux-basierende Workgroup-Server und bekommen IPs vom internen DHCP und nutzen auch den DNS. Somit wäre das rechtlich illegal ohne ausreichende CALs. (Mal davon abgesehen das mir die MS-Politik mit den CALs als reine Gelddruckmaschinerie einfach gegen den Stricht geht. Ich zahle gerne 700 EUR für MS Server OS. Auch zahle ich gerne 100 EUR für MS Desktop-OS, aber dann auch noch ein paar Tausend EURONEN alle ca. 4 Jahre für CALs geht einfach zu weit... daher springen wir auch relativ spät auf neue Server OS damit wir nicht jedesmal CALs neu kaufen müssen... und das ist viel bei 250 Usern x ca. 40 EUR pro CAL = 10.000 EUR!!!)
Wie gesagt: das ist ja auch nur der erste Schritt. Mir persöhnlich schwebt auch eine AD auf Samba-Basis vor was zum jetzigen Zeitpunkt aber noch ferne Zukunftsmusik ist.. MS will ich nicht missen, Desktops werden immer MS-OS haben bei mir. Aber im Server- und Netzwerktechnik-Bereich muss das ja nicht unbedingt sein. Ausserdem macht es mir ja auch Spass MS Desktops mit Linux-Servern zu kombinieren ;)
moin...
ist simpel....
Fehler 13568
frank
Ich denke ich habe den Fehler gefunden. Zumindest ist es ein schwerwiegender Fehler und wahrscheinlich hat dieser auch die misslungene Migration verursacht:
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
ist simpel....
Fehler 13568
frank
Zitat von @Vision2015:
moin...
ist simpel....
Fehler 13568
frank
moin...
Ich denke ich habe den Fehler gefunden. Zumindest ist es ein schwerwiegender Fehler und wahrscheinlich hat dieser auch die misslungene Migration verursacht:
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
ist simpel....
Fehler 13568
frank
Diese Vorgehensweise habei ch gestern ebenfalls so gefunden. Doch wird die bei mir ja nichts nutzen, oder?
Ich habe nur einen SBS-Server, also auch nur einen DC. Die im Link beschriebene Vorgehensweise setzt aber voraus das es einen DC im Netz gibt welcher eine funktionierende SYSVOL hat, oder habe ich das falsch verstanden gehabt?
Zitat von @117471:
Hallo,
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
Hallo,
evtl. mal die SYSVOL-Replikation von FRS auf DFS umstellen?
Gruß,
Jörg
Das würde ich gerne probieren. Mit einem Snapshot davor kann ja nichts schief gehen...
Meinst du das geht weil das SysVol ja defekt ist? Und wenn es geht, wird die DFS dann korrekt sein?
Mache ich das in der Server-Verwaltung oder?
moin...
also schubse alles auf den 2016er, ja auch den DNS etc... schiebe die rollen rüber, burflags wie beschrieben- und gut ist!
später kannst du ja deine Linux DNS gefummel machen...
Frank
Zitat von @kaineanung:
Diese Vorgehensweise habei ch gestern ebenfalls so gefunden. Doch wird die bei mir ja nichts nutzen, oder?
doch...Zitat von @Vision2015:
moin...
ist simpel....
Fehler 13568
frank
moin...
Ich denke ich habe den Fehler gefunden. Zumindest ist es ein schwerwiegender Fehler und wahrscheinlich hat dieser auch die misslungene Migration verursacht:
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis
ist simpel....
Fehler 13568
frank
Diese Vorgehensweise habei ch gestern ebenfalls so gefunden. Doch wird die bei mir ja nichts nutzen, oder?
Ich habe nur einen SBS-Server, also auch nur einen DC. Die im Link beschriebene Vorgehensweise setzt aber voraus das es einen DC im Netz gibt welcher eine funktionierende SYSVOL hat, oder habe ich das falsch verstanden gehabt?
sagtest du nicht, das du noch einen 2016er hast?also schubse alles auf den 2016er, ja auch den DNS etc... schiebe die rollen rüber, burflags wie beschrieben- und gut ist!
später kannst du ja deine Linux DNS gefummel machen...
Frank
Mist, den MS2016 DC habe ich gestern demotet und wieder sauber aus der Domäne genommen.
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
Wenn SYSVOL fehlerhaft ist, wird der SBS dann trotzdem die Logon-Batch-Dateien und die GPO-Ordner übertragen?
Wenn nein: Manuell kopieren?
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
Wenn das auch eine Mögliche Lösung wäre dann müsste ich nicht vorab nochmal migrieren... ist aber nur so eine Idee... ich migriere noch 100x wenn mich das weiterbringt vom SBS weg zu kommen...
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
Wenn SYSVOL fehlerhaft ist, wird der SBS dann trotzdem die Logon-Batch-Dateien und die GPO-Ordner übertragen?
Wenn nein: Manuell kopieren?
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
Wenn das auch eine Mögliche Lösung wäre dann müsste ich nicht vorab nochmal migrieren... ist aber nur so eine Idee... ich migriere noch 100x wenn mich das weiterbringt vom SBS weg zu kommen...
Schön, ändert aber nicht an der Tatsache.
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
moin..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
ja...
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
ja... nur ohne NETLOGON-Freigabe geht das nicht! und die domänenfunktionsebene muss mindestens server 2008 sein!
ein sagt dir mehr!
bessser wäre es erst auf 2012R2 zu gehen, dann die SYSVOL-Replikation auf DFSR umstellen, und weiter nach Server2016!
da würde ich aber gleich auf 2019 gehen...
einen umzug gleich auf 2003 -->2016 ist eigentlich unsauber, und nix für anfänger wie dich!
also mach einen umweg über 2012R2!
ich meine das nicht böse, aber was fummelst du in einer 250 User klitsche rum, an sachen die sicher laufen müssen? wenn du das AD in den sand setzt, merkst du es teilweise erst wenn es zu spät ist!°
das machen meine Azubis mitlerweile im schlaf...
wenn du magst, schreib mir eine PN, die helfen die dann mal eben... (natürlich kostenlos) ist nen job für nebenbei
kein problem...
Frank
Zitat von @kaineanung:
Mist, den MS2016 DC habe ich gestern demotet und wieder sauber aus der Domäne genommen.
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
ok...Mist, den MS2016 DC habe ich gestern demotet und wieder sauber aus der Domäne genommen.
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
Wenn SYSVOL fehlerhaft ist, wird der SBS dann trotzdem die Logon-Batch-Dateien und die GPO-Ordner übertragen?
Wenn nein: Manuell kopieren?
nein, dann BurFlags wie im link von mir anwenden!Wenn nein: Manuell kopieren?
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
ein
Get-ADDomainbessser wäre es erst auf 2012R2 zu gehen, dann die SYSVOL-Replikation auf DFSR umstellen, und weiter nach Server2016!
da würde ich aber gleich auf 2019 gehen...
einen umzug gleich auf 2003 -->2016 ist eigentlich unsauber, und nix für anfänger wie dich!
also mach einen umweg über 2012R2!
ich meine das nicht böse, aber was fummelst du in einer 250 User klitsche rum, an sachen die sicher laufen müssen? wenn du das AD in den sand setzt, merkst du es teilweise erst wenn es zu spät ist!°
das machen meine Azubis mitlerweile im schlaf...
wenn du magst, schreib mir eine PN, die helfen die dann mal eben... (natürlich kostenlos) ist nen job für nebenbei
Wenn das auch eine Mögliche Lösung wäre dann müsste ich nicht vorab nochmal migrieren... ist aber nur so eine Idee... ich migriere noch 100x wenn mich das weiterbringt vom SBS weg zu kommen...
kein problem...
Frank
moin...
das sehe ich auch so...
Frank
Zitat von @wiesi200:
Schön, ändert aber nicht an der Tatsache.
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
Schön, ändert aber nicht an der Tatsache.
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
das sehe ich auch so...
Frank
Zitat von @wiesi200:
Schön, ändert aber nicht an der Tatsache.
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
Schön, ändert aber nicht an der Tatsache.
<OT>
Sind nicht im AD, werden nicht zentral Verwaltet. Haben auf den Geräten dann vermutlich auch wenig bis keine Beschränkung. Somit gehören die nicht ins Firmennetz.
Seperates VLan. Wenn es den sein muss, dann rechte von dort aus nur auf den Linux Server.
Und da spielt es keine Rolle ob du ne Windows Domain verwaltet oder das unter Linux läuft.
Das sind dann unsichere Geräte.
Egal wie man sich die Situation schön redet.
Das hat nichts mit CALS zu tu.
</OT>
Wie gesagt: Zukunft würde ich mir wünschen alles was nur geht weg von MS auf Linux hin was Server angeht.
Alleine schon aufgrund der Gelddruckmasche mit den CALs.
Ein kleinen lustigen Grund habe ich auch noch: Ausserdem habe ich mir vor Jahren für mein Samsung TV eine Skype-Kamera gekauft und MS hat dann alle Skpes von allen TVs entfernen lassen.
Da hat meine Abneigung gegen MS-Politik so richtig begonnen... ;)
Zitat von @Vision2015:
moin..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
ja...
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
ja... nur ohne NETLOGON-Freigabe geht das nicht! und die domänenfunktionsebene muss mindestens server 2008 sein!
ein sagt dir mehr!
bessser wäre es erst auf 2012R2 zu gehen, dann die SYSVOL-Replikation auf DFSR umstellen, und weiter nach Server2016!
da würde ich aber gleich auf 2019 gehen...
einen umzug gleich auf 2003 -->2016 ist eigentlich unsauber, und nix für anfänger wie dich!
also mach einen umweg über 2012R2!
ich meine das nicht böse, aber was fummelst du in einer 250 User klitsche rum, an sachen die sicher laufen müssen? wenn du das AD in den sand setzt, merkst du es teilweise erst wenn es zu spät ist!°
das machen meine Azubis mitlerweile im schlaf...
wenn du magst, schreib mir eine PN, die helfen die dann mal eben... (natürlich kostenlos) ist nen job für nebenbei
kein problem...
Frank
moin..
Zitat von @kaineanung:
Mist, den MS2016 DC habe ich gestern demotet und wieder sauber aus der Domäne genommen.
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
ok...Mist, den MS2016 DC habe ich gestern demotet und wieder sauber aus der Domäne genommen.
Dieser DC war ja alleine nicht lauffähig (darum ja auch das Ganze) und da dachte ich ich stelle wieder den Ursprungszustand her.
DNS ist schon lange wieder auf dem SBS zurück (als AD integrierter DNS-Server) und Bind9 lediglich als Slave was ja dann gar keine Rolle spielt ob der da oder nicht da ist..
Also soll ich nochmals einen W2K16 als DC promoten, schauen ob alle SYSVOL-Inhalte übertragen wurden und dann o.g. Vorgehensweise ausführen?
Wenn SYSVOL fehlerhaft ist, wird der SBS dann trotzdem die Logon-Batch-Dateien und die GPO-Ordner übertragen?
Wenn nein: Manuell kopieren?
nein, dann BurFlags wie im link von mir anwenden!Wenn nein: Manuell kopieren?
Was ist mit dem Vorschlag die FRS auf DFS zu bringen was der Jörg bzw. @fa-jka vorgeschlagen hatte?
ein
Get-ADDomainbessser wäre es erst auf 2012R2 zu gehen, dann die SYSVOL-Replikation auf DFSR umstellen, und weiter nach Server2016!
da würde ich aber gleich auf 2019 gehen...
einen umzug gleich auf 2003 -->2016 ist eigentlich unsauber, und nix für anfänger wie dich!
also mach einen umweg über 2012R2!
ich meine das nicht böse, aber was fummelst du in einer 250 User klitsche rum, an sachen die sicher laufen müssen? wenn du das AD in den sand setzt, merkst du es teilweise erst wenn es zu spät ist!°
das machen meine Azubis mitlerweile im schlaf...
wenn du magst, schreib mir eine PN, die helfen die dann mal eben... (natürlich kostenlos) ist nen job für nebenbei
Wenn das auch eine Mögliche Lösung wäre dann müsste ich nicht vorab nochmal migrieren... ist aber nur so eine Idee... ich migriere noch 100x wenn mich das weiterbringt vom SBS weg zu kommen...
kein problem...
Frank
Nein, da hast du was falsch verstanden: WIR in der Hauptfirma, also da wo ich in der IT arbeite, haben 250 User. Dort hat die Migration, die ich im Alleingang erledigt habe von DC2003 auf DC2016 direkt und ohne Umwege wunderbar geklappt. Ich habe mich lange vorbereitet und getestet und getestet (habe mein eigenes Subnetz abgekoppelt vom Firmennetz für solche Tests) und gelesen und gelesen und euch und einem anderen Forum viele Fragen gestellt. Hat auf Anhieb geklappt und daß sogar mit DNS und DHCP ausschliesslich auf Linux-Basis.
Hier geht es um ein Tochterunternehmen mit viel weniger Usern und Clients. Nichts desto Trotz ist es wichtig das es auch hier gut über die Bühne gebracht wird.
Daher habe ich mir ja auch gedacht: pah, pipifax. Das wird laufen wie geschmiert... und daher habe ich ohne viel Vorbereitung und Lesen über die Besonderheiten einer SBS-Domäne einfach mal drauf 'losmigriert'.
Das ist schief gegangen und jetzt muss ich mich eben zusammenreissen...
Vielen Dank für das Angebot. Ich werde, wenn alle Strike reissen, sehr gerne darauf zurückgreifen und mit meinem Vorgesetzten darüber reden das dies eben nicht kostenlos sein darf. Ich würde mich aber riesig freuen wenn ich das selber überdie Bühne bringen könnte. Alleine schon wegen dem Prestige in der Firma ;)
Spaß bei Seite: alleine schon wegen dem neuen Wissen und der Erfahrung..
Wie gesagt: wenn alles reissen sollte dann sehr gerne!
Ich migriere auch gerne erstmal auf 2012. Muss ich ja nicht kaufen und die Evaluation-Version tut es sicherlich auch.
Ich frage mich aber wieso mir das was bringt? In der Hauptfirma hat es vom 'normalen' DC W2K3 auf W2K16 ja auch geklappt und ich habe danach auf DFSR umgestellt mit diesen 4 Schritten mit der "dfsrmig SetGlobal State".
Ich bin gerade dabei nochmals einen 2. DC in die Domäne des SBS2003 hinzu zu fügen.
Dabei sagt mir die Voraussetzungsprüfung u.a. das der FRS veraltet ist und ich auf DFS migrieren sollte mit dem DFSRMIG und das ich möglicherweise in Zukunft kein DC hinzufügen werden kann der eine zukünftige Windows Server Version haben wird.
So, ist das der Grund warum ich vielleicht erst auf 2012 R2 migrieren sollte und dann erst auf 2016 nachdem ich dort auf DFSR migriert habe?
Die Voraussetzungsprüfung würde mich jedenfalls auch jetzt, trotz der Warnung, den Vorgang machen lassen.
Ist das vielleicht auch der Grund warum mir die Ereignisanzeige Fehler bei der FSR gemeldet hat?
Kennt SBS 2003 kein DFSR so daß ich bereits vor dem hinzufügen des W2k16 DC zu DFSR migrieren könnte falls doch?
Dabei sagt mir die Voraussetzungsprüfung u.a. das der FRS veraltet ist und ich auf DFS migrieren sollte mit dem DFSRMIG und das ich möglicherweise in Zukunft kein DC hinzufügen werden kann der eine zukünftige Windows Server Version haben wird.
So, ist das der Grund warum ich vielleicht erst auf 2012 R2 migrieren sollte und dann erst auf 2016 nachdem ich dort auf DFSR migriert habe?
Die Voraussetzungsprüfung würde mich jedenfalls auch jetzt, trotz der Warnung, den Vorgang machen lassen.
Ist das vielleicht auch der Grund warum mir die Ereignisanzeige Fehler bei der FSR gemeldet hat?
Kennt SBS 2003 kein DFSR so daß ich bereits vor dem hinzufügen des W2k16 DC zu DFSR migrieren könnte falls doch?
moin...
So, ist das der Grund warum ich vielleicht erst auf 2012 R2 migrieren sollte und dann erst auf 2016 nachdem ich dort auf DFSR migriert habe?
jo... wie ich geschrieben habe... besser ist das
also mach es so, wie es weiter oben geschrieben habe...
Frank
Zitat von @kaineanung:
Ich bin gerade dabei nochmals einen 2. DC in die Domäne des SBS2003 hinzu zu fügen.
fein..Ich bin gerade dabei nochmals einen 2. DC in die Domäne des SBS2003 hinzu zu fügen.
Dabei sagt mir die Voraussetzungsprüfung u.a. das der FRS veraltet ist und ich auf DFS migrieren sollte mit dem DFSRMIG und das ich möglicherweise in Zukunft kein DC hinzufügen werden kann der eine zukünftige Windows Server Version haben wird.
genau...So, ist das der Grund warum ich vielleicht erst auf 2012 R2 migrieren sollte und dann erst auf 2016 nachdem ich dort auf DFSR migriert habe?
Die Voraussetzungsprüfung würde mich jedenfalls auch jetzt, trotz der Warnung, den Vorgang machen lassen.
Ist das vielleicht auch der Grund warum mir die Ereignisanzeige Fehler bei der FSR gemeldet hat?
ja..Kennt SBS 2003 kein DFSR so daß ich bereits vor dem hinzufügen des W2k16 DC zu DFSR migrieren könnte falls doch?
nein, erst ab 2008....also mach es so, wie es weiter oben geschrieben habe...
Frank
Hi,
ich verstehe aber eines nicht: um die FRS auf DFSR zu migrieren darf der SBS2003 kein DC mehr sein, richtig? Es geht um die Gesamtstruktur und solange der SBS2003 noch DC ist kann ich die nicht anheben.
So weit so schlecht.
Wenn ich jetzt einen DC2012 R2 hinzufüge kann ich ebensowenig auf DFSR migrieren wie mit einem DC2016. Wenn ich den SBS aber demote, dann kann ich auf DFSR migrieren ebal ob der verbliebene DC ein 2012 oder ein 2016 ist, oder übersehe ich da irgendetwas?
Und noch was:
Ich habe das im Januar ja bereits bei uns in der Hauptfirma emacht: wir hatten einen einzigen DC2003 als phsykalsiche Maschine und auf mein 2-jähriges Drängen hin bekam ich das go für die Migration. Ich habe direkt auf 2016 migriert, den DC 2003 demotet, die Gesamtstrutkur und Domänenstruktur auf 2016 angehoben und dann von FRS auf DFSR migriert.
Das ist doch hier im Prinzip nichts anderes nur das ich eben von einem SBS komme. Übersehe ich hier etwas?
Und ein letztes:
Ich habe ja das "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis.".
Ich habe hier und auch über Google den Hinweis bekommen das mit der D4 setzen in der Registry usw. um den Fehler in der SYSVOL zu reparieren.
Ich bin jetzt verwirrt: ist die SYSVOL nun kaputt oder ist es nur weil es auf FRS ist und es nicht auf DFSR mirgriert werden kann? Wenn das nämlich so ist dann nutzt mir ja die 'Reparatur mit der genannten Vorgehensweise' ja gar nichts?
Daher nochmals die Frage: Ereignis ID 13568 ist wie ursprünglich gedacht ein Fehlerhaftes SYSVOL das ich versuchen soll zu reparieren oder ist dieses Ereignis aufgrund des inkompatiblen "Dateisystems" (oder wie auch immer das mit der FRS und DFSR genannt wird) vorhanden und eine Reparatur zwecklos? Wenn es das wäre dann habe ich ja ein mega Problem: ich kann den SBS 2003 nicht demoten weil der DC 2016 alleine nicht laufen würde. Und alleine nicht lauffähig bedeutet ich kann nich von FRS nach DFSR migrieren.... Also HOFFE ich das die SYSVOL lediglich beschädigt ist...
P.S. ich setze in der CMD auf dem neuen DC den 'net share'-Befehl ab und bekomme keine SYSVOL-Freigabe. Ich habe ihm mal Zeit gelassen und es zwei Stunden später nochmals probiert (ich glaube irgendwo gelesen zu haben das es manchmal seine Zeit braucht daß diese SYSVOL synchronisiert ist und dort erscheint) mit dem gleichen negativen Ergebnis.
Auch unter C:\SYSVOL finde ich zwar einen Ordner mit dem Domainnamen, der ist aber leer und auch nicht freigegeben.
somit kann ich die Reparatur der alten SYSVOL auf dem alten Server ja gar nicht durchführen da ja eine korrekt funktionierende SYSVOL in der Domäne vorhanden sein muss . Ich meine darum ja auch mein zweiter Versuch den 2. DC in die Domäne aufzunehmen. Dieser Versuch ist dann wohl ebenfalls schief gegangen, richtig?
So, was jetzt?
ich verstehe aber eines nicht: um die FRS auf DFSR zu migrieren darf der SBS2003 kein DC mehr sein, richtig? Es geht um die Gesamtstruktur und solange der SBS2003 noch DC ist kann ich die nicht anheben.
So weit so schlecht.
Wenn ich jetzt einen DC2012 R2 hinzufüge kann ich ebensowenig auf DFSR migrieren wie mit einem DC2016. Wenn ich den SBS aber demote, dann kann ich auf DFSR migrieren ebal ob der verbliebene DC ein 2012 oder ein 2016 ist, oder übersehe ich da irgendetwas?
Und noch was:
Ich habe das im Januar ja bereits bei uns in der Hauptfirma emacht: wir hatten einen einzigen DC2003 als phsykalsiche Maschine und auf mein 2-jähriges Drängen hin bekam ich das go für die Migration. Ich habe direkt auf 2016 migriert, den DC 2003 demotet, die Gesamtstrutkur und Domänenstruktur auf 2016 angehoben und dann von FRS auf DFSR migriert.
Das ist doch hier im Prinzip nichts anderes nur das ich eben von einem SBS komme. Übersehe ich hier etwas?
Und ein letztes:
Ich habe ja das "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis.".
Ich habe hier und auch über Google den Hinweis bekommen das mit der D4 setzen in der Registry usw. um den Fehler in der SYSVOL zu reparieren.
Ich bin jetzt verwirrt: ist die SYSVOL nun kaputt oder ist es nur weil es auf FRS ist und es nicht auf DFSR mirgriert werden kann? Wenn das nämlich so ist dann nutzt mir ja die 'Reparatur mit der genannten Vorgehensweise' ja gar nichts?
Daher nochmals die Frage: Ereignis ID 13568 ist wie ursprünglich gedacht ein Fehlerhaftes SYSVOL das ich versuchen soll zu reparieren oder ist dieses Ereignis aufgrund des inkompatiblen "Dateisystems" (oder wie auch immer das mit der FRS und DFSR genannt wird) vorhanden und eine Reparatur zwecklos? Wenn es das wäre dann habe ich ja ein mega Problem: ich kann den SBS 2003 nicht demoten weil der DC 2016 alleine nicht laufen würde. Und alleine nicht lauffähig bedeutet ich kann nich von FRS nach DFSR migrieren.... Also HOFFE ich das die SYSVOL lediglich beschädigt ist...
P.S. ich setze in der CMD auf dem neuen DC den 'net share'-Befehl ab und bekomme keine SYSVOL-Freigabe. Ich habe ihm mal Zeit gelassen und es zwei Stunden später nochmals probiert (ich glaube irgendwo gelesen zu haben das es manchmal seine Zeit braucht daß diese SYSVOL synchronisiert ist und dort erscheint) mit dem gleichen negativen Ergebnis.
Auch unter C:\SYSVOL finde ich zwar einen Ordner mit dem Domainnamen, der ist aber leer und auch nicht freigegeben.
somit kann ich die Reparatur der alten SYSVOL auf dem alten Server ja gar nicht durchführen da ja eine korrekt funktionierende SYSVOL in der Domäne vorhanden sein muss . Ich meine darum ja auch mein zweiter Versuch den 2. DC in die Domäne aufzunehmen. Dieser Versuch ist dann wohl ebenfalls schief gegangen, richtig?
So, was jetzt?
moin...
So weit so schlecht.
Wenn ich jetzt einen DC2012 R2 hinzufüge kann ich ebensowenig auf DFSR migrieren wie mit einem DC2016.
ich denke, du verstehst das nicht richtig....
um es kurz zu machen, erstelle eine 2012er VM, mache sie zu einem zusäztlichen domänencontroller, FMSO verschieben--> alles gut...
Active Directory-Migration von Windows Server 2003 auf Windows Server 2012R2
mach das bitte so, und nicht andres!
Wenn ich den SBS aber demote, dann kann ich auf DFSR migrieren ebal ob der verbliebene DC ein 2012 oder ein 2016 ist, oder übersehe ich da irgendetwas?
ja.. wenn alle rollen umgezogen(verschoben) sind, muss noch die domänen- wie auch gesamtstrukturfunktionsebenen heraufgestuft werden.
den 2016er hast du ja nicht mehr im netz, sondern nur noch den 2012er...und genau jetzt kannst du DFSR migrieren... nicht vorher!
das ist doch nun wirklich einfach!
Und noch was:
Ich habe das im Januar ja bereits bei uns in der Hauptfirma emacht: wir hatten einen einzigen DC2003 als phsykalsiche Maschine und auf mein 2-jähriges Drängen hin bekam ich das go für die Migration. Ich habe direkt auf 2016 migriert, den DC 2003 demotet, die Gesamtstrutkur und Domänenstruktur auf 2016 angehoben und dann von FRS auf DFSR migriert.
Das ist doch hier im Prinzip nichts anderes nur das ich eben von einem SBS komme. Übersehe ich hier etwas?
ja... es ist nicht das gleiche system!
und nur weil du etwas einmal gemacht hast, musss es nicht immer klappen- dir fehlt schlicht die erfahrung und ruhe das zu erledigen!
Und ein letztes:
Ich habe ja das "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis.".
Ich habe hier und auch über Google den Hinweis bekommen das mit der D4 setzen in der Registry usw. um den Fehler in der SYSVOL zu reparieren.
Ich bin jetzt verwirrt: ist die SYSVOL nun kaputt oder ist es nur weil es auf FRS ist und es nicht auf DFSR mirgriert werden kann?
das eine hat nix mit dem anderen zu tun....
Wenn das nämlich so ist dann nutzt mir ja die 'Reparatur mit der genannten Vorgehensweise' ja gar nichts?
das keine SYSVOL-Freigabe bei der migration erstellt wird, kommt öfter mal vor, und ist kein drama!
arbeite von oben nach unten alles so ab, und gut ist!
Frank
Zitat von @kaineanung:
Hi,
ich verstehe aber eines nicht: um die FRS auf DFSR zu migrieren darf der SBS2003 kein DC mehr sein, richtig? Es geht um die Gesamtstruktur und solange der SBS2003 noch DC ist kann ich die nicht anheben.
genau...Hi,
ich verstehe aber eines nicht: um die FRS auf DFSR zu migrieren darf der SBS2003 kein DC mehr sein, richtig? Es geht um die Gesamtstruktur und solange der SBS2003 noch DC ist kann ich die nicht anheben.
So weit so schlecht.
Wenn ich jetzt einen DC2012 R2 hinzufüge kann ich ebensowenig auf DFSR migrieren wie mit einem DC2016.
um es kurz zu machen, erstelle eine 2012er VM, mache sie zu einem zusäztlichen domänencontroller, FMSO verschieben--> alles gut...
Active Directory-Migration von Windows Server 2003 auf Windows Server 2012R2
mach das bitte so, und nicht andres!
Wenn ich den SBS aber demote, dann kann ich auf DFSR migrieren ebal ob der verbliebene DC ein 2012 oder ein 2016 ist, oder übersehe ich da irgendetwas?
ja.. wenn alle rollen umgezogen(verschoben) sind, muss noch die domänen- wie auch gesamtstrukturfunktionsebenen heraufgestuft werden.
den 2016er hast du ja nicht mehr im netz, sondern nur noch den 2012er...und genau jetzt kannst du DFSR migrieren... nicht vorher!
das ist doch nun wirklich einfach!
Und noch was:
Ich habe das im Januar ja bereits bei uns in der Hauptfirma emacht: wir hatten einen einzigen DC2003 als phsykalsiche Maschine und auf mein 2-jähriges Drängen hin bekam ich das go für die Migration. Ich habe direkt auf 2016 migriert, den DC 2003 demotet, die Gesamtstrutkur und Domänenstruktur auf 2016 angehoben und dann von FRS auf DFSR migriert.
Das ist doch hier im Prinzip nichts anderes nur das ich eben von einem SBS komme. Übersehe ich hier etwas?
und nur weil du etwas einmal gemacht hast, musss es nicht immer klappen- dir fehlt schlicht die erfahrung und ruhe das zu erledigen!
Und ein letztes:
Ich habe ja das "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis.".
Ich habe hier und auch über Google den Hinweis bekommen das mit der D4 setzen in der Registry usw. um den Fehler in der SYSVOL zu reparieren.
Ich bin jetzt verwirrt: ist die SYSVOL nun kaputt oder ist es nur weil es auf FRS ist und es nicht auf DFSR mirgriert werden kann?
Wenn das nämlich so ist dann nutzt mir ja die 'Reparatur mit der genannten Vorgehensweise' ja gar nichts?
Daher nochmals die Frage: Ereignis ID 13568 ist wie ursprünglich gedacht ein Fehlerhaftes SYSVOL das ich versuchen soll zu reparieren oder ist dieses Ereignis aufgrund des inkompatiblen "Dateisystems" (oder wie auch immer das mit der FRS und DFSR genannt wird) vorhanden und eine Reparatur zwecklos? Wenn es das wäre dann habe ich ja ein mega Problem: ich kann den SBS 2003 nicht demoten weil der DC 2016 alleine nicht laufen würde. Und alleine nicht lauffähig bedeutet ich kann nich von FRS nach DFSR migrieren.... Also HOFFE ich das die SYSVOL lediglich beschädigt ist...
P.S. ich setze in der CMD auf dem neuen DC den 'net share'-Befehl ab und bekomme keine SYSVOL-Freigabe. Ich habe ihm mal Zeit gelassen und es zwei Stunden später nochmals probiert (ich glaube irgendwo gelesen zu haben das es manchmal seine Zeit braucht daß diese SYSVOL synchronisiert ist und dort erscheint) mit dem gleichen negativen Ergebnis.
Auch unter C:\SYSVOL finde ich zwar einen Ordner mit dem Domainnamen, der ist aber leer und auch nicht freigegeben.
somit kann ich die Reparatur der alten SYSVOL auf dem alten Server ja gar nicht durchführen da ja eine korrekt funktionierende SYSVOL in der Domäne vorhanden sein muss . Ich meine darum ja auch mein zweiter Versuch den 2. DC in die Domäne aufzunehmen. Dieser Versuch ist dann wohl ebenfalls schief gegangen, richtig?
So, was jetzt?
mach nicht so ein. Drama, wenn es nötig ist, BurFlags auf D4 schrauben, und gut ist.P.S. ich setze in der CMD auf dem neuen DC den 'net share'-Befehl ab und bekomme keine SYSVOL-Freigabe. Ich habe ihm mal Zeit gelassen und es zwei Stunden später nochmals probiert (ich glaube irgendwo gelesen zu haben das es manchmal seine Zeit braucht daß diese SYSVOL synchronisiert ist und dort erscheint) mit dem gleichen negativen Ergebnis.
Auch unter C:\SYSVOL finde ich zwar einen Ordner mit dem Domainnamen, der ist aber leer und auch nicht freigegeben.
somit kann ich die Reparatur der alten SYSVOL auf dem alten Server ja gar nicht durchführen da ja eine korrekt funktionierende SYSVOL in der Domäne vorhanden sein muss . Ich meine darum ja auch mein zweiter Versuch den 2. DC in die Domäne aufzunehmen. Dieser Versuch ist dann wohl ebenfalls schief gegangen, richtig?
So, was jetzt?
das keine SYSVOL-Freigabe bei der migration erstellt wird, kommt öfter mal vor, und ist kein drama!
arbeite von oben nach unten alles so ab, und gut ist!
Frank
Sorry das ich ein Drama mache. Aber du hast es ja bereits erkannt: ich mache das nicht allzuoft und wenn 2 Dinge die inch im Grundsatz brauche mir jedoch konträr erscheinen, dann bin ich erstmal verwirrt. Wenn es dabei auch noch um das Lebenselexier eines Unternehmens ist (und das ist eine Domäne sicher) und ich es reparieren muss damit das Unternehmen auch sicher weiter funktionieren kann, dann ist der Druck enorm...
Druck + Verwirrung -> Drama...
Also bitte nochmals für ganz blöde:
Der Fehler "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis" ist ein Fehler unabhängig von FRS / DFSR. Es ist ein Fehler, die Sysvol ist beschädigt. Punkt.
Darauf setzen wir dann mal als Basis auf.
Hier die Punkte die in dieser Reihenfolge in meinem Kopf schwirren:
1. Es gibt nur eine Möglichkeit um das Problem zu überwinden: Reparatur der SYSVOL!
2. Um eine Reparatur der Sysvol durchzuführen braucht man ZWINGEND eine korrekte weitere SYSVOL in der Domäne.
3. Da dies hier nicht gegeben ist (ich habe nur diesen SBS in der Domäne als DC), muss ich einen weiteren DC ins Netz bringen.
4. Einen weiteren DC ins Netz bringen hat nicht geklappt da SYSVOL nicht auf den neuen 2016'ner DC repliziert wird. Domäne funktioniert somit aktuell nicht ohne dass der alte SBS (als DC) online ist.
Habe ich bis hierhin soweit alles korrekt verstanden? Noch spielt FRS / DFSR keine Rolle, richtig?
So, du Frank schlägst jetzt vor:
1. einen weiteren Server mit der AD Rolle ins Netz bringen . Jedoch nicht 2016 sondern 2012 R2 (da habe ich eine ISO von. Ohne R2 habe ich keine ISO und das ist verdammt schwer zu organisieren. Ich hoffe 2012 R2 ist ok).
2. Promoten zum DC
3. WENN SYSVOL korrekt repliziert wurde, Reparaturvorgang laut o.g. Anleitung durchführen.
4. Wenn alles ok FSMO Rollen auf 2012 R2 übertragen und SBS demoten. Gesamtstruktur und Domänenstruktur auf 2012 R2 anheben.
5. Wieder einen neuen Server als DC promoten, dieses mal jedoch den finalen 2016ner. FSMO-Rollen übertragen und den temporären 2012 R2 demoten. Jetzt nur noch beide Strukturen auf 2016 anheben und fertig.
So habe ich dein Vorschlag nun verstanden.
Mein Problem bei alldem ist aber:
Punkt 3 -> SYSVOL wird NICHT korrekt repliziert. Ich habe keinen neuen DC im Netz. Zumindest nicht wenn ich es mit einem 2016ner versuche.
Punkt 3 -> wenn Sysvol aber korrekt repliziert werden würde dann kann ich mir die Reparatur des SBS-Sysvols auch sparen da ich den ja dann demoten kann...
So, habeich alles korrekt verstanden? Wenn ja, was ist dann mit meinem gerade erwähnten Problem mit der SYSVOL die nicht repliziert wird? Meinst du das passiert mir mit einem 2012er Server so nicht?
Wenn du das meinst, dann wäre ich beruhigt und würde es einfach probieren sofern eine 2012 R2-ISO ok für das ganze Vorgehen wäre.
Wenn das mit dem 2012er aber genauso scheif geht wie mit dem 2016er, dann weiß ich nicht was ich dann konkret machen soll? An welchem o.g. Punkt soll ich dann was anders machen?
Ich hoffe du verstehst jetzt mit meiner Auflistung was ich im Kopf nicht ganz 'synchron' bekomme....
Druck + Verwirrung -> Drama...
Also bitte nochmals für ganz blöde:
Der Fehler "Ereignis ID: 13568 Problem mit dem SysVol-Verzeichnis" ist ein Fehler unabhängig von FRS / DFSR. Es ist ein Fehler, die Sysvol ist beschädigt. Punkt.
Darauf setzen wir dann mal als Basis auf.
Hier die Punkte die in dieser Reihenfolge in meinem Kopf schwirren:
1. Es gibt nur eine Möglichkeit um das Problem zu überwinden: Reparatur der SYSVOL!
2. Um eine Reparatur der Sysvol durchzuführen braucht man ZWINGEND eine korrekte weitere SYSVOL in der Domäne.
3. Da dies hier nicht gegeben ist (ich habe nur diesen SBS in der Domäne als DC), muss ich einen weiteren DC ins Netz bringen.
4. Einen weiteren DC ins Netz bringen hat nicht geklappt da SYSVOL nicht auf den neuen 2016'ner DC repliziert wird. Domäne funktioniert somit aktuell nicht ohne dass der alte SBS (als DC) online ist.
Habe ich bis hierhin soweit alles korrekt verstanden? Noch spielt FRS / DFSR keine Rolle, richtig?
So, du Frank schlägst jetzt vor:
1. einen weiteren Server mit der AD Rolle ins Netz bringen . Jedoch nicht 2016 sondern 2012 R2 (da habe ich eine ISO von. Ohne R2 habe ich keine ISO und das ist verdammt schwer zu organisieren. Ich hoffe 2012 R2 ist ok).
2. Promoten zum DC
3. WENN SYSVOL korrekt repliziert wurde, Reparaturvorgang laut o.g. Anleitung durchführen.
4. Wenn alles ok FSMO Rollen auf 2012 R2 übertragen und SBS demoten. Gesamtstruktur und Domänenstruktur auf 2012 R2 anheben.
5. Wieder einen neuen Server als DC promoten, dieses mal jedoch den finalen 2016ner. FSMO-Rollen übertragen und den temporären 2012 R2 demoten. Jetzt nur noch beide Strukturen auf 2016 anheben und fertig.
So habe ich dein Vorschlag nun verstanden.
Mein Problem bei alldem ist aber:
Punkt 3 -> SYSVOL wird NICHT korrekt repliziert. Ich habe keinen neuen DC im Netz. Zumindest nicht wenn ich es mit einem 2016ner versuche.
Punkt 3 -> wenn Sysvol aber korrekt repliziert werden würde dann kann ich mir die Reparatur des SBS-Sysvols auch sparen da ich den ja dann demoten kann...
So, habeich alles korrekt verstanden? Wenn ja, was ist dann mit meinem gerade erwähnten Problem mit der SYSVOL die nicht repliziert wird? Meinst du das passiert mir mit einem 2012er Server so nicht?
Wenn du das meinst, dann wäre ich beruhigt und würde es einfach probieren sofern eine 2012 R2-ISO ok für das ganze Vorgehen wäre.
Wenn das mit dem 2012er aber genauso scheif geht wie mit dem 2016er, dann weiß ich nicht was ich dann konkret machen soll? An welchem o.g. Punkt soll ich dann was anders machen?
Ich hoffe du verstehst jetzt mit meiner Auflistung was ich im Kopf nicht ganz 'synchron' bekomme....
moin...
nur kurz....
2012R2 ist ok....
wenn dein Problem mit der SYSVOL, die nicht repliziert kommt, was zu 80% so sein wird----> Burflags auf D4 und alles wird gut!
Frank
nur kurz....
2012R2 ist ok....
wenn dein Problem mit der SYSVOL, die nicht repliziert kommt, was zu 80% so sein wird----> Burflags auf D4 und alles wird gut!
Frank
Zitat von @Vision2015:
moin...
nur kurz....
2012R2 ist ok....
wenn dein Problem mit der SYSVOL, die nicht repliziert kommt, was zu 80% so sein wird----> Burflags auf D4 und alles wird gut!
Frank
moin...
nur kurz....
2012R2 ist ok....
wenn dein Problem mit der SYSVOL, die nicht repliziert kommt, was zu 80% so sein wird----> Burflags auf D4 und alles wird gut!
Frank
Habe ich jetzt gemacht und, wie zu erwarten, die SYSVOL kann nicht repliziert werden.
So, ich nutze jetzt die o.g. Anleitung zur Reparatur der SYSVOL (das mit D4 Burflags..).
Nur, da ich ja KEIN funktionierendes SYSVOL habe in der Domäne, ist meine Frage nun: auf welchem setze ich das Burflag denn jetzt? Auf dem 2012er?
moin..
natürlich auf beiden... bitte genau lesen, und nicht nur überfliegen!
Neuer Active Directory Controller – SYSVOL & NETLOGON Freigabe fehlen
Frank
natürlich auf beiden... bitte genau lesen, und nicht nur überfliegen!
Neuer Active Directory Controller – SYSVOL & NETLOGON Freigabe fehlen
Frank
Sorry, ich glaube ich hatte da noch meine gefundene Anleitung zu diesem Thema im Kopf und die war nicht so eindeutig.
Also danke, es hat geklappt. Zumindest 'net share' hat mir nach ca. einer quälend langer Minute dann NETLOGON als auch SYSVOL-Freigabe angezeigt.
Mehr habe ich nicht probiert und das mache ich auch dann mal morgen.
Eine kleine, wahrscheinlich unwichtige Frage habe ich aber zu diesem Vorgang dann doch noch:
Muss ich die Werte der Burflags wieder zurücksetzen nach dem Vorgang? Der steht immer noch auf D4 und D2...
Jedenfalls vielen Dank!
Ach ja, morgen habe ich folgendes vor:
Migration auf DC2106 ohne auf DFRS zu mirgieren (erstmal). Ich kann die FSMO-Rollen nicht vom SBS weg transferieren sonst schaltet er sich ja bekanntlich nach einer Grace-Periode selber ab (wenn er nicht der FSMO-Rolleninhaber ist).
Da ich keine 2012er Lizenz habe und nicht weiß wie lange der 'schwebende Zustand' anhält bis der SBS ganz abgeschaltet werden kann, will ich erstmla einen DC2016 im Netz haben und schauen ob er alleine, ohne SBS, funktionstüchtig ist. Wenn ja: gleich Lizenz verbraten und fest machen... dann habe ich Zeit mich noch zu vergewissern das alles vom SBS weg migriert wurde bevor ich dann die FSMO-Rollen übertrage und diesen dann demote...
Ist diese Vorgehensweise ok?
Also danke, es hat geklappt. Zumindest 'net share' hat mir nach ca. einer quälend langer Minute dann NETLOGON als auch SYSVOL-Freigabe angezeigt.
Mehr habe ich nicht probiert und das mache ich auch dann mal morgen.
Eine kleine, wahrscheinlich unwichtige Frage habe ich aber zu diesem Vorgang dann doch noch:
Muss ich die Werte der Burflags wieder zurücksetzen nach dem Vorgang? Der steht immer noch auf D4 und D2...
Jedenfalls vielen Dank!
Ach ja, morgen habe ich folgendes vor:
Migration auf DC2106 ohne auf DFRS zu mirgieren (erstmal). Ich kann die FSMO-Rollen nicht vom SBS weg transferieren sonst schaltet er sich ja bekanntlich nach einer Grace-Periode selber ab (wenn er nicht der FSMO-Rolleninhaber ist).
Da ich keine 2012er Lizenz habe und nicht weiß wie lange der 'schwebende Zustand' anhält bis der SBS ganz abgeschaltet werden kann, will ich erstmla einen DC2016 im Netz haben und schauen ob er alleine, ohne SBS, funktionstüchtig ist. Wenn ja: gleich Lizenz verbraten und fest machen... dann habe ich Zeit mich noch zu vergewissern das alles vom SBS weg migriert wurde bevor ich dann die FSMO-Rollen übertrage und diesen dann demote...
Ist diese Vorgehensweise ok?
moin...
Jedenfalls vielen Dank!
gern...
Ach ja, morgen habe ich folgendes vor:
Migration auf DC2106 ohne auf DFRS zu mirgieren (erstmal).
blöde idee...
Ich kann die FSMO-Rollen nicht vom SBS weg transferieren sonst schaltet er sich ja bekanntlich nach einer Grace-Periode selber ab (wenn er nicht der FSMO-Rolleninhaber ist).
bitte halte dich an meine anleitung, und denke dir nix aus... das geht in die hose!
Du wirst jetzt Alles auf den 2012er schieben, ja, auch die FMSO Rollen
warum: weil die gesamtstrukturfunktionsebenen heraufgestuft werden muss, das geht nicht mit den 2003er.....
nach den verschieben der FMSO Rollen würde ich etwa 2 Stunden warten, und prüfen ob alle AD Replikate durch sind (sollte aber)
noch mal sysvol prüfen und mit:
sehen ob der 20112er wirklich alle rollen hat.
mit DCpromo den 2003er loswerden....
dann gesamtstrukturfunktionsebenen anheben und DFRS migration!
eine Neue 2016er VM erstellen- und alles rüberschieben...
Fertig....
bis heute 17 uhr ist das locker zu schaffen....
Frank
Zitat von @kaineanung:
Sorry, ich glaube ich hatte da noch meine gefundene Anleitung zu diesem Thema im Kopf und die war nicht so eindeutig.
Also danke, es hat geklappt. Zumindest 'net share' hat mir nach ca. einer quälend langer Minute dann NETLOGON als auch SYSVOL-Freigabe angezeigt.
Mehr habe ich nicht probiert und das mache ich auch dann mal morgen.
Eine kleine, wahrscheinlich unwichtige Frage habe ich aber zu diesem Vorgang dann doch noch:
Muss ich die Werte der Burflags wieder zurücksetzen nach dem Vorgang? Der steht immer noch auf D4 und D2...
nein... nix mehr machen!Sorry, ich glaube ich hatte da noch meine gefundene Anleitung zu diesem Thema im Kopf und die war nicht so eindeutig.
Also danke, es hat geklappt. Zumindest 'net share' hat mir nach ca. einer quälend langer Minute dann NETLOGON als auch SYSVOL-Freigabe angezeigt.
Mehr habe ich nicht probiert und das mache ich auch dann mal morgen.
Eine kleine, wahrscheinlich unwichtige Frage habe ich aber zu diesem Vorgang dann doch noch:
Muss ich die Werte der Burflags wieder zurücksetzen nach dem Vorgang? Der steht immer noch auf D4 und D2...
Jedenfalls vielen Dank!
Ach ja, morgen habe ich folgendes vor:
Migration auf DC2106 ohne auf DFRS zu mirgieren (erstmal).
Ich kann die FSMO-Rollen nicht vom SBS weg transferieren sonst schaltet er sich ja bekanntlich nach einer Grace-Periode selber ab (wenn er nicht der FSMO-Rolleninhaber ist).
Da ich keine 2012er Lizenz habe und nicht weiß wie lange der 'schwebende Zustand' anhält bis der SBS ganz abgeschaltet werden kann, will ich erstmla einen DC2016 im Netz haben und schauen ob er alleine, ohne SBS, funktionstüchtig ist. Wenn ja: gleich Lizenz verbraten und fest machen... dann habe ich Zeit mich noch zu vergewissern das alles vom SBS weg migriert wurde bevor ich dann die FSMO-Rollen übertrage und diesen dann demote...
Ist diese Vorgehensweise ok?
nein, das ist blödsinn....Ist diese Vorgehensweise ok?
bitte halte dich an meine anleitung, und denke dir nix aus... das geht in die hose!
Du wirst jetzt Alles auf den 2012er schieben, ja, auch die FMSO Rollen
warum: weil die gesamtstrukturfunktionsebenen heraufgestuft werden muss, das geht nicht mit den 2003er.....
nach den verschieben der FMSO Rollen würde ich etwa 2 Stunden warten, und prüfen ob alle AD Replikate durch sind (sollte aber)
noch mal sysvol prüfen und mit:
netdom query fsmomit DCpromo den 2003er loswerden....
dann gesamtstrukturfunktionsebenen anheben und DFRS migration!
eine Neue 2016er VM erstellen- und alles rüberschieben...
Fertig....
bis heute 17 uhr ist das locker zu schaffen....
Frank
Ich habe da ein kleines Problem:
Nach einem Gespräch mit meinem Vorgesetzten habe ich erfahren das der alte SBS-Server noch eine Weile in Betrieb bleiben soll da auf ihm noch diverse Dinge wie das CAS-System, eMail und Druckerfreigaben (meint wohl Printserver?) laufen.
Den Printserver (bzw. es sind nur Druckerfreigaben aber das ist ja dann Printserver würde ich sagen) schaffe ich sicherlich ebenfalls auf den neuen Server zu migrieren. Aber eMail ist ein Job eines externen Dienstleisters weil die in unser Workgroup als separate Firma / Mandant integriert werden sollen. Auch das CAS ist ein Problem da wir mit dieser Software nichts am Hut haben und eine Lösung her muss.
Lange Rede kurzer Sinn: mir sind die Hände vorerst gebunden was die vollständige und 'abgeschlossene' Migration angeht.
Somit soll ich dafür Sorgen das die Domäne lauffähig bleiben sollte wenn der mittlerweile virtualisierte SBS-Server abrauchen sollte (was auf der physikalischen Maschine ständig der Fall war, seit es virtualisiert wurde ist er stabil). Der SBS-Server soll aber weiterhin die anderen Dienste im Netz noch eine Weile anbieten (ich hoffe nicht allzulange, aber mehr als hoffen bleibt mir nicht). Da der SBS-Server ja nicht laufen will ohne seine blöden FSMO-Rollen, kann ich keine vollständige Migration vorerst machen. Somit kommt jetzt der Server 2016er DC ins Netz und wird 2. DC ohne FSMO-Rollen und die Gesamtsrtuktur bleibt erstmal auf 2003.
Oder aber jemand sagt mir hier der SBS wird auch weiterhin laufen wenn er gar kein DC mehr ist und dann die FSMO-Rollen egal sind?
Das wäre perfekt. Ansonsten muss ich das eben so wie beschrieben machen...
Die Frage ist nun an alle die sich mit SBS auskennen:
Ohne FSMO-Rollen fährt der SBS herunter nachdem die Graceperiode abgelaufen ist.
Kann der SBS auch als 'NICHT-DC' laufen und somit nur als Fileserver, Printserver oder irgendein-Server laufen? Dann könnte ich nämlich komplett migrieren und den alten demoten und somit die Gesamtstruktur anheben.
Nach einem Gespräch mit meinem Vorgesetzten habe ich erfahren das der alte SBS-Server noch eine Weile in Betrieb bleiben soll da auf ihm noch diverse Dinge wie das CAS-System, eMail und Druckerfreigaben (meint wohl Printserver?) laufen.
Den Printserver (bzw. es sind nur Druckerfreigaben aber das ist ja dann Printserver würde ich sagen) schaffe ich sicherlich ebenfalls auf den neuen Server zu migrieren. Aber eMail ist ein Job eines externen Dienstleisters weil die in unser Workgroup als separate Firma / Mandant integriert werden sollen. Auch das CAS ist ein Problem da wir mit dieser Software nichts am Hut haben und eine Lösung her muss.
Lange Rede kurzer Sinn: mir sind die Hände vorerst gebunden was die vollständige und 'abgeschlossene' Migration angeht.
Somit soll ich dafür Sorgen das die Domäne lauffähig bleiben sollte wenn der mittlerweile virtualisierte SBS-Server abrauchen sollte (was auf der physikalischen Maschine ständig der Fall war, seit es virtualisiert wurde ist er stabil). Der SBS-Server soll aber weiterhin die anderen Dienste im Netz noch eine Weile anbieten (ich hoffe nicht allzulange, aber mehr als hoffen bleibt mir nicht). Da der SBS-Server ja nicht laufen will ohne seine blöden FSMO-Rollen, kann ich keine vollständige Migration vorerst machen. Somit kommt jetzt der Server 2016er DC ins Netz und wird 2. DC ohne FSMO-Rollen und die Gesamtsrtuktur bleibt erstmal auf 2003.
Oder aber jemand sagt mir hier der SBS wird auch weiterhin laufen wenn er gar kein DC mehr ist und dann die FSMO-Rollen egal sind?
Das wäre perfekt. Ansonsten muss ich das eben so wie beschrieben machen...
Die Frage ist nun an alle die sich mit SBS auskennen:
Ohne FSMO-Rollen fährt der SBS herunter nachdem die Graceperiode abgelaufen ist.
Kann der SBS auch als 'NICHT-DC' laufen und somit nur als Fileserver, Printserver oder irgendein-Server laufen? Dann könnte ich nämlich komplett migrieren und den alten demoten und somit die Gesamtstruktur anheben.
Hallo,
Der fährt dir immer wieder runter.
Somit abwarten, du kannst es nicht fertig machen.
Der fährt dir immer wieder runter.
Somit abwarten, du kannst es nicht fertig machen.
moin...
du hast irgendwo weiter oben geschrieben, das du glänzen willst... tja... jetzt kannst du deinem chef sagen, das du einfach viel arbeitszeit in den sand gesetzt hast, weil dir der weitblick fehlt zu realisieren was auf dem SBS läuft, und welche voraussetzungen nötig sind die weiteren dienste zu betreiben.
das wäre nämlich auch deine aufgabe gewesen...
der 2016er kommt nicht in frage, und die Gesamtsrtuktur kann nicht auf 2012 angehoben werden!
ergo, du bist jetzt fertig, der 2003er bleibt dc mit allen rollen... der 2012er kann auch dc sein, mehr aber nicht!
das wars...
Oder aber jemand sagt mir hier der SBS wird auch weiterhin laufen wenn er gar kein DC mehr ist und dann die FSMO-Rollen egal sind?
nein, das sagt dir keiner...
noch mal, hast du eigentlich genau gelesen, was ich geshrieben habe, und was in den links so alles steht?
Die Frage ist nun an alle die sich mit SBS auskennen:
Ohne FSMO-Rollen fährt der SBS herunter nachdem die Graceperiode abgelaufen ist.
ja...
also bist du fertig...
Frank
Zitat von @kaineanung:
Ich habe da ein kleines Problem:
Nach einem Gespräch mit meinem Vorgesetzten habe ich erfahren das der alte SBS-Server noch eine Weile in Betrieb bleiben soll da auf ihm noch diverse Dinge wie das CAS-System, eMail und Druckerfreigaben (meint wohl Printserver?) laufen.
Den Printserver (bzw. es sind nur Druckerfreigaben aber das ist ja dann Printserver würde ich sagen) schaffe ich sicherlich ebenfalls auf den neuen Server zu migrieren. Aber eMail ist ein Job eines externen Dienstleisters weil die in unser Workgroup als separate Firma / Mandant integriert werden sollen. Auch das CAS ist ein Problem da wir mit dieser Software nichts am Hut haben und eine Lösung her muss.
sorry, das fällt euch aber sehr früh ein...Ich habe da ein kleines Problem:
Nach einem Gespräch mit meinem Vorgesetzten habe ich erfahren das der alte SBS-Server noch eine Weile in Betrieb bleiben soll da auf ihm noch diverse Dinge wie das CAS-System, eMail und Druckerfreigaben (meint wohl Printserver?) laufen.
Den Printserver (bzw. es sind nur Druckerfreigaben aber das ist ja dann Printserver würde ich sagen) schaffe ich sicherlich ebenfalls auf den neuen Server zu migrieren. Aber eMail ist ein Job eines externen Dienstleisters weil die in unser Workgroup als separate Firma / Mandant integriert werden sollen. Auch das CAS ist ein Problem da wir mit dieser Software nichts am Hut haben und eine Lösung her muss.
du hast irgendwo weiter oben geschrieben, das du glänzen willst... tja... jetzt kannst du deinem chef sagen, das du einfach viel arbeitszeit in den sand gesetzt hast, weil dir der weitblick fehlt zu realisieren was auf dem SBS läuft, und welche voraussetzungen nötig sind die weiteren dienste zu betreiben.
das wäre nämlich auch deine aufgabe gewesen...
Lange Rede kurzer Sinn: mir sind die Hände vorerst gebunden was die vollständige und 'abgeschlossene' Migration angeht.
Somit soll ich dafür Sorgen das die Domäne lauffähig bleiben sollte wenn der mittlerweile virtualisierte SBS-Server abrauchen sollte (was auf der physikalischen Maschine ständig der Fall war, seit es virtualisiert wurde ist er stabil). Der SBS-Server soll aber weiterhin die anderen Dienste im Netz noch eine Weile anbieten (ich hoffe nicht allzulange, aber mehr als hoffen bleibt mir nicht). Da der SBS-Server ja nicht laufen will ohne seine blöden FSMO-Rollen, kann ich keine vollständige Migration vorerst machen. Somit kommt jetzt der Server 2016er DC ins Netz und wird 2. DC ohne FSMO-Rollen und die Gesamtsrtuktur bleibt erstmal auf 2003.
solange der 2003er im netz ist, kannst du den rest vergessen!Somit soll ich dafür Sorgen das die Domäne lauffähig bleiben sollte wenn der mittlerweile virtualisierte SBS-Server abrauchen sollte (was auf der physikalischen Maschine ständig der Fall war, seit es virtualisiert wurde ist er stabil). Der SBS-Server soll aber weiterhin die anderen Dienste im Netz noch eine Weile anbieten (ich hoffe nicht allzulange, aber mehr als hoffen bleibt mir nicht). Da der SBS-Server ja nicht laufen will ohne seine blöden FSMO-Rollen, kann ich keine vollständige Migration vorerst machen. Somit kommt jetzt der Server 2016er DC ins Netz und wird 2. DC ohne FSMO-Rollen und die Gesamtsrtuktur bleibt erstmal auf 2003.
der 2016er kommt nicht in frage, und die Gesamtsrtuktur kann nicht auf 2012 angehoben werden!
ergo, du bist jetzt fertig, der 2003er bleibt dc mit allen rollen... der 2012er kann auch dc sein, mehr aber nicht!
das wars...
Oder aber jemand sagt mir hier der SBS wird auch weiterhin laufen wenn er gar kein DC mehr ist und dann die FSMO-Rollen egal sind?
Das wäre perfekt. Ansonsten muss ich das eben so wie beschrieben machen...
das wird auch nicht gehen!noch mal, hast du eigentlich genau gelesen, was ich geshrieben habe, und was in den links so alles steht?
Die Frage ist nun an alle die sich mit SBS auskennen:
Ohne FSMO-Rollen fährt der SBS herunter nachdem die Graceperiode abgelaufen ist.
Kann der SBS auch als 'NICHT-DC' laufen und somit nur als Fileserver, Printserver oder irgendein-Server laufen? Dann könnte ich nämlich komplett migrieren und den alten demoten und somit die Gesamtstruktur anheben.
in der regel nicht mehr sauber....also bist du fertig...
Frank
Frank, ja, ich habe deine Links sehr genau gelesen. Auch deine Kommentare hier verschlinge ich geradezu (ehrlich gesagt am liebsten da sehr genau und sehr gut). Ich habe nirgends gelesen daß der SBS nicht als DC-Server laufen kann. Er kann nicht ohne FSMO-Rollen laufen, das ist schon länger klar und wurde hier deutlich kommuniziert. Es wäre aber eine Möglichkeit gewesen daß er eventuell eben OHNE DC-Rolle läuft und dann auch ohne FSMO. Scheint zwar nicht der Fall zu sein wie ich jetzt weiß, aber vor deinem Kommentar war diese Frage ja noch nicht gestellt und nicht beantwortet, also offen.
Und wegen meiner fehlenden Weitsicht:
Vorgesetzter, der eine extrem feste Meinung zu allem hat und immer gerne Recht hat, sagt: Herr XY, der einzige DC-Server bei unserer Tochter geht alle paar Tage aus. Ist fast 20 Jahre alt und da läuft ein SBS drauf. Bitte gestern irgendwas tun damit die Domäne gerettet wird und die Daten sowieso.
Machen Sie doch gleich eine neue Serverstruktur und am besten auf einer neuen SAN und ESX-Servern. Externe Dienstleister brauchen Sie doch gar nicht. Sie sind doch sehr gut... Ach ja, und kosten sollte das ganze am besten so wenig wie möglich. Sie wissen ja, wir sind ein armes schwäbisches mittelständisches Familienunternehmen...... "Augenzwinker'...
Ich: ok. Ich muss mich reinlesen in ESX und SAN, Angebote einholen für die Hardware und die Lizenzen. Dann selber aufbauen und zum laufen bringen und ESX-SAN-Schnell-Crashkurs in diversen Foren usw. machen.
Frage an Vorgesetzten: was läuft denn alles auf dem SBS?
Vorgesetzer: eMail bin ich mir nicht sicher, notfalls haben die halt Pech gehabt. Haben ja sicher noch ein eMailarchiv... DC und Fileserver und Druckerfreigaben und sonst NICHTS.
Ich: Ok, dann mache ich mich mal auf die Socken......
.
.
.
So, was soll ich dazu sagen? Ich bin hier definitv das Opfer.....
ABER: ich habe mein Teil der Aufgaben dank diverser anderer Foren bezüglich ESX und SAN hervorragend gelöst (ich habe tatsächlich alles alleine aufgebaut mit miniSAS-SAN angebunden auf mehreren ESX-Servern und einer VCSA mit allem drum und drann..) und dank euch hier eben der Teil mit dem SBS selber.
Wenn mein Vorgesetzter jetzt um die Ecke kommt und sagt: nene, der muss noch laufen weil so und so.. ja was soll ich da dann machen?
P.S. meine Aufgabe wäre es sicherlich gewesen rauszufinden was alles auf dem Server läuft. Mein Vorgesetzer will aber die Zügel in der Hand haben und ich soll nur das ausführende Organ sein. Das hat er dann auch bekommen....
Aber eines will ich doch noch fragen:
Ich habe gefragt:
Antwort war:
Nicht mehr sauber hört sich nach einem "JAEIN" an? Was heisst nicht mehr sauber? Alle MS-Dienste werden nicht mehr bnötigt. Wenn der Server ohne DC-Rolle einfach nur läuft ohne sich abzuschalten, dann hätte ich ja das was ich wollte....
Ansonsten bleibt mir dann nichts übrig als abzuwarten. Leider haben wir für den 2012er DC keine Lizenz und die Evaluation-Periode ist ja nicht so üppig.
Wenn ich die SYSVOL nun repariert habe, dann könnte ich den 2012er doch demoten und einen 2016 promoten als 2. DC?
Ich kann ja später die Migration von FSR auf DFRS versuchen und wenn es nicht klappt dann demoten und wieder einen 2012 promoten? Das dauert ja nicht allzulange mit promoten / demoten?
Jetzt mal unabhängig von meinen angeblichen und tatsächlichen Verfehlungen in dieser Migrations-Geschichte. Könnte ich den 2012er nun demoten in Hinsicht auf die gesetzen Burflags?
Und wegen meiner fehlenden Weitsicht:
Vorgesetzter, der eine extrem feste Meinung zu allem hat und immer gerne Recht hat, sagt: Herr XY, der einzige DC-Server bei unserer Tochter geht alle paar Tage aus. Ist fast 20 Jahre alt und da läuft ein SBS drauf. Bitte gestern irgendwas tun damit die Domäne gerettet wird und die Daten sowieso.
Machen Sie doch gleich eine neue Serverstruktur und am besten auf einer neuen SAN und ESX-Servern. Externe Dienstleister brauchen Sie doch gar nicht. Sie sind doch sehr gut... Ach ja, und kosten sollte das ganze am besten so wenig wie möglich. Sie wissen ja, wir sind ein armes schwäbisches mittelständisches Familienunternehmen...... "Augenzwinker'...
Ich: ok. Ich muss mich reinlesen in ESX und SAN, Angebote einholen für die Hardware und die Lizenzen. Dann selber aufbauen und zum laufen bringen und ESX-SAN-Schnell-Crashkurs in diversen Foren usw. machen.
Frage an Vorgesetzten: was läuft denn alles auf dem SBS?
Vorgesetzer: eMail bin ich mir nicht sicher, notfalls haben die halt Pech gehabt. Haben ja sicher noch ein eMailarchiv... DC und Fileserver und Druckerfreigaben und sonst NICHTS.
Ich: Ok, dann mache ich mich mal auf die Socken......
.
.
.
So, was soll ich dazu sagen? Ich bin hier definitv das Opfer.....
ABER: ich habe mein Teil der Aufgaben dank diverser anderer Foren bezüglich ESX und SAN hervorragend gelöst (ich habe tatsächlich alles alleine aufgebaut mit miniSAS-SAN angebunden auf mehreren ESX-Servern und einer VCSA mit allem drum und drann..) und dank euch hier eben der Teil mit dem SBS selber.
Wenn mein Vorgesetzter jetzt um die Ecke kommt und sagt: nene, der muss noch laufen weil so und so.. ja was soll ich da dann machen?
P.S. meine Aufgabe wäre es sicherlich gewesen rauszufinden was alles auf dem Server läuft. Mein Vorgesetzer will aber die Zügel in der Hand haben und ich soll nur das ausführende Organ sein. Das hat er dann auch bekommen....
Aber eines will ich doch noch fragen:
Ich habe gefragt:
Kann der SBS auch als 'NICHT-DC' laufen und somit nur als Fileserver, Printserver oder irgendein-Server laufen? Dann könnte ich nämlich komplett migrieren und den alten demoten und somit die Gesamtstruktur anheben.<<
in der regel nicht mehr sauber....<
Nicht mehr sauber hört sich nach einem "JAEIN" an? Was heisst nicht mehr sauber? Alle MS-Dienste werden nicht mehr bnötigt. Wenn der Server ohne DC-Rolle einfach nur läuft ohne sich abzuschalten, dann hätte ich ja das was ich wollte....
Ansonsten bleibt mir dann nichts übrig als abzuwarten. Leider haben wir für den 2012er DC keine Lizenz und die Evaluation-Periode ist ja nicht so üppig.
Wenn ich die SYSVOL nun repariert habe, dann könnte ich den 2012er doch demoten und einen 2016 promoten als 2. DC?
Ich kann ja später die Migration von FSR auf DFRS versuchen und wenn es nicht klappt dann demoten und wieder einen 2012 promoten? Das dauert ja nicht allzulange mit promoten / demoten?
Jetzt mal unabhängig von meinen angeblichen und tatsächlichen Verfehlungen in dieser Migrations-Geschichte. Könnte ich den 2012er nun demoten in Hinsicht auf die gesetzen Burflags?
moin...
was ist, wenn du die kiste in den sand fahrst.... datenverlust, ausfall etc... ?
ABER: ich habe mein Teil der Aufgaben dank diverser anderer Foren bezüglich ESX und SAN hervorragend gelöst (ich habe tatsächlich alles alleine aufgebaut mit miniSAS-SAN angebunden auf mehreren ESX-Servern und einer VCSA mit allem drum und drann..) und dank euch hier eben der Teil mit dem SBS selber.
Wenn mein Vorgesetzter jetzt um die Ecke kommt und sagt: nene, der muss noch laufen weil so und so.. ja was soll ich da dann machen?
na sagen, das du das nicht kannst!
frage doch mal deinen chef wer haftet wenn... und ob du das schriftlich bekommst!
P.S. meine Aufgabe wäre es sicherlich gewesen rauszufinden was alles auf dem Server läuft. Mein Vorgesetzer will aber die Zügel in der Hand haben und ich soll nur das ausführende Organ sein. Das hat er dann auch bekommen....
das ist die falsche einstellung
Aber eines will ich doch noch fragen:
Ich habe gefragt:
Antwort war:
Nicht mehr sauber hört sich nach einem "JAEIN" an? Was heisst nicht mehr sauber? Alle MS-Dienste werden nicht mehr bnötigt. Wenn der Server ohne DC-Rolle einfach nur läuft ohne sich abzuschalten, dann hätte ich ja das was ich wollte....
das wird aber nicht gehen... in einer arbeitsgruppe wäre möglich- dann hast du aber ein rechte problem!
komm nicht auf die idee zu denken, ich habe ja eine backup von 2003er...wenn dein AD zerschossen ist! das könnte so enden, das für alle die vertrauenstellung hin ist, und kein login mehr möglich ist!
bin mal gespannt was dein schwaben chefchen dann sacht
Frank
Zitat von @kaineanung:
Frank, ja, ich habe deine Links sehr genau gelesen. Auch deine Kommentare hier verschlinge ich geradezu (ehrlich gesagt am liebsten da sehr genau und sehr gut). Ich habe nirgends gelesen daß der SBS nicht als DC-Server laufen kann. Er kann nicht ohne FSMO-Rollen laufen, das ist schon länger klar und wurde hier deutlich kommuniziert. Es wäre aber eine Möglichkeit gewesen daß er eventuell eben OHNE DC-Rolle läuft und dann auch ohne FSMO. Scheint zwar nicht der Fall zu sein wie ich jetzt weiß, aber vor deinem Kommentar war diese Frage ja noch nicht gestellt und nicht beantwortet, also offen.
Und wegen meiner fehlenden Weitsicht:
Vorgesetzter, der eine extrem feste Meinung zu allem hat und immer gerne Recht hat, sagt: Herr XY, der einzige DC-Server bei unserer Tochter geht alle paar Tage aus. Ist fast 20 Jahre alt und da läuft ein SBS drauf. Bitte gestern irgendwas tun damit die Domäne gerettet wird und die Daten sowieso.
Machen Sie doch gleich eine neue Serverstruktur und am besten auf einer neuen SAN und ESX-Servern. Externe Dienstleister brauchen Sie doch gar nicht. Sie sind doch sehr gut... Ach ja, und kosten sollte das ganze am besten so wenig wie möglich. Sie wissen ja, wir sind ein armes schwäbisches mittelständisches Familienunternehmen...... "Augenzwinker'...
Ich: ok. Ich muss mich reinlesen in ESX und SAN, Angebote einholen für die Hardware und die Lizenzen. Dann selber aufbauen und zum laufen bringen und ESX-SAN-Schnell-Crashkurs in diversen Foren usw. machen.
Frage an Vorgesetzten: was läuft denn alles auf dem SBS?
Vorgesetzer: eMail bin ich mir nicht sicher, notfalls haben die halt Pech gehabt. Haben ja sicher noch ein eMailarchiv... DC und Fileserver und Druckerfreigaben und sonst NICHTS.
Ich: Ok, dann mache ich mich mal auf die Socken......
.
.
.
So, was soll ich dazu sagen? Ich bin hier definitv das Opfer.....
warum kannst du nicht einfach sagen, sorry, das kann ich nicht?Frank, ja, ich habe deine Links sehr genau gelesen. Auch deine Kommentare hier verschlinge ich geradezu (ehrlich gesagt am liebsten da sehr genau und sehr gut). Ich habe nirgends gelesen daß der SBS nicht als DC-Server laufen kann. Er kann nicht ohne FSMO-Rollen laufen, das ist schon länger klar und wurde hier deutlich kommuniziert. Es wäre aber eine Möglichkeit gewesen daß er eventuell eben OHNE DC-Rolle läuft und dann auch ohne FSMO. Scheint zwar nicht der Fall zu sein wie ich jetzt weiß, aber vor deinem Kommentar war diese Frage ja noch nicht gestellt und nicht beantwortet, also offen.
Und wegen meiner fehlenden Weitsicht:
Vorgesetzter, der eine extrem feste Meinung zu allem hat und immer gerne Recht hat, sagt: Herr XY, der einzige DC-Server bei unserer Tochter geht alle paar Tage aus. Ist fast 20 Jahre alt und da läuft ein SBS drauf. Bitte gestern irgendwas tun damit die Domäne gerettet wird und die Daten sowieso.
Machen Sie doch gleich eine neue Serverstruktur und am besten auf einer neuen SAN und ESX-Servern. Externe Dienstleister brauchen Sie doch gar nicht. Sie sind doch sehr gut... Ach ja, und kosten sollte das ganze am besten so wenig wie möglich. Sie wissen ja, wir sind ein armes schwäbisches mittelständisches Familienunternehmen...... "Augenzwinker'...
Ich: ok. Ich muss mich reinlesen in ESX und SAN, Angebote einholen für die Hardware und die Lizenzen. Dann selber aufbauen und zum laufen bringen und ESX-SAN-Schnell-Crashkurs in diversen Foren usw. machen.
Frage an Vorgesetzten: was läuft denn alles auf dem SBS?
Vorgesetzer: eMail bin ich mir nicht sicher, notfalls haben die halt Pech gehabt. Haben ja sicher noch ein eMailarchiv... DC und Fileserver und Druckerfreigaben und sonst NICHTS.
Ich: Ok, dann mache ich mich mal auf die Socken......
.
.
.
So, was soll ich dazu sagen? Ich bin hier definitv das Opfer.....
was ist, wenn du die kiste in den sand fahrst.... datenverlust, ausfall etc... ?
ABER: ich habe mein Teil der Aufgaben dank diverser anderer Foren bezüglich ESX und SAN hervorragend gelöst (ich habe tatsächlich alles alleine aufgebaut mit miniSAS-SAN angebunden auf mehreren ESX-Servern und einer VCSA mit allem drum und drann..) und dank euch hier eben der Teil mit dem SBS selber.
Wenn mein Vorgesetzter jetzt um die Ecke kommt und sagt: nene, der muss noch laufen weil so und so.. ja was soll ich da dann machen?
frage doch mal deinen chef wer haftet wenn... und ob du das schriftlich bekommst!
P.S. meine Aufgabe wäre es sicherlich gewesen rauszufinden was alles auf dem Server läuft. Mein Vorgesetzer will aber die Zügel in der Hand haben und ich soll nur das ausführende Organ sein. Das hat er dann auch bekommen....
Aber eines will ich doch noch fragen:
Ich habe gefragt:
Kann der SBS auch als 'NICHT-DC' laufen und somit nur als Fileserver, Printserver oder irgendein-Server laufen? Dann könnte ich nämlich komplett migrieren und den alten demoten und somit die Gesamtstruktur anheben.<<
in der regel nicht mehr sauber....<
Nicht mehr sauber hört sich nach einem "JAEIN" an? Was heisst nicht mehr sauber? Alle MS-Dienste werden nicht mehr bnötigt. Wenn der Server ohne DC-Rolle einfach nur läuft ohne sich abzuschalten, dann hätte ich ja das was ich wollte....
Ansonsten bleibt mir dann nichts übrig als abzuwarten. Leider haben wir für den 2012er DC keine Lizenz und die Evaluation-Periode ist ja nicht so üppig.
tja... dann warte ab.. und kauf eine 2012 lizenz!Wenn ich die SYSVOL nun repariert habe, dann könnte ich den 2012er doch demoten und einen 2016 promoten als 2. DC?
nein...wie ich schon geschrieben habe, 2016 geht nicht mit 2003...Ich kann ja später die Migration von FSR auf DFRS versuchen und wenn es nicht klappt dann demoten und wieder einen 2012 promoten? Das dauert ja nicht allzulange mit promoten / demoten?
da gibbet kein später...Jetzt mal unabhängig von meinen angeblichen und tatsächlichen Verfehlungen in dieser Migrations-Geschichte. Könnte ich den 2012er nun demoten in Hinsicht auf die gesetzen Burflags?
dir bleibt nur der weg richtung 2016 ohne 2003...komm nicht auf die idee zu denken, ich habe ja eine backup von 2003er...wenn dein AD zerschossen ist! das könnte so enden, das für alle die vertrauenstellung hin ist, und kein login mehr möglich ist!
bin mal gespannt was dein schwaben chefchen dann sacht
Frank
Holla die Waldfee ist hier viel passiert!
Interessante Lektüre, auf jeden Fall
Frank muss ich in allen Punkten recht geben.
Normalerweise kannst du für deine eingesetzten Lizenzen Downgrade-Kits kaufen das dich berechtigt auch frühere Versionen einzusetzen.
Allerdings weiß ich gar nicht ob du das für 2016 noch kriegst. Da musst du deinen Distributor fragen ob er das noch anbietet.
Ansonsten ist hier erstmal Schluss, mehr kannst du nicht machen
Interessante Lektüre, auf jeden Fall
Frank muss ich in allen Punkten recht geben.
Normalerweise kannst du für deine eingesetzten Lizenzen Downgrade-Kits kaufen das dich berechtigt auch frühere Versionen einzusetzen.
Allerdings weiß ich gar nicht ob du das für 2016 noch kriegst. Da musst du deinen Distributor fragen ob er das noch anbietet.
Ansonsten ist hier erstmal Schluss, mehr kannst du nicht machen
