kosta88

Und habe soeben rausgefunden was ich vorher falsch gemacht habe: Die Anleitung für das Webinterface habe ich nicht gefunden, daher habe ich angenommen es funktioniert wie der 1810. Aber neeeein... Wie bei der Console gesehen, der Switch hat eine Einstellung per VLAN. Das war mir unklar. Lässt sich auch per Interface verstellen, nun muss man beim default VLAN auf disabled umstellen, wenn man auf ein anderes VLAN umstellt. Der 1810 hat ein "Switch" dafür, und beim 2510 sind es bereits die VLANs. Tja. Man lernt.

Ahhhhh Dummkopf. Natürlich. OK, werde nur VLAN11 vergeben und basta. Danke :) Ich hab nun ein wenig sch**s seitdem ich mich gestern ausgesperrt habe. Aber ich vermute dass solang ich die Consolenverbindung habe, kann nix schief gehen!

Alsoooo... Console Cable bekommen, mit etwa Mühe und Programmsuche was funktioniert, hinbekommen. Putty ging nicht. Bin also wieder im Switch, auch per Web, scheinbar hat der Switch auf die alte Konfiguration zurückgestellt, ohne dass ich das wusste. Habe ich erst per Console gesehen. Jetzt bleibt weiterhin die Aufgabe, den Switch aus beiden 11er und 32er Netz managen zu können. Daher muss die Management-IP des Switchs ins Management VLAN 11 hinein. Manual: "If multiple VLANs are configured, then each VLAN can have its own IP address. This is because each VLAN operates as a separate broadcast domain and requires a unique IP address and subnet mask. A default gateway (IP) address for the switch is optional, but recommended." So, hier mal ein Beispiel wie ich das konfigurieren würde. Wenn ich dann Zugriff via VLAN11/32 habe und es funktioniert, würde ich DEFAULT_VLAN entfernen. Foto entfernt da gelöst. Die wichtigste Frage: wenn ich diese Einstellungen ändere, ändere ich wohl *nichts* an den Switch Einstellungen die das Netzwerk selber betreffen - d.h. es wird im Netz zu keiner Unterbrechung des Dienstes kommen? Und bevor jemand aufschreit warum man aus dem Produktivnetz das Switchmanagement zugreifen soll: wird per Firewall später blockiert und nur meiner Station Zugriff erlaubt.

Ahhhh OK! Top Sache, jetzt hab ich's geschnallt ;-) Ich hätte eh zur Not gleich daneben eine alte XP Kiste die Serielle Schnittstelle hat, aber wenn ich per Notebook managen kann, umso besser. Montag früh müsste ich vom Bekannten in einer IT Firma das Kabel bekommen, die haben dann auch eventuell ein Adapter für USB. Ich hoffe alles spielt sich richtig aus!

Ahh super, tftp32 ist eine gute Idee, solang DHCP wirklich aktiviert wird. Allerdings ist der Post by h-d.neuenfeldt genau das auf was ich mich bezogen habe! Wobei jetzt lese ich hier folgendes: "By default, the switch is configured to automatically receive IP addressing on the default VLAN from a DHCP/Bootp server that has been configured correctly with information to support the switch." Irgendwie konträr. Daher bin ich sehr unsicher ob ich ein Reset vorm Montag mache, da es passieren könnte, dass grossteil der Firma nicht online kommt (-> absolutes no-go). Also wie du sagst, derzeit ist glaube ich besser wenn ich abwarte bis ich das serielle Kabel habe... obwohl mich wundert dass ich das serielle Kabel wirklich brauche: Du hast oben den Vorschlag Seriell-USB gemacht. Der Switch hat nicht die serielle Schnittstelle, sondern RJ45. Dieses "Console Cable" ist eigentlich DSUB9-RJ45. Gibt es nicht als USB-RJ45 Kabel?? Oder braucht man noch ein Zwischenadapter? Ich habe noch unten ein EDIT hingeschrieben: nach dem Router-reset, gab keine IP mehr. Daher vermute ich dass wohl was anderes im Spiel war, weiss aber nicht was. Das erste mal hat's bezogen, und dann nicht mehr, bzw. erscheint nicht mehr in der Liste der DHCP-IP weder am Router noch am DC (derzeit wird noch das 32er Netz per Router vergeben, ich werde es dann erst auf DC umstellen wenn der Switch ordentlich funktioniert). Die Switch-IP (Management) sollte eigentlich eh vom DC vergeben werden, daher war sehr seltsam warum das am Router erschienen ist. In der DHCP Liste am DC ist es noch immer drinnen. Nun weiss ich nicht ob das wirklich der Switch ist (kein Name) und sehe nicht wann vergeben, nur wann ausläuft. Ich hab eigentlich ein sc***s vor irgendwelchen Änderungen, da derzeit das Produktiv-Netz funktioniert und ich es nicht lahmlegen will :( Es gibt was ich gesehen habe Ports 1-48, dann 49-50, und Console. 49-50 sind derzeit Trk1, für die Verbindung zum anderen Switch. 1-32 sind das Netz32, unser Produktiv-Netz, bereits im VLAN32 und funktioniert, DHCP kommt vom Router, und Port 48 ist separate noch VLAN14, was anderes. Ports 33-47 sind im Prinzip nichts... Management-Port gibt es glaube ich nicht.

Jau, jetzt verstehe ich auch, warum man es eventuell benötigt. Kannst du mir bitte sagen welchen Adapter meinst du denn genau? Ich hätte gedacht ich brauche das Console Cable + Terminal Emulator (zB. putty) damit das funktioniert. Geht es etwa anders? Lt. Bedienungsanleitung kommt es ohne IP-Konfiguration. Heisst das dass DHCP eingestellt ist? Weil wenn ja, ist das grundsätzlich schlecht, da ich in diesen Fall gar nicht zum Router mehr komme (oder ganz schwierig via 5 Umleitungen). Ganz b***d dass nicht mit einer IP vorkonfiguriert, dann kann man wie bei anderen Switchen einfach mit dem Laptop Zugriff bekommen. Ja, habe ich bevor ich bei der Management-IP auf VLAN umgestellt habe. Nun kann ich das Config nicht einspielen, da ich kein Zugriff mehr habe... Tue ich nicht. Eigentlich ist die IP fix, aber da der Switch nicht auf VLAN mit fix IP umstellen wollte, habe ich dennoch DHCP versucht und das hat funktioniert. Das Management vorm umstellen habe ich eben via fixer IP und gleichen Subnet am Laptop gemacht. Ist sie nicht. Flexibilität ist notwendig, weil entweder gehe ich via Remote von zu Hause, dann kann ich am Server die Admin-Station zugreifen, die befindet sich am CoreSwitch, aber auch lokal von meinem eigenen Rechner, dieser hängt eigentlich an dem 2510. Die saubere Lösung wäre alle Switches (und alle anderen "Management" Geräte) im selben VLAN zu haben, somit kann ich das Management-Netz schön vom restlichen Netz im Firewall abschotten. Auf jeden Fall, danke. Wie ich arbeite, so habe ich meine Doku offen und führe die Schritte durch.

Hallo, Also, nachdem ich heute etliche Stunden beim Konfigurieren unseres Netzwerks ins VLAN (erfolgreich) verbracht habe, habe ich doch am Ende geschafft einen Fehler scheinbar zu machen. Und zwar aus irgendeinen Grund kann ich mich per IP nicht mehr in den Switch 2510 verbinden. Die Netzwerktopologie ist folgende: Coreswitch (Procurve 1810G-24) Dann "sternförmig" vom Coreswitch weg 2 Switches: 1x 1810G 1x 2510 Die Grundidee war die ganzen Management Sachen im Netzwerk ins VLAN11 zu platzieren, also auch die Switch Management-IPs. Die zwei 1810G habe ich erfolgreich umkonfiguriert und beide sind im VLAN11 und vom Admin-Rechner (der am CoreSwitch hängt), zugreifbar. Die Konfiguration ist folgende: 3 Trunks am CoreSwitch: 1x Trunk zum Router, 2x Trunk zum zweiten 1810G und 2x Trunk zum 2510. So bin ich vorgegangen: Am CS habe ich bei allen VLANs alle Trunks auf T (Tagged) gestellt. Genauso wie am 2510. Am 2510 habe ich nur die VLANs erstellt, die an dem Switch genutzt werden, und für die dann die Trunk Leitung am CS auch auf allen erstellten VLANs auf T gestellt. Somit sollte die Konfiguration ausreichend sein (war beim zweiten 1810G) um den 2510 vom CoreSwitch (Rechner) zu erreichen. Somit habe ich das Default VLAN (ich war direkt am Switch verbunden) auf VLAN11 Management gewechselt und neugestartet (DHCP auch zur Sicherheit aktiviert). Der Switch bekommt die IP vom DHCP, und erscheint in der Liste vom LANCOM Router als VLAN11. Also muss die Konfiguration geklappt haben?? Sonst würde der Switch ja keine IP bekommen! Also, gekürzt: CS: VLAN1: Trunk1/2/3 = E VLAN11: Trunk1/2/3 = T, Port17(Admin-Rechner) = U VLAN32: Trunk1/2/3 = T 2510: (soweit ich mich erinnern kann) VLAN11: Trunk1 = T VLAN32: Trunk1 = T Am 2510 sind Ports 49-50 als Trunk via CLI konfiguriert worden, und VLAN32 funktioniert richtig (somit kann ich sagen dass der Trunk OK ist). Nichts zu trotz, kann ich den Switch von meinem Admin-Rechner nicht erreichen, und der befindet sich auch im VLAN11. Der CoreSwitch und der 2. 1810G sind normal erreichbar. Kann jemand da herauslesen was los ist? Ich habe versucht den Switch durch jegliche Einstellung wieder zu erreichen, habe sogar versucht das Laptop direkt anzuschliessen und die IP in das gleiche Subnet zu stellen + VLAN11 auf der Netzwerkkarte, und trotzdem konnte ich mich nicht verbinden (aber hier vermute ich, dass es daran liegt, dass derzeit kein Port am 2510 als VLAN11 eingestellt ist, ausser Trunk-Leitung halt). Und dann, am Ende, wollte ich ein Full-Reset des 2510 machen, nun habe ich gelesen der Switch hat Defaultmässig keine IP-Konfiguration, und da ich unser Konsolenkabel nicht finden kann, würde ich mich auf den Switch gar nicht verbinden können. Somit habe ich das gelassen. Vielleicht schaffe ich ja doch das Kabel über's Wochenende aufzutreiben, und wenn nicht, dann am Montag und dann kann ich das Management-VLAN11 hoffentlich entfernen, bzw. auch die letzte funktionierende Konfiguration laden. Gibt es eine andere Möglichkeit, zb. nicht via DB9-RJ45 zu arbeiten, sondern direkt via Netzwerk-Kabel?? Habe ich irgendeine andere Lösung die gespeicherte Konfiguration zu laden?? Kann ich irgendwie die Serielle Verbindung "umgehen" oder wandeln? Vielleicht finde ich eine alte Kiste die Seriell hat, aber mein Arbeits--Lenovo-Laptop hat keine Serielle Schnittstelle mehr, auch nicht die Dockingstation. Für jegliche Hilfe bin ich extremst dankbar!! Besten Dank, Kosta EDIT: Jetzt Router neugestartet, und merke der 2510 bekommt nichtmal die IP... tja, das war's wohl. Bleibt die einzige Frage: gibt es andere Wege um den Switch zu erreichen?

Vielleicht habe ich mich etwa falsch ausgedrückt. Also, ich habe ne OU, in der OU sind die Benutzer, und gleich daneben eine Gruppe. Die GPO ist verlinkt auf die OU, nicht auf die Gruppe, das verstehe ich schon. In der Gruppenrichtlinienverwaltung kann ich ja die Gruppenrichtlinienobjekte auf die OUs verlinken. Wenn ich dich jetzt richtig verstehe, will du mir sagen, dass hätte ich NUR die Gruppe in der OU, und die Benutzer woanders, würde sich die OU nicht auf diese Benutzer auswirken - OK, das hätte ich nicht gewusst, daher danke. Ich werde das durchgehen sobald ich ein wenig Luft bekomme. Wie schon gesagt, sind beide (Gruppe und Benutzer) drinnen, deswegen wirkt es ja. Habe ich schon geprüft.

Danke, schaut wie ein toller Artikel für den Anfang. Werde ich lesen. Du weißt schon, dass Gruppenrichtlinien nicht auf auf Gruppen, oder? ;) Ja schon. Deswegen habe ich OUs ;-) Wenn Gruppenzugehörigkeit, dann wirklich nur zu den Admins. Jeder, jeder Benutzer ist Domänen-Benutzer. Für lokale Admins würde ich es vermutlich eher so machen: http://www.gruppenrichtlinien.de/artikel/lokaler-administrator-install-agent-delegation-pro-computer/ Ich brauche auch die Gruppen für die Nutzer, da ich so leichter die TS Zugriffe erlauben kann, ohne auf den TS gehen zu müssen. Link schaue ich mir an, sicherlich informativ! An einem DC kann sich out-of-the-Box nur ein Domain Account anmelden, beantwortet das deine Frage? Und normalerweise gilt: Admin ist Admin ist Admin. Mit Ausnahmen bei den Admin-Gruppen in der Domain. OOTB ist mir klar. Aber man kann einen Nutzer erstellen und ihm die Domänen-Admin Gruppe zuteilen. Und dann hat er absolut die gleichen Berechtigungen und Möglichkeiten wie der "Administrator". Deswegen für mich die Frage warum die Mühe überhaupt.

Sorry für die späte Antwort, war auf unseren Firmenschulungen in Deutschland. Bin jetzt etwa schlauer wenn's um die Netzwerkkonfiguration und Troubleshooting geht ;-) Also, ich habe mir im AD zwei OUs erstellt, eine für den/die Admin(s) und eine für die Laptop-Benutzer, so dass ich hier leicht zwischen GPOs trennen kann, oder so ist mindestens der Plan :) Dann in jeder OU ist eine Gruppe, jeweils für alle Nutzer drinnen - damit ich die Gruppe(n) zB. für Remote am TS freigeben kann. Soweit so gut. In diesen Gruppen weise ich die Zugehörigkeit den jeweiligen Gruppen - Domänen-Administrator und Administratoren(lokal) bzw. Domänen-Benutzer und Benutzer(lokal). Auch entferne ich die Gruppe Domänen-Benutzer wenn es ein Admin ist. Macht Sinn? Bin zwar noch am testen was alles geht und was nicht, aber grundsätzliche Frage: Was kann ein Administrator-Konto am DC mehr als ein angelegter Benutzer-Konto der Mitglied der Gruppe Domänen-Admins ist?

Daniel, Habe dein Vorschlag versucht, nun entweder mache ich was falsch oder etwas funktioniert nicht. Wenn ich diesen admin-user als Mitglied der lokalen Administratoren Gruppe und Domänen-Benutzer eintrage, funktionieren am Client nach dem erneuten Login trotzdem nicht die Admin-Rechte. zB. Server-Manager lässt sich nicht öffnen und sagt es fehlen die Administrator-Rechte. Ich kann natürlich als Admin ausführen und den Domänen-Administrator eintragen, aber macht das Sinn? Ist das was du meintest?

Nachlesen + Nachdenken + Beiträge + Lämpchen = Ergebnis :p Ist so ähnlich wie beim VLAN gewesen. Die ganze Zeit denke ich mir nun häää, wovon reden die...und dann wenn man es einmal gecheckt hat, die Welt geht auf. Nun, jetzt geht's erstmal in die Tiefe :)

Haaaaaaaaaaaa, voll im Griff! Habe auf diese Homepage gruppenrichtlinien.de viel nachgelesen, und ja... man muss am TS, unter Remotedesktop Benutzer schon was eintragen. Und am leichtesten ist wohl eine neue Gruppe für den TS1 erstellen, alle Nutzer die Zugriff bekommen sollen reinhaun, und die Gruppe in den Remotedesktop "Benutzer auswählen..." eintragen. Somit kann ich im AD einfach Mitglieder für die Gruppe wählen, die Zugriff auf dem TS1 haben dürfen. Und wie geil isn das, unsere Software kann sogar die Nutzer direkt aus dem AD auslesen und eintragen. Coole Gschicht, wie man bei uns in Ö sagt ;-)

Ich mache mir ernsthaft die Mühe. Ich meinte eh das Benutzerkonto. Ich kann das ganze Netzwerktechnische wesentlich besser auf Englisch, da ich mit Computern seit meiner Jugend zu tun habe, und Deutsche Sprache ist eben für mich netzwerktechnisch relativ neu. So, nachdem du gesagt hast "Der darf sich am TS anmelden", vermute ich dass man den AD Benutzerkonto Zugriffserlaubnis für den TS geben muss. Nicht nur allgemein RDP sondern auch Rechner-spezifisch. Muss jetzt ganz b***d fragen wie? Von der Diskussion was lokal zu machen bin schon längst weg. TS ist in der Domäne, nun bekomme ich kein Zugriff ohne lokal am TS die Benutzerkonten einzutragen (wie oben erwähnt).

TS war bis jetzt nicht in der Domäne. Es gab am Rechnern immer zwei Nutzer: ein lokaler Konto als Rechner-Login und ein 2. Nutzer für die TS-Sitzungen. Die Nutzer sind lokal angelegt und dann im RDP im System eingetragen (Unter System -> Erweiterte Systemeigenschaften -> Remote -> Remotedesktop am Terminal Server). Dann wurde DC eigerichtet und TS in die Domäne gesetzt. So jetzt will ich weg vom lokalen Konten und die Rechnerkonten aus dem AD nutzen, sodass der Rechnerlogin = RDP Berechtiger ist, und kein weiterer Nutzer benötigt ist. Ich hoffe dass das Sinn macht und so machbar ist. Die Userdirs würde ich dann aber doch gerne am Server legen, und irgendwie die Möglichkeit haben die Profile zu bereinigen (nach den Schulungsessions einfach alles löschen was die Benutzer gespeichert haben). Die derzeitige Einstellung ist die mittlere, und hier sind die lokalen Benutzer eingetragen. Wenn ich hier den AD-Konto für die RDP-Sitzung eintragen, dann geht's. Ohne, nicht. Geht es überhaupt nur via AD? Es ist vermutlich die Einstellung 3 die richtige, auf der Netzwerkebene zulassen, nun jetzt kann ich nicht umstellen, da der TS gerade in Verwendung ist. (wobei die mittlere müsste die 3. Option eigentlich inbegriffen haben)

Scheinbar habe ich mehr Problem mit den deutschen Wörtern (ist nicht meine Muttersprache) bzw. verwechsle noch Gruppenrichtlinien, Berechtigungen usw. Was ich aber dann meistens schon weiß, was hinter was steckt. Ich weiß zB. dass man in GPO nicht Ordner freigeben kann (Permissions). Nein. Ich weiss leider nicht mehr genau wie es heisst, irgendwo habe ich es nachgelesen, und derjenige hat es irgendwie genannt. Ob Key oder irgendwie sonst, weiss ich nicht mehr genau. Habe ich bereits gesagt :) Aber...nachdem mir einige hier sehr hilfreiche Sachen geschrieben haben, ist mir gerade ein Lämpchen aufgeleuchtet. Es war ein Gedankenfehler von mir zu denken dass ich für jeden Rechner einen Nutzer benötige. Ich soll eigentlich die Domäne wie einen grossen Rechner sehen der andere "Rechner" enthält. Vereinfacht gesagt. Ein Admin Konto der dafür da ist, alle Rechner zu verwalten. Und dann gibt's das Thema Roaming User Profile, das muss ich noch nachsehen/lernen. Sicher? Da das Profil weiterhin am lokalen Rechner gespeichert wird... nun der Ordner heisst anders: username.domain.local, oder wie auch immer die Domäne heisst. Nur wenn du dein Profil im Netz ablegst (das verstehe ich unter Roaming User Profile), hast du dein Profil nicht mehr am Rechner, sondern am Server, und wird jedes mal kopiert. Das Profil wird zwar lokal nicht gelöscht, aber ich weiss nicht ob offline geladen werden kann... vermute ja... Aber wie gesagt, muss hier noch einiges nachlesen, vielleicht schreibe ich eh ein Blödsinn :) Highlander-Prinzip ;-) Genau, soweit war ich auch schon :-) Aber das ganze ist mir jetzt wesentlich klarer. Die Server sind bereits in der Domäne. Nun muss ich herausfinden wie ich die Kontoeinstellungen und Profil vom lokalen Konto in das Domänenprofil übertrage. Das habe ich bereits schon mal gefragt, es ist alles andere ausser einfach. Dass die Admins dürfen, OK, aber das was du für die Benutzer geschrieben hast, habe ich glaube ich ja genauso gemacht. Den "Nutzer01", das ist das Konto, habe ich als Mitglied der Gruppe Remotedesktopbenutzer gemacht. Trotzdem wollte er ohne Eintrag im System nicht per RDP verbinden. Habe noch extra gegen Admin Konto geprüft, mit dem kommt man hinein. Welches Buch hast du denn? Ich hab das Server 2012 by Sams.

Dann aus meiner Sicht, habe ich die Grundlagen. Was eine Domäne und wie fuktioniert...verstanden. Konto vs. Profil lediglich wörtlich verwechselt. Ich weiss was der Unterschied ist. Gruppenrichtlinien - ich weiss was sie tun, wie sie wirken, nun habe mich nicht tief damit auseinander gesetzt, da es einfach so viel ist. Ich werde mir allerdings mehr Mühe machen Konto und Profil zu unterscheiden. Ich erkenne schon dass ich es immer wieder verwechsle. Die Frage zu Remote ist doch berechtigt, oder sieht ihr das nicht so?

Jeder war mal an Anfang, und zwar mit jeden Thema. Der Forum ist eigentlich der letzte Ort wo ich hingehe. Oft passiert es aber auch, dass ich nicht weiter weiss, dann schreibe ich, und in der Zwischenzeit komme ich selber zur Lösung, nachdem ich entweder gelesen oder was ausprobiert habe.

Interessant ist wie jeder bestimmt was "Grundlagen" sind. Aber keine Sorgen: I got the message.

Hmmm, nicht wie ich es (aus dem Buch, und vom "Eli") verstanden habe. Wenn man sich bei der Domäne anmeldet, ist zwar das Konto in der Domäne, die Dateien (Profil) liegen aber noch immer lokal. Aus der Domäne wird lediglich der Key bezogen (glaube so heisst es), im Prinzip nichts anderes als Berechtigungen. Also das Konto ist zwar weg, aber der Profil bleibt lokal. Die Gruppenrichtlinien kommen eben aus der Domäne durch das Konto. Oder habe ich hier was verwechselt? (ist sicher möglich) Zusätzlich kann man sich mit dem Benutzer auch ohne Netzwerkanschluss anmelden, dann bleiben einfach die Berechtigung vom letzten Bezug. So hätte ich es verstanden. Habe vorher noch im Laufe des Nachmittags das ausprobiert und du hast natürlich recht. Es sind lokale Nutzer am TS gar nicht notwendig, sondern es reicht wenn ich die Nutzer im AD anlege, und am TS lediglich unter Remote -> Benutzer auswählen das Erlaubnis für diesen Nutzer hinterlege. Ich frage mich allerdings, ob man diese Eintragungen am TS (Systemeigenschaften -> Remote -> Benutzer auswählen) vermeiden kann? Ich habe ohne den Eintrag versucht, allerdings im AD für den Nutzer als Mitglied von Remotedesktopdienste eingetragen. Leider so klappt es nicht. Was verpasse ich denn?

Okay, super. Das hilft. Und ja, bin gerade dabei diese Sachen zum lernen, genauso wie bei den anderen Themen :) Nun wie immer das so ist, lange mit der Einrichtung kann ich nicht warten, und ein simples Setup am Anfang wird reichen, um einige weitere Installationen durchführen zu können. Ich kann zB. sagen, nachdem ich vorige Woche erfolgreich VLAN eingerichtet habe, jetzt habe ich den WinSrv2008R2 DC mit DNS und DHCP der ordentlich funktioniert, und die VMs die den DNS sehen und via nslookup ordentlich Forward und Reverse Lookup Zonen eintragen :)

Ja, sind alles berechtigte Fragen. Wie schon oben erwähnt, die Domäne bzw. zentrale Nutzerverwaltung brauche ich eigentlich nur für die 10 Nutzer. Wir haben daneben aber noch andere 20 Mitarbeiter und einige VMs. Wenn ich schon eine Domäne aufziehe, werde ich dann wohl alle zur Domäne hinzufügen. TS bekommt lokale Konten, damit sich die Nutzer per RDP einloggen können. Wenn ich das richtig verstehe, diese sind nicht Domänennutzer, sondern lokal für den TS. Jeder hat seinen Desktop etc. Die Rechner selber (das sind die oben erwähnten 10 Rechner) sind aber schon in der Domäne, damit ich die Rechte zentral verwalten kann. Weil das, was ich wie oben beschrieben will, kann ich nicht über Arbeitsgruppe lösen. Die Rechner müssen fix in einer Domäne sein, und damit zentral verwaltet werden. Aus der Domäne kommt man auch nicht ohne dem Admin-Passwort. Verstehe die Frage nicht. Die Gruppenrichtlinien, wenn ich welche setzen will, wirken sich dann auf diesen Nutzer aus, egal wo der ist. Das war meinerseits ein Denkfehler. Ich will eigentlich einen Domänenadmin, und wenn man sich einloggt, wird dieser sowieso lokal gecached. Man erstellt eh keinen User lokal. Lokale Administrator Konto existiert weiterhin, hat aber mit der Domäne nichts zu tun.

Eh klar, dafür will ich es auch haben - spezifisch eigentlich nur für 10 Rechner, die ich nicht einzeln konfigurieren will. Nun, zu den Servern: d.H. ich kann mir wohl ein einziges Konto im AD erstellen, den ich dann für alle Server nutze? Ein Konto mit vollen Admin Rechten und mit gewissen Einstellungen, die dann vom Server zum Server übernommen werden? Sagen wir es wird srvadmin heissen, dann gebe ich diesen User bestimmte Einstellungen und die Sache hat sich. Muss natürlich den Nutzer auch am jeden Server (lokal) erstellen?

Hallo Martin, Danke für die rasche Antwort. 1) ich weiss "wie" man die Arbeitsstation zur Domäne hinzufügt. Meine Frage war bloss, ob man das Administrator Konto dafür üblicherweise nutzt, oder erstellt man sich ein anderes? Es ist mehr oder weniger eine Sicherheitsfrage. Ich sehe kein Nachteil darin dass ich das Administrator Konto nutze, nun frage ich mich ob sinnvoll und notwendig ist, ein anderes Konto, wie zB. "Admin" zu erstellen, und diesen dann die Berechtigung geben, die Nutzer der Domäne hinzufügen. 2) Die Frage ist, ob Sinn macht, die Server der Domäne hinzufügen, wenn man eigentlich nur das lokale Administrator Konto nutzt? Grundsätzlich ist es bei einem Server so, dass man meistens nur das Administrator Konto nutzt, und dieser dann als Fileserver, SQL-Server oder was auch immer sonst dient. Hier gehe ich noch nicht in das Thema Terminalserver, da dieser auch in unseren Netzwerk existiert, und da sind die Sachen anders, da dieser natürlich Nutzer enthält. Die Grundfrage unter 2 ist: was bringt eine Domänenteilnahme einen Server, wenn man nur das lokale Konto nutzt?

Hallo, Während ich AD lerne und verstehe, würde ich nun gerne wissen ob ich paar Dinge richtig verstanden habe. Um ein Rechner in die Domäne anzumelden, bracht man ein Login/PWD von einem Konto am DC der dazu berechtigt ist. Unter anderem auch der Administrator Konto. Nutzt man idR dieses Konto dafür? Sofern man nur alleine als Sysadmin arbeitet, sehe ich keine Nachteile. Weiterhin, wenn man dieses Login für die Anmeldung verwendet, heißt noch lang nicht, dass man für diesen Rechner je ein Konto auf dem DC erstellen bzw. nutzen wird. Bei einem anderen Server, wie FS, SQL-SRV, wird die IP vermutlich fix vergeben und zum einloggen üblicherweise Administrator Konto verwendet (der lokale Administrator Konto). Korrekt? Sind vermutlich eher simple Fragen. Danke :) Kosta