none
Ist hierfür eine eigene Domain mit Memberserver nötig? RRS feed

  • Frage

  • Hallo. Nach Jahren der Nutzung eines SAMBA-Servers, soll jetzt ein bisher eigenstänges Netzwerk in ein AD integriert werden. Da tauchen natürlich in der Planungsphase schon etliche Fragen auf. Die bisherige Struktur des Ad ist eher schlicht. Es wurden OUs für diverse Bereiche gebildet um Nutzer und Computer stukturell zu trennen. Soweit nachvollziehbar. Allerdings wurde bisher darauf verzichtet, den Nutzern eigene Nutzerprofile zu erlauben. Das war aber in der SAMBA-Umgebung zwingend nötig, da diverse Anwendungssoftware einige Anpassungen nätig machte. Das will ich natürlich nicht aufgeben. Jetzt komme ich langsam zum Punkt. Meine Vorstellung war bisher, einen weiteren DC als Memberserver mit ins AD zu hängen, um eben auf gemeinsam genutze Nutzerdatenbank und Druckerrecourcen des AD zuzugreifen aber eben auch eingenständige Anpassungen wie Nutzervorlagen im NETLOGON zu erhalten. Die kann man, so meine ich, ja schlecht im Basis-DC ablegen, weil die ja dann auch für die Bereich gelten würden, die das nicht nutzen wollen/sollen. Die Admins des DC meinten, das "müsste auch über OUs möglich sein". Ich habe da Zweifel ... Wie gesagt, bisher nur SAMBA-Erfahrung und mal testweise eine DC-Umgebung aufgebaut die auch recht gut funktioniert. Jetzt soll es aber "Ernst" werden und ich will nicht schon den Anfang "versauen".
    Donnerstag, 6. Juni 2013 08:42

Antworten

Alle Antworten

  • Wie lautet Deine konkrete Frage?

    Vorab lies Dich bitte in die Begrifflichkeiten ein, da Du aktuell diese durcheinander wirfst und uns so mehr verwirrst denn Klarheit über Deine Frage gibst.

    Active Directory
    http://technet.microsoft.com/en-us/library/bb742424.aspx

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Donnerstag, 6. Juni 2013 08:51
  • Nach meinem bisherigen Verständnis (SAMBA, bzw. NT-Domaincontroller) sind Clients und User einer Domain zugeordnet. Da NETLOGON eine Systemfreigabe des DC ist, gehe ich davon aus, dass das bei einem AD nicht anders ist, sprich die Clients und User können (und sollen auch) zwar einer OU zugeordnet werden, der DC an sich bleibt aber für die gesamte AD-Struktur zuständig und damit auch \\NETLOGON, das wiederum Nutzervorlagen enthalten KANN.  Da, wie beschrieben,  die schon vorhandenen OUs keine servergestützen Nutzerprofile wollen, ich aber schon, ergibt sich da Konflikpotenzial. Meine Idee wäre nun einen Memberserver mit eigenem DC ins AD zu integrieren, um dem Problem aus dem Weg zu gehen. Oder kann man das anders lösen? Ich gebe zu, dass ich und ein Kollege hier einen ziemlichen Blindflug hinlegen, weil einfach Erfahrungen mit AD-Severn fehlen. Aber die Aufgabe von SAMBA ist beschlossen und das ganze soll im September laufen.

    Verwendet werden soll Server 2008 R2, Clients Windows 7.

    Donnerstag, 6. Juni 2013 09:57
  • Dieses gibt es nicht: "einen Memberserver mit eigenem DC ins AD zu integrieren"

    Entweder Member Server oder Domain Controller.

    Deswegen: Beschreibe Deine Frage neu.

    Des Weiteren definiere: "Nutzervorlagen" im Zusammenhang mit NETLOGON

    Und zum Schluss: Was willst Du eigentlich erreichen, dass ist mir (und bestimmt vielen anderen hier) immer noch nicht klar. Und bitte beschreibe nicht WIE Du es lösen willst, sondern WAS Du erreichen willst.

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Donnerstag, 6. Juni 2013 12:04
  • Gut. Da es den DC schon gibt, bleibt es bei diesem. Dann also das Nutzerprofil. Zumindest bis jetzt liegt, für die sich anmeldenden Nutzer, in der Freigabe \\NETLOGON ein Ordner "Default User.v2" mit diversen Unterordnern und Dateien die einem, sich beim ersten Mal anmeldenden User, die entsperechenden Einstellungen verpassen. Das sehe ich als Nutzervorlagen an. Einiges lässt sich über Gruppenrichtlinien regeln, einiges eben nicht (MS-fremde Software). Da, wie erneut angemerkt, die bereits vorhandenen OUs keine servergespeicherten Nutzerprofile verwenden wollen, führt das meines Erachtens zu einem Konflikt. Erreichen will ich eben möglichst geringen, nachgeordneten, administrativen Aufwand. Natürlich könnte man bei jedem Client die "Default User"-Einstellungen anlegen und dann vermutlich mindestens zwei mal im Jahr bei allen einzeln ändern. Das will ich aber zentral regeln. Und da kommt eben NETLOGON ins Spiel. Wenn es dafür andere Lösungen gibt, z.B. \\NETLOGON für jede OU frei zu definieren geht, bitte gern. Wie schon beschrieben, kommen mein Kollege und ich aus der Linux/SAMBA Ecke und mein Nick ist ja auch ein Hinweis. Von AD "haben wir mal was gehört" bzw. ich hab mir vor einem halben Jahr mal eine auch funktionierende Testumgebung mit Windows 2008 Server gebaut. Da habe ich schon einiges erreicht, ist aber auch Makulatur, weil die Struktur die jetzt schon da ist, eben mitbenutzt werden soll. Da wird es für unseren Bereich eine eigene OU geben, in der der wir uns dann auslassen können. Ein durchaus nötiger Weiterbildungskurs wurde im letzten Jahr beantragt aber da tut sich nichts.

    • Bearbeitet irixfan Donnerstag, 6. Juni 2013 13:53
    Donnerstag, 6. Juni 2013 12:57
  • Ah, ok, Du meinst ein "network default user profile" wie u.a. hier beschrieben: http://support.microsoft.com/kb/973289/en-us

    Ok. Nur das versteh ich noch nicht:

    "vorhandenen OUs keine servergespeicherten Nutzerprofile verwenden"

    Servergespeicherte Profile ("Roaming Profiles") werden pro Benutzer und nicht an OUs gebunden.

    Das local/network "default user profile" wird nur beim ersten Anmelden des Benutzers, wenn noch kein Profil vorhanden ist als Blaupause verwendet.

    Sämtliche weiteren Anpassungen müssen dann mit anderen Technologien wie Group Policies (ggf. mit eigenen ADM Templates - s. z.B. http://www.gruppenrichtlinien.de/artikel/oreilly-uebersetzung-adm-templates-erstellen/), Hypried Profiles (z.B. via Appsense Environment Manager) oder Logon-Scripting gepflegt werden.

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Donnerstag, 6. Juni 2013 16:39
  • Soweit ich das einschätze, reicht dem anderen Bereich/OU der Standardameldeprozess und es werden keine severgespeicherten Profile angelegt (obwohl die an meiner Lösung Interesse bekundet haben) bzw. nur temporäre. Nach Abmeldung oder Neustart ist alles weg (HDD-Schutz). Sowas will ich nicht und werde da mit Sicherheit auf Kollisionskurs mit den Kollegen gehen.

    Ein funktionierendes System zu verlassen bringt immer Stress. Allerdings  häufen sich nach dem Umstieg von XP auf W7 bei den Clients die "merkwürdigen Netzwerkabbrüche" drastisch. Mit dem Testsystem war alles IO. Daher liegt der Verdacht nahe, dass SAMBA da Mist baut. Und SAMBA 4 traue ich nicht über den Weg und das gemeinsame AD für alle ist "von oben" beschlossen, also bin ich dran ...

    Zurück zum Thema. Mir sind die Möglichkeiten und Grenzen einer OU natürlich noch nicht klar, daher auch meine möglicherweise nicht klar gestellte Frage dazu. Mit meinem Testsystem habe ich das ganze durchgespielt mit Gruppenrichtlinien, Systemordner umleiten und Default User Profilen im \\NETLOGON. Das hat funktioniert und deshalb komme ich auch darauf zurück. Nächste Woche gibt es ein Meeting mit Vorbesprechungen dazu und ich würde gern vorher wissen was geht und was nicht. Ich habe auf meinem Schreibtisch die "2008 R2 Bibel" liegen, doch das Thema bleibt trotz 1728 Seiten im Dunkeln.

    Donnerstag, 6. Juni 2013 17:43
  • Lies mal folgende Guide:

    Managing Roaming User Data Deployment Guide
    Managing Group Policy ADMX Files Step by Step Guide

    Download: http://www.microsoft.com/en-us/download/details.aspx?id=23947

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Donnerstag, 6. Juni 2013 18:26
  • Mein Problem wird da auch nicht umrissen. Was dort beschrieben wird, war mir nicht unbekannt, einiges davon habe ich auch so gemacht. Letztlich reicht bei servergestützten Profilen das Hin-und-herkopieren von Roaming völlig aus. Das reduziert den Traffice erheblich. Das ist ja auch nicht mein Problem.

    Ich hab gerade nochmal mit den Kollegen gesprochen. Die setzen über Richtlinien Variablen für die raumweise Nutzung von unterschiedlichen Profilpfaden. Auch eine Variante ... Zumindest wird dort nicht der Systemstandardpfad \\<Server>\netlogon\Default User.v2\ dafür benutzt. Insofern waren meine Überlegungen, mit der Verwendung des Standardpfades "Unruhe" zu verursachen, nicht verkehrt.

    Freitag, 7. Juni 2013 06:36
  • Nach einigen Tagen des Studiums diverser Threads zur Roaming Profile Problematik, bin ich der Lösung nicht näher gekommen. Allerdings definitiv der Erkenntnis, dass ich den Systemstandardpfad \\<Server>\netlogon\Default User.v2\ für die Voreinstellung der Profile nicht nutzen kann, ohne den anderen Beteiligten den Tag zu versauen. Die Nutzung von GPOs gibt die von mir gewünschte Funktionalität leider nicht her oder ist mir zu "fummelig" und "mandatory profiles" will ich den Nutzern nicht antun. Also weitersuchen ...
    Montag, 10. Juni 2013 18:07
  • Sollte dir das Standard-Verhalten nicht ausreichen, schau Dir, wie schon erwähnt 3rd-Party Lösungen (Stichwort: Hybrid-Profile - s.a. http://www.tricerat.com/blog/270) wie z.B. Appsense Environment Manager.

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Dienstag, 11. Juni 2013 07:55
  • Auf Drittanbieter auszuweichen wird nicht möglich sein, da dafür keine Mittel vorgesehen sind. Es ist nur schade, dass die Flexiblität einer AD-Umgebung in einem so wichtigen Punkt nicht gegeben ist. Eine Stelle für ein Default User profil für alle wenn die OUs doch relativ frei definiert werden können ist etwas unverständlich. Da bleibt wohl doch nur das "Default User" an den Clients zu modifizieren.
    Dienstag, 11. Juni 2013 08:17