NilsK

Moin, welcher Replikationsbereich ist denn bei den DNS-Zonen eingetragen? Gruß, Nils

Moin, weil ein RODC Einschränkungen hat, die den Aufwand erhöhen und den Nutzen einschränken, u.U. erheblich. Sofern es an dem Standort einen ordentlichen Serverraum gibt und der DC nicht physisch gefährdet wäre, ist ein DC die bessere Wahl. Ob das Sinn ergibt, ist damit aber noch lange nicht gesagt. Wenn die Lage ist wie beschrieben, dürfte ja auch RDP kaum nutzbar sein - ob eine lokale Anmeldung dann weiterhilft, halte ich für fraglich. Wie gesagt, wäre das aber Thema für eine ausführliche Betrachtung und nicht für ein Forum. Gruß, Nils

Moin, wenn es nicht an Profilen liegt und die GPOs unauffällig sind, dann sind 10-15 Minuten für einen Logon in der Tat heftig. Dann dürfte alles Weitere, was über das WAN geht, an dem Standort aber auch nahezu unbrauchbar sein, oder? Auf Grundlage des hier Diskutierten würde ich aber immer noch nicht einen RODC ins Spiel bringen. Um aussichtsreiche Lösungsvorschläge zu entwickeln, müsste man sich die Umgebung und die Anforderungen in größerem Stil ansehen. Das ist aus meiner Sicht nichts für ein Forum. Die Exchange-Frage ist ja soweit beantwortet. Gruß, Nils

Moin, "die Anmeldung" heißt was? Sind da Roaming Profiles im Spiel oder sowas? Gruß, Nils

Moin, und was bedeutet "Probleme mit der Anmeldung"? Da Windows auf Cached Credentials zurückgreift, sollte die eigentliche Anmeldung kaum ein Problem darstellen. Was genau ist das Problem? Ein RODC hilft in seltenen Fällen, aber noch seltener in den Fällen, in denen viele das vermuten. Daher sähe ich das erst mal skeptisch. Der Aufwand dafür ist auch nicht zu unterschätzen - wenn RODC, muss man es auch richtig machen. Gruß, Nils

Moin, da ADMX-Dateien nur die Verwaltungsoberfläche steuern, aber nicht die Funktion der GPOs, würde ich kein komplexes Versionssystem erfinden, sondern immer die neuesten Versionen einsetzen. Gruß, Nils

Moin, ja, du hast Recht, der Prozess ist sozusagen umgekehrt. Der Client ändert das Kennwort. Der Punkt, den ich meine: Das Ändern des Computerkennworts geschieht nicht durch das AD ohne Kontakt zum Client. Viele vermuten das. Daher kann ein Client nicht durch ein "automatisch geändertes Kennwort" aus der Domäne fallen, wenn er zu lange keinen Kontakt zum AD hat. Gruß, Nils

Moin, abgesehen davon, ändert sich das Computerkennwort nur, wenn dies gemeinsam von dem Client und dem DC gemacht wird. Der DC ändert das nicht "in Abwesenheit", das wäre auch nutzlos. Wenn das regelmäßig auftritt, vermute ich, dass was anderes im Busch ist. Wie lautet die Fehlermeldung denn genau? In welcher Situation tritt sie auf, was passiert vor- und nachher? Was sagt das Eventlog? Gruß, Nils

Moin, So altes Zeug wird keiner mehr kaufen. Windows 7 ist in einem halben Jahr aus dem Support. Bücher kann man auch ins Altpapier tun. Gruß, Nils

Moin, dann nehme ich mal an, dass sich nicht nur der Bildschirm abschaltet, sondern der Rechner in einen Sparmodus geht. Gruß, Nils

Moin, was passiert denn eigentlich genau? Im Betreff steht "Absturz", aber jetzt klingt es eher so, als würde nur die Kommunikation mit dem Dienst abreißen. Bitte beschreib mal genauer. Gruß, Nils

Moin, nachgucken kannst du im Eventlog. Da sollte sich was dazu finden. Schau dir alles an, was zeitlich in der Nähe liegt. Gruß, Nils

Moin, ich stimme zu - Diskussion per PN ist nicht der Sinn eines Forums. Was heißt dies genau? Gruß, Nils

Moin, *lol* das ist in der Tat witzig. Wobei "Grotesk" einfach ein traditioneller Name für nüchterne, serifenlose Schriften ist. https://de.wikipedia.org/wiki/Grotesk_(Schrift) Gruß, Nils

Moin, lass dir auf beiden Seiten den Verzeichnisbaum als Text in eine Datei schreiben. Dann nimm ein Vergleichstool, so kannst du identifizieren, was doppelt ist. Gruß, Nils

Moin, bei Kennwörtern ist faktisch nur die Länge entscheidend. Wie viele Zeichen genau, ist Glaubenssache, aber 8 Zeichen gelten schon seit Jahren als zu kurz für ernst gemeinte Angriffe, insbesondere bei hochprivilegierten Konten. Meine Ansicht dazu ist: alles unter 20 Zeichen ist zu kurz für einen Account, der Schlimmes anrichten kann. Hier helfen Kennwortsätze. Das mit dem Sperren würde ich lassen - das ist eine Krücke, die wenig hilft, aber viel schadet. [DOS-Angriff für jedermann: AD-Konten sperren | faq-o-matic.net] https://www.faq-o-matic.net/2013/08/07/dos-angriff-fr-jedermann-ad-konten-sperren/ Und gleich noch ein Tool für lange Kennwörter, die man gut tippen kann (es gibt noch ca. 1000 andere solche Tools): [Bessere Kennwörter erzeugen und merken | faq-o-matic.net] https://www.faq-o-matic.net/2017/07/26/bessere-kennwrter-erzeugen-und-merken/ Gruß, Nils

Moin, [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, die Kennwörter werden ja nicht ausgelesen. Nur das neu gewählte Kennwort wandert einmal durch den Filter, bevor das AD es als neues Kennwort akzeptiert. Danach ist es nicht mehr auslesbar. Durch einen anderen als den eingebauten Filter ändert sich an dem Prinzip nichts - oder anders: Der Vorgang geschieht jetzt auch schon. Gruß, Nils

Moin, in Outlook unter iOS gegen ein O365-System ist das schon lange so. Dort sieht man es ach "direkt", ohne ein anderes Tab öffnen zu müssen. Auf dem PC hab ich noch nie danach gesehen. Gruß, Nils

Moin, bitte gewöhne dir an, solche Informationen gleich zu liefern und nicht erst weit hinten im Thread. Da es in deinen Problemen um Exchange und Authentifizierung geht, ist sowas von Belang. Gruß, Nils

Moin, da ihr bereits einen 2016-DC in Betrieb habt, habe ich die Exchange-Frage nicht beleuchtet. In eurer quasi ungepatchten Konstellation habt ihr das Risiko (und eine nicht supportete Umgebung) bereits seit der Integration des 2016-DCs, es entsteht nicht erst in dem Moment, in dem ihr den alten DC rausnehmt. Gruß, Niös

Moin, nein, die Reihenfolge ist egal. Zu beachten ist nichts Besonderes, wenn die restliche Infrastruktur (insbesondere DNS) korrekt ist. Sollte es sich bei dem DC, der entfernt werden soll, um den ersten jemals installierten handlen, ist es ratsam, das EFS-Zertifikat mit dem Private Key zu exportieren. Auch wenn es nicht mehr gültig ist, kann es sein, dass man es später noch mal zum Entschlüsseln alter Dateien braucht. Gruß, Nils

Moin, um das Schema zu aktualisieren, muss man Mitglied der Gruppe Schema-Admins sein. Ob der betreffende Account in der Root Domain oder in einer Subdomain beheimatet ist, ist dabei egal. Kann das Schema-Update wegen mangelnder Berechtigungen nicht stattfinden, wird einen die AD-Installation darüber informieren. Auch wenn es technisch möglich ist, eine Subdomain vor der Root Domain zu aktualisieren, ist es gerade wegen solcher Zusammenhänge i.d.R. nicht sinnvoll. Gruß, Nils

Moin, könnte man denken. In der Cloud habe ich eine abgeschaltete VM, falls ich die noch nicht gelöscht habe. Und meine Frau hat ihre Mailbox bei einem Cloud-Provider. Die fünf Webseiten, die ich betreue, laufen als Shared Hosting mit Ökostrom. Das war's im Wesentlichen. Zugegeben: Wäre ich Freiberufler, nutzte ich vielleicht ein wenig mehr, aber auch dann bräuchte ich es nur punktuell. Ich will hier auch niemanden angreifen, aber ich finde die Tendenz der Diskussion gerade etwas ... ergänzungsbedürftig. Gruß, Nils

Moin, hm. Und wofür braucht ihr das? Steht dem ein reeller Nutzen entgegen? Mein 4-Personen-Haushalt wird vom Energieversorger schon seit Jahren als weit unterdurchschnittlich eingestuft (trotz zwei Teenie-Töchtern - aber Smartphones brauchen für Insta und Youtube halt nicht viel Strom). Ich brauche einfach privat keine IT, schon gar keine, die durchlaufen würde. Geek hin oder her, aber irgendwann ist es ja auch eine Frage der Verantwortung. Gruß, Nils