NilsK

Moin, und der DC und alle Server und Clients haben ausschließlich den DC als DNS-Server eingetragen? Die Fehlermeldungen stammen aus dem laufenden Betrieb, d.h. nicht direkt nach dem Neustart des DCs? Gruß, Nils

Moin, diese Information solltest du gleich geben. Bei der ersten Erwähnung klang es, als würde das grundsätzlich nicht funktionieren. Hier ist das Problem also sehr wahrscheinlich bei dem einen Client bzw. dem einen Computerkonto zu suchen, nicht allgemein. Insbesondere den Verdacht, das AD sei irgendwie inkonsistent, können wir getrost begraben (oder zumindest in den Warteraum schieben - es ist ausgesprochen unwahrscheinlich). Und, hast du die Stunde jetzt investiert? Gruß, Nils

Mom, Wir lange würde es denn dauern, das "große" GPO neu zusammen zu klicken? Eine halbe Stunde? Eine ganze? Gruß, Nils

Moin, Wenn neue GPOs funktionieren, würde ich bei nur sechs Objekten insgesamt nicht mehr lange fackeln ... Gruß, Nils

Moin, Bitte gewöhne dir an, mit Schlussfolgerungen zurückhaltender zu sein. Wie sicherst du deine DC-VM? Sinnvoller wäre, du würdest das AD per System State sichern, das hilft dir dann auch, wenn es gar nicht darum geht, den DC wiederherzustellen. In diesem Moment etwa würde dir eine separate AD-Sicherung wahrscheinlich mehr helfen als ein ganzer DC. Ist momentan aber Essig, es gibt ja kein Backup. Wir gesagt, ich kann das jetzt nicht mehr in der Tiefe supporten. Was ich jetzt prüfen würde: - sind wirklich die GPO-Dateien noch da oder nur die Ordner? -kannst du die GPOs zum Bearbeiten öffnen? - wenn du ein neues GPO anlegst, funktioniert dies dann auf dem Client? - wenn du von einem bestehenden GPO den Link entfernst und es dann neu verknüpfst, geht es dann? - wenn du einen Client aus der Domäne nimmst und neu hinzufügst, geht es dann? (Alternativ einen ganz neuen Client, etwa eine neue VM.) Gruß, Nils

Moin, nur damit wir uns richtig verstehen: Was genau hast du da nachgesehen? Um wie viele Clients handelt es sich denn? Und um wie viele GPOs? Für weitergehenden Support fehlt mir im Moment die Zeit. Meine Einschätzung ist aber: Du hast gar kein großes Problem, nur ein lästiges. Ein Backup deines AD hast du jetzt doch hoffentlich eingerichtet, oder? Gruß, Nils

Moin, das ist mir schon klar. Die Frage ist aber: gibt es außer den GPO-Sachen noch weitere Fehler oder Probleme auf dem DC? Wenn ja, welche genau? Was ist denn mit dem DC passiert? Ist das so? Wäre eher untypisch. Hattest du denn auch die Fehlermeldung, die in dem Artikel genannt wird? Dahinter liegt eine eher mystische Vorstellung von der Replikation, die oft anzutreffen ist. "Schäden auf einem DC" replizieren sich aber nicht. Das AD repliziert Daten, sehr vorhersagbar. Künftig sei also empfohlen, dass du dir früher Unterstützung suchst, statt einfach was auszuprobieren. So, jetzt nähern wir uns mal dem Problem. Sind denn die Gruppenrichtlinienobjekte im AD und auf dem DC vorhanden? Das prüfst du einerseits in der GPMC (gpmc.msc aufrufen) und zum anderen im Dateisystem im SYSVOL (%logonserver%\sysvol\%userdnsdomain%\Policies aufrufen). Sind die erwarteten Objekte da? Die weiteren Eventlog-Meldungen kannst du erst mal ignorieren. An den Time Service und die DFS-Replikation solltest du später mal ran, aber erst mal schauen wir, was mit den GPOs los ist. Gruß, Nils

Moin, willkommen an Board! Auch wenn dein Problem dich stresst (was ich verstehe), solltest du dich um genaue Beschreibungen bemühen. Es wird sonst unnötig umständlich. Welches sind diese "extremen Probleme"? Weiter unten gibst du an, dass eigentlich alles geht, bis auf die GPOs. Ist da nun noch mehr im Busch oder nicht? Der DSRM ist im Wesentlichen dafür da, das AD aus einem Backup wiederherzustellen. Da du das offenbar nicht getan hast, was hast du denn dort genau gemacht? Von solchen Schnellschüssen solltest du künftig Abstand nehmen. Einen neuen DC hinzuzufügen, ist erst mal OK, aber den alten zu entfernen, solange noch Probleme bestehen, war u.U. voreilig. Eine Lüge wäre ja eine absichtliche Fehlinformation. Ich glaube nicht, dass Windows dich anlügen will, sondern denke eher, dass es aus seiner Sicht Recht hat. Die Frage wäre also eher, warum Windows versucht, den SPN zu registrieren, wenn er doch anscheinend da ist - und warum das fehlschlägt. Da der SPN ja aber anscheinend da ist, kann man dieses Problem vermutlich zunächst ignorieren. Zu den anderen Events müsstest du bitte mal angeben, was dort steht. Hier wird niemand die IDs im Kopf haben. Was führt dich zu dieser Aussage? Was versuchst du genau, und was passiert dann? Weiter oben schreibst du, dass die Clients die GPOs sehr wohl erhalten, aber nicht anwenden. Hier müssten wir jetzt also erst mal klären, was denn genau das Problem ist. Auch diese Schlussfolgerung scheint mir etwas voreilig zu sein. Wenn der Dienst dort nicht auftaucht, dann hat er keine Berechtigungen. Und damit könnte das Problem durchaus das sein, das in dem Artikel beschrieben wird. Wenn es auch weiterhin nicht geht, müsste man noch mal prüfen, was du dort denn genau gemacht hast; an der Stelle kann man durchaus auch unabsichtlich falsch vorgehen. Also schau doch mal, ob du die fehlenden Informationen nachliefern kannst. Gruß, Nils

Moin, okay, also eben nicht unabhängig von der Anwendung, sondern nur aus dem Browser. In dem Fall scheint mir Martins Hinweis ein guter Kandidat zu sein. Vermutlich scheitert de Browser im ersten Anlauf daran, die Inhalte in die Datei zu kopieren. Wie lautet die Fehlermeldung denn genau? Gruß, Nils

Moin, Ich stimme Evgenij völlig zu. Technisches Aufrüsten wird das Problem nicht lösen, sondern vor allem viel Geld kosten und die loyalen Mitarbeiter nerven. Wenn ein Mitarbeiter mit bestimmten, wichtigen Daten arbeiten muss, dann wird er auch Zugriff darauf haben. Und da in Deutschland niemand seinen Job von heute auf morgen wechselt, wird jemand, der Daten mitnehmen will, dies völlig unauffällig vorbereiten können. Man muss hier also einen sinnvollen Umgang finden. Nicht jeden Praktikanten an die kritischen Geheimnisse zu lassen, ist sinnvoll. Irgendwelche technischen Hürden aufzubauen, ist hingegen meist unsinnig. Und da gehört die Beratung hin. Gruß, Nils

Moin, Ich glaube nicht, dass Schnellschüsse hier helfen. Zunächst wäre doch mal zu klären, was überhaupt das Problem ist und wie künftig die Zugriffe geregelt werden sollen. Möglicherweise reichen ja doch recht simple Zugriffsrechte aus? Eine Planung wirst du in jedem Fall machen müssen, das nehmen dir die ganzen Tools, die du nennst, nicht ab. Gerade wenn es das Geld des Kunden ist, hat er ein Recht auf Beratung. Gruß, Nils

Moin, das heißt, Speichervorgänge von diesem Server aus auf beliebige andere Server führt unabhängig von der Anwendungssoftware zu Problemen? Dann sollte sich doch sicher was im Eventlog dazu finden, oder? Neustart schon versucht? Gibt es weitere Probleme auf dem System? Ist die Uhrzeit auf dem Server korrekt? Gruß, Nils

Moin, Deine Frage ist nachvollziehbar, aber leider so nicht zu beantworten. Um zu verstehen, was du verstehen willst, musst du nicht den Event Viewer verstehen, sondern die jeweilige Komponente, die ihre Meldungen ins Log schreibt. Ja, das kann jeweils eine sehr große Aufgabe sein. Leider wird dir faktisch nicht viel anderes übrig bleiben, als intensiv in der jeweiligen Situation zu recherchieren. Gruß, Nils

Moin, wenn du die Frage 20 Leuten stellst, wirst du mindestens 21 Antworten dazu bekommen. Die meisten davon sind plausibel, keine passt überall. Da sAMAccountName und UPN unterschiedlich sein können, der UPN das Format einer Mailadresse hat und der SAM-Name begrenzt ist, könnte man aus der Not eine Tugend machen: Den SAM-Namen unabhängig vom "echten" Namen machen und den UPN identisch zur (personenbezogenen) Mailadresse. Dann bleibt einer der Namen auch dann gleich, wenn z.B. jemand den Namen seiner Frau annimmt. Gleichzeitig kann man sich die Anmeldung an Windows und an M365 gut merken. Für den SAM-Namen sollte man dann ein Attribut nehmen, das sich im Unternehmen wirklich nicht ändert. Meist eignet sich dazu die Personalnummer. Nicht schön, aber simpel und eindeutig. Gruß, Nils

Moin, meines Wissens nicht - denn dann hat der Lizenzgeber ja keinen Vertrag mit dem Unternehmen, das die Lizenzen tatsächlich nutzt. In allen leicht zugänglichen Dokumenten heißt es deshalb "one single licensing organization" oder vergleichbar. Aber ich bin auch kein Lizenzspezi. Unabhängig davon rate ich aber dazu, das Konstrukt auch technisch-organisatorisch zu betrachten. Erfahrungsgemäß tun sich auch dabei oft Punkte auf, wegen derer man noch mal anders denken sollte. Gruß, Nils

Moin @R2D2-4dot0, nur nebenbei bemerkt: Dein eigener Ton ist auch hochgradig kritikwürdig. Vielleicht mal etwas durchatmen. Gruß, Nils

Moin, einfach so zugreifen (also die Lizenz der anderen Firma nutzen) geht nicht. Vermieten lässt die Lizenz auch nicht zu. Ein Verkauf sollte möglich sein. Ich zweifle aber, ob das mit dem Gesamtkonstrukt lizenzrechtlich funktioniert - die zugreifenden User brauchen ja auch noch Windows- und RDS-CALs. Und man darf nicht einfach so Mitarbeiter einer anderen Firma seine Systeme nutzen lassen - auch das schließen die Lizenzen aus. Hier wäre vorab eine Beratung sinnvoll, bei der das Konzept sowohl technisch als auch lizenzrechtlich geprüft wird. Nur technisch oder nur rechtlich würde vermutlich jeweils einen wichtigen Teil unberücksichtigt lassen. Ein Fall für einen kompetenten Dienstleister, würde ich sagen. Gruß, Nils

Moin, was die Kollegen meinen, aber - warum auch immer - nicht sagen: Ein "zweiter Server" in dem Sinn, wie er dir vorschwebt, wäre nicht einfach ein zweiter Server, sondern er würde zu einem recht komplexen Konstrukt gehören, das in den Bereich "Verfügbarkeit" bzw. "Hochverfügbarkeit" gehört. Allgemein bezeichnet man das als Failover Cluster, im Fall von Exchange bezeichnet man das seit einigen Jahren als Database Availability Group. Damit hättest du jetzt ein paar Stichworte, mit denen du weiterkommen solltest. Gruß, Nils

Moin, ich ergänze mal: Normalerweise sind für einen Domain Join auch gar keine AD-Adminrechte nötig. Die Vermutung wäre also, dass es gar nicht mit den Adminrechten zusammenhängt, sondern etwas anderes hakt. Andere Vermutung: Je nachdem, was du mit "am WDS-Server anmelden" meinst, könnte dir theoretisch auch UAC dazwischenfunken, denn der Builtin-Administrator wird nicht durch UAC eingeschränkt, alle anderen Administratoren hingegen schon. Das ist auch praktisch das einzige, das diesen Administrator zum "Ober-Admin" macht. (Ob das bei WDS tatsächlich einen Unterschied macht, weiß ich nicht. Ich muss zum Glück keine Clients installieren. ) Gruß, Nils

Moin, Ich muss zustimmen, ich verstehe auch kein Wort. Bitte noch mal in Ruhe erklären. Gruß, Nils

Moin, da du ja nur drei Fälle zu unterscheiden hast, reicht vielleicht ein CASE-Konstrukt aus. Eine eigene Funktion dafür kann man auch bauen, aber das erscheint mir hier zu hoch gegriffen. [CASE (Transact-SQL) - SQL Server | Microsoft Docs] https://docs.microsoft.com/de-de/sql/t-sql/language-elements/case-transact-sql?view=sql-server-ver15 Vielleicht noch eine allgemeine Anmerkung: Wie gesagt, für den Anfang ist das Vorhaben schon ziemlich komplex. Ich würde das jetzt erst mal in kleine Teile zerlegen. Für die Einsortierung in wenige Kategorien etwa wirst du im Web -zig Anregungen finden. Bau dir damit erst mal ein paar Abfragen, die die Werte nur ausgeben. Wenn du das drauf hast (da wird es vermutlich mehrere Möglichkeiten geben) gehst du weiter und schaust, welchen der Wege du in deinem Szenario gut weiter verwenden kannst. Gruß, Nils

Moin, Eine View baust du mit Create View. Auch dazu findest du das Nötige in der Doku. Dein Update geht deshalb nicht, weil die Tabelle ja keine Spalte "Alter" hat. Die hast du nur in deiner Abfrage virtuell erzeugt. Du könntest aber die Logik, die in deiner Abfrage das Alter errechnet, auch direkt in deinem Update-Statement in der Where-Klausel verwenden. Gruß, Nils

Moin, ja, "sollte" ... aber wie das dann eben in der typischen AD-Umgebung mit solchen Gruppenmitgliedschaften ist. Und ruck-zuck ist LAPS der Hebel, der dem Angreifer den Weg vom Eindringling zum Admin ermöglicht. Kann gutgehen, aber ich hab da eben so meine Zweifel, was den Umgang mit Berechtigungen im AD angeht. Gruß, Nils

Moin, ich ergreife die Gelegenheit, meine grundsätzlichen Bedenken gegen LAPS noch einmal anzubringen. Die Lösung ist sicher pfiffig, aber nur innerhalb enger Grenzen. Leider wird sie in der Praxis oft jenseits dieser Grenzen eingesetzt. Der Sicherheitsgewinn von LAPS hängt nahezu ausschließlich an den Berechtigungen für das Kennwort-Attribut im AD. Damit das funktioniert, braucht man strenge administrative Prozesse, die sinnvoll regeln, wer auf diese Kennwörter nun zugreifen darf. An der Stelle sehe ich in der Praxis Nachlässigkeiten - und schon hat man nicht mehr, sondern weniger Sicherheit, indem man Anwendern, die es eigentlich nicht können sollten, die Kennwörter auf dem Silbertablett darreicht. Und damit natürlich auch Angreifern. Und dann kommen schnell Jenseits-der-Grenze-Ideen dazu wie der Klassiker "Adminrechte temporär vergeben, indem man dem User das lokale Kennwort gibt und es gleich danach per LAPS ändert". Man kann LAPS sinnvoll einsetzen, aber das erfordert dann eine Sorgfalt, die in vielen Umgebungen nicht vorhanden ist. Gruß, Nils

Moin, indem man den Termin nicht von Montag 10 Uhr bis Mittwoch 18 Uhr laufen lässt, sondern einen Serientermin über drei Tage einrichtet: Montag bis Mittwoch jeweils 10 bis 18 Uhr. Das umgeht (meist) technische Hakeleien, und es sorgt auch für bessere Übersicht. Ganztätige Termine oder solche, die über die Tagesgrenze gehen, zeigt Outlook leider in einigen Ansichten nicht gut an, sodass man sie leicht übersieht (z.B. in der Planungsansicht). Serientermine mit Start- und Endzeit sind besser sichtbar. Insgesamt gibt es bei Kalendereinträgen aber immer wieder Probleme, besonders wenn man mit verschiedenen Clientprogrammen und mehreren Usern darauf zugreift. Manchmal kann man da nur mildern, aber nicht lösen. Gruß, Nils