Eye-Q

Bevor wir dir hier die Antwort vorkauen eine Gegenfrage: hast Du überhaupt versucht, selbst eine Lösung zu finden (wenn ja, was denkst Du was die Lösung sein könnte?) oder glaubst Du, die Frage mit eigenem darüber Nachdenken sowieso nicht herauszufinden? Im zweiteren Fall werde zumindest ich dir nicht helfen, da das später im Berufsleben auch eher schlecht als recht funktioniert (ich gehe davon aus, dass Du noch Azubi bist, sonst bekommt man solche Fragen eigentlich nicht gestellt)...

Nein, das ist schon richtig so.
Sophos RED sind Netzwerkgeräte, die mit ihrem WAN-Port an einen vorhandenen Router angeschlossen werden, von diesen eine IP-Adresse per DHCP beziehen und sich anschließend mit ihrer Seriennummer bei einem Sophos-Server im Internet melden. Dort ist verzeichnet, zu welchem Hostnamen sich die RED verbinden soll, das tut die dann und die Sophos-Firewall, bei der sich die meldet, verwaltet dann die RED inklusive DHCP-Server-Dienst an den LAN-Ports der RED. So können kleine Außenstellen schnell an die Zentrale angebunden werden, ohne dass jemand mit vielen IT-Kenntnissen in die Außenstellen tigern muss.
Das machen Router, die sich ihre IP-Adresse z.B. von einem Kabelmodem per DHCP holen und intern einen DHCP-Server-Dienst bereitstellen, genauso.
 
Zur (schon beantworteten) Frage an sich: ich hätte auch darauf getippt, dass jemand einen LAN-Anschluss der Fritzbox ebenfalls an den internen Switch, der eigentlich komplett hinter der RED hängen soll, angeschlossen hat. Eine statische IP-Adresse an der Fritzbox braucht die RED auf keinen Fall, da der RED-Tunnel zur Sophos-Firewall in der Zentrale von der RED initiiert wird und die Fritzbox ausgehend standardmäßig nichts blockt.
Was Du machen könntest, um so etwas zukünftig zu verhindern, ohne dass der DHCP-Dienst der Fritzbox deaktiviert wird: die DHCP-Range der Fritzbox auf eine einzelne IP-Adresse beschränken, dann kann kein anderes Gerät, was an einem LAN-Port der Fritzbox angeschlossen wird, eine DHCP-Adresse erhalten.

Öhm, ein WSUS ist nicht einfach "Fire and forget", sondern der muss auch gepflegt werden, damit die WSUS-Datenpartition nicht einfach komplett vollgeschrieben wird, es muss entschieden werden, welche Updates genehmigt werden sollen etc. Außerdem ist der WSUS ja eigentlich nur dazu da, um die Updates zentral bereitzustellen anstatt dass sich jeder Server und Client einzeln die Updates aus dem Internet herunterlädt.
Die Entscheidung, wann die Updates installiert werden, ist vom WSUS unabhängig und kann einfach per Gruppenrichtlinien eingestellt werden. Die Einstellung per Gruppenrichtlinien hat natürlich den Nachteil, dass man nicht einfach zentral sagen kann "mach' mal jetzt Updates", sondern es eben einen festen Zeitraum gibt, in dem die Updates installiert werden, der nur durch Änderung der Gruppenrichtlinie geändert werden kann.
 
A propos Gruppenrichtlinien: anhand dieses Stichworts gehe ich davon aus, dass es eine Windows-Domäne gibt, richtig? Ohne Windows-Domäne sind natürlich Gruppenrichtlinien auch hinfällig...

Das geht aus deiner ursprünglichen Fragestellung aber mal komplett überhaupt nicht hervor...
 
Eine der Alternativen zur serverbasierten Backup-Lösung ist eine clientbasierte Backup-Lösung - ob eine clientbasierte Backup-Lösung besser oder schlechter (effizienter oder ineffizienter/günstiger oder teurer/schneller oder langsamer) ist, kommt immer auf den Anwendungsfall an, aber da Du bisher nur sehr verallgemeinert gefragt hast, können wir nur verallgemeinert antworten.

Wieso willst Du die Switches zwischen den VLANs routen lassen? So könnte das Gast-WLAN ja wieder auf das interne LAN zugreifen und Du hättest so gut wie nichts gewonnen...
Stattdessen solltest Du auch auf dem Draytek-Router ein entsprechendes VLAN 2 mit IP-Adresse 192.168.2.10 anlegen, am besten sollte der auch den DHCP-Server für das VLAN beinhalten, der dann die 192.168.2.10 als Gateway ausgibt. Dann im Draytek-Router einstellen, dass das VLAN 2 nur auf das Internet zugreifen darf und fertig ist die Laube.

Für einen seriösen Vergleich gibt es zu wenige Informationen, denn aus deinem Text wird die Infrastruktur nicht klar: es könnte sein, dass die "mehreren 100 Mbit/s-Switches", der Server und die Internetleitung untereinander über einen zentralen Switch verbunden sind, es könnte aber auch sein, dass mehrere Switches kaskadiert sind und der Server bzw. die Internetleitung an einem der am ungünstigsten angeschlossenen Switches verbunden sind.
Allgemein ist zu sagen, dass sich bei so einer relativ geringen Internetbandbreite subjektiv wahrscheinlich in Richtung Internet nicht viel tun wird, nur in Richtung interner Server kann es gut sein, dass sich die erhöhte Bandbreite auch subjektiv auswirkt, je nach Bandbreitenanforderungen der Anwender. Ein klarer Vorteil einer strukturierten Verkabelung (d.h. einem Netzwerkschrank mit einem oder zwei Switches und Patchpanels) ist, dass bei einem Netzwerkproblem nicht an mehreren Stellen, sondern idealerweise nur an einer zentralen Stelle nach dem Fehler gesucht werden muss. Außerdem haben dann theoretisch alle PCs gleich viel Bandbreite zur Verfügung und es müssen sich nicht mehrere PCs einen 100 Mbit/s-Uplink zum nächsten Switch teilen, der dann vielleicht auch nur einen 100 Mbit/s-Uplink zum darauf folgenden Switch besitzt etc., was die effektive Bandbreite für die PCs, die am "entferntesten" Switch verbunden sind, verringert, solange mehrere PCs gleichzeitig hohe Bandbreitenanforderungen haben.

Das hört sich schon mal nach einer soliden Basis an, auf der aufgebaut werden kann.
Die Bereitschaft zur Weiterentwicklung und die Affinität zur IT lässt sich nicht gut aneignen, Wissen schon. Da Du anscheinend die ersten beiden Punkte besitzt, sollte der letzte Punkt auch kein Problem darstellen. Da Du als IT-Kundenbetreuerin gearbeitet hast, solltest Du zumindest so weit im Thema drin sein, dass Du nicht wie der Ochs' vor'm Berg da stehst, und kein Arbeitgeber erwartet, dass Du gleich von 0 auf 100 einsteigen kannst.
 
Also: nur keine Panik, und falls es mit diesem Job nichts wird, gibt es massenweise andere Angebote, da IT-Fachkräfte händeringend gesucht werden. Eventuell speziell auf "Junior"-Stellen bewerben, da sollte dir beim Einstieg noch mehr zur Hand gegangen werden, da diese Stellen eben dafür ausgelegt sind (sein sollten), unerfahrenere Leute gut einzuarbeiten.

Kein Exchange heißt ja, dass das Outlook mindestens ein POP3- oder IMAP-Postfach eingebunden hat. Die Kennwörter, die man im Outlook speichert, sind in Windows unter "Netzwerkkennwörter" zu finden. Das einfach in das Suchfenster im Startmenü eintippen und schon können alle Einträge, die mit "Outlook" zu tun haben, entfernt werden. Anschließend Outlook erneut abfragen lassen, dann sollte das Kennwort, was per "Kennwort speichern" in die Netzwerkkennwörter eingetragen wird, als einzige Möglichkeit für Outlook bleiben, wenn es das POP3/IMAP-Konto abruft und die Kennwortabfrage sollte nicht mehr erscheinen.

Ein DNS-Server kann beides, also einen Hostnamen zu einer IP-Adresse auflösen (Forward Lookup) und eine IP-Adresse zu einem Hostnamen auflösen (Reverse Lookup). Das Reverse Lookup ist jedoch nicht so wichtig wie das Forward Lookup, denn die Geräte müssen ja in eine Domäne mit einem Domänennamen und nicht in eine Domäne mit einer Domänen-IP aufgenommen werden, richtig? 
Was meinst Du mit "meine IP"? Eine Reverse-Lookupzone umfasst normalerweise ein gesamtes Subnetz, keine einzelne IP-Adresse. Am besten ist es, erstmal eine Forward- und dann eine Reverse-Lookupzone einzurichten. Standardmäßig werden die Clients dann in beide Zonen eingetragen, sobald die sich eine IP-Adresse vom in das AD integrierten DHCP-Server holen.
Nein und Ja.
Wenn der Windows Server nicht den DHCP-Server spielt, muss das ja ein anderes Gerät machen, wahrscheinlich dein Router. Dieser Router weiß jedoch von der Domäne überhaupt nichts, deswegen können die Clients, die sich ebenfalls die Adressen vom DHCP-Server im Router holen, den Domänennamen nicht auflösen und deswegen nicht der Domäne beitreten. Deswegen sollte der DHCP-Server des Routers deaktiviert werden, denn zwei DHCP-Server in einem Netzwerk sind kontraproduktiv.
 
Es ist am einfachsten zu handhaben, wenn (einer) der Domänencontroller sowohl DNS- als auch DHCP-Server spielt, denn so verzahnen sich die Dienste (Active Directory, DNS und DHCP) am besten. Dafür ist es Pflicht, dass der Domänencontroller eine statische IP-Adresse erhält, und zwar aus einem Bereich, der nicht vom später einzurichtenden DHCP-Server verteilt wird. Als DNS-Server bekommt der dann (falls vorhanden) die IP-Adresse des zweiten Domänencontrollers und seine eigene IP-Adresse mitgeteilt, das Standardgateway ist die IP-Adresse des Routers.
Wenn Du den DHCP-Server auf dem Domänencontroller einrichtest, musst Du auch einen Bereich angeben, in dem der DHCP-Server Adressen verteilen soll, da sollte ein sinnvoller Bereich gewählt werden, bei einem Subnetz 192.168.0.0/24 dann z.B. 192.168.0.100 bis 192.168.0.253. So hast Du genügend freie IP-Adressen, die Du statisch an Server, Drucker, NAS-Boxen etc. verteilen kannst, nämlich die unterhalb von 192.168.0.100. In den DHCP-Optionen muss eingestellt werden, welche IP-Adresse den DNS-Server bereitstellt (in diesem Fall die IP-Adresse des Domänencontrollers) und welche IP-Adresse das Standardgateway ist (die IP-Adresse des Routers).
Wenn sich die Clients dann eine IP-Adresse vom DHCP holen und Du die in die Domäne aufnehmen willst, fragen die den Domänencontroller nach dem Namen der Domäne und der gibt zurück, dass die dazugehörige IP-Adresse er selbst ist.

Ob man nun Hyper-V, ESXi oder sonstwas nimmt, ist wurscht, der Unterbau ist für die Lizenzierung egal.
Das ist dann sozusagen wie im VMWare Workstation Player, wenn man die GUI installiert. Man darf sogar einen normalen Windows Server auf das Blech installieren, die Hyper-V-Rolle installieren und dann zwei VMs einrichten, dann darf das Hostbetriebssystem aber nichts anderes machen als Hyper-V zu hosten. Alternativ kann man wie geschrieben einen Hyper-V-Server (ohne GUI), einen ESXi, einen Xen oder sonstwas installieren und die dann über ihre Verwaltungsmöglichkeiten verwalten, um auf die Konsole der Gäste zu kommen.

Wir kaufen in der Firma oft Lizenzen von usedSoft, das klappt immer bestens.
So eine CAL gibt es nicht, es gibt Windows Server CALs, die es in User- und Device-CAL-Ausführung gibt. Wenn man sich 10 Windows Server 2016-CALs kauft, ist man berechtigt, auf beliebig viele Windows Server 2016 innerhalb des selben Netzwerks zuzugreifen, trotzdem heißt sie nicht "Netzwerk User CAL".
 
Eine Anmerkung noch zum Vorhaben: ich hoffe, dass ihr nicht vor habt, einen Domänencontroller einzurichten und die User dann per RDP auf diesem Server per RDP arbeiten zu lassen, das geht sowieso nur mit extremer Verbiegung der Rechte. Besser ist es, den DC zu virtualisieren (falls neue Hardware angeschafft werden soll und es eigentlich geplant war, den Windows Server direkt auf's Blech zu installieren) und eine zusätzliche VM als Terminalserver einzurichten. Mit einer Windows Server 2016 Standard-Lizenz ist man auch berechtigt, zwei VMs einzurichten, lizenztechnisch ist das also sauber.

Ein DNS-Server kann beides, also einen Hostnamen zu einer IP-Adresse auflösen (Forward Lookup) und eine IP-Adresse zu einem Hostnamen auflösen (Reverse Lookup). Das Reverse Lookup ist jedoch nicht so wichtig wie das Forward Lookup, denn die Geräte müssen ja in eine Domäne mit einem Domänennamen und nicht in eine Domäne mit einer Domänen-IP aufgenommen werden, richtig? 
Was meinst Du mit "meine IP"? Eine Reverse-Lookupzone umfasst normalerweise ein gesamtes Subnetz, keine einzelne IP-Adresse. Am besten ist es, erstmal eine Forward- und dann eine Reverse-Lookupzone einzurichten. Standardmäßig werden die Clients dann in beide Zonen eingetragen, sobald die sich eine IP-Adresse vom in das AD integrierten DHCP-Server holen.
Nein und Ja.
Wenn der Windows Server nicht den DHCP-Server spielt, muss das ja ein anderes Gerät machen, wahrscheinlich dein Router. Dieser Router weiß jedoch von der Domäne überhaupt nichts, deswegen können die Clients, die sich ebenfalls die Adressen vom DHCP-Server im Router holen, den Domänennamen nicht auflösen und deswegen nicht der Domäne beitreten. Deswegen sollte der DHCP-Server des Routers deaktiviert werden, denn zwei DHCP-Server in einem Netzwerk sind kontraproduktiv.
 
Es ist am einfachsten zu handhaben, wenn (einer) der Domänencontroller sowohl DNS- als auch DHCP-Server spielt, denn so verzahnen sich die Dienste (Active Directory, DNS und DHCP) am besten. Dafür ist es Pflicht, dass der Domänencontroller eine statische IP-Adresse erhält, und zwar aus einem Bereich, der nicht vom später einzurichtenden DHCP-Server verteilt wird. Als DNS-Server bekommt der dann (falls vorhanden) die IP-Adresse des zweiten Domänencontrollers und seine eigene IP-Adresse mitgeteilt, das Standardgateway ist die IP-Adresse des Routers.
Wenn Du den DHCP-Server auf dem Domänencontroller einrichtest, musst Du auch einen Bereich angeben, in dem der DHCP-Server Adressen verteilen soll, da sollte ein sinnvoller Bereich gewählt werden, bei einem Subnetz 192.168.0.0/24 dann z.B. 192.168.0.100 bis 192.168.0.253. So hast Du genügend freie IP-Adressen, die Du statisch an Server, Drucker, NAS-Boxen etc. verteilen kannst, nämlich die unterhalb von 192.168.0.100. In den DHCP-Optionen muss eingestellt werden, welche IP-Adresse den DNS-Server bereitstellt (in diesem Fall die IP-Adresse des Domänencontrollers) und welche IP-Adresse das Standardgateway ist (die IP-Adresse des Routers).
Wenn sich die Clients dann eine IP-Adresse vom DHCP holen und Du die in die Domäne aufnehmen willst, fragen die den Domänencontroller nach dem Namen der Domäne und der gibt zurück, dass die dazugehörige IP-Adresse er selbst ist.

Da gibt es zwei Möglichkeiten:
DHCP-Reservierung für den TP-Link in der Fritzbox einstellen Im TP-Link den WAN-Port von DHCP auf statische IP umstellen und die Einstellungen tätigen Kommt im Prinzip auf's gleiche hinaus, nämlich dass der WAN-Port des TP-Links eine statische IP-Adresse hat.

Schau' mal, ob Veeam Backup for Office 365 funktioniert. Ist zwar eigentlich "nur" für Exchange im eigenen Haus und Office 365 gedacht, die Technik dürfte aber bei einem Hosted Exchange genauso sein.

Im TP-Link steht als Standargateway und als DNS-Server die interne IP-Adresse der Fritzbox bzw. der TP-Link erhält von der Fritzbox seine IP-Adresse auf dem WAN-Port.
Du hast geschrieben die Fritzbox erscheint im TP-Link mit der WAN-IP, was nicht das selbe ist.
Ja, sonst gibt es ja keine Möglichkeit, Portfreigaben/-weiterleitungen in der Fritzbox einzurichten...
Weil ich im ersten Abschnitt empfohlen habe, dass Du dem TP-Link auf dem WAN-Port diese IP-Adresse geben solltest, damit der TP-Link immer die selbe IP-Adresse besitzt, auf die die Portweiterleitung der Fritzbox zeigen kann.
Wenn Du den TP-Link weiterhin so eingestellt lässt, dass der sich eine IP-Adresse per DHCP holt, kann es sein, dass sich die WAN-IP-Adresse des TP-Link ändert und die Portweiterleitung der Fritzbox dann nicht mehr funktioniert.

"Ausgehend" und "eingehend" sind meiner Meinung nach hier nicht die richtigen Begriffe. In diesen Routern stellt man einfach ein, ob eine Verbindung, die auf einem bestimmten Port von extern kommt, auf dem selben oder einem anderen Port an eine interne IP-Adresse weitergereicht wird, das war's.
Eher andersherum, oder? Der TP-Link erscheint in der Fritzbox mit seiner WAN-IP. Da diese WAN-IP in der Standard-DHCP-Range der Fritzbox liegt (ab der 192.168.178.20), gehe ich davon aus, dass der TP-Link seine IP-Adresse von der Fritzbox per DHCP erhalten hat, sofern die DHCP-Range in der Fritzbox nicht geändert wurde. Für eine Portweiterleitung ist eine statische IP-Adresse jedoch besser, also solltest Du im TP-Link folgendes auf dem WAN-Port einstellen:
IP-Adresse 192.168.178.10 (falls Du diese IP-Adresse noch keinem anderen Gerät hinter der Fritzbox gegeben hast, ansonsten eine andere freie zwischen 192.168.178.2 und 192.168.178.19) Subnetzmaske: 255.255.255.0 Standard-Gateway: 192.168.178.1 DNS-Server: 192.168.178.1 Dann im TP-Link die Portweiterleitungen einrichten:
Port 52000 auf die 192.168.0.111 Port 53000 auf die 192.168.0.112 Anschließend in der Fritzbox folgende Portweiterleitungen einrichten:
Port 52000 auf die 192.168.178.10 (bzw. die IP-Adresse, die Du dem WAN-Port des TP-Link gegeben hast) Port 53000 auf die 192.168.178.10 (bzw. die IP-Adresse, die Du dem WAN-Port des TP-Link gegeben hast) Dann kannst Du per <DynDNS-Name>:52000 auf das Gerät mit der 192.168.0.111 und per <DynDNS-Name>:53000 auf das Gerät mit der 192.168.0.112 zugreifen, weil die Fritzbox beide Verbindungen, die von außen kommen, auf den selben Port auf die WAN-IP des TP-Link leitet und der TP-Link dann die eine Verbindung auf die 192.168.0.111 und die andere auf die 192.168.0.112 leitet.

"Verbinden" ist eine unklare Bezeichnung, deswegen kann es keine allgemeingültige Aussage zu "es ist mir nicht gelungen" treffen.
Also: Was meinst Du genau mit "verbinden" und an welchem Punkt kommst Du nicht weiter?

Ich werde ganz sicher keine Office-Dokumente aus mir unbekannter Quelle öffnen. Sinnvollerweise stellt man so etwas entweder als PDF zur Verfügung oder alternativ als Bild, das hier direkt angezeigt werden kann.

https://de.wikipedia.org/wiki/Private_IP-Adresse
Ich fürchte, wenn Du solche Basis-Fragen stellst und die nur jede für sich einzeln, wird das hier sehr lange dauern. Am besten Du schaust dir mal einen Grundlagenkurs für Netzwerktechnik an, bevor Du dir falsche Dinge angewöhnst.
 
P.S.: in Foren siezt man üblicherweise nicht, außer man ist in einem Anwalts-Forum oder so, allerdings sind wir das hier nicht.

Ein DNS-Server kann beides, also einen Hostnamen zu einer IP-Adresse auflösen (Forward Lookup) und eine IP-Adresse zu einem Hostnamen auflösen (Reverse Lookup). Das Reverse Lookup ist jedoch nicht so wichtig wie das Forward Lookup, denn die Geräte müssen ja in eine Domäne mit einem Domänennamen und nicht in eine Domäne mit einer Domänen-IP aufgenommen werden, richtig? 
Was meinst Du mit "meine IP"? Eine Reverse-Lookupzone umfasst normalerweise ein gesamtes Subnetz, keine einzelne IP-Adresse. Am besten ist es, erstmal eine Forward- und dann eine Reverse-Lookupzone einzurichten. Standardmäßig werden die Clients dann in beide Zonen eingetragen, sobald die sich eine IP-Adresse vom in das AD integrierten DHCP-Server holen.
Nein und Ja.
Wenn der Windows Server nicht den DHCP-Server spielt, muss das ja ein anderes Gerät machen, wahrscheinlich dein Router. Dieser Router weiß jedoch von der Domäne überhaupt nichts, deswegen können die Clients, die sich ebenfalls die Adressen vom DHCP-Server im Router holen, den Domänennamen nicht auflösen und deswegen nicht der Domäne beitreten. Deswegen sollte der DHCP-Server des Routers deaktiviert werden, denn zwei DHCP-Server in einem Netzwerk sind kontraproduktiv.
 
Es ist am einfachsten zu handhaben, wenn (einer) der Domänencontroller sowohl DNS- als auch DHCP-Server spielt, denn so verzahnen sich die Dienste (Active Directory, DNS und DHCP) am besten. Dafür ist es Pflicht, dass der Domänencontroller eine statische IP-Adresse erhält, und zwar aus einem Bereich, der nicht vom später einzurichtenden DHCP-Server verteilt wird. Als DNS-Server bekommt der dann (falls vorhanden) die IP-Adresse des zweiten Domänencontrollers und seine eigene IP-Adresse mitgeteilt, das Standardgateway ist die IP-Adresse des Routers.
Wenn Du den DHCP-Server auf dem Domänencontroller einrichtest, musst Du auch einen Bereich angeben, in dem der DHCP-Server Adressen verteilen soll, da sollte ein sinnvoller Bereich gewählt werden, bei einem Subnetz 192.168.0.0/24 dann z.B. 192.168.0.100 bis 192.168.0.253. So hast Du genügend freie IP-Adressen, die Du statisch an Server, Drucker, NAS-Boxen etc. verteilen kannst, nämlich die unterhalb von 192.168.0.100. In den DHCP-Optionen muss eingestellt werden, welche IP-Adresse den DNS-Server bereitstellt (in diesem Fall die IP-Adresse des Domänencontrollers) und welche IP-Adresse das Standardgateway ist (die IP-Adresse des Routers).
Wenn sich die Clients dann eine IP-Adresse vom DHCP holen und Du die in die Domäne aufnehmen willst, fragen die den Domänencontroller nach dem Namen der Domäne und der gibt zurück, dass die dazugehörige IP-Adresse er selbst ist.

Das ist ja eine erschöpfende Aussage ... nicht ... 
Ich kann mir schon denken, woran es liegt, mit so wenigen Informationen ist das aber ein Raten in's Blaue hier, deswegen lasse ich meine Vermutungen sein...
Mal ein Denkansatz: damit ein Client den Domänencontroller erreichen kann, müssen der Domänenname und der Servername zu IP-Adressen aufgelöst werden. Welche Komponente tut das und wie bringst Du die Clients dazu, diese Komponente zu nutzen?
Anders herum gefragt: welche Komponente spielt bei dir den DHCP-Server und welche IP-Adresse gibt der als DNS-Server an die Clients? Kennt der DNS-Server, den die Clients somit befragen, die Domäne?

Das ist ja eine erschöpfende Aussage ... nicht ... 
Ich kann mir schon denken, woran es liegt, mit so wenigen Informationen ist das aber ein Raten in's Blaue hier, deswegen lasse ich meine Vermutungen sein...
Mal ein Denkansatz: damit ein Client den Domänencontroller erreichen kann, müssen der Domänenname und der Servername zu IP-Adressen aufgelöst werden. Welche Komponente tut das und wie bringst Du die Clients dazu, diese Komponente zu nutzen?
Anders herum gefragt: welche Komponente spielt bei dir den DHCP-Server und welche IP-Adresse gibt der als DNS-Server an die Clients? Kennt der DNS-Server, den die Clients somit befragen, die Domäne?

Was sind bei dir "IT-Themen zuhause"? Es gibt so eine Fülle an Dingen, die man erst im ständigen Berufsalltag richtig mitbekommt, dass "IT-Themen zuhause" teilweise ziemlich irrelevant sind, oder bist Du da ständig mit Gruppenrichtlinien, Virtualisierung, Exchange-Server, VLANs im Netzwerk, DAUs (die Dinge machen, die sie nicht sollen) etc. am rumspielen?
Es kann natürlich sein, dass die Themen, die Du zuhause hast, genau zu dem passen, was bei einer hypothetischen Stelle gefordert ist, die Wahrscheinlichkeit ist aber gering.
Zum Thema "was man heute lernt, kann morgen schon wieder obsolet sein": sooo schnell ändert sich die IT auch nicht. Im Vergleich zu anderen Feldern ist die IT relativ schnelllebig, allerdings bleiben viele Systeme (Server, Storages, Telefonanlagen, Netzwerke) ja jahrelang im Betrieb, bis sie abgeschrieben sind (oder sogar noch länger *hust*). Außerdem gibt es viele Dinge, die z.B. in Windows Server 2016 noch genauso sind wie in Windows Server 2003, dann gibt es aber auch größere Schnitte wie z.B. der Umstieg von Exchange 2010 zu 2013, da wurde vieles geändert, wobei auch einiges wiederum gleich geblieben ist.
 
Ergo: meiner Meinung nach ist Berufserfahrung durch nichts zu ersetzen als durch mehr Berufserfahrung, denn theoretisches Wissen ist gut, praktische Erfahrung bleibt aber deutlich länger kleben als wenn man mal einen Kurs für Software XY absolviert hat oder sich mal eine Woche zuhause mit einem virtualisierten Exchange (o.ä.) beschäftigt hat, ohne die Probleme kennengelernt zu haben, die so im täglichen Betrieb auftreten (können).

Was sind bei dir "IT-Themen zuhause"? Es gibt so eine Fülle an Dingen, die man erst im ständigen Berufsalltag richtig mitbekommt, dass "IT-Themen zuhause" teilweise ziemlich irrelevant sind, oder bist Du da ständig mit Gruppenrichtlinien, Virtualisierung, Exchange-Server, VLANs im Netzwerk, DAUs (die Dinge machen, die sie nicht sollen) etc. am rumspielen?
Es kann natürlich sein, dass die Themen, die Du zuhause hast, genau zu dem passen, was bei einer hypothetischen Stelle gefordert ist, die Wahrscheinlichkeit ist aber gering.
Zum Thema "was man heute lernt, kann morgen schon wieder obsolet sein": sooo schnell ändert sich die IT auch nicht. Im Vergleich zu anderen Feldern ist die IT relativ schnelllebig, allerdings bleiben viele Systeme (Server, Storages, Telefonanlagen, Netzwerke) ja jahrelang im Betrieb, bis sie abgeschrieben sind (oder sogar noch länger *hust*). Außerdem gibt es viele Dinge, die z.B. in Windows Server 2016 noch genauso sind wie in Windows Server 2003, dann gibt es aber auch größere Schnitte wie z.B. der Umstieg von Exchange 2010 zu 2013, da wurde vieles geändert, wobei auch einiges wiederum gleich geblieben ist.
 
Ergo: meiner Meinung nach ist Berufserfahrung durch nichts zu ersetzen als durch mehr Berufserfahrung, denn theoretisches Wissen ist gut, praktische Erfahrung bleibt aber deutlich länger kleben als wenn man mal einen Kurs für Software XY absolviert hat oder sich mal eine Woche zuhause mit einem virtualisierten Exchange (o.ä.) beschäftigt hat, ohne die Probleme kennengelernt zu haben, die so im täglichen Betrieb auftreten (können).

Erstmal: hast Du wirklich diese Subnetze oder hast Du die wegen Verschleierung geändert? Im zweiteren Fall bringt dir das null komma gar nichts, solange Du private IP-Ranges nutzt, die im Internet sowieso nicht geroutet werden und Du kannst auch die echten Subnetze angeben.
Dann:
Was heißt "angehängt"? Kannst Du das bitte mal aufzeichnen? So wie Du das beschreibst steige ich da nämlich nicht durch, wie das physikalisch miteinander verbunden ist, und ohne dass man weiß, wie das physikalisch miteinander zusammen hängt, ist das nur ein Ratespiel.