Jump to content

Velius

Expert Member
  • Gesamte Inhalte

    5.644
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Velius

  1. Welche VM Server Version (WMare/Virtual Server)?:confused:

     

     

    RAID 6 würd ich nicht nehmen - die zweite Parity geht zu ungunsten der Performance (mehr noch als RAID 5). Dann eher eine Hotspare.

     

    RAID 10 (1 + 0) ist am performantesten, frist aber am meisten Platz/Disks. Ein Ordentlicher Controller mit Backup Battery Cache sollte es auch sein, sonst hast du nur Read-Ahead gewinn (ziemlich unnütz bei VMs).

  2. USN Rollback: Kenne ich grundsätzlich; wobei das ja von einer gewissen Zeit abhängig ist wo der zweite DC offline war. Sollte ich da bei unter 12 Stunden jemals probleme kriegen? Länger dauert das kopieren sowie der Hardwareumbau sicherlich nie.

     

    lg

     

    Auch die kleinste Änderung im AD wärend der andere offline war und du hast nen Roll-back. VM Snap-Shots & AD Domänen Controller passen etwa so gut zusammen wir Käse und ein Schokoladen Milch-shake. Vergiss es!

  3. Bricklevel - AKA Sicherungen der einzelnen Mailboixen über die EX API. Veritas/Symantec und auch andere machen das schon länger, ist aber wie erwähnt etwas fehleranfällig (by design) und dauert enorm lange, viel länger als eine Store/Storage Group Sicherung. Seit Backup Exec 11d oder 12 macht es das etwas anders und heisst neu GRT.

     

    Einfach mal schlau machen oder den EX Recovery Store verwenden um einzelne Elemente zu recovern.

     

    Recovery Storage Groups

  4. VSS funktioniert eigentlich so, dass er den SQL in einen 'freeze' versetzt, sprich laufende Transaktionen werden in ein differentail File geschrieben, üblicherweise ein Log, bis die Sicherung der DB erfolgt ist. Die Änderungen am Log werden dann nach der Sicherung dem eigentlichen File übergeben usw.

     

     

    Mal mit MS Kontakt aufgenommen? Dein Problem scheint sehr spezifisch und vllt noch unbekannt.

  5. Kuck mal hier: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.isaserver&tid=abc373d3-9bef-4d5f-abb3-663155bcd669&p=1

     

    Try to following registry changes. We were having the same problem and ran

    ISA Best Practices Analyzer and it suggested making the following changes and

    it worked.

     

     

    HKLM\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters

     

    EnableRSS Change to 0

     

    EnableTCPA Change to 0

  6. Die Checkbox kenne ich sogar, und die existiert auch wirklich. Welches SP fährst du denn beim ISA2004:suspect::wink2:

     

    Das sich was RPC Call änderte seit SP1 war mir auch klar. Einige andere Firewall Produkte hatten auch ihre Mühe, vor allem damit, dass Windows Server seit SP1 zwei GUIDs, bzw. zwei Calls auf einmal anfragen/durchführen kann.

     

     

     

    By the way: IPsec zwischen den DC ist wie erwähnt nur eine Lösung. Da du ja das Problem mit dem ISA isoliert hast, versuch's doch zu lösen (z.B. aktuellstes SP einspielen welches den veränderten RPC-Call versteht??).

  7. Welcher zum Beispiel ? Wie macht der Client das (der VA ist ja eigentlich nur eine virtuelle Netzwerkkarte) ? Ich kenne es so, dass die SPD bestimmt, was wie wohin geht, ob mit Adapter oder ohne. Es gehen dann natürlich schon, je nach Konfiguration, bestimmte Dinge nur über den VA, was aber nicht am Vorhandensein des VAs liegt, sondern weil die SPD so konfiguriert ist (zumindest bei den Dingern, die ich so gesehen habe).

     

     

    Wie erwähnt, die erbeiten unterschiedlich. Aventail besipielsweise macht bei aktiver Verbindung einen PPP Adapter auf mit eigener MAC, IP, DNS und sonstigen IP Einstellungen (kein zusätzliches Protokoll auf dem physischen Adapter gebunden). Auch Routing Einträge werden geschrieben, je nachdem ob die Verbindung offen ist oder nicht. Check Point erstellt hingegen einen vollwertigen Netzwerk Adapter (virtuell) der sich ansonsten nicht gross vom Aventail unterscheidet, ausser dass ein zusätzliches Protokoll an den Adapter gebunden wird bei der Installation.

     

    Für's OS ist es somit Transparent was geschiet, und wenn ein Packet für die VPN Domain bestimmt ist wird es (kann weder der Client noch das OS an sich ja wissen) anhand der IP Eigentschaften entweder direkt, über den physischen Adpater oder gekapselt mit der IP des phyischen Adapters and die entsprechenden Orte gesendet.

     

    Ich geb dir recht, dass insofern der Client bestimmt, welche IP Eigentschaften & Routing Tebellen geschrieben werden (aufgrund der Konfiguration des Clients), doch die Packete werden über das OS anhand der der IP Eigenschafen versendet. Wo und wie der Hook im TCP/IP Stack implementiert ist ist eine andere Frage.

  8.  

    am dynamischen Zuordnen knusper ich noch ein wenig rum, die feste zuordnung einzelner ports funktioniert schon einmal, die empfehlung ueber VPN zu tunneln find ich sehr ernuechternd.

    ehrlich gesagt so wahnsinnig ungewöhnlich finde ich das ganze Konstrukt (Firewall zwischen Internem Netz und Perimeternetz) nun auch nicht, ich quäl mich mal weiter durch die recht umfangreiche Doku für die ich mich nochmals bedanken möchte.

     

    Ist es auch nicht, auch ohne fixe Port Zuweisung - aber ehrlich gesgat ist es schwierig dir so in einem Board zu helfen wenn da noch Polemik hinzukommt.:wink2:

     

     

     

    hätte nur noch die Frage ob ich korrekt verstanden habe das sich nur fest vergebne Ports ueber die Firewall erreichen lassen und ob es notwendig ist die Server im ISA zu publishen?

     

    Publishen in diesem Szenario schon gar nicht und auch dynamische Ports, ob mit ISA oder ohne, sind machbar.

  9. oder doch, ich verstehe z.b. nicht, warum rpc-verkehr von dc1 auf dc2 als rpc erkannt wird und analog der regel durchgeroutet wird waehrend der verkehr von dc2 zu dc1 auf port 135 als "unidentifizierter traffic" geblockt wird.

     

    Scheint grundsätzlich ne Macke mit DC2 zu sein - neu machen scheint mir da nicht unsinnig.

     

    mir ist ganz grundsaetzlich nicht klar, warum alle naselang die alten netbios-ports mit den lustigsten verrenkungen benoetigt werden obwohl doch alles im schoenen neuen windows ldap und tcp/ip-basiert ist.

     

    Yup, das sieht man. Diese 'Netbios-Ports' sind NetBios over TCPIP oder kurz NBT. Scheinbar bist du dem leider immer noch vorliegenden Mythos auf den Leim gegangen, NetBUI hätte auch nur entfernt was mit NBT zu tun. Wie auch immer, los wirst du die definitv nur dann, wenn NBT auf der Netzwerkkarte deaktiviert wird, ansonsten wird es zur abwärtskompatibilität weiter verwendet.

  10. Versteh das Problem nicht - ISA 2004 bringt schon einen respektablen Monitor mit, warum nicht den Benutzen? Oder liegt es da am Verständnis?

     

    Ausserdem, RPC-Call == Request auf Port 135 und Ausshandeln der entsprechenden Caller Funktion entsprechend seiner GUID auf einem Port > 1024. Aber das sollte ja kein Problem sein 'wenn' alles offen ist zwischen den beiden. Fehlkonfigurationen sind aber nicht ausgeschlossen.

     

     

    cheers

    Velius

     

     

    P.S.: Wie sieht die DNS Reiehnfolge deines DCs in den Eigenschaften der NIC aus? Sich selbst zuerst, anderen zuerst oder was? More details please...

  11. Ich empfehle eine Seite des Kommunikationspaares (Switch/Netzwerkkarte) auf Fest 100 (bzw. 1000) full duplex einzustellen und die andere auf Autosensing.

     

    WIr stellen die Switche auf Autosensing und die Karten fix ein. Das hat den Vorteil dass weniger Overhead bei der Kommunikation zwischen Switch und Karte verlorengeht, wenn die beiden ausdiskutieren, wer den Speed vorgibt.

     

    Das ist nicht zu empfehlen:

     

    A duplex mismatch occurs when two connected devices are configured in different duplex modes. This may happen for example if one is configured for autonegotiation while the other one has a fixed mode of operation that is full duplex (no autonegotiation). In such conditions, the autonegotiation device correctly detects the speed of operation, but is unable to correctly detect the duplex mode. As a result, it sets the correct speed but starts using the half duplex mode.

     

    Autonegotiation - Wikipedia, the free encyclopedia

     

     

    Entweder beide auf Auto oder beide fix.

    Der Overhead ist vernachlässigbar genüber einem Duplex Missmatch.

×
×
  • Neu erstellen...