6
Schrittweiser Wechsel vom SBS 2011 zu WS 2016
Hallo,
wir habe bei uns seit vielen Jahren einen SBS 2011 im Einsatz. Nun soll das ganze auf eine neue Hardware umgezogen werden. Um die Leichen nicht mit in die neue Welt zu übernehmen, planen wir eine komplett neue Domäne aufzusetzen. Da wir nur eine kleine Firma sind, soll der Aufwand möglichst geringgehalten werden, unsere Tätigkeit erfordert aber ein paar Spezialitäten. Geplant ist folgendes:
Neue Hardware mit 4 NICs:
- Hyper-V Host auf Windows Server 2016 Standard Basis (nur Hyper-V Rolle und Backup-Software)
- Gast 1: Windows Server 2016 als DC, DNS, DHCP und Essentials Rolle für Client Backups und Freigaben
- Gast 2: zukünftig geplant, Windows Server 2016 mit Exchange 2016 (da wir sehr viele Postfächer und viele TLD im Einsatz haben, ist der gehostete Aufwand am Ende recht teuer und kompliziert).
- Gast 3: alter SBS 2011 für einen Übergangszeitraum
- Gast 4 ggf.: Windows Server 2016 Essentials, siehe Kommentar weiter unten
Deshalb wollen wir den SBS 2011 mit seiner alten Domäne (die dann nur noch er selbst verwendet) erst einmal weiterbetreiben. Er läuft jetzt schon in einer VM und dürfte somit einfach umgezogen werden können.
In Ruhe würden wir den Gast 2 einrichten und alles vorbereiten. Wenn es dann soweit ist, würde ein Wechsel vom alten zum neuen Exchange Server vorgenommen und anschließend der SBS stillgelegt.
Wir wissen natürlich, dass es besser wäre, die Rollen von Gast 1 auf mehrere VMs zu verteilen, aber das würden wir gerne vermeiden. Denkbar wäre noch, eine weitere Gast VM mit einem Windows Server 2016 Essentials einzurichten. Da sind die Lizenzkosten dann etwas geringer. Nur bin ich mir nach vielen Artikeln und Forumseinträgen immer noch nicht sicher, ob ein Essentials-Mitgliedsserver lizenzrechtlich und funktionsmäßig gestattet ist (also keine Lizenz-Warnmeldungen/-verletzungen oder ungewollte Neustarts).
Bei den IP-Adressen haben wir uns das beispielshaft so vorgestellt:
Router / Firewall: 192.168.16.1 | 255.255.0.0
Host: NIC 1 - 192.168.1.1 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 1: NIC 2 - 192.168.1.2 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 2: NIC 3 - 192.168.1.3 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 3: NIC 4 - 192.168.16.2 | 255.255.0.0 (DNS 192.168.16.2, „AlteDomäne“)
Die < 10 Clients werden dann mit der „NeueDomöne“ verbunden, bekommen eine 192.168.1.xxx IP mit 192.168.1.2 als DNS-Server.
Die Mails werden über das Internet abgerufen bzw. verschickt (zumindest solange der Exchange vom alten SBS noch verwendet wird).
Haben wir da irgendwo einen Denkfehler im Konzept oder würde drängen sich Verbesserungen auf, ohne alles deutlich komplizierter zu machen?
Vielen Dank schon mal an alle Profis
Hans
wir habe bei uns seit vielen Jahren einen SBS 2011 im Einsatz. Nun soll das ganze auf eine neue Hardware umgezogen werden. Um die Leichen nicht mit in die neue Welt zu übernehmen, planen wir eine komplett neue Domäne aufzusetzen. Da wir nur eine kleine Firma sind, soll der Aufwand möglichst geringgehalten werden, unsere Tätigkeit erfordert aber ein paar Spezialitäten. Geplant ist folgendes:
Neue Hardware mit 4 NICs:
- Hyper-V Host auf Windows Server 2016 Standard Basis (nur Hyper-V Rolle und Backup-Software)
- Gast 1: Windows Server 2016 als DC, DNS, DHCP und Essentials Rolle für Client Backups und Freigaben
- Gast 2: zukünftig geplant, Windows Server 2016 mit Exchange 2016 (da wir sehr viele Postfächer und viele TLD im Einsatz haben, ist der gehostete Aufwand am Ende recht teuer und kompliziert).
- Gast 3: alter SBS 2011 für einen Übergangszeitraum
- Gast 4 ggf.: Windows Server 2016 Essentials, siehe Kommentar weiter unten
Deshalb wollen wir den SBS 2011 mit seiner alten Domäne (die dann nur noch er selbst verwendet) erst einmal weiterbetreiben. Er läuft jetzt schon in einer VM und dürfte somit einfach umgezogen werden können.
In Ruhe würden wir den Gast 2 einrichten und alles vorbereiten. Wenn es dann soweit ist, würde ein Wechsel vom alten zum neuen Exchange Server vorgenommen und anschließend der SBS stillgelegt.
Wir wissen natürlich, dass es besser wäre, die Rollen von Gast 1 auf mehrere VMs zu verteilen, aber das würden wir gerne vermeiden. Denkbar wäre noch, eine weitere Gast VM mit einem Windows Server 2016 Essentials einzurichten. Da sind die Lizenzkosten dann etwas geringer. Nur bin ich mir nach vielen Artikeln und Forumseinträgen immer noch nicht sicher, ob ein Essentials-Mitgliedsserver lizenzrechtlich und funktionsmäßig gestattet ist (also keine Lizenz-Warnmeldungen/-verletzungen oder ungewollte Neustarts).
Bei den IP-Adressen haben wir uns das beispielshaft so vorgestellt:
Router / Firewall: 192.168.16.1 | 255.255.0.0
Host: NIC 1 - 192.168.1.1 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 1: NIC 2 - 192.168.1.2 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 2: NIC 3 - 192.168.1.3 | 255.255.0.0 (DNS 192.168.1.2, „NeueDomäne“)
Gast 3: NIC 4 - 192.168.16.2 | 255.255.0.0 (DNS 192.168.16.2, „AlteDomäne“)
Die < 10 Clients werden dann mit der „NeueDomöne“ verbunden, bekommen eine 192.168.1.xxx IP mit 192.168.1.2 als DNS-Server.
Die Mails werden über das Internet abgerufen bzw. verschickt (zumindest solange der Exchange vom alten SBS noch verwendet wird).
Haben wir da irgendwo einen Denkfehler im Konzept oder würde drängen sich Verbesserungen auf, ohne alles deutlich komplizierter zu machen?
Vielen Dank schon mal an alle Profis
Hans
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 386254
Url: https://administrator.de/contentid/386254
Printed on: April 20, 2024 at 00:04 o'clock
6 Comments
Latest comment
Moin,
leider einige - im Ergebnis wird es aber wahrscheinlich irgendwie funktionieren
Ich rate dringend euch ein Systemhaus mit ins Boot zu holen. (das Thema ist im Verhältnis zu eurem Kenntnisstand zu komplex, um das hier mal eben abzuarbeiten)
Gruß
leider einige - im Ergebnis wird es aber wahrscheinlich irgendwie funktionieren
oder würde drängen sich Verbesserungen auf, ohne alles deutlich komplizierter zu machen?
die beiden Punkte schließen sich, wie hier, meist aus.Ich rate dringend euch ein Systemhaus mit ins Boot zu holen. (das Thema ist im Verhältnis zu eurem Kenntnisstand zu komplex, um das hier mal eben abzuarbeiten)
Gruß
Hallo Hans,
was spricht gegen eine Migration?
Läuft mit dem SBS2011 alles korrekt und es soll keine Umbenennung der Domäne stattfinden, würde ich mirgieren.
Gerade, wenn der Exchange umfassend konfiguriert wurde (ÖOs, Transportregeln, etc).
Die Mitarbeiter merken im Idealfall gar nicht mal, dass es einen Systemwechsel gegeben hat.
was spricht gegen eine Migration?
Läuft mit dem SBS2011 alles korrekt und es soll keine Umbenennung der Domäne stattfinden, würde ich mirgieren.
Gerade, wenn der Exchange umfassend konfiguriert wurde (ÖOs, Transportregeln, etc).
Die Mitarbeiter merken im Idealfall gar nicht mal, dass es einen Systemwechsel gegeben hat.
Hmm, vollumfassend kann ich das nicht auf die Schnelle analysieren, mir sind bloß gleich 2 Punkte aufgefallen:
- der Hyper-V darf kein Mitglied der Domäne werden (egal ob Domäne alt oder Domäne neu), da der neue DC ja auch nur virtuell auf eben diesem Hyper-V sein wird. Andernfalls gäb's ein Henne-Ei-Problem nach dem Neustart des Hypervisors. Ihn nicht in die Domäne aufzunehmen, hätte aber auch Nachteile, unter anderem würde die Möglichkeit wegfallen (falls Ihr Euch zukünftig dafür entscheiden wolltet), mit einem zweiten, bau- und leistungsgleichen Hyper-V das sog. "Hyper-V-Replica"-Feature zu nutzen, denn das benötigt mindestens eine Kerberos-Authentifizierung, die es ohne Domäne nicht gibt. Dieses Problem ließe sich am Einfachsten durch einen Nicht-MS-Hypervisor beseitigen, nämlich durch VMware.
- sobald die neue Domäne läuft, aber der neue Exchange noch nicht, die Clients aber bereits in der neuen Domäne sind, können diese mit dem alten SBS (und dessen Exchange 2010) natürlich nicht mehr zusammenarbeiten, ich denke, das ist ein äußerst kritischer Punkt in Deiner Planung. Wenn Du vom alten Exchange auf den neuen "wechseln" willst, klingt das für mich eher nach Migration. Du schreibst aber, daß Du nicht migrieren willst, sondern eine ganz neue Domäne bauen willst. Diesen Punkt (E-Mail, Exchange) stellst Du Dir meines Erachtens zu einfach vor
Deine Bedenken, Gast 1 würde zu viele Rollen kriegen, kann ich zerstreuen, AD-DC, DNS und DHCP auf einer Maschine (bzw. in einer VM) ist durchaus üblich, ich kenne es gar nicht anders, zumindest im KMU-Bereich.
Ich verstehe bloß nicht, was Du zwischendurch immer wieder mit diesem Essential-Gedöns (Gast 1, Gast 4) herumtust. Virtuelle Maschinen würde ich komplett mit Veeam sichern (dazu empfiehlt sich eine eigene, andere, zusätzliche Hardware für den Veeam-Server/Verwaltung/Medienverwaltung, Veeam kann zusätzlich auch die Clients sichern).
Ich weiß nicht, wie wichtig E-Mails in Eurem täglichen Geschäft sind, aber nach dem, was und wie Du speziell dazu geschrieben hast, fällst Du dabei am Ehesten auf die Nase.
Alles in allem würde auch ich empfehlen, die Aktion als Projekt in Zusammenarbeit mit dem Systemhaus Deines geringsten Mißtrauens durchzuführen. Und die werden fast hundertprozentig sicher, wie es auch @goscho weiter oben geschrieben hat, zu einer Migration raten. Die gibt es, von entsprechend fachlichen Hirnen und Händen durchgeführt, auch "in sauber", Leichenbeseitigung inklusive.
Viele Grüße
von
departrue69
- der Hyper-V darf kein Mitglied der Domäne werden (egal ob Domäne alt oder Domäne neu), da der neue DC ja auch nur virtuell auf eben diesem Hyper-V sein wird. Andernfalls gäb's ein Henne-Ei-Problem nach dem Neustart des Hypervisors. Ihn nicht in die Domäne aufzunehmen, hätte aber auch Nachteile, unter anderem würde die Möglichkeit wegfallen (falls Ihr Euch zukünftig dafür entscheiden wolltet), mit einem zweiten, bau- und leistungsgleichen Hyper-V das sog. "Hyper-V-Replica"-Feature zu nutzen, denn das benötigt mindestens eine Kerberos-Authentifizierung, die es ohne Domäne nicht gibt. Dieses Problem ließe sich am Einfachsten durch einen Nicht-MS-Hypervisor beseitigen, nämlich durch VMware.
- sobald die neue Domäne läuft, aber der neue Exchange noch nicht, die Clients aber bereits in der neuen Domäne sind, können diese mit dem alten SBS (und dessen Exchange 2010) natürlich nicht mehr zusammenarbeiten, ich denke, das ist ein äußerst kritischer Punkt in Deiner Planung. Wenn Du vom alten Exchange auf den neuen "wechseln" willst, klingt das für mich eher nach Migration. Du schreibst aber, daß Du nicht migrieren willst, sondern eine ganz neue Domäne bauen willst. Diesen Punkt (E-Mail, Exchange) stellst Du Dir meines Erachtens zu einfach vor
Deine Bedenken, Gast 1 würde zu viele Rollen kriegen, kann ich zerstreuen, AD-DC, DNS und DHCP auf einer Maschine (bzw. in einer VM) ist durchaus üblich, ich kenne es gar nicht anders, zumindest im KMU-Bereich.
Ich verstehe bloß nicht, was Du zwischendurch immer wieder mit diesem Essential-Gedöns (Gast 1, Gast 4) herumtust. Virtuelle Maschinen würde ich komplett mit Veeam sichern (dazu empfiehlt sich eine eigene, andere, zusätzliche Hardware für den Veeam-Server/Verwaltung/Medienverwaltung, Veeam kann zusätzlich auch die Clients sichern).
Ich weiß nicht, wie wichtig E-Mails in Eurem täglichen Geschäft sind, aber nach dem, was und wie Du speziell dazu geschrieben hast, fällst Du dabei am Ehesten auf die Nase.
Alles in allem würde auch ich empfehlen, die Aktion als Projekt in Zusammenarbeit mit dem Systemhaus Deines geringsten Mißtrauens durchzuführen. Und die werden fast hundertprozentig sicher, wie es auch @goscho weiter oben geschrieben hat, zu einer Migration raten. Die gibt es, von entsprechend fachlichen Hirnen und Händen durchgeführt, auch "in sauber", Leichenbeseitigung inklusive
.Viele Grüße
von
departrue69
Zitat von @departure69:
Hmm, vollumfassend kann ich das nicht auf die Schnelle analysieren, mir sind bloß gleich 2 Punkte aufgefallen:
- der Hyper-V darf kein Mitglied der Domäne werden (egal ob Domäne alt oder Domäne neu), da der neue DC ja auch nur virtuell auf eben diesem Hyper-V sein wird. Andernfalls gäb's ein Henne-Ei-Problem nach dem Neustart des Hypervisors.
Sorry, aber das ist falsch. Es gibt kein Henne-Ei-Problem:Hmm, vollumfassend kann ich das nicht auf die Schnelle analysieren, mir sind bloß gleich 2 Punkte aufgefallen:
- der Hyper-V darf kein Mitglied der Domäne werden (egal ob Domäne alt oder Domäne neu), da der neue DC ja auch nur virtuell auf eben diesem Hyper-V sein wird. Andernfalls gäb's ein Henne-Ei-Problem nach dem Neustart des Hypervisors.
Schau mal hier rein:
Yes, Your Hyper-V Host Should be Domain-Joined
Myth 2: The Hyper-V Domain Controller Myths
I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.
I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.
Ich verstehe bloß nicht, was Du zwischendurch immer wieder mit diesem Essential-Gedöns (Gast 1, Gast 4) herumtust.
Genau, diesen sollte man sofort vergessen, wenn man virtualisiert.Virtuelle Maschinen würde ich komplett mit Veeam sichern (dazu empfiehlt sich eine eigene, andere, zusätzliche Hardware für den Veeam-Server/Verwaltung/Medienverwaltung, Veeam kann zusätzlich auch die Clients sichern).
Bei kleinen Umgebungen richte ich den Backupserver auf dem Hyper-V-Host ein.Dazu nutze ich Veritas BackupExec. Das kann sowohl physische als auch virtuelle Maschinen in einem Abwasch sichern.
@goscho:
O.K., dann ist das Henne-Ei-Problem nur theoretischer Natur bzw. tritt frühestens erst nach 180 Tagen permanenter Abwesenheit des DC auf (so lange funktionieren gecachte Anmeldecredentials maximal).
Ist ja sicherlich auch nicht kostenlos. Veeam kann das ebenfalls, und das sehr gut, und sind m. E. doch noch besser auf Virtualisierung spezialisiert als Symantec. Aber hier beginnen Glaubensfragen, mit denen wir den TE nicht belasten sollten. Er soll nur wissen, daß für seine zukünftige Umgebung alle Marken-Backupmethoden, die insbesondere auf Virtualisierung zielen bzw. diese ausdrücklich beherrschen, besser sind als die Backupmöglichkeiten der Essentials.
Viele Grüße
von
departure69
O.K., dann ist das Henne-Ei-Problem nur theoretischer Natur bzw. tritt frühestens erst nach 180 Tagen permanenter Abwesenheit des DC auf (so lange funktionieren gecachte Anmeldecredentials maximal).
Dazu nutze ich Veritas BackupExec. Das kann sowohl physische als auch virtuelle Maschinen in einem Abwasch sichern.
Ist ja sicherlich auch nicht kostenlos. Veeam kann das ebenfalls, und das sehr gut, und sind m. E. doch noch besser auf Virtualisierung spezialisiert als Symantec. Aber hier beginnen Glaubensfragen, mit denen wir den TE nicht belasten sollten. Er soll nur wissen, daß für seine zukünftige Umgebung alle Marken-Backupmethoden, die insbesondere auf Virtualisierung zielen bzw. diese ausdrücklich beherrschen, besser sind als die Backupmöglichkeiten der Essentials.
Viele Grüße
von
departure69
Erst einmal vielen Dank an alle Rückmeldungen und Denkanstöße. Der Essentials-Gedanke hat eigentlich nur mit dem Client-Backup zu tun. Ich nutze das privat seit Home-Server Zeiten und habe damit auch bei Wiederherstellungen immer gute Erfahrungen gemacht. Wobei lokal i.d.R. nichts gespeichert werden soll. Deshalb war die Überlegung, das auch in der Firma für die paar Clients einzusetzen (als Rolle auf dem Standard-Server oder eben als Essentials-VM). Ich werde nun mal eine Testumgebung mit Veem aufsetzung und mir das genauer ansehen. Unsere SBS 2011 VM sichern wir aktuell mit Altaro. Mit Veem würden alle Backups dann aus einer Hand kommen.
Den Altaro-Artikel zu Host-in-die-Domäne hatte ich ebenfalls bereits gelesen und es leuchtet ein. Deshalb ist das künftig so geplant. Aber das ist sicherlich eines der mehr "religiösen" Themen in der IT
Die Überlegung zu migrieren und nicht alles neu aufzusetzen ist der Tatsache geschuldet, dass im Laufe der vielen Jahre (und während der Lernkurve) nicht alles ganz richtig gemacht worden ist. Mit dem Exchange kennen wir uns mittlerweile recht gut aus, da wir diesen intensiv nutzen. Man siehts am Thread, da ist grundlegenden Themen mehr Unsicherheit
Wir werden das jetzt auf der neuen Hardware nochmals aufbauen und durchtesten.
Schönes Wochenende,
Hans
Den Altaro-Artikel zu Host-in-die-Domäne hatte ich ebenfalls bereits gelesen und es leuchtet ein. Deshalb ist das künftig so geplant. Aber das ist sicherlich eines der mehr "religiösen" Themen in der IT
Die Überlegung zu migrieren und nicht alles neu aufzusetzen ist der Tatsache geschuldet, dass im Laufe der vielen Jahre (und während der Lernkurve) nicht alles ganz richtig gemacht worden ist. Mit dem Exchange kennen wir uns mittlerweile recht gut aus, da wir diesen intensiv nutzen. Man siehts am Thread, da ist grundlegenden Themen mehr Unsicherheit
Wir werden das jetzt auf der neuen Hardware nochmals aufbauen und durchtesten.
Schönes Wochenende,
Hans
