NilsK

Moin, der ganze Aufbau ist Schrott. Mach es richtig, wenn es klappen soll. Und weg, Nils

Moin, die Daten sagen mir jetzt nichts, weil ich eure Struktur nicht kenne. Wenn die Ausgabe (wie ich vermute) darauf hindeutet, dass die Zuordnung von Subnets und Sites nicht stimmt bzw. nicht sinnvoll ist, dann korrigiere dies. Je nach Komplexität der Umgebung erfordert das etwas Planung, ist technisch aber recht schnell gemacht. An den Prioritäten der DNS-Einträge macht man normalerweise nicht rum. Wenn das Site-Konzept passt, dann ist das nicht nötig. Gruß, Nils

Moin, soll der Neustart einmalig geschehen? Oder soll das was Regelmäßiges werden? Falls Letzteres: Warum? "Die automatischen Serverneustarts" richtet man schon lange nicht mehr ein. Wenn überhaupt, dann sehr selektiv, aber selbst dann ist das ein Notbehelf, der Probleme auf anderen Ebenen (eher schlecht als recht) umgeht. Gruß, Nils

Moin, Einstellungen, die sich mit dem vorhandenen ADMX-Satz nicht (mehr) anzeigen lassen, tauchen im GPMC-Report als "Zusätzliche Registry-Einstellungen" auf, oder? Gruß, Nils

Moin, nein, das ist nicht möglich. José verlässt sich auf die automatische DC-Auswahl durch den Client. Wenn da bei dir ein Entfernter genommen wird, dürfte eure Site-Zuordnung nicht korrekt sein. Wahrscheinlich handelt der dann auch die Anmeldung ab. Was geben denn folgende Kommandos auf deiner Workstation zurück? echo %logonserver% nltest /dsgetsite nltest /dsgetdc:YourDomainName.com nltest /sc_query:YourDomainName.com Was meinst du mit der "höchsten Priorität"? Ein solcher Mechanismus ist mir im AD nicht bekannt. Gruß, Nils

Moin, hm ... nimm es mir nicht übel, aber da zweifle ich. Wenn ein Betriebssystem per GPO eine Einstellung bekommt, die es nicht versteht (weil es die zu konfigurierende Komponente nicht hat), dann ignoriert es die Einstellung. Genau das meinte ich oben mit den heterogenen Clients: Du kannst z.B. Windows 7 und Windows 10 parallel betreiben und mit denselben Gruppenrichtlinien konfigurieren. Die Einstellungen, die Windows 7 nicht kennt, wendet es nicht an. Die Einstellungen für Windows 7, für die Windows 10 keine Komponenten mehr hat, wendet Windows 10 nicht an. Das ist durchaus korrekt, aber hier überhaupt nicht das Thema. Seit vielen Jahren steht bei "allen" (sprich: den meisten ...) Einstellungen dabei, auf welche Client-Versionen sie sich auswirken. Bei Windows 10 wird tatsächlich nach den einzelnen Releases unterschieden (1511, 1607 ...), nach Build-Nummern (zumindest bislang) nicht. Das werten die Clients selbst aus, siehe oben. Die Skepsis ist verständlich, aber funktionale Fehler stehen auf einem anderen Blatt und haben mit der Anwendungslogik von GPOs nichts zu tun. Gruß, Nils

Moin, bitte NIEMALS einen Hyper-V-Host mit irgendeiner anderen Rolle konfigurieren. Schon gar nicht mit einem DC. Wie du merkst, geht das ganz schnell schief. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Ein Host ist ein Host ist ein Host. Jede andere Rolle kommt in eine VM (bzw. in verschiedene VMs). Und bitte ebenfalls NIEMALS aufs Geratewohl an den Netzwerkverbindungen oder den vSwitches eines Hyper-V-Hosts rumbasteln. [Hyper-V und Netzwerke | faq-o-matic.net] http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ [What is the Hyper-V Virtual Switch and how does it work?] http://www.altaro.com/hyper-v/the-hyper-v-virtual-switch-explained-part-1/ Gruß, Nils

Moin, um das noch mal in Kürze aufzuklären: Die ADMX-Dateien haben mit der Anwendung und der Funktion der Gruppenrichtlinien nichts zu tun. Sie dienen nur der Verwaltung. Mit den ADMX-Dateien arbeitet ausschließlich der Administrator, der die Gruppenrichtlinien konfiguriert. Der Client, der die Gruppenrichtlinien anwendet, hat mit den ADMX-Dateien nichts zu tun. Anderenfalls könnte man in einem Netzwerk ja keine heterogenen Clients haben, wenn man mit Gruppenrichtlinien arbeitet. Tatsächlich kann es sein, dass der Administrator mit "neuen" ADMX-Dateien einzelne vorhandene Einstellungen nicht mehr korrekt sieht, die mit "älteren" ADMX-Dateien erzeugt wurden. Die Einstellungen selbst bleiben dann aber unverändert und wirken weiter. Hier hat Mark das gut beschrieben, das Prinzip stimmt immer noch: http://www.gruppenrichtlinien.de/artikel/wie-funktioniert-ein-adm-template/ Ein Detail hat sich (leider) verändert: Mittlerweile hat Microsoft tatsächlich vereinzelt Einträge aus neueren ADMX-Versionen entfernt. Wie oben dargelegt, wirkt sich das aber nicht auf die Wirksamkeit der Einstellungen aus, sondern nur auf deren Administration. Soweit ich es bei einem schnellen Blick gesehen habe, ist es (bislang) aber unwahrscheinlich, dass diese entfernten Einträge überhaupt genutzt worden waren. Gruß, Nils

Moin, äh - wie jetzt? Derselbe Server ist gleichzeitig Hyper-V-Host und DC? Dann wundere dich nicht über Fehlfunktionen. Das verstehe ich nicht. Wovon redest du hier? Du hast Recht, da habe ich mich geirrt. In dem Auswahlfenster taucht ein DC tatsächlich als Auswahl auf, er hat aber keine lokalen Konten. Die anderen Fehlermeldungen, die du angibst, deuten allerdings in der Tat auf DNS hin. Poste doch mal bitte die Ausgabe von ipconfig -all des Servers. Nur so zur Sicherheit: Neu gestartet hast du den Server schon? Gruß, Nils

Moin, der "SERVER-DELLPOWE" kann nicht DC sein, sonst würde in dem Screenshot der Servername nicht zur Auswahl von Anmeldekonten auftauchen (in dem Dialog, der direkt hinter der Kennwortabfrage steht). Ein DC hat keine lokalen Konten. Irgendwas stimmt hier also nicht. Entweder ist der Server nicht korrekt eingerichtet, oder du unterliegst einem oder mehreren Irrtümern. Gruß, Nils

Moin, kann es sein, dass der betreffende Server nicht Mitglied des AD ist? Gruß, Nils

Moin, technisch ist es völlig egal, ob und wie du mit Gruppen arbeitest. Das A-G-DL-P-Prinzip ist eine organisatorische Empfehlung, mehr nicht. Es gibt keinen technischen Zwang dazu und keinen technischen Vorteil dadurch. A-G-DL-P bewährt sich in größeren Umgebungen, weil es eine strukturierte Vergabe von Berechtigungen nach einem "Rollenkonzept" erleichtert. Außerdem führt es, wenn man es einigermaßen konsequent und durchdacht macht, zu einer besseren Dokumentierbarkeit der Berechtigungen. Es hat allerdings auch seine Nachteile, weil es gerade in solchen Umgebungen schnell Skalierungsprobleme aufwirft - es gibt dann schnell sehr viele Gruppen. Gruß, Nils

Moin, in der Tat dürfte der Besitzer nur gesetzt werden, wenn der User Vollzugriff auf Share-Ebene hat und auf NTFS-Ebene die Berechtigungen ändern darf. Beim Kopieren wird immer eine neue Datei erzeugt, also müsste das dort greifen. Falls der zugreifende User Mitglied der lokalen Administratoren des Dateiservers ist, wird automatisch die Admin-Gruppe als Besitzer eingetragen. Gruß, Nils

Moin, OK, also geht es eher um Update-Management als um das Verhindern von Updates bzw. Upgrades. Das lässt sich ja nun steuern ... Wegen solcher Probleme auf Updates zu verzichten, wäre - neben den Lizenzfragen - grob fahrlässig. Zumal bei einem Rechner, der in dieser Weise von verschiedenen Personen verwendet wird. Das hat mit "spürbaren Vorteilen" wenig zu tun, sondern einfach mit Betriebssicherheit. Der Weg wäre also nicht Abschalten, sondern managen. Gruß, Nils PS. Dass ihr den Rechner mit einem Desktop-OS in dieser Weise lizenzrechtlich betreiben dürft, habt ihr geprüft? Ein Client ist ja nun mal kein Server ...

Moin, schön, dann wäre die Kuh ja vom Eis. Ohne euch zu nahe treten zu wollen, aber ihr solltet an eurem Know-how und euren Prozessen arbeiten ... Gruß, Nils

Moin, also gibt es bereits zwei DCs. Damit gibt es auch das Risiko des USN-Rollback, und aller Wahrscheinlichkeit nach ist genau das eingetreten. Wie das geschehen ist, weiß ich nicht - aber in Verdacht steht natürlich der Hyper-V-Snapshot. Vielleicht hat der Kollege den ja nicht integriert, sondern "angewendet" - was effektiv heißt, dass er auf den Snapshot zurückgesprungen ist. Ein USN Rollback lässt sich nicht wirklich beheben. Da der einzige DC, den ihr entfernen könnt, der neue ist, würde ich diesen wieder entfernen. Dann auf dem alleinstehenden SBS nach Möglichkeit alle weiteren Fehler beheben und die Replikation wieder aktivieren. Danach dann den Zusatz-DC neu installieren. Und seht zu, dass ihr mit anderen Methoden die Daten sichert. Gruß, Nils

Moin, <OT> ein sehr schönes Wort! :D </OT> Gruß, Nils

Moin, wie Dr.Melzer schon sagt, ausführt: Vielleicht warten wir erst mal auf den TO, statt weiter zu mutmaßen, raten. Was die persönliche Bewertung angeht: Kann jeder so sehen, wie er will, nützt aber u.U. nichts. Gruß, Nils

Moin, als TO solltest du den Beitrag, der die Lösung enthält (also z.B. den von testperson), als "Lösung" markieren können. scheint nicht (mehr?) zu gehen? Gruß, Nils

Moin, also - AD repliziert normalerweise. Was soll die Replikation dann zerstören? Die eigentlich interessante Frage ist, warum die Replikation überhaupt aus ist. In diesem Thread kommen die Informationen ja nur krümelweise, daher musst du da selbst forschen. Du hast oben was von einem Snapshot erwähnt und von USN Rollback. Das kann in der Tat ein Problem sein und würde auch dazu führen, dass die Replikation aus ist. Vielleicht findet sich im Verzeichnisdienst-Eventlog noch der Fehler 2103, der dann protokolliert wird. Das allerdings würde nur auftreten, wenn es mehr als einen DC gibt. Davon war bislang nicht die Rede, wir sind alle hier von einem einzigen DC (dem SBS) ausgegangen. Also vielleicht dann doch mal Karten auf den Tisch. Gruß, Nils

Moin, also, wenn dein Problem darin besteht, dass die Replikation abgeschaltet ist, dann würde ich grundsätzlich zwei Schritte für sinnvoll halten: Herausfinden, warum das so ist, die Ursache ggf. korrigieren Die Replikation einschalten Da die funktionierende Replikation der Normalzustand ist, was für Probleme befürchtest du dann, wenn du sie einschaltest? Gruß, Nils

Moin, du musst, nachdem du die Variable gesetzt hast, im Geräte-Manager auch noch die Anzeige nicht vorhandener Geräte aktivieren. Abgesehen davon, sehe ich aber auch gerade das Problem nicht. Welche Nummer da hinten steht, ist doch rein kosmetisch. Gruß, Nils

Moin, für mich klingt das, als solltet ihr erst mal in Ruhe die Anforderungen klären. Danach mit jemandem, der sich auskennt, die Optionen besprechen, mit denen sich die Anforderungen erfüllen lassen. Und erst im dritten Schritt konkrete Hardware und Sizings auswählen. Ihr macht anscheinend gerade den dritten Schritt zuerst. Das ist in der IT zwar beliebt, führt aber in aller Regel in die Irre. Gruß, Nils

Moin, jupp, das ist die empfohlene Interims-Konfiguratoin. Gruß, Nils

Moin, was du dazu für eine Haltung hast, ist am Ende juristisch egal. Wir können hier nicht beurteilen, ob die Klauseln vor deutschen Gerichten Bestand haben, aber sie stehen nun mal im Lizenzvertrag: Das Anwenden von Updates und Upgrades nach Microsofts Vorgabe ist Grundlage der Lizenz. https://www.computerbase.de/2015-07/windows-10-eula-zwangs-updates-support-zeitraum-und-hardwarebindung/ Und, wie gesagt: Lizenzverstöße werden in diesem Board nicht supportet. Dem hast du auch zugestimmt, als du dich hier angemeldet hast. Gruß, Nils