Bei der Einrichtung unseres neuen Servers und der VPN-Verbindung (Haupstelle, Nebenstelle, zwei Standorte) sind ein paar Fragen aufgekommen, mit denen ich hier hoffentlich richtig bin.
Wir haben auf einem Win2K3 R2 x64 SP2 Server eine Single-Domäne mit FQDN (intranet.firma.de), Benutzer und Computer nach Abteilungen in OUs mit einer GPO (kein Internet über eine Fake-Proxy)
In der Netzwerkumgebung stehen alle PCs und Server - fern oder lokal - in einer langen Liste. Gibt es eine Möglichkeit diese Ansicht zu beinflussen bzw. zusammenzufassen, so dass man sieht: Dies ist der entfernte Standort mit Rechner X, Y und Z und dies ist hier lokal A, B und C?
Ich habe im ADS eigene OUs erstellt mit derm Namen "Computer" und "Benutzer", darunter dann "Haupstelle", "Nebenstelle 1" usw. Nun stehen dort aber noch so Gruppen wie "Computers", "Users", die leer sind. Kann ich diese irgendwie aus der Ansicht verbannen oder müssen die zwingend bleiben? Dient rein der Ordnung und Übersicht.
Obschon ich das deutsche MUI-Pack für den Server installiert habe, sind einige Menu-Dialoge trotzdem in Englisch geblieben. Auch eine Nachinstallation des Sprach-Patches und Neustart haben da keine Besserung gebracht. hat jemand eine Ahnung, woran es liegen könnet und wie man das komplett umstellen kann.
Ich habe mir das neue Gruppenrichtlinienverwaltungstool (gpmc.msc) vom MS geholt und möchte es gerne benutzen. Wenn ich aber nun auf eine GPO gehe und mit "edit" diese ändern möchte, erscheint die Meldung, dass "gpedit.msc" nicht gefunden werden konnte. Vorhanden ist es aber.
Da es auf unserem deutschen Win2k3 x32 R2 BDC aber funktioniert, denke ich, ist es ein Sprachversionsproblem. Es ist auch nicht dramatisch, da es ja egal ist, ob ich die GPO auf dem BDC oder PDC ändere, aber es wäre schon gut, dies zu wissen.
Unter AD-Standorte und -Dienste habe ich zwei Standorte stehen, einmal "Standardname-des-ersten-Standorts" und den von mir erstellten Standort "Nebenstelle-1". Kann man den "Standardnamen-des-ersten-Standorts" gefahrlos umbenennen in "Hauptstelle"?
Gibt es eine Möglichkeit die IP-Einstellungen (DNS, Gateway) der Clients per GPO zu ändern? Unsere Clients haben statische IPs, also nicht via DHCP.
zu 1:
-mir nicht bekannt, bei mir bekommen alle Rechner einen Prefix
zu 2:
-in eigenen OUs muss man nicht zwingend weitere Ordner haben, die "mitgelieferten" Computers und Users wuerd ich mal schoen da lassen (mir ist auch schleiderhaft warum Du nun "Computer" und "Benutzer" selber erstellt hast)
zu 3:
-ich benutze keine Lang-Packs, u.a. auch wegen dieser moeglichen Fehler unter 4/5.
zu 6:
-wenn Du die Moeglichkeit hast es umzustellen dann mach es einfach
zu 7:
-Du willst was, fuer jeden Rechner eine neue Kombination vergeben oder alle auf einmal auf DHCP umstellen?
(letzteres ginge, ich glaub aber nicht per GPO)
01. Okay, das ist ein Workaround. Leider aber nicht unbedingt eine praktikable Lösung.
02. Auf die mitgelieferten Container kann man keine GPOs anwenden, da es keine OUs sind. Zumindest geht es bei mir nicht.
03. Nun, bei einem so dimensionierten Server (8 GB RAM) wäre es blöd, keinen x64er Software zu verwenden.
Wenn ich auf komplett Englisch umstelle, sind alle Serverrelevanten Meldungen und Dialoge bei den Clients auf Englisch. Ausser mir spricht niemand hier ausreichend Englisch.
06. Okay, versuche ich mal nach Feierabend.
07. Ja, ich möchte für jeden Rechner sicherstellen, dass er eine bestimmt Kombination aus DNS 1, DNS 2 und Gateway hat ohne jetzt an jeden Rechner gehen zu müssen. Ggf. würde mir auch reichen zu wissen, wo's in der Registry steht, da ich auf diese Remotezugriff habe.
zu 7:
Das mit der Registry wuerd ich gleich mal abhaken oder gibt es bei Dir im Hause nur einen Typ von Netzwerkkarte?
Es ginge wenn dann nur per Script, um welche Anzahl handelt es sich denn?
zu 2: Jup. Keine GPOs auf die Standard Container. Macht immer Sinn, neue OUs anzulegen (Vorbild SBS2k3 ist da nicht schlecht).
zu 3: Schwierig. Würde direkt bei MS nachhaken. Könnte ja sein, dass einige Dialoge wirklich nicht übersetzt wurden, weil sie später hinzukamen.
zu 4: Lösung ist ziemlich einfach. Du wirst warscheinlich das AdminPak.msi für die 32Bit Version installiert haben. Es gibt Inkompatibilitäten bei 32Bit und 64Bit SnapIns. Einen großen Artikel dazu findest Du hier: http://support.microsoft.com/kb/304718/en-us.
Musst einfach das AdminPak für die 64Bit laden.
zu 5: Liegt nicht an der Sprachversion, da alle SnapIns immer die gleichen Dateinamen haben (englisch) -> Lösung siehe Punkt 4.
zu 6: Sollte man ändern können. Wüsste aber nicht warum. Habe ich noch nie gemacht. Würde mich aber interessieren, ob das glatt geht. Hätte in meinen Augen höchstens kosmetischen Charakter.
zu 7: Per GPO geht das nicht. Du könntest in das Login-Script einen netsh Befehl einbauen. Bedingung dafür wäre, dass die Netzwerkverbindung bei allen LAN-Verbindung heisst (also der Standardname):
Code:
netsh interface ip set address "LAN Verbindung" dhcp
[...]zu 6: Sollte man ändern können. Wüsste aber nicht warum. Habe ich noch nie gemacht. Würde mich aber interessieren, ob das glatt geht. Hätte in meinen Augen höchstens kosmetischen Charakter.[...]
Kann und sollte man ändern - zumindest, wenn man mehr als nur zwei Standorte hat, sieht sonst in der AD-Dokumentation (mit Jose z.B.) eher unschön aus. Aber: KEINE Leerzeichen beim Standortnamen verwenden, das knallt!
Zitat:
[...]zu 7: Per GPO geht das nicht. Du könntest in das Login-Script einen netsh Befehl einbauen. Bedingung dafür wäre, dass die Netzwerkverbindung bei allen LAN-Verbindung heisst[...]
Und das der User entsprechende Rechte hat?
Von direkten Registry-Änderung (im Prinzip ja auch nix anderes wie GPOs) würde ich dringend abraten, die lassen sich zwar auch per GPO realisieren, damit kannst du aber auch ein komplettes Netz "auf einen Streich" lahmlegen. DHCP heisst die einzige Lösung.
Per Reg halte ich für sehr schwierig, da man in diesem Fall doch mehr, als nur den Namen der Verbindung kennen muss.
Erinnere mal mal an ein vbsScript, bei dem ich alles mögliche einer Netzwerkverbindung ausgelesen habe. Da alle Eventualitäten abzudecken war ein Graus. Muss das unbedingt mal suchen, da das ein echter Geniestreich war.
Was die Rechte angeht. Ist natürlich ein Problem. Kleiner Tip, der sich im Alltag (weniger im großen Enterprise Bereich, aber dort hat man auch ganz andere Möglichkeiten) bewährt hat. Bei Kunden zwischen 20-50 Usern kann man das, wenn es nicht anders geht, machen:
Erstelle eine Domain-Security Group namens LocalAdmin. Diese DomainGruppe packst Du bei jedem Rechner in die Sicherheitsgruppe "Lokale Administratoren".
Abends alle User Mitglied der Domain Group "LocalAdmin" machen und schon sind sie auf jeder Kiste lokale Admins und man kann auch tiefergreifende Scripts starten. Man sollte natürlich nicht vergessen, diese dann Mittags (wenn mal jeder Rechner on war) wieder rauszunehmen.
Eine andere Möglichkeit wäre, das netsh Script per AutoIT als Admin zu starten. Somit hättest Du gar kein Sicherheitsrisiko.
Ne dritte Möglichkeit wäre, nen separaten Batch mit entsprechenden Rechten zu starten, wobei ich hier Kixtart empfehlen würde, das kann im Gegensatz zur Windows Shell die Passwörter verschlüsselt im Code der Batch ablegen - bei Windows selbst stünde das Adminpasswort im Klartext inner Batch und das will man ja nun wirklich nicht.
Erstmal vielen Dank für die Antworten und Tipps! Sehr brauchbar und verständlich.
Das mit den Netzwerkeinstellungen werde ich doch wahrscheinlich manuell vor Ort bei 20 Clients regeln. Aber ich werde mir alle Methoden mal ansehen.
Also, ich habe den Standardnamen des ersten Standorts umbenannt - ohne Leerzeichen in "Haupstelle". Damit ist mir aber die Sichbtbarkeit der über VPN verbundenen Rechner in der gegenseitigen Netzwerkumgebung verlorengegangen. Hm. dcdiag, Direktansprache per IP und Replikation funktionieren jedoch einwandfrei und geben keine Fehler aus. Nur sehe ich die vpn-verbundenen Rechner nicht mehr in der Netzwerkumgebung. Wovon ist denn sie Sichtbarkeit in der Netzwerkumgebung bei VPN abhängig? NetBIOS, WINS und DNS sind einwandfrei für alle verbundenen Server redundant konfiguriert.
Und ich bekomme jetzt aber immer die Meldung in der Ereignisprotokollierung: "Während der letzten 4,24 Stunden gab es 69 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden."
und
"Keine IP-Adresse (192.168.3.2) dieses Domänencontroller stimmt mit dem konfigurierten Standort "Nebenstelle-1" überein. Obwohl es sich hierbei um eine vorübergehende Situation aufgrund von IP-Adress-Änderungen handeln kann, wird empfohlen, dass die IP-Adresse des Domänencontrollers (zugreifbar für Computer in der Domäne) mit dem Standort, den der DC bedient, übereinstimmt. Wenn die oben angegebene Liste von IP-Adressen dauerhaft ist, sollten Sie diesen Server zu einem Standort verschieben, so dass die oben angegebene IP-Adresse mit dem ausgewählten Standort übereinstimmt (ggf. sollten Sie einen neuen Standort erstellen). Dies erfordert möglicherweise die Erzeugung eines neuen Subnetzobjekts (dessen Bereich die obige IP-Adresse einschließt), das mit dem ausgewählten Standort übereinstimmt."
Gerade die letzte Meldung verstehe ich nicht. Der DC der Nebenstelle-1 hat aber doch die IP 192.168.3.2 und das ist doch der Netzbereich der Nebenstelle (192.68.3.x). In allen anderen Standorten kriege ich auch diese Meldung.
Ich habe nun alle selbst erstellten Standortverknüpfungen und die vom KCC erstellten gelöscht. Normalerweise werden diese ja doch automatisch wieder erstellt, oder? Kann man dien KCC-Dienst dazu auffordern?
Navigation
2K3 - Fragen zu AD, Win2K3 x64 und GPO
Linear-Darstellung
