Jump to content

DocMF

Members
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

10 Neutral

About DocMF

  • Rank
    Newbie
  1. @Norbert: in der Theorie ist das schön, in der Praxis aber weniger (vielleicht stehe ich aber grad wirklich auf dem Schlauch): Zu 1.: so ist ja die Ausgangssituation: jeder darf sich überall anmelden, d.h. ich muss an irgendeiner Stelle entweder erstmal Berechtigungen entfernen oder Einschränkungen setzen. Berechtigungen entfernen würde bedeuten, ich bearbeite die Benutzergruppe auf den jeweiligen PCs (was ich aber als riskant empfände, da ich mir gut vorstellen kann, dass das Nebenwirkungen hat). Umständlich wäre es aber so oder so. Was das Einschränkungen setzen angeht wären wir dann bei Punkt 2. Zu 2.: Verweigern ist relativ umständlich, denn wenn ich auf einem PC nur einen User erlauben will, muss ich alle anderen verweigern, d.h. ich müsste für jeden PC, für den ich die Anmeldungen beschränken will, eine extra Gruppe führen, in der jeweils sämtliche User enthalten sind, bis auf den der sich anmelden darf. Und das dann noch für mehrere Clients zu machen... MS hätte z.b. bei den Computerobjekten eine Einstellung implementieren könne, in der man Domänen-User eintragen kann, die sich auf dem Client einloggen dürfen. Das würde mein Problem einfach (zumindest einfacher als die restlichen Optionen) und vor allem übersichtlich lösen. @Sunny61: wenn ich deinen Vorschlag richtig verstehe, müsste ich dann aber trotzdem für jeden Client eine GPO anlegen oder? Das muss ich mal durchspielen, danke
  2. Moment, ich habe Computer- und Benutzerebene verwechselt, die OU-Struktur der Computer ist deutlich weniger unterteilt als die User-OUs (und damit für die Verwendung per GPO so erstmal nicht geeignet). Dann werde ich mir hier etwas überlegen müssen, trotzdem vielen Dank für Eure Hilfe/Infos! Doch nochmal ich: wenn man es per GPO macht, müsste man es folgendermaßen machen, um zu erreichen, dass sich nur ein bestimmter User einloggen kann: unter "Lokal anmelden verweigern" müsste man ALLE anderen Domain-User eintragen (diese Liste müsste man dann natürlich bei neuen Usern pflegen etc.) außer dem User, der sich anmelden soll. Das wäre ja ein irrer Aufwand (oder sehe ich etwas falsch?). Microsoft muss sich doch für den Fall "Mitarbeiter sollen sich nicht an Rechnern von Chefs einloggen können" mal irgendetwas überlegt haben
  3. Hallo, Warum ich das so einschränken will? Primär sollen sich natürlich Mitarbeiter nicht an PCs einloggen können, die "nichts für sie sind" (z.B. Vorgesetzte etc.). Ich bin gerade am Überlegen, ob ich als ersten Step erstmal nicht jeden Mitarbeiter nur auf seinen eigenen PC lasse, sondern erstmal die PCs der Vorgesetzten einschränke, das könnte ich mir unserer OU-Struktur wahrscheinlich auch hinbekommen, ohne übermäßig großen Aufwand.
  4. Ok, danke. Diese Variante wäre für mich insofern aber umständlich, da ich (bis auf wenige Ausnahmen) jedem User nur Berechtigungen zum Anmelden auf seinen PC geben will. Und dann würde ich für jeden PC eine eigene Gruppenrichtlinie benötigen (wenn ich jetzt nicht auf dem Schlauch stehe)
  5. Vielen Dank für die schnelle Antwort. Ok, d.h. aber einen ganz anderen Weg (den ich gar nicht auf dem Schirm hatte) gibt es nicht, oder? In dem Fall würde ich dann die Domain-User-Gruppe auf den Clients rausschmeißen und durch eine geeignete Gruppe oder User ersetzen
  6. Hallo, standardgemäß wird ja bei jedem Domain-Client die Gruppe "Domänen-Benutzer" zur lokalen Benutzer-Gruppe hinzugefügt, d.h. jeder User kann sich auf jedem Domain-Client einloggen. Das möchte ich nun verhindern. In den Eigenschaften eines AD-Users gibt es ja die Option "Anmelden an...", die ich aber aus zwei Gründen nicht nutzen möchte: - Aufwand, das bei jedem User händisch einzutragen - die Option müsste eigentlich "Anmelden von..." heißen, denn hier muss man die Hostnames eintragen VON denen man sich einloggen will (was Probleme macht, wenn die Mitarbeiter über VPN arbeiten) Daher meine Frage: welche Möglichkeiten habe ich noch? Müsste ich die Gruppe "Domain-Benutzer" aus der lokalen Benutzer-Gruppe der Clients entfernen und nur den Domain-User eintragen (geht das oder hat das unerwünschte Nebenwirkungen?) oder gibt es einen komfortableren Weg? Danke schon mal im Voraus! Grüße DocMF
  7. Mir war nicht bewusst, dass es auch derlei Vorlagen für andere Programme gibt :-o Danke für den Tipp, werde ich mir mal anschauen ;-)
  8. Ok, ich hatte eh nur die von Windows drin (direkt bei MS heruntergeladen), d.h. die Win10-Files sollten mir ausreichen. Vielen Dank für Deine Hilfe! Grüße
  9. Ja, das sollten wir mal umstellen (2003er haben wir nicht mehr). Geht ja auch noch wenn man keinen 2008er mehr hat oder (wir haben 2 x 2012 und 1 x 2012R2)? Genau, um diese "zusätzlichen" ADMX-Files geht es, also ob man die braucht oder nicht. D.h. im Idealfall kopiere ich die Win7-ADMX-Files rein, kopiere zusätzlich die Win8.1- und im Anschluss die Win10-Files rein?
  10. Hallo, wir benutzen für unsere Gruppenrichtlinien einen Central Store. Nun will ich die aktuellen Windows 10-Templates/-ADMX-Files in den Central Store kopieren. Wenn ich die neuen Files zu den bereits vorhandenen Dateien in das Verzeichnis kopiere (und bei Konflikten überschreiben lasse), meldet mir der DC im EventLog eine NtFrs-Warnung (ID: 13567, "...Updates, die die Inhalte der Dateien nicht ändern, werden unterdrückt, um unnötige Replikationsaktivitäten zu verhindern. Folgende sind allgemeine Beispiele für Updates, die die Inhalte der Dateien nicht verändern..."). Wie die Meldung schon sagt, wurde der Central Store auch nicht korrekt auf die anderen DCs repliziert. Daher habe ich den Central Store komplett geleert (dies wurde korrekt repliziert) und dann die neuen Win10-Templates reinkopiert. Dann funktioniert auch die Replikation und der Central Store ist auf allen 3 DCs up-to-date. Nun bin ich mir aber nicht sicher, wie das bei den ADMX-Files ist, enthalten diese ALLE Einstellungen (also auch die vorheriger Windows-Versionen) oder nur die neuen Einstellungen? Sprich ist mein Vorgehen OK oder benötige ich noch andere, ältere ADMX-Files? Auf die Frage habe ich im Internet leider noch keine eindeutige Antwort gefunden, ich vermute zwar, dass alle Einstellungen enthalten sind, bin mir aber nicht sicher. Vielleicht kann mir hier jemand helfen. Vielen Dank im Voraus! MfG DocMF
  11. In Ordnung, vielen Dank! Wie kann ich den Beitrag schließen?
  12. Erstmal danke für Eure Antworten. Absehbare Zukunft bedeutet ca. halbes Jahr, soll dann auf einen Exchange 2013 migriert werden. Ok, dann werde ich mich doch mal mit dem Upgrade auf SP3 auseinandersetzen.. Danke!
  13. Hallo, wir haben folgendes Szenario: 1 x Server 2008 DC 2 x Server 2012 DCs Domain und Forest Functioning Level: Server 2008 1 x Exchange 2007 SP2 (08.02.0301.000) Nun müsste ich den 2008er DC demoten, sodass nur noch 2012er DCs existieren. Hat das Beeinträchtigungen für den Exchange-Server? Bei MS (http://technet.microsoft.com/library/ff728623%28v=exchg.150%29.aspx) ist immer nur die Rede von Exchange 2007 SP3. Da der Exchange in absehbarer Zukunft sowieso ersetzt wird, will ich auf diesem nicht mehr auf SP3 hoch bzw. größere Änderungen durchführen. Weiß hier jemand Bescheid und kann mir weiterhelfen? Das wäre super! Grüße DocMF
  14. Siehe Anhang, scheinen die gleichen Meldungen zu sein wie bei dcdiag.. replsummary.txt showrepl.txt
  15. Danke :) Ich kann nicht mit 100%er Sicherheit sagen, inwiefern die Replikation schon funktioniert hat, der Win 2000 Server war früher Backup DC und es gab da keine Probleme. Und wenn ich am Win 2008 oder 2003 einen Domänenbenutzer anlege oder lösche, erscheint der auch am Win 2000 bzw verschwindet dann dort auch wieder. Irgendetwas an der Replikation funktioniert also noch. Welche DNS-Einträge meinst Du? DNS-technisch hatten wir keine Probleme und mir sind auch keine falschen Einträge o.ä. aufgefallen.
×
×
  • Create New...