Bloodie

Den Traffic über das Gateway wäre die einfachste Variante , richtig. Wir hätten da auch Gigabit Ethernet , allerdings würde ich das auf jedenfall vermiden wollen , da der Interne Traffic eigentlich nicht "geregelt" werden muss und somit das GW Traffic bekommt , den es garnicht brauch. Wenn ich nun aber dem 49er Netz auch den L3 Switch als GW gebe, habe ich das Problem , das sobald der L3 Switch ausfällt , sowohl Clients als auch Server nicht mehr arbeiten , oder? Es sieht im Prinzip so aus: GW --- L2 Server Switche --- L3 Switche ---- Client Switche Meine Grundidee war, das die Server auch noch arbeiten , wenn das hintere Stück ab dem L3 Switch wegbricht , da wir noch Standorte ausserhalb haben , die über VPN Tunnel auf unsere Server zugreifen. Bricht mir nun der L3 Switch weg , würden die Server aus ihrem 49er Netz doch nicht mehr rauskommen , da ihnen der GW fehlt oder? Das wäre dann wieder problematisch , da sie Daten von anderen Servern in der DMZ und anderen Standorten holen und liefern.

Moin, ich zerbrech mir gerade meinen Kopf über eine Routing Lösung mittels einem Layer 3 Switch und glaube , das ich da irgendwo einen Denkfehler habe. Ich fang mal vorne an , damit vieleicht der Hintergedanke und das Ziel erkennbar (hoffe ich zumindest :) ) wird. Wir haben hier ein Netz 192.168.49.0/24 , indem sind momentan sowohl die Server als auch die Clients drin. Da nur mit statischen IPs gearbeitet wird , wird das ganze langsam knapp an IPs und unnötig schwer zu managen. Auf der 49.1 sitzt die Firewall , die als Gateway fungiert. Um das ganze nun zu entzerren , sollen die Benutzer in ein neues Netz ziehen und das soll mittels einem Layer3 Router in das alte 49er Netz geroutet werden. Im 49er Netz sollen die Drucker und die Server bleiben mit festen IPs bleiben , die User sollen in ein neues Netz mit der IP 192.168.50.0/24 ziehen. Das Netz einfach auf Klass B umstellen geht nicht , da wir noch andere Standorte haben , die Class C Netzte im Bereich 192.168.XXX.0/24 haben und die Firewall Regeln sonst komplett neu gemacht werden sollen. Ich habe mir gedacht , das ich das am VLANS löse und zwischen den beiden VLANs ein Routing mache. Mein Problem nun: ich würde die Server gerne so belassen , dass sie alle die 49.1 als Gateway behalten , damit der Layer3 Switch ,der das Routing zwischen User und Server Netz macht , ruhig ausfallen kann und die Server trotzdem noch arbeiten können. Wie muss ich nun das Layer 3 Routing konfigurieren , damit die User aus dem 50er Netz einerseits auf die internen Server Dienste zugreifen können (wie DNS, AD , Fileserver , Domänendienste...) ohne über die Firewall zu gehen und auf der anderen Seite ins Internet (also über die Firewall als Gateway) kommen? Fragen über Fragen....

Willst du den Tunnel direkt von den Servern , die auch als DC fungieren , aufbauen lassen? Das würde ich nicht für eine so gute Idee halten , da man ja hin und wieder die DCs auch warten muss und wenn dir dann bei einem Neustart der VPN Tunnel fehlt (aus was für Gründen auch immer...). CISCO ist für sowas echt nur zu empfehlen (zumindest aus meiner Erfahrung). Einfach an beiden Standorten so ein kleines CISCO Dingen hinstellen (da gibt es auch recht günstige Modelle , haben wir teilweise auch bei unseren Aussendienstlern im Homeoffice) , einmal richtig konfiguriert oder konfigurieren lassen und man hat eigentlich gar keinen Stress mehr mit VPN . Zweiter Vorteil wäre , das du damit auch (bei entsprechender Konfiguration) ein Backupkonzept hättest , das wenn dir z.B. ein DC ausfällt , die Leute sich immer noch über VPN an dem 2. DC anmelden können - oder um es noch weiter zu treiben , könntest wahrscheinlich auch ein Backupkonzept machen , das im Notfall das Komplette Netz am Standort A durch VPN zu B geroutet wird und über den Gateway auf B Seite ins Netz gehen (wenn auf A Seite Gateway weg ist).

Beim Note- oder Netbook fährst eh am besten , wenn du ein angepasstest Installationsmedium hast , gerade bei WinXP. Meistens musst du eh alle Treiber nachinstallieren und musst zumindest den Netzwerktreiber irgendwie auf das Netbook bekommen, wahrscheinlich also per USB Stick. Bist die ganzen Treiber vorher zusammengestellt hast , entpackts hast und auf den Stick geschoben und später dann installiert hast , in der Zeit hast dir vorher auch nen Bootstick gemacht. Mal davon abgesehen , das über USB Stick die Installation wesentlich schneller von statten geht. Ausserdem , wenn du ein speziellen Treiber für den HDD Controller brauchst bei XP , bist beim Netbook eh aufgeschmissen , da die Floppy erwarten und da hörts dann beim Netbook spätestens auf - mit der angepassten InstallationsCD auf Stick kannst das alles erschlagen. Und bei den Preisen heute für Sticks wird es wohl auch die billigste Variante sein.

Moin, ist das Notebook ausserhalb des AD? Falls ja , müsstest du bei Vista bei der Anmeldung am Exchange mit "Domäne\Benutzername" arbeiten. Bei XP ging das noch , das man mit gleichen Lokalen Benutzernamen wie Domänenuser sich ohne Domänenangabe vorm Benutzernamen anmelden konnte. (So hab ich es zumindest bisher erlebt.)

Das war das , was ich mit "Inteligenz der SAN" meinte. Ich gehe mal davon aus , das ein SAN so clever ist , eine so grosse Datei auch so zu verteilen , das wenn die Datei von vorne nach hinten gelesen wird , auch jeweils immer über die verschiedenen Platten liest/schreibt - also ganz primitiv ausgedrückt Bit 1 liegt auf Platte 1 , Bit 2 auf Platte 2 usw usw. Wenn das so ist , würde es sinn machen , virtuelle Disks auch zu defragmentieren , da die Performance der SAN ja von mehreren "parallel" arbeitenden Platten profitieren sollte. Ich hoffe , das kommt einigermaßen verständlich herüber :)

Wir haben mittlerweile auch rund 20 Patchpanels im Einsatz, die Beschriftungen haben wir immer auf Doppeldosen ausgelegt und unterscheiden zwischen Telefon und EDV. Wir haben dann also immer T-Paare für die Doppeltelefondosen , also z.B. T1.1 , T1.2 usw. auf dem Panel , das wäre dann eine Doppeldose, bei den Netzwerkdosen dann E1.1 und E1.2 für eine Doppeldose. Dazu gibt es dann natürlich einen Gebäudeplan mit den Standort der Dosen - wobei immer die gleichen Nummern von T und E Dosen an einem Ort sind. Zu der Verkabelung selber: Listen führen ist zwar toll , aber aus meiner Sicht nicht sehr verlässlig , gerade wenn mehrere Leute damit arbeiten. Wenn das nicht mit äusserster Sorgfalt gemacht wird bzw. du nicht das Vertrauen in die anderen hast ,kannst jedes mal Kabel suchen. Wir sind mittlerweile zu Kabeln mit Lichtidentifikation übergegangen von SaCon. Die haben sehr gute Messwerte von der Qualität (stehen Dätwyler und Kerpten in nichts nach) und kosten nur ein paar Cent mehr. Vorteil du kannst an einem Steckerende einen sogenannten "Injektor" aufstecken , und dann blinken die beiden Steckerenden - so kannst du selbst alleine in kürzester Zeit Anfang und Ende eines Kabels , egal wie lang , zielsicher finden.

Für mein Verständnis nicht und es wird teilweise auch von den Virtualisierungssoftwareherstellern empfohlen. Eine Virtual Disk ist im Prinzip ja nichts anderes wie ein oder mehrere große Files , die auf deinem darunterliegenden SAN System liegen. Beim Defragmentieren werden ja im Prinzip die Daten nach bestimmten Vorgaben "sortiert" , z.B. das Daten die häufig im Zugriff sind , möglichst nah bei einander liegen, damit der Lesekopf der Festplatte kurze Wege hat. Ich denke , dass bei einer SAN auch Vorteile dadurch entstehen , wenn die Daten in dieser Datei wie an einer Perlenkette aufgeschnürrt liegen und die SAN dann hoffentlich so inteligent ist und diese entsprechend performant abgreift. Was aber auch noch wichtig ist , ist dass die Virtuellen Disk sauber auf die SAN abgestimmt sind , bei VMWare nennt sich das "Partition Allignment" , Link siehe hier.

Moin, wir haben Avira im Einsatz und sind auch recht zufrieden damit , Performance Einbussen sind aus unserer Erfahrung sehr gering und hat bisher eine zuverlässige Erkennung. Wir hatten vorher Kaspersky im Einsatz und da waren teilweise sehr starke Performance Einbussen zu bemerken. Von Avira gäbe es da auch ein entsprechendes Bundle , Small Business , würde wohl für 3 Jahre und 5 Clients um die 600€ kosten. Da ist dann auch Exchange mit dabei und die ganze Management Geschichte. Link hier.

Ok , nach einem Kaffee und einer Zigarette war wohl das Hirn angereichert genug , um selber zu einer Lösung zu kommen...:cool: Folgendes Problem war es wohl: Bei dem Lösungsansatz habe ich die alten Default Policies mitübernommen , scheinbar konnte darauf aber , trotz stimmiger GUID nicht zugriffen werden und verweigerte wohl somit auch das Erstellen neuer GPOs (wieder etwas gelernt...). Da wir eh noch nichts mit GPOs gemacht haben , tat es hier auch nicht weh , die Default Policies neu zu erstellen. Gemäß der Anleitung hier habe ich also die alten Defaults gelöscht und neu erstellt. Danach hab ich noch mal wegen unserem Exchange 2k7 die Domäne , das AD und das Schema neu vorbereitet (setup.com /pd , setup.com /ps , setup.com /ad). Und Siehe da , ich hab die Defaults wieder drin , ich kann neue erstellen und hoffe nun , das alles tut , wie es soll :D Grüße, Bloodie

Hallo Zusammen, ich hab ein (hoffentlich) nur kleines Problem mit dem GPO Editor auf unseren DCs. Ausgangssituation war ein Falsch Repliziertes SYSVOL bei uns in der Domäne. Ich hab das soweit wohl wieder hinbekommen , das auf allen DCs nun die Replikation funktioniert. Als Anleitung habe ich mich an dem Artikel hier orientiert. Ich hab hier nun jeweils 2 DC mit W2k3SP2 und 2DC mit W2k8SP1. Wenn ich nun den Gruppenrichtlinien Editor starte , sieht alles gut aus. Ich sehe die Default Domain Policy und die Default Domain Controller Policiy und die Domänenstruktur und kann die beiden Policies auch bearbeiten. Aber wenn ich eine neue Policie erstellen möchte - egal in welche OU auch immer , selbst da wo die beiden Defaults sind - bekomme ich auf den 2003er als Fehler "Das System kann die angegebene Datei nicht finden" und bei den 2008er "Der Netzwerkname wurde nicht gefunden" - den Namen für eine GPO kann ich noch vorher angeben , aber erstellt wird nix und ich hab auch kein Eintrag irgenwo im Eventlog. Die Berechtigungen bei "Delegierungen" in der Domäne sehen soweit eigentlich gut aus , zumindest ist der Adminstrator dort überall drin , der auch angemeldet ist. Weiss jemand dazu einen Lösungsansatz - ich blick es irgendwie nicht mehr im Moment , nach dem ganzen SYSVOL Debakel....:confused: Danke schon mal. Bloodie