DocMF

@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

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

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.

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)

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

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

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 ;-)

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

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?

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

In Ordnung, vielen Dank! Wie kann ich den Beitrag schließen?

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!

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

Siehe Anhang, scheinen die gleichen Meldungen zu sein wie bei dcdiag.. replsummary.txt showrepl.txt

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.

Okay, ich habe gerade die 2. NIC deaktiviert. WINS ist keiner im Einsatz, der Computerbrowser Dienst läuft auf Win 2000 und Win 2003. FSMO Rollen sind alle auf dem Win 2003. Das AD funktioniert bis auf eine Fehlermeldung bezüglich Replication (dcdiag auf Win 2008 ausgeführt), siehe Anhang. Vielen Dank für die Antworten! dcdiag.txt

Hier ist der Win 7 Client, die 3 Server siehe Anhang: Win 7 Client: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : PC-MF2 Prim„res DNS-Suffix . . . . . . . : Fuerth.docware.de Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : Fuerth.docware.de Systemquarant„nestatus. . . . . . : Nicht eingeschr„nkt Ethernet-Adapter LAN-Verbindung 2: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9 Physikalische Adresse . . . . . . : 00-FF-1D-95-EA-85 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: fuerth.docware.de Beschreibung. . . . . . . . . . . : Broadcom NetLink Gigabit Ethernet Physikalische Adresse . . . . . . : A4-BA-DB-FD-D3-13 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::95d0:bbe:8ab:70a1%10(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 10.10.10.114(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.0.0 Lease erhalten. . . . . . . . . . : Montag, 18. Juni 2012 16:08:04 Lease l„uft ab. . . . . . . . . . : Montag, 23. Juli 2012 16:08:07 Standardgateway . . . . . . . . . : 10.10.10.1 DHCP-Server . . . . . . . . . . . : 10.10.10.12 DHCPv6-IAID . . . . . . . . . . . : 245676763 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-14-4D-C6-F6-A4-BA-DB-FD-D3-13 DNS-Server . . . . . . . . . . . : 10.10.10.12 10.10.10.14 NetBIOS ber TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.fuerth.docware.de: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: fuerth.docware.de Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{1D95EA85-33C9-4CC6-8322-ED2B2311E1E2}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja ipconfig_win2000.txt ipconfig_win2003.txt ipconfig_win2008.txt

Hallo zusammen, wir haben hier eine Windows Domäne mit 3 DCs (2K, 2K3, 2K8) und knapp 30 Windows 7-Clients. Vor kurzem wollten wir den 2K entfernen (auf diesem läuft nichts mehr Produktives, er ist einfach nur noch DC). Wir haben es erst mit "dcpromo" versucht, schlug aber mit der Meldung "Der Verzeichnisdienst konnte die lokale Änderung nicht replizieren" fehl. Daher haben wir ihn erstmal ausgeschaltet um herauszufinden, ob das irgendwelche negativen Auswirkungen hat (sprich ob es überhaupt nötig ist, ihn aus der Domäne zu entfernen). Nun erschienen bei den Clients unter "Netzwerk" aber plötzlich nur noch wenige PCs (vorher wurden alle im Netzwerk Verfügbaren angezeigt). Als wir den 2K-Server wieder eingeschaltet haben, wurden auch wieder alle PCs angezeigt. Kann uns hier jemand weiterhelfen? Wie kriegen wir den alten DC doch noch aus der Domäne? Vielen Dank im Voraus! Grüße DocMF