Domänencontroller in unterschiedlichen Sprachen - möglich oder nicht?

  • Article

Hallo, Fabian hier. Ab und an stellt sich bei unseren Kunden die Frage ob es problemlos möglich ist, Domänencontroller in unterschiedlichen Sprachen innerhalb einer Windows Server 2003 Domäne einzusetzen. Die Antwort lautet - wie so oft - ganz eindeutig: Jein - oder: Kommt drauf an. ;-)

Gleich zu Beginn sei gesagt, daß es grundsätzlich auf jeden Fall möglich und supportet ist, Domänencontroller in unterschiedlichen Sprachen innerhalb einer Domäne und damit eines Forests zu betreiben. Die internen Strukturen der Active Directory sind unabhängig von der "Darstellungssprache". Denn mehr als eine Darstellung nach außen ist die Sprachwahl innerhalb einer Domäne nicht.

Ausnahme sind hier MUI (Multilingual User Interface) Packs - hier gab es in der Vergangenheit ab und an Probleme, weshalb ich eher davon abraten würde, MUI Packs auf DCs zu nutzen.

Es kann jedoch trotzdem durchaus Sinn machen, die Domänencontroller in einer einheitlichen Sprache zu betreiben. Daher an dieser Stelle ein paar Stichpunkte, warum dies "Best Practice" ist:

  • Oftmals wird bei der Einrichtung einer Domäne vergessen, daß die Sprache des ersten Domänencontrollers auch die "Darstellungssprache" innerhalb einer Domäne bestimmt. So werden beim DCPROMO des ersten DCs einer Domäne beispielsweise die Namen der Builtin-Accounts über diese Sprache festgelegt. Nutzt man also für dieses DCPROMO der Domäne ein englisches System, werden auch die Standard-Konten wie "Administrator" oder Standard-Gruppen wie  bzw. "Administrators" oder "Domain Admins" in englischer Sprache benannt. Ist der erste Domänencontroller jedoch etwa ein deutsches System, werden diese nach deutschem Namensschema benannt, so z.B. "Administratoren" oder "Domänen Admins".
    Als weiteres Konto ist außerdem der erste Administrator des Forests zu erwähnen, der beim DCPROMO des ersten DCs des Forests benannt wird. Da im Englsichen als auch im Deutschen der "Administrator" gleich heißt, ist das eher kein Problem. In anderen Sprachen / Zeichensätzen kann das jedoch durchaus ein Problem darstellen.

    Zwar läßt sich der sAMAcoountName für diese Builtin-Accounts und -Gruppen problemlos ändern, jedoch gilt dies nicht für den Common Name (cn) und damit verbunden den Distinguished Name (dn). Diese Attribute sind vom SYSTEM geschützt und können nur mit etwas Aufwand geändert werden, was an dieser Stelle jedoch nicht empfohlen wird.

  • Auch wenn sich die Problematik mit Hilfe von Managementsystemen wie MOM / SCOM oder ähnlichen Produkten entschärft, so muß doch weiterhin das Management der Systeme im Auge behalten werden. Will man etwa ein Script gegen die Server laufen lassen, gilt es bei unterschiedlichen Sprachversionen ggf. deren Eigenheiten zu beachten. So sind zum Beispiel die Dienstnamen in unterschiedlichen Sprachversionen meist verschieden oder es gibt andere Besonderheiten in Namensgebung oder Zeichensatz. Dies hat zwar nur indirekt mit der Active Directory als solches zu tun, ist jedoch ein nicht unwesentlicher Faktor bei der Frage, ob man mehrere Sprachversionen einsetzen möchte oder eher nicht.

  • Sind Administratoren aus unterschiedlichen Ländern mit der Wartung bzw. Betreuung der Systeme betraut, macht auch hier eine einheitliche Sprache Sinn. Niemand wird einen Ausfall riskieren wollen, weil der spanische Mitarbeiter gerade kein Kyrillisch in der Fehlermeldung oder im Ereignisprotokoll übersetzen kann und den falschen Schalter drückt (siehe dazu "Hilfe zur Selbsthilfe"). ;-)
    Englisch ist beispielsweise eine Sprache, die die meisten Mitarbeiter innerhalb der IT länderübergreifend sprechen oder zumindest verstehen. Auch im Supportfall oder beim Hinzuziehen eines externen Dienstleisters kann es durchaus von Vorteil sein, wenn nicht nur Muttersprachler die Installationssprache verstehen.

  • Zwar entschärft sich das Problem immer mehr (durch angepaßte "Patchdays", durch WSUS Deployments etc.), jedoch ist auch das Patchmanagement eine kritische Angelegenheit. Früher kamen lokalisierte Hotfixes oftmals zu unterschiedlichen Zeiten heraus, was zu unerwarteten Problemen führen konnte. Gerade in Bezug auf Hotfixes von diverser Drittsoftware existiert diese Einschränkung oft immer noch, so daß auch hier einheitliche Installationssprachen die Situation entschärfen können. Gleiches gilt natürlich auch grundsätzlich für die Software, die ggf. auf den Systemen zusätzlich installiert werden soll (sei es die GPMC, Backup-Software, Monitoring-Software etc.).

  • Kennwortrichtlinien können ebenfalls ein Problem darstellen, denn einige andere Zeichensätze (wie zum Beispiel Japanisch) kennen keine Sonderzeichen wie etwa " $ % & ?". Hier kann es Sinn machen die Umgebung in einer einheitlichen Sprache aufzusetzen, so z.B. in Englisch (und nicht Japanisch).

Bleibt also unter dem Strich stehen, daß es im Normalfall also kein technisches Problem ist, verschiedene Installationssprachen einzusetzen. Die Frage ist viel eher, wie viele "Mehrprobleme" man sich ins Haus holt, wenn man keine einheitliche Sprache der Domänencontroller (oder weiter gefaßt: auch der Memberserver und -clients) wählt.

 Viele Grüße, Fabian.