Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.135
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von NilsK

  1. Moin,

     

    ich denke auch, dass man den PDC nicht umbedingt virtualisieren sollte.

     

    im AD gibt es keinen PDC.

     

    Da, a) wenn er alleine auf dem ESX läuft, man sich die Virtualisierungschicht sparen könnte oder b) wenn noch weitere Maschinen mit auf dem ESX laufen, ich sowieso davon abrate (siehe Windowsbetatester)

     

    Dafür gibt es technisch keinen Grund.

     

    Wir haben hier als 3.DC einen noch virtuell laufen, dass halte ich da für die Bessere lösung.

     

    Das mag für euch okay sein, ist als allgemeine Empfehlung aber unsinnig.

     

    Zumal der "echte" DC auch Leistungsfähiger ist, als der auf dem ESX (bei uns zumindestens| ohne Storage)

     

    In den allermeisten Netzwerken stehen DCs so gut wie gar nicht unter Last. Das bisschen "Virtualization Fee" ist also zu vernachlässigen.

     

    Gruß, Nils

  2. Moin,

     

    Windows 7 lässt sich problemlos in einem 2003-Netzwerk betreiben. Die Gruppenrichtlinien, die die 7-Features steuern sollen, kann man (wie schon vorher unter Vista) nur von einem 7-Client mit RSAT aus verwalten. (Allgemein gilt, dass man zur Bearbeitung von GPOs immer den neuesten unterstützten Client einsetzen sollte.)

     

    Die Sache mit den Profilen hat mit Windows 2003 nichts zu tun.

     

    Gruß, Nils

  3. Moin,

     

    grundsätzlich spricht nichts dagegen, einen DC zu virtualisieren, sofern die Umgebungsbedingungen stimmen. Ein paar Aspekte habt ihr ja schon angesprochen. Ob man das durch einen "separaten" physischen Server löst oder anders, ist eher sekundär.

     

    In einigen Situationen ist ein virtueller DC sogar von Vorteil, weil man etwa beim Recovery die Hardware-Abstraktion nutzen kann (keine bzw. weniger Treiberprobleme, als wenn man einen phys. Server auf anderer Hardware recovern müsste).

     

    Ein No-go sind allerdings Snapshots und ähnliche Funktionen, weil sie die Replikation aus dem Tritt bringen und die Datenkonsistenz gefährden (USN Rollback).

     

    Gruß, Nils

  4. Moin,

     

    du wirst keine sinnvolle Möglichkeit haben, einen solchen Angriff auf andere Weise zu korrigieren. Was mal wieder die Notwendigkeit zweier Dinge zeigt: Laufende Backups und verantwortungsbewusste Administration. Denn kaputt spielen kann man alles, sogar unsinkbare Kreuzfahrtschiffe.

     

    Gruß, Nils

  5. Moin,

     

    in ERP-Systemen wird oft ein Aufbau mit Development-Test-Production genutzt. In diesem Szenario gibt es die produktiven Systeme und losgelöst davon ein Entwicklungs- und ein Testsystem. Auf letzteren werden Änderungen an der ERP-Software entwickelt und getestet, bevor sie ins Produktionssystem kommen.

     

    Diese Testsysteme dienen also nicht der Evaluation eines Produkts, sondern laufenden Kompatibilitäts- und Funktionstests der ERP-Anwendung. Die Entwicklungssysteme hingegen dürften dem Szenario üblicher Entwicklersysteme entsprechen, wie sie auch in der Applikationsentwicklung genutzt werden.

     

    Wie ist hier zu lizenzieren? Für die Produktionssysteme benötigt ein Kunde ganz "normale" Lizenzen - klar. Aber bei den Entwicklungs- und Testsystemen? Reichen da MSDN-Lizenzen oder Ähnliches aus? Falls Letzteres: Gilt das für Betriebssystem und alle Applikationskomponenten?

     

    Gruß, Nils

  6. Moin,

     

    wow, den Kollegen möcht ich mal kennen lernen. Oder noch besser: Eure Geschäftsführung.

     

    Preisfrage: Wie sinnvoll ist es in so einer Situation, überhaupt mit dem Restore von Band zu warten und sich in Foren rumzutreiben?

     

    Oder um es genau zu sagen: Sieh zu, dass du dein Backup zurückspielst. Und danach besucht ihr einen Grundkurs in verantwortlicher IT-Administration.

     

    Gruß, Nils

×
×
  • Neu erstellen...