kosta88

Danke für die Hilfe.

Ob sinnvoll oder nicht, wieviel und wie weit ist immer eine Ansichtssache. All die Gründe sind eigentlich vollkommen egal. Wenn ich mich nicht auskenne, frage ich ja.

Soweit weiß ich ja, dass ich RSAT installieren kann und damit die Server-Verwaltung direkt vom Client zu machen, aber was bringt mir das? Die lokalen GPOs werden damit ja nicht in den zentralen Store der Domäne übernommen, und die Clients beziehen doch die GPOs nicht vom Win10 Client.

Öhm, wie soll ich das in einer Domäne machen? Sorry, ich stehe komplett auf der Leitung.

Wie meinst du das?

Ja, schon, hier ist es eben PolicyDefinitions\de-DE (ursprünglich auch in dem Ordner, auf der Win10 Kiste).

Ahhhhhhhhh.... das hatte ich mißverstanden. Ja, jetzt ist OK. Besten Dank.

Nächste Unklarheit:

DataCollection.admx

Wird von Win10 kopiert, existiert auf 2012r2 nicht, kopiert in zentralen Store, und erscheint in Gruppenrichtlinienverwaltungs-Editor nicht.

Idee, bzw. Grund?

Ah ja, die Faulheit überwiegt... tut mir leid. Habe schon gefunden.

Ich will eh die aus 1607 nehmen, also nehme ich von dort die admx+adml.

EDIT:

Und weil du gesagt hast keine komischen Zeichen:

Hallo,

ich kämpfe ein wenig mit den Policy Definitions für Win10.

Wir müssen intern auf 1607 bleiben.

Ich möchte hierfür Serverseitig "Updates zurückstellen" aktivieren.

Jedoch geht das nicht ohne entsprechender ADMX.

So habe ich versucht mit 1607 - hier kommen immer wieder sehr komische Zeichen in der Beschreibung - ist wohl bekannt.

Empfehlung ist auf 1703 zu gehen - so habe ich das auch versucht - hier ist dann was ganz seltsam, die Einstellung für den Windows-Zeitgeber ist auch ganz anders, fehlen Einstellungen, gar nicht vergleichbar mit der Anleitung die ich auf gruppenrichtlinien.de verfolgt habe.

Ist es OK einfach einzelne ADMX zu nehmen? zB. nur WindowsUpdate.admx?

Danke!! Die Sache ist jetzt klar und ja, es war auch notwendig, da unsere Leute im RZ eingegriffen haben und dort eigenen NTP-Server eingerichtet.

Das habe ich nicht gewusst bzw. zuerst gesehen, erst als ich gemerkt habe dass ich 1-2 Minuten Differenz habe.

Na dann ist gut.

Für 2 DCs ist die Quelle PDC-DC (3 DCs insgesamt).

Für alle anderen Domain-Mitglieder scheinbar nach Wahl...

Norbert, es sind auch zwei GPOs, wie in deiner Anleitung, aber die zuerst geschrieben Konfiguration (die de auch gequotet hast) war ein Fehler - dieser wurde korrigiert. Eine GPO (Schritt 1) ist auf DC-OU verlinkt und eine GPO (Schritt 2) auf die Domain-Ebene verlinkt.

Ich verstehe aber trotzdem nicht, warum manche Server auf 2. DC greifen, dieser ist natürlich kein PDC. Soweit ich das verstehe, alle Rechner, inkl. andere DCs, müssten auf den PDC-DC greifen, oder!?

Die kann man einfach ignorieren. Zumindest wenn es die Fehlermeldung ist, die ich kenne. Aber da du ja nichts dazu schreibst, mußt du eben damit leben.

 

 

Nö, oder hab ich irgendwo geschrieben, dass man zwei GPOs auf die Domain Controllers OU verlinken soll?

 

Bye

Norbert

Sind auch nicht zwei GPOs in DC-OU verlinkt!

Eine GPO ist in DC und eine auf der Domain-Ebene - wie beschrieben.

Ich wiederhole mich mal wieder: in einem AD muss man an der  Stelle nichts konfigurieren. Nur der DC mit dem PDC-Emulator muss mit einer externen Zeitquelle synchronisiert werden.

Da muss man man nur 1x "w32tm /config /manualpeerlist:timeserver /syncfromflags:manual /reliable:yes /update"  eingeben.

 

Alle  anderen Geräte, auch die anderen DCs, holen sich die Zeit nunmehr  per AD-Gedöns (NT5DS).

 

Siehe auch https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-configuration-in-active-directory/

Das verstehe ich jetzt nicht - ein Befehl ist angeblich das gleiche wie eine GPO, wenn auf PDC ausgeführt.

GPO auf dem PDC greift ja auch, hier steht als Server pool.ntp.org. Nirgendwo sonst.

Ansonsten ist eine GPO auf der Domain-Ebene, die besagt NT5DS, wie in der Anleitung beschrieben.

EDIT:

Ich habe jetzt auf allen Server hintereinander den /unregister /register und Dienst-neustart gemacht, gefolgt von gpupdate und Server Neustart.

Jetzt haben alle entweder ersten oder den zweiten DC eingetragen: ist das korrekt?? Oder müssten ALLE mit 1.DC antworten?

Vorweg: ich habe das HowTo von gruppenrichtlinien.de abarbeitet und das hat nicht funktioniert - die WMI-Filterung hat nicht funktioniert, da ich da eine Fehlermeldung vonwegen Namespace bekomme (und habe hier nach einiger Recherche es nicht zum laufen bringen können), und wenn ich dann abfrage ob die Gruppenrichtlinie auf anderen DCs in der OU greift (via gpresult), sehe ich sie auf den anderen DCs als aktiv. Deswegen die Filterung - sie greift.

Außerdem: es steht sogar am Ende des Dokuments dass man das via Sicherheitsfilterung machen kann, jedoch bietet die WMI-Filterung gewisse Automatik, also sehe ich hier nichts falsches. Auch kein "Gebastel".

Also grundsätzlich habe ich wie geschrieben gemacht, dann geprüft, hat nicht funktioniert.

Ich habe ja auch dann andere Versuche gemacht, wie auf anderen Seiten empfohlen, bspw:

https://serverfault.com/questions/584397/active-directory-time-synchronisation-time-service-event-id-50/584420#584420

Aber weitere Recherche bringt mich auf folgendes (und ja ich habe auch auf die Empfehlung von gruppenrichtlinien.de zurückgestellt):

Nachdem die 2. GPO auf alle Domain-Mitglieder verteilt wird, kann es denn sein, dass sich jeder Server die Sache irgendwie DNS-bezogen bezieht? Bspw. merke ich das ja zwar öfters PDC gewählt wird, aber dann auch der 2. DC, auch wenn primärer DNS der 1. DC (PDC) eingetragen ist.

Was ich nicht verstehe welche "Parameter" notwendig sind, bzw. wonach richtet sich das W32Time Dienst, wenn ein Zeitserver gesucht wird, und warum landet W23TM dann auf dem 2. DC, wenn der einzige Server der die GPO trägt der 1. DC ist (beim 2.DC steht noch ausdrücklich nicht angewandt).

Moin,

lefg:

Es geht nicht so um was nicht funktioniert, da ich das nicht so leicht überprüfen kann (ist die Zeit wirklich synchron?), sondern eher um die Korrektheit des "w32tm /query /status" -> da mein Verständnis ist, dass hier immer ein DC angezeigt werden soll, sofern die GPO auf alle DCs ausgerollt wird. Ich werde noch testen damit, die NTP-Server-Funktion in GPO auf einen DC zu begrenzen.

Nils:

Alle 5 Rollen sind bereits auf dem einen Hauptserver, der auch NTP-Server werden sollte. Scheint korrekt zu sein.

Nachdem ich gestern mehrfach darüber gelesen habe, habe ich es jetzt mit einer einfachen Konfiguration versucht. Und zwar:

Es sind 3 DCs.

Auf einem der die Rollen inkl. PDC hat, habe ich eine GPO mit Filterung (wohlgemerkt nicht WMI, da ich nicht weiß ob verlässlich greift) auf den DC, und Einstellungen NtpServer pool.ntp.org, Type NTP. GPO auf die OU Domain Controllers gebunden.

Eine weitere GPO auf die DC-OU gebunden, Windows-NTP-Server aktivieren Aktiviert. Filterung auf alle 3 DCs.

Jetzt werde ich die Filterung bei der 2. GPO auf nur einen DC, und zwar den PDC-Träger filtern, und versuchen via /unregister /register die Konfiguration zurückzusetzen.

Ziel ist: alle Rechner beziehen die Zeit von einen DC (oder mehrere). Aber kein Local CMOS Clock.

Aber ich würde gerne wissen ob ich am richtigen Weg bin?

Hallo,

gestern habe ich mich damit beschäftigt, eine ordnungsgemäße Zeitregelung in der Domäne zu gewährleisten.

Somit bin ich nach dieser Anleitung vorgegangen:

https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

Jedoch irgendwie funktioniert nicht wie das sein soll...

Mein Verständnis ist dass wenn man Befehl "w32tm /query /source" ausführt, DC mit dem PDC Emulator erscheinen müsste.

Das ist leider nicht der Fall, sondern der alte DC von dem die Rollen übertragen wurden.

Integrationsdienste bei HV sind deaktiviert.

Grundsätzlich wenn man dieses Befehl auf allen Servern ausführt, passiert folgendes:

PDC Emulator DC: pool.ntp.org

Andere 2 DCs: Local CMOS Clock

Andere Server: entweder korrekter DC oder der alte DC, von dem die Rollen ursprünglich übertragen wurden

Wie gehe ich am besten mit dem Troubleshooting voran?

Danke

OK, das macht Sinn. Aber Idee wie das ist mit den Gruppen, und warum es nur an den DCs erscheint?

Wäre für mich auch so logisch gewesen, Norbert. Aber gut, wenn es default ist, ist mir grundstzlich egal.

Nun, ich habe gerade auf einem Client ausprobiert:

Wenn mich als Benutzer einlogge, steht dort eben dieser Benutzername. Aber, wenn ich mich als domain\administrator anmelde, steht dort eben dieser Benutzer.

Und jetzt wird's noch verwirrender:

Ich habe einige Benutzer, inkl. mich (Domain-Benutzer, auch Mitglied der Dom-Admins) und den Domänen-Administrator (Hauptkonto) zur Gruppe der Remotedesktopbenutzer auf dem DC hinzugefügt.

Damit habe ich grundsätzlich mit beiden Logins RDP Zugriffe auf die Rechner, ABER in der Liste von oben aus dem Screenshot erscheinen diese Benutzer ausschließlich auf den DCs (allen 3), aber nicht auf einem anderen Server oder Client.

Ich bin jetzt mehr verwirrt als vorher...

Die Bezeichnung mag unglücklich sein, ändert aber nix daran, dass diese Gruppe nach einem DomJoin vorhanden ist  :p

 

@kosta88

Die lokalen Gruppen können via Gruppenrichtlinie den wünschen nach angepasst werden.

 

Lokale Gruppen und Benutzer über Gruppenrichtlinien verwalten

https://www.windowspro.de/wolfgang-sommergut/lokale-gruppen-benutzer-ueber-gruppenrichtlinien-verwalten

Das kenne ich, danke, habe ich auch bereits im Einsatz. Ich hinterfrage allerdings die Notwendigkeit danach... warum würde ich einen Benutzer der lokalen RDP-Gruppe hinzufügen? Eventuell nur um einen Benutzer auf einem Rechner RDP-Zugriff geben, oder?

Die Mitglieder der lokalen Administratoren Gruppe sind: Administrator und Domänen-Admins.

Ich bin ja der Mitglied der Domänen-Admin.

Sind die Domänen-Admin von Haus aus die Mitglieder dieser Gruppe?

Und nein, Hostname ist nicht gleich Domainname.

Hallo,

hab hier ein kleines Problemchen...

Siehe da:

Normalerweise steht hier "Administrator hat bereits Zugriff". (oder Domain\Administrator)

Jedoch steht auf dem einen Rechner:

domain\username hat bereits Zugriff.

Warum das, wovon hängt das ab, bzw. wie entsteht dieser Eintrag und wie kann ich das ändern?

Danke

Ist in Ordnung - die Ansicht ist zwar falsch (die Unternehmensstruktur ist unbekannt - und ist auch allgemein sehr schwierig, daher sind leider auch die Ansichten der Poster hier falsch).

Nach einigen Seiten kann ich nur sagen dass ich für die Hilfe sehr dankbar bin - und jetzt sind wir auch am Ende.

Ein Bonus der ganzen Sache ist dass ich mal wieder viel gelernt habe, und das ist mir persönlich sehr wichtig.

Du möchtest es aber nicht verstehen - die Software für die Automatisierung wird von der selben Programmierteam wie die Software (eh nur ein paar Hunderte Personen) geschrieben, und wird ausschließlich in deren RZ verwendet.

Ich schätze die Hilfe hier sehr, aber wir sind bei dem Thema komplett entgleist. Es geht nach wie vor um das Thema DC und nicht Admin-Rechte oder Automatisierung.

Ich wäre somit gerne ein Feedback zum Thema HV. Und zwar ob sich ein solcher Prozess an die Funktion des DCs auswirkt.

Lassen wir bitte das Thema Installation der internen Software - hier wird zu viel geraten und schlicht blind vorgeschlagen. Ich weiß dass unsere Software-Installation automatisiert werden kann, aber auf diese Tools habe ich keinen Zugriff - einfach so wie hier vorgeschlagen geht das nicht.

magheinz, ich kann hier wirklich schwer die interne Struktur und Zuständigkeiten beschreiben, und erklären warum was und wo installiert werden muss oder soll. Es ist notwendig dass gewisse Kollegen einen MS Surface haben, dann andere brauchen eher leistungsstarke Laptops und dann auch andere brauchen nur kleine i3-Clients. Und jeder dieser Kollegen braucht aus persönlichen Bedürfnissen ZU dem RDS Client eine lokale Installation derselben Software. Ein Linux-TC ist no-go, zwar geht halbwegs, aber lieber nicht.

###########

Mal eine andere Frage, auch DC bezogen:

Macht es was für einen DC aus wenn ich eine neue VM erstelle und die gleich VHD einbinde?

Process:

1) alte VM in Hyper-V umbenennen

2) neue VM mit dem gleichen Name erstellen

3) bestehende VHD einbinden

4) zuerst ohne Netzwerk-Verbindung starten, IP Adresse fixieren, gleich wie alt

5) ggf. MAC-Adresse abgleichen, ist glaube ich aber nicht nötig

6) neustarten im "echten" Netzwerk

Warum?

Weil ich Depp vergessen habe HV Ordner auf D:\ zu ändern, und meine C:\läuft langsam voll.

Ich möchte aber wenn möglich keine Live-Migration machen, sondern wirklich neu erstellen.

Danke

zu deinem Lokalen-Admin-Problem.

Nutze doch einfach eine Softwareverteilung wie z.B. opsi.

Bei uns können alle User ausgewählte Software selber installieren ohne das wir ihnen extra Rechte dafür geben müssen.

Ich kenne opsi nicht, jedoch weiß ich dass unsere Software eigene Installationsroutinen hat, und kann mir nicht vorstellen dass irgendeine Software das korrekt regeln kann.

Ob man für die Installation dem Benutzer nicht ein extra Konto dafür gibt?

Hm, wäre zu überlegen. Ist aus dem Sicherheitsaspekt ja wesentlich besser als Admin-Rechte lokal.

Man muss auch so sehen: lokal gibt es kein Outlook, und surfen wenn schon dann sehr wenig. Und das kann ich auch mittels Firewall leicht, auch Clientbezogen, sperren.

In der RDS Sitzung natürlich nicht, das steuert das RZ.

Lokal ist wenn, dann nur Office (W/E/P) installiert, Programme von Adobe für das Marketing, und unsere Software.

Aber ja, ich sehe wie ich das mit dem Installations-Admin machen könnte - konstruktiver Vorschlag, danke.

Ist das ein Fehler oder ist das eine Warnung? Ist denn die DFSR installiert/aktiviert auf einem oder allen DC/Servern? Wofür DFSR notwendig, für andere Server, die Fileserver?

Warnung, mit darauffolgenden OK, gleich in der nächsten Sekunde. DFS wird nicht genutzt, könnte genauso abdrehen.

Und es passiert nur zwischen einem lokalen DC und RZ-DC, nicht zwischen den lokalen DCs.

Weil derzeit unsere Struktur es nicht erlaubt, dass ich den Benutzern die Installationsmöglichkeit komplett wegnehme. Es ist nie gewährleistet dass jemand für die Installation von irgendetwas vor Ort ist, und ich bei einem Kundentermin bin, daher bekommen nur gewisse Benutzer (nicht alle wohl gemerkt) die Admin Rechte, und zwar die, wo es wahrscheinlich ist, dass irgendwas von unserer Software ein Mitarbeiter sich installieren muss. Es ist für unsere Software notwendig und empfohlen die Admin-Rechte für die Installation zu haben.

Diese Benutzer sind in der lokalen "Administratoren" Gruppe, nicht in der Domänen-Sicherheitsgruppe (wird verteilt mittels Restricted Groups in GPOs).

Was mir aber nutzen würde, wenn ich über GPO die Gruppenzugehörigkeit pro Rechner begrenzen könnte. Aber ich wüsste keinen Weg das relativ einfach zu machen. Wenn Ideen, bitte.

Übrigens, die Konfiguration von 3 DCs ist derzeit komplett stabil und ohne Fehler (außer das ominöse DFSR Fehler). Dafür waren eigentlich nur zwei Sachen notwendig: Registry-Eintrag PublishAdresses und DC in RZ primärer DNS auf den einen von zwei lokalen DCs. Und alles ist gut. Kurzfristig OK Lösung. Bin ziemlich sicher jeden Tag im System, ein kurzer Check der Replikation kostet ja nicht viel Zeit.

Bin nur noch wegen DHCP gespannt, wird interessant wie sich das als DHCP-Cluster verhält.