MurdocX

Bei so etwas offensichtlichem fühle ich mich verpflichtet darauf hinzuweisen Wenn du vom Client aus einen Drucker vom Printserver mappst, musst du dann die Admin-Berechtigungen am Client eingeben? Bevorzugt auf einem probieren auf dem der Drucker nicht funktioniert.

Ohne den zweiten DC bei den Clients eingetragen, hat der Kunde einen Single-Point-Of-Failure.

interface GigabitEthernet9/0.100 -> ip address 192.168.10.1 Der DNS-Server in deinem DHCP-Pool zeigt auch auf die 192.168.10.1 Empfehlung: Für die Übersichtlichkeit und dadurch fehlerfreieres Arbeiten würde ich die Gateway-Adressen im letzen Oktett gleichsetzen (.1 oder .254). Nachtrag: Ich verstehe nicht ganz wie du auf die .254 Adresse im 192.168.10.0/24 - Netz kommst, wenn deine Konfiguration folgendes sagt: interface GigabitEthernet9/0.100 description Privates Netz encapsulation dot1Q 100 ip address 192.168.10.1 255.255.255.0 ! interface GigabitEthernet9/0.200 description Netz Administration encapsulation dot1Q 200 ip address 192.168.20.1 255.255.255.0 ! interface GigabitEthernet9/0.300 description Netz Verwaltung encapsulation dot1Q 300 ip address 192.168.30.1 255.255.255.0

Wäre es denn für Dich möglich die Netzwerkkonfiguration der Router hier zu posten? Handelt es sich hier eigentlich um eine "Hausaufgabe" oder eine andere Vorbereitungsaufgabe?

Hallo Mex990, ich habe ein paar Fragen zu dieser Konfiguration: - Werden die IP-Adressen via DHCP verteilt? - Warum wurde nur 1 DNS (.100) und nicht auch der 2 DNS (.97) bei beiden DCs eingetragen? - Sind beide DNS-Server auch in der Konfiguration der Clients vorhanden? Schöne Grüße Jan

Schon mal nach Firmware-Updates gesucht? Um welches Gerät u. Model handelt es sich denn?

Hallo xrated2, Ich glaube was @Dukel damit sagen möchte ist, das im Allgemeinen die Komponenten der großen Hersteller aufeinander abgestimmt sind. Nicht pauschal das Supermicro schlecht ist. Diese sind nicht nur auf Hardwarebasis, sondern auch auf Softwarebasis (Firmeware) abgestimmt. Das hat entscheidende Vorteile im Support, Teile Nachkauf und die optimale Funktionsweise der Komponenten untereinander. Das ist nicht von der Hand zu weisen. Ich persönlich verkaufe meine Professionalität meinen Kunden nicht durch meine vor Ort Präsens, sondern dadurch das sich meine Kunden sich seltenst melden. Das klingt erst mal komisch, zeigt aber im Umkehrschluss das die Produkte (Server, Software und etc.) die ich berate, anbiete und umsetze alle ausgereift sind und auch für den eingesetzten Zweck hergestellt worden sind. Falls Geräte nun ausfallen, Performance-Probleme auftreten oder es auch nur um kleine Erweiterungen geht, kann ich im Normalfall davon ausgehen das das nicht viel Zeit in Anspruch nehmen wird. Aus dieser Sicht und meiner Erfahrung würde ich, damit schließe ich mich der Meinung meines Vorredners an, keine selbstgebauten Server empfehlen. Grüße Jan

Hallo Cizen, willkommen an Board. Diese Art der Authentifizierung muss von der (Web-)Anwendung als Funktion vorhanden sein. Um welche Webanwendung handelt es sich denn?

Stimmen denn die Routen zwischen den Routern?

Ich kann hier nicht für alle Produkte sprechen, kann mir aber vorstellen das das dort eingebaut ist. Wenn es das Feature und dessen Konfiguration zulässt, ja. Mehr kann ich Dir leider mit den genannten allgemeinen Informationen nicht helfen.

Das klingt etwas ungläubig aber Ja. PS: Eigentlich hab ich mit meiner Antwort oben schon alles Beantwortet.

Bei Windows Server Standard gibt es keine Benutzer- und Computerbegrenzung. Die Begrenzung ist/sind deine vorhandenen Device/User CALs.

Mit dem Vorschlag von @testperson wäre eine saubere Trennung von DC und Diensten dann möglich. Dieser Schritt bietet einige Vorteile.

An dem Thema war ich mal dran. Die Zielgruppenadressierung ein riesiges Thema. Dann lieber als XML exportieren, mit Notepad++ die Einträge ersetzen und wieder via Copy&Paste einfügen.

Die Replikation unter DCs ist am gleichen Standort nahezu in Echtzeit.

Nein. Alternativ mit dem Server-Manager.

Das kannst du z. B. über deine Firewall regeln. Entweder du machst ein Failover oder einfach Loadbalancing. Von Sophos gibt es die UTM mit minimalsten Funktionen auch für Unternehmen kostenlos. Die Anbindungen sollten am Besten nicht vom gleichen Anbieter sein, sonst hast du evtl. zwei tote Leitungen.

Freut mich das es geklappt hat und viel Spaß damit Wenn du den Thread noch als "Gelöst" ( Beste Antwort ) markieren könntest, dann finden die anderen Sucher vielleicht auch diese Antwort unter google.

Ich hab auch schon einige CUs auf unterschiedlichen Ex-Systemen mit den unterschiedlichsten Konfigurationen durchgeführt. Alle bisher ohne Zwischenfälle. So wie sich das bei Dir ließt, ist das alles Andere als prickelnd.

Mit dieser Alternative hast du ganz schnell ein Single-Point-of-Failure und im Endeffekt nichts zu vorher gewonnen. @NilsK hat die andere, falsch konfigurierte, Variante ausführlich erklärt. Da intern mehrere DCs vorhanden sind (sein sollten), werden beide nicht gleichzeitig aus sein. Damit ist das auch die einzige sinnvolle Lösung -> mehrere DCs

Ja, ich kenne einen. Eine sehr rare Spezies Ganz ehrlich.. Ich finde die Lösung auch (eigentlich wollte ich was anderes schreiben) suboptimal. Erkläre deinem Kunden einfach das du keinen kennst. Vielleicht kennt einer der Exchange Spezis hier eine Lösung /Alternative über den Transportdienst?

Das ist der klassische Fehler. NTFS Berechtigung passt, aber die Berechtigung der Freigabe steht noch auf "Jeder" und "Nur lesen"

Hallo Speer, du könntest die Installation auch über einen WDS regeln. Wenn du das Image schon hast, einfach dort importieren, die unattended.xml bereitstellen und das wars. Grüße Jan

Das wäre gut. Die UDP-Pakete benötigst du, denn in denen wird, wie oben geschrieben, die Info übergeben was der Client vom Server laden soll. Wenn die nicht ankommen, dann haben wir genau das Problem. Mein UDP-Payload mit der benötigten Information: .....ÝYz.......P............È[vá............TEST-SRV2012....................................................boot\x64\wdsmgfw.efi............................................................................................................c.Sc6.....a..Là.;.#².¨\×yQ.B!<.PXEClient5..ü7\Tmp\x64uefi{2FAF9885-4C67-474E-B3E5-7C3B4A756E22}.bcd.ú...........p..................ÿÿ Noch zu klären: - Habt Ihr mehrere Netze die der DHCP versorgt? Dann könnte IPHelper noch ein Thema für euch sein. - Wichtig hier auch die Thematik mit DHCP-Snooping, also dem schlucken der Pakete durch den Server - Welche MTU-Size hat der Netzwerkadapter? -> Powershell: -> unter 1500? Dann bitte auf 1500 stellen. Get-NetAdapter | Select-Object Name,MtuSize

Hier kann mann die Problematik im Vergleich sehr gut sehen. Im UDP-Paket, welche vorher ausgetauscht wurden, steht die wdsmgfw.efi im Payload als Bootfile drin, weshalb auch die TFTP-Verbindung den Pfad boot\x64\wdsmgfw.efi unter File enthält. Leider ist der Pfad bei Dir leer. Das erklärt auch, warum nicht gebootet werden kann. Wie sieht denn die Payload der beiden UDP-Pakete davor aus? Nachtrag: - Habt Ihr zufällig auf euren Switchen die Funktion "DHCP-SNOOPING" aktiv oder ähnliches? Diese verhindert quasi einen zweiten DHCP-Server. - Wird ein Windows DHCP verwendet?