kosta88

Ich muss ehrlich sagen, ich weiß nicht wovon du sprichst wenn du von Routinginstanzen sprichst. Mein Netzwerk-Wissen reicht für das Thema sicher nicht ganz genug, so kann ich teilweise nur von Aussagen anderer gehen. Aber das Thema NAT (also PAT) in meinem Beispiel ist mir doch irgendwie logisch. RZ kann unser Netz, also 10.146.32.0/24 sozusagen nicht "durchlassen", was auch logisch klingt, denn was würde passieren, wenn ein anderer Kunde auch den selben Bereich nutzt, speziell weil der VPN-Terminierungs-Punkt mit anderen Kunden geteilt ist. Deswegen vergibt uns RZ das Client-Netz, um die Clients in unserem Netzwerk doch mit einer IP - der übersetzter IP - erreichen zu können. Simples Routing wäre das, wenn RZ unser 10.146.32.0 kennen würde (ansprechen könnte), dann wäre das ganze ohne jeglichen Problem. Oder sehe ich das falsch? Kein Problem :) Ich weiß, das Thema verdreht mir auch die Augen. Wäre die PAT nicht vorhanden, würde ich die Clients aus 10.146.32.0 auf gar keine Weise erreichen können. Das Netz ist aus dem RZ nicht auffindbar/erreichbar. Ich kann das gerne nächste Woche ausprobieren, also die Übersetzung entfernen. Das hier ist eine Übersetzung von drinnen (10.146.32.0) nach draussen (10.241.56.0). Es gibt keine (eingerichtete) Rückübersetzung auf dem LANCOM - ob die automatisch geschieht, das weiß ich nicht.

Ich habe mir erlaubt Visio als Alternative mit der ich mich auskenne zu benutzen :) Die statische Route ist notwendig, und zwar als 10.146.32.0/24 10.241.56.251 (VPN Gateway). Wichtig zu verstehen ist eines: Nach die Route gesetzt wurde, kann ich die Clients nicht mit ihrer echten IP, sondern nur via übersetzter IP (Client-Netz-IP im RZ) zugreifen. ABER, aus irgendeinem Grund konnte ich einen Rechner den ich probiert habe, via DNS-Namen anpingen. Die angezeigte IP war jedoch aus dem Client-Netz Bereich. D.h. irgendwo werden die Einträge gepflegt, also es gibt eventuell irgendwo ein DNS im Client-Netz, und dieser sorgt dafür, dass ein "Client01.domain.local" mit der original-IP bspw. 10.146.32.10 den Eintrag client01.domain.local 10.241.56.10 bekommt, und so abgefragt werden kann. Würde erklären warum ich aus dem Server-Netz im RZ die IP 10.146.32.10 nicht pingen kann, aber wohl client01.domain.local (oder nur client01 sofern ich die DNS-suffixe eingetragen habe), und dieser antwortet als 10.241.56.10. Nun zu den Fragen, ich versuche sie nach meinen besten Fähigkeiten zu beantworten. Der einzige Bereich von der interne DNS Rolle spielt ist eigentlich 10.146.32.0/24 Netz. Im Server-Netz im RZ wird man nur ggf. ins Internet gehen, und das ist leicht zu lösen. Wichtig ist nur, dass die Anfragen, sollte der lokale DNS ausfallen, 1. den Weg zum RZ-DNS und 2. retour finden. 1. Wohl, im Client zwei DNS einrichten: - DNS lokal - DNS RZ 2. unsicher - die statische Route sorgt dafür dass wenn DNS im RZ nach der IP aus dem 10.146.32.0 sucht, diese Anfrage über dem VPN Gateway geht, womit auch per hostname die Adresse auffindbar ist (siehe oben die Erklärung), jedoch NICHT per IP (um per IP zu finden, muss man Client-Netz berücksichtigen) Da beginnt genau mein Problem, ich kenne nicht genau wie die Pakete aussehen, bzw. wie sich das hier verhält. Helfe mir zu verstehen bitte. Beispiel: Schritt 1: client01 mit IP 10.146.32.10 sendet die Anfrage an RZ-DNS: "wer ist" server01 Schritt 2: LANCOM übersetzt die IP von 10.146.32.10 in 10.241.56.10, vermutlich wird die dann im Client-Netz auch als "client01.domain.local" bekannt ("geheimer" DNS?) Schritt 3: RZ-DNS bekommt die Anfrage, jedoch von wem als Quelle: 10.146.32.0 ODER 10.241.56.0??? (inwischen ist am LANCOM die Übersetzung passiert, wirkt sich das auf das DNS-Paket, bzw. wem DNS als Quelle sieht?) Schritt 4: RZ-DNS sendet die IP-Adresse des server01 retour, jedoch an wem? Versucht DNS den "client01", oder 10.146.32.x oder 10.241.56.x zu erreichen? (hängt wohl davon ab, was passiert mit dem DNS-Paket genau bei der N:1-NAT Übersetzung). Das behaupte ich schon. Die Route via VPN-Gateway scheint zu funktionieren, siehe ganz oben wegen Erreichbarkeit. Was ist das?

Genau. Es ist mir klar was die nächsten Schritte sind und werde hier sicher mal wieder schreiben, wenn soweit bzw. durchgeführt. Danke für alles einstweilen!

Ich glaube jedoch dass das hier der Knackpunkt ist - ich befürchte ohne PAT wird das nicht gehen, da wenn das Client-Netzwerk auf dem VPN Termininierungs-Punkt im RZ unserem Netz nicht entsprechen kann, wird das ohne Übersetzung auf unserer Seite nicht funktionieren - wir müssen uns an das Client-Netz im RZ anpassen, und da wir das lokale Netz NICHT ändern können, können wir ja nur übersetzen.

Technisch und vom Vorgang her, vollkommen korrekt, lefg. Jedoch ist das "Projekt", wenn man es so nennen will, nicht meins. Ich war erstmals 2 Jahre dort, dann 1 Jahr Pause und jetzt wieder. Ich habe die Firma damals mit einem funktionierenden Server, DC, weitere VMs, Backup (soweit möglich),USV, redundanten Routern, Internet Leitungen usw. und entsprechender Dokumentation verlassen. Die Umstellung ins RZ (Wunsch der GL) hat ca. 2 Wochen vor meinem Eintritt in die Firma begonnen - ausgegangen hat es von einer sehr unfähigen Mitarbeiterin, die sehr viel falsch gemacht hat (das kann durchaus öffentlich gesagt werden), unter anderem auch den lokalen Server als "defekt" eingestuft - dieser funktioniert nach wie vor ordentlich, mit einer Ausnahme - die Spare-Platte meldet einen Ausfall an - neue bereits bestellt. Darauf wird anstatt 2008R2 bald 2012R2 installiert, alle VMs sind bereits gesichert. Die zukünftige Infrastruktur soll ja ziemlich einfach sein: 4 Server ausgelagert, tragen DC, Backup DC, Test-Umgebung und noch paar Kleinigkeiten, und der lokale Server dient als lokaler DC, um WAN zu entlasten. Das Thema Netzwerke wird bereits in dem anderen Thread diskutiert, wobei es mich auch sehr freuen würde, mehr Details in dem Gebiet zu bekommen. Nächste Woche, wie gesagt, kommt hoffentlich noch das Gespräch mit den Personen die das Projekt gemeinsam mit dem Kollegen vor Ort gemacht haben (also die DC Umstellung auf die Notebooks...), um eventuelle Missverständnisse zu vermeiden.

Darauf tät ich mich nicht verlassen... Marke Lenovo, Modell T500. Akku noch nie gewechselt, soweit ich weiß.

Heute noch nichts. Nächste Woche werde mit paar Kollegen aus dem Mutterkonzern telefonieren, da sie auch an dem Thema sich beteiligt haben. Danach mit den Infos zum Chef. Nachdem ich gerade 2 Wochen bei der Firma bin (jedoch war ich vor einem Jahr bereits zwei Jahre bei der Firma), es ist nicht so leicht zu sagen dass die Situation gruselig ist - aber wenn ich alle Fakten habe, kann ich die Situation gut schildern, und mindestens sagen welchen Weg ich gehen würde. Der Kollege der noch da ist hat heute gemeint dass wir noch ein Monat abwarten, dann kommt wer aus dem MK. Seine Meinung ist die Laptops halten die Domäne jetzt, und werden wohl noch 4 Wochen aushalten, wenn bereits 6 Wochen alles ok ist... was ich davon halten soll, weiß ich nicht mehr. Auf jeden Fall muss ich mehr Fakten zusammensuchen, und berichten, bevor ich selber eingreife dort, wo andere bereits was getan haben.

Tja. Ich muss es ausbaden (versuchen). Der Chef bekommt eh bald bescheid, wie der Status ist, ich will jedoch trotzdem mindestens wissen woran ich bin, und welchen Weg genau ich gehen kann - mit klarer Aussage dass die Situation ja gruselig ist, und es kann unter Umständen viel schief laufen.

Kann ich leider nicht ganz bestätigen. Dann verstehe ich das so: dafür dürfte man keine Übersetzung mehr machen, und das Netz 10.146.32.0 müsste man ohne jegliche Eingriffe (also nur die statische Route für den VPN-Gateway) aus dem Netz 10.241.56.0 erreichen können. Bin mir nicht sicher ob das funktioniert. Würde ich sowas machen können, würde ich. Jedoch sind wir leider sehr stark an unser Mutterkonzern angewiesen. Wir sind zwar ein eigenständiges Unternehmen, jedoch können wir nicht beliebig wie wir nur wollen die Netze erstellen. Die zwei ganz oben genannten Netze können nicht geändert werden, und das Netz im RZ auch nicht. Alles sind fix vorgegebene Werte. Ich *muss* drumherum arbeiten. Der Dienstleister ist unser Mutterkonzern, aber das Verhältnis spielt jetzt hier keine Rolle wirklich. 2. Server ist nicht angedacht, hier handelt es sich um einen relativ alten HP DL380 G7, und dieser wird auch nicht erweitert. Deswegen wird dieser lediglich als lokaler Server genutzt, um die Auslastung der WAN Verbindung zu vermeiden, die über Mobilfunk geht. Sollte die S2S (die ja über Mobilfunk geht) relativ leicht ausfallen, dann haben wir kein DC, wenn der lokale DC nicht läuft - und das will ich damit vermeiden. Ursprunglich war es so angedacht dass wir den DC NUR im RZ haben. Jedoch bin ich mit der Idee gekommen, den lokalen DC auch zu machen, um gewisse Redundanz und die WAN zu entlasten. Also auch wäre der lokale DC nicht da, müsste man die Lösung mit dem DC im RZ hinbekommen, und die Problematik mit 2 verschiedenen Netzen besteht weiterhin.

Ja, es ist eine berechtigte Frage. Die Site-to-Site habe nicht ich eingerichtet, sondern die LANCOM Kollegen vom RZ. Aber meine Vermutung ist weil das RZ Netz nicht auf unser lokales Netz, aus welchen Grund auch immer, nicht zugreifen kann. Aber RZ kann auf das eingerichtete Client-Nezt (10.241.56.0) zugreifen. Daher ist diese Übersetzung eingerichtet, um die Clients im lokalen Netzwerk zugfreifen zu können. Daher wird es auch notwendig sein, um DNS aus dem RZ in das lokale Netz zugreifen zu können. Soweit ich das verstehe, unser 10.146.32.0/24 Netz kann im RZ nicht als Client-Netz eingerichtet werden. Allerdings, es gibt eine offene Frage, die mir derzeit keiner wirklich beantworten kann - lt. Info die so "herumschwebt" ist derzeit "nur" ein Point-to-Site eingerichtet. Dazu finde ich aber keine Spuren im LANCOM Router, und sehe nur eine Site-to-Site Verbindung eingerichtet. Lt. Infos muss im RZ noch etwas umgestellt werden, damit der Weg auch sozusagen rückwärts funktioniert (also damit ich 10.146.32.0 zugreifen kann). Aber wie schon erwähnt, wenn die statische Route eingerichtet wird, kann ich die Clients im lokalen Netz über die übersetzte IP (10.241.56.0) zugreifen, ansonsten funktioniert es nicht (also rede ich hier von N:1-NAT). Deswegen schieb ich auch über die gleiche Funktion aus dem RZ -> lokal. Aber es ist wahrscheinlich komplett Sinnfrei, da wenn die Adresse einmal NAT (oder in diesem Fall PAT) passiert hat, hat sie die Adresse aus dem Client-Netz, und alle Anfragen von dort müssen in dem Client-Netz bleiben. Am Beispiel der DHCP-Abfrage, angenommen lokale DC ist ausgefallen. 1) Client broadcastet nach einem DHCP, LANCOM Router ist der einzige der sich meldet, hat eine Weiterleitung nach Priorität eingerichtet (1. lokale DC, 2. DC im RZ) 2) Paket wird an die IP des DC geschickt (REQUEST) - die IP des Clients wird am LANCOM in 10.241.56.x übersetzt 3) DHCP in RZ bekommt die Anfrage mit 10.241.56.x und schickt dann an 10.241.56.x die Antwort (Offer) retour, dass die IP vergeben werden kann 4) Geht retour (Request), Client kann ja nur wieder mit 10.146.32.x antworten, wird übersetzt... 5) ACK vom DHCP an den Client Beim DNS sehe ich nur Bedarf alle Weiterleitungen und DHCP DNS Einstellung ordentlich eingerichtet zu haben. D.h. in jeden Fall muss so sein, dass wenn die Anfrage irgendwo eintrifft, und es muss so sein dass die Clients alle DNS Server sowohl eingetragen (passiert ja via DHCP) wie auch erreichbar haben, die Antwort auch an die Clients zurück kommt. Nicht falsch verstehen, ich versuche das Thema einfach im Kopf zu "sortieren", damit ich ohne viel Probleme die DC-Umstellung machen kann (siehe anderer Thread zum Thema DC-Problem).

Niemand? Wenn zumindest eine Grundfrage beantwortet werden könnte: habe ich ein Problem wenn sich die DCs (somit auch DHCP und DNS) in verschiedenen Netzen befinden? Die DNS Replikation kann ich vorerst abdrehen, ist aber nicht eine langfristige Lösung, wäre nur gut zu wissen, ob da was schief laufen kann? Aus meiner Sicht nicht, da DNS lediglich "Einträge" sind, die ich im schlimmsten Fall wieder korrigieren kann, sollte was nicht funktionieren. Oder? Und kann eventuell 2012R2 eine IP Übersetzung (N:1-NAT) machen? Also zB. die ersten 3 Octets wenn bspw. 10.146.32.x eingetippt wird, automatisch in 10.241.56.x umzuwandeln? Ich kenne leider 2012R2 Router nicht so gut. Ob das überhaupt Sinn macht ist ne andere Sache...

Es waren in meiner Abwesenheit leider mehrere dafür schuld, jedoch verlassen diese Personen bald die Firma, und bei mir gehen die Sachen ein wenig anders ab - behaupte keinerlei dass ich ein Top-Admin bin, aber ich weiß wann ich wirklich vorsichtig sein muss. Ja, Thema FSMOs... :( :( :( Die sind natürlich nicht übertragen worden, da der alte DC gar nicht abgeschaltet wurde - es wurde die Maschine aus dem HV exportiert und dann auf ein Notebook draufgespielt. DC auf dem Notebook hat deshalb die gleiche IP, was ich dann auch erst mit den ersten Analysen festgestellt habe. Deswegen fragte ich ja wegen der Replikation, da ich dann die Rollen sauber übertragen könnte. Es läuft darauf hinaus, dass ich die FSMOs auf einem der Notebooks seizen muss, da ich sonst neue DCs gar nicht aufziehen kann.

Hallo, ich bin mir nicht sicher ob das hierher oder im Netzwerk gehört. Die Basis ist Netzwerk, aber ggf. liegt die Antwort bei Windows Server. Wir sind dabei zwei DCs über VPN einzurichten. Ein DC ist lokal, und eins sollte im Rechenzentrum eingerichtet werden. Dabei handelt es sich um eine Site-to-Site VPN Verbindung, jedoch nicht um gleiche (Client-)Netze. Das lokale Netz, 10.146.32.0, wird gegenwärtig für den DC, andere Server, Clients, Telefonie, usw. verwendet. Infrastrukturbedingt kann dieses Netz nicht geändert werden. Das Rechenzentrum VPN Netz kann aber auch nicht auf unser Netz angepasst werden (Terminierung des VPN Tunnels ist geshared auch für andere Kunden), und hat eine Clientnetz-Adresse 10.241.56.0. Unser Netzwerk, das für die Server im RZ verwendet wird, ist auch ein anderes, also 10.225.159.0. Hier sind derzeit Server mit IPs im letzten Octet Nr. 1-4. Auf unserem LANCOM Router lokal hier in der Firma, dieser baut auch die VPN Verbindung auf, ist eine Netz-Übersetzung von 10.146.32.0 ins 10.241.56.0 eingerichtet. Somit, nach der Einrichtung einer statischen Route auf dem Server im RZ, damit die Anfragen die an 10.146.32.0 gestellt werden, über dem VPN-Gateway verlaufen, passiert folgendes: - beim anpingen des hostname.domain.local, kommt eine Antwort mit der IP 10.241.56.x (x=letztes Octet der IP-Adresse aus dem Netz 10.146.32.0) - ist klar, wegen der Übersetzung im LANCOM - beim anpingen der Adresse 10.241.56.x kommt eine Antwort - klar, wie oben - beim anpingen der IP 10.146.32.x kommt keine Antwort (auch klar - es gibt keine Übersetzung im Rechenzentrum, vermute auch dass keine möglich ist) Ich sehe ggf. Probleme beim DNS: Wenn neue DC eingerichtet wird und repliziert, repliziert er die Adressen 1:1 vom ersten DC. Dieser hat Einträge aus dem Netz 10.146.32.0. Ich weiß dass DNS auch mehrere A-Records für den gleichen Hostname und verschiedene IP haben kann, klar, aber wenn ich dann im RZ eine Adresse 10.146.32.x anpingen versuche, dann wird keine Antwort kommen. Ich könnte jedoch im DNS im RZ als Weiterleitung den lokalen DNS eintragen... die Einträge werden repliziert, alle, und die Weiterleitungen an allen DNS würden dazu sorgen, dass die Abfragen überall passieren. Dürfte ja gehen, oder? Ich weiß nicht ob es sinnvoll ist auch dort noch DHCP zu betreiben (zzgl. zum lokalen DHCP auf dem DC). Die Anfragen kann ich ja im LANCOM an beide Server senden, und in Windows DHCP die Verzögerung (ich bilde mir ein, irgendwas davon gelesen zu haben, habe jetzt nur kein 2012R2 zu checken) einrichten. Aber bin ich mit meiner Mathe zu Ende. Funktioniert das wie ich mir vorstelle? Mir kommt es nur so vor, als die wichtigste Aufgabe sein wird, alle Weiterleitung und DNS Server im DHCP einzutragen, und dafür sorgen dass die DNS und DHCP Abfragen überall hinkommen können, wenn zB. der lokale DC abkackt. Also nochmals, wenn das eher zu Netzwerk gehört, bitte verschieben, aber das Thema läuft hauptsächlich auf die Sache DC/DNS/DHCP in einem anderen Netzwerk und wie das genau funktionieren wird. Ich werde auf jeden Fall in einer Lab-Umgebung simulieren. Jedoch wäre vorher gut die Theorie zu wissen. Ich hoffe klar genug. ;) Besten Dank! Kosta

Nils, wie immer, vielen vielen Dank, klingt gut und werde so machen! Und ja... rest scheint zu funktionieren fast wie üblich.

Hallo zusammen, Also bitte urteilt nicht über die folgenden Fragen oder Situation. Die Situation ist so wie sie ist, und ich muss die Sache versuchen soweit möglich jetzt gerade zu bügeln. Ich war eine Weile nicht in der Firma, und da kamen diese Zustände zu folge. Für die Einfachkeit der Diskussion, nennen wir die DCs so: DC1 - original DC, unter 2008R2 DC2 - Laptop1, 2012R2 DC3 - Laptop2, 2012R2 DC4 - ausgelagert in RZ Früher war in der Firma nur ein DC vorhanden (virtuell in HV). In einen Backup wollte nicht investiert werden. In meiner Abwesenheit, hat jemand "gedacht" dass der Server ausfallen wird, und da wurden zwei Laptops mit 2012R2 installiert und beide als DC konfiguriert, und zwar so: DC2 wurde mit 2012R2 installiert und als DC konfiguriert, Replikation fand statt. Dieser Server bekam eine andere IP, und als DC1 abgeschaltet wurde, kam natürlich zu Problemen, nachdem dieser auch als DNS agierte, und DHCP dann auch nicht mehr vorhanden war (war auf DC1). Um das zu "beheben": DC3 wurde installiert (zweiter Laptop), dieser bekam die gleiche IP und Namen des DC1, hat auch das derzeit funktionierende DNS, und DHCP wurde am Router eingerichtet. Nun, der DC1 Server ist nicht defekt, und soll wieder in Normalbetrieb aufgenommen werden. Inzwischen wurde eine P2S VPN zum DC4 eingerichtet, mit Absicht diesen als Haupt-DC zu verwenden. Jedoch bin ich über der Idee nicht ganz erfreut, einen DC nur über Mobilfunk VPN erreichbar zu haben. Die Endlösung soll so aussehen: zwei DCs: 1x lokal DC1 auf 2012R2 1x DC2 in RZ ausgelagert mit S2S verbunden. Meine Sorge ist folgende: Sollte ich jetzt den Weg rückgängig machen, also bspw. DC3 abdrehen, DC1 aufdrehen und replizieren von DC2, befürchte es könnte zu Replizierungsproblemen kommen. Irgendwas habe ich nämlich in Erinnerung, dass wenn die Replikation schon länger nicht stattgefunden hat, dass zu irgendwelchen Problemen kommen kann... stimmt das? Auch, wer wird von wem replizieren? Ich weiß ich kann in NTDS Settings händisch replizieren, kann ich aber irgendwie vermeiden dass die Replikation automatisch stattfindet? Löst das mein Problem? Das Problem ist allerdings, ich bekomme den DC1 nicht aus der Domäne heraus und dann wieder herein (das wäre eine der Ideen, um es sauber von DC2 zu bekommen), weil er die gleiche IP wie DC3 hat, und sollte ich ihm wieder einschalten (und DC3 wegen IP Konflikts abdrehen), riskiere ich die eventuellen Probleme mit der Replikation von DC2. Könnt ihr aus meiner Erklärung überhaupt verstehen was passiert ist, und hat jemand eine Empfehlung für mich, was man tun sollte, um es wieder sozusagen rückgangig zu bekommen? Besten Dank! Kosta

Norbert, gute Punkte, macht Sinn. Danke. Monstermania, es soll hinter der (Hardware) Sophos mein ganzes Netzwerk sein, nicht nur Testlab. Die hohe CPU-Taktrate wird wegen IPS empfohlen. Und ich habe hier 100Mbit. Dazu wird auch VPN gemacht... außer hier von dir, wurde mir die Konfiguration für die Sophos Lösung "abgesegnet", wenn man so will. (und ja, ich will unbedingt Sophos)

Wehren sich Ex und SQL irgendwie? Worauf beziehst du dich da genau?

Gegen Overcommitting spricht in einer Testumgebung ja nichts dagegen, sofern die Platte genug bumms hat, oder? (was die 960pro definitiv hat) HV hat doch smart paging... Dann kommt noch Dynamic Memory dazu, dynamic disks... alles was ich eigentlich nutzen kann, da ich keine riesigen dauer-IOs haben werde. Und auch wenn ja, kann ich dann den Disk auf fixed umwandeln, und mein Mainboard nimmt bis zu 64GB an RAM (Asus Maximus VIII Hero). Ich glaube genug Resourcen, mindestens für ne Weile? :)

Norbert, es ist mir bewusst dass nach oben viel viel Platz ist. Ich *will* aber keine 300w+ im laufenden Betrieb haben. Die Leistung brauche ich nicht, die VMs werden zu 99% Idle laufen. Auch wenn Exchange, passiert drauf nicht wirklich viel, lediglich wenn ich die Sachen ausprobiere und eine oder andere Email durchgeht. Irgendwie kann ich nicht glauben dass ich dafür 2 Xeons brauche... (es gibt genügend Firmen die 1 CPU haben, und haben drauf sowohl Exchange, DC, App-Server, SQL usw. laufen). Ich brauche ein stabil laufendes System mit Möglichkeit viele VMs zu installieren, um so viel wie möglich virtuell zu simulieren. Verlässlichkeit ist mir vorerst egal, die Backups kommen auf die NAS. Ob die SSD eingeht und dann nix mehr geht, ist mir auch egal. Kommt halt die neue. Derzeit wird wahrscheinlich mein Rechner auf 32GB aufgerüstet und die SSD dazu. Dann kann ich schon einiges machen. Die SSD kann ich dann in einem Xeon-Server (wie im Beispiel oben) verwenden.

Habe wohl oben nicht erwähnt: (idle) Stromverbrauch ist mir wichtig und möchte es auf möglichst Minimum halten, ohne auf Atom gehen zu müssen. Ausgerechnet mit meinem Build sollte ich ca. 40-50W treffen. Mit dem oben erwähnten Board, 2 CPUs und RAM, schätze ich dass unter 150W in Idle keine Rede ist... eher mehr. Aber was meinst du bitte genau mit Bottleneck? Derzeit werde ich aus Kostengründen auf 10GBit nicht gehen, und wenn ja, dann per PCIe nachträglich (deswegen auch passendes Board und das Gehäuse) - derzeit kein Budget um auch die Infrastruktur auf 10Gbit zu pushen.

Da ich mit EX keine Betriebs- und Installationserfahrung noch habe, weiß ich nicht ob es zu unlösbaren Problemen kommen könnte, wenn ich Exchange hinter zwei Firewalls habe (1x LANCOM, bzw. Sophos Hardware, 1x Sophos virtuell in Hyper-V). Danke! Tolle Sache! Ich habe mir bereits überlegt gehabt, auf ganz "Consumer" zu gehen. Sprich günstiges Mainboard mit 2 Netzwerkkarten, i7 (wegen HT), non-ECC und non m.2. Ich denke nur dass ich früher oder später auf 64gb gehen werde, und da ich da mit Supermicro besser bedient bin. Außerdem sind die IOPS wichtig, jedoch kann ich persönlich nicht einschätzen wieviel, da ich keine wirklichen Schwerlasten haben werde, aber möchte dass alles zügig geht. Kann nämlich etwas unter SSD Geschwindigkeit gar nicht mehr leiden ;-) Meine Konfiguration wäre folgende: Firewall: Silverstone SST-PT13B-120 Petit Thin-Mini-ITX-Gehäuse Asus H110T Mainboard (90MB0Q40-M0EAY0) Intel Core i3-6320 Prozessor 2x 3.90GHzx boxed (BX80662I36320) HyperX Impact SO-DIMM Kit 8GB, DDR4-2133, CL13-13-13 (HX421S13IBK2/8) Transcend MTS600 64GB SSD, M.2 2260 (TS64GMTS600) HV-Host: Chieftec UE-02B 250W Tower-Gehäuse schwarz (UE-02B) Supermicro X11SSH-F Mainboard retail (MBD-X11SSH-F-O) Intel Xeon E3-1230 v5 Prozessor 4x 3.40GHz boxed (BX80662E31230V5) Kingston ValueRAM DIMM Kit 32GB, DDR4-2133, CL15-15-15, ECC (KVR21E15D8K2/32) Samsung SSD 960 Evo 500GB, M.2 2280 (MZ-V6E500BW) zzgl. Kleinkramm Kühler, Lüfter usw. Kommt alles gemeinsam auf ca. €1700. USV/NAS/Switch(Smart Managed) vorhanden.

Ich habe vielleicht schlampig gefragt. Die getrennte Konfiguration wäre auch virtuell. Der Unterschied: LANCOM -> Hyper-V-Host (i7) -> (virtualisiert) SophosUTM -> VMs vs SophosUTM -> Hyper-V-Host (Xeon) -> VMs 1. ist jetzt. 2. ist die Hardware-Lösung, wenn man so will. Ich weiß nicht was mich erwartet, aber ich hinterfrage wegen Exchange und Routing, ob hier was zu bedenken wäre oder problematisch ist (bei der aktuellen Lösung).

Als physisch würde ich es nun sehr minimalistisch machen, wenn schon. Ich habe mir ausgerechnet dass ich eine Kiste mit Xeon, 32GB RAM und einer m.2 960 Pro(oder Evo) mit 500gb für ca. €1300 zusammenstellen kann. Das + ca. €500 für die SophosUTM Kiste ist natürlich eine Lösung. Absichtlich kein Storage o.ä., Backup auf die NAS reicht. Trotzdem könnte ich auf meinen 6700K noch 16GB draufknallen und die gleiche SSD... ist dann aber im Vergleich keine 24/7 Maschine. Ersparnis von ca. €800 immerhin. Der externe Router ist ein LANCOM, ist aber schon ziemlich veraltet. Da wird die Sophos ziemlich sicher hinkommen. Ich ginge eben davon aus, dass ich das Routing so hinrichten kann, damit die ganze virtualisierte Umgebung die auf meinem i7 rennt, auch vollständig mit Exchange betrieben werden kann.

Hallo, Ich baue, wie ich meine Stoffe durchgehe, meine Lab-Umgebung. Derzeit auf meinem Rechner im Hyper-V auf Win10. Derzeit sind drin eine Sophos UTM, und "dahinter" paar Server, Client... damit kann ich doch schon einiges anfangen. Geplant ist noch als "2. Standort" eine 2. Firewall und Server dahinter. Bald wird aber auch sein, dass ich mir ein Exchange installiere um zu testen. Jedoch würde ich gerne auch die Kommunikation nach außen haben (eigene Domain). Also ich versuche damit nicht meine normale Email Adresse zu ersetzen, aber Echtbetrieb zu simulieren. Da ich davon bereits noch nicht wirklich viel weiß, bedarf so eine Situation eine Konfiguration wo ich zB. eine SophosUTM oder pfSense "echt" laufen habe, also in einem selbst gebauten Rechner und dann die VMs mit einer direkten Anbindung oder funktioniert das auch wenn ich das ganze, genau wie jetzt, ausschließlich virtuell betreibe? In beiden Fällen muss ich die Hardware erweitern, sowohl Storage wie RAM, nur kostet mich die non-virtuelle Lösung locker einen Tausender mehr... Danke!

OK, also könnte zum Gebrauch kommen wenn man zwei verschiedene Berechtigungsstufen hat, zB. only Files und only Folders..., könnte ich Delete auf einzelne Objekte setzen... ob sinnvoll... tja, besser haben als brauchen, klar ;)