NilsK

Moin, das Entfernen ist sozusagen eine "Notfunktion" beim Restore einer Datenbank auf einen anderen als den Ursprungsserver. Da in so einem Fall die Replikation nicht funktionieren würde, entfernt SQL Server sie im Restore-Prozess. Das ist nicht zum Übertragen usw. gedacht. Soweit ich mich erinnere, muss die Replikation in solchen Fällen komplett neu eingerichtet werden. Damit habe ich aber (zum Glück) vor über 20 Jahren das letzte Mal gearbeitet. Gruß, Nils

Moin, Ja, das ist normal und erwünscht, um das ausdrücklich zu beantworten. Die RAM-Nutzung ist beim SQL Server kein Hinweis auf Last. Gruß, Nils

Moin, Ist dir das nur aufgefallen oder entstehen daraus Probleme? Ich habe keine direkte Erklärung, aber vermutlich hängt es damit zusammen, wie SQL Server die Daten in den Dateien organisiert. Sie liegen meist nicht "am Stück". Durchaus denkbar, dass eine der Angaben daher falsch oder irreführend ist. Ich kann dem im Moment leider nicht genauer auf den Grund gehen. Gruß, Nils

Moin, Wenn das Netzwerk so klein ist, dass ein DC reicht, dann sind diese Einschränkungen sicher zu akzeptieren. Was uns zu der Frage nach den Anforderungen zurück bringt. Gruß, Nils

Moin, wenn Anwendungen und Daten in der Cloud sind, wozu dann noch ein DC? Ernst gemeinte Frage - nur wenn man die Anforderung kennt, kann man eine Lösung entwerfen. Gruß, Nils

Moin, sehr gut. Und eigentlich was für die Liste "Freie Wildbahn". Gruß, Nils

Moin, naja ... das ist am Ende Gutdünken des Entwicklers. In den Einzelbewertungen hab ich da eine ganze Menge Kritikpunkte. Aber man muss das Tool ja auch nicht als unfehlbare Quelle der Wahrheit ansehen. Gruß, Nils

Moin, die Frage ist, welches Problem du überhaupt zu lösen versuchst. Möglicherweise gibt es einen verwaisten Berechtigungseintrag, zu dem der SID nicht mehr auflösbar ist - dann stellt das eher ein theoretisches Problem dar, denn der zugehörige Account existiert nicht. Es gibt also kein höheres Angriffspotenzial als bei jedem anderen Berechtigungseintrag, im Gegenteil - mit dem Account kann sich ja niemand anmelden. Vielleicht arbeitet PingCastle aber auch irgendwie fehlerhaft. Denn aktuell scheint ja nur PingCastle "das Problem" anzuzeigen. Solange es kein weiteres Problem gibt, das damit im Zusammenhang stehen könnte, würde ich mir jetzt überlegen, wie viel Energie ich an welcher Stelle noch investiere. Gruß, Nils

Moin, das heißt, der Berechtigungseintrag wird dir nicht angezeigt? Oder was meinst du genau? Wenn die einzige Fundstelle der PingCastle-Report ist, dann könnte da ja auch irgendwas falsch sein. Gruß, Nils

Moin, Gibt es ein Konto des Namens lokal auf dem Rechner? Es kommt vor, dass Windows dann durcheinander kommt. Gruß, Nils

Moin, das weiß ich doch. Ich wollte mal was anderes schreiben als "PKI ist böse". Wie, habe ich darauf schon mal hingewiesen? Ich bin doch sonst so zurückhaltend. Gruß, Ni"sehr uneitel"ls

Moin, wer sagt denn sowas? Ja, das ist das Grundproblem der ganzen PKI-Klamotte. Wir ersetzen Vertrauen durch Verträge, die uns nicht bekannte Unternehmen miteinander geschlossen haben. Im Falle von Unterschriften muss man aber auch dazu sagen, dass die Anforderungen an digitale Signaturen viel höher sind als die an die analoge Welt. Einer auf Papier gekritzelten Unterschrift kann ich nicht ansehen, wer da gekritzelt hat. Trotzdem kann man damit Arbeitsverträge kündigen und Grundstücke kaufen. Das ist jetzt Äpfel mit Pflaumen vergleichen. Letsencrypt macht ausschließlich TLS-Zertifikate vom Typ "Domain Validated". Da passt deren Prozess. Für andere Zwecke passt er nicht, aber die bedient die Organisation auch nicht. Gruß, Nils ... die Langfassung gibt es auch als Vortrag von mir.

Moin, dsacls (gehört zu den AD-Verwaltungstools) sollte auch SIDs entgegennehmen. Ich hab dein Szenario nicht geprüft, aber im Grundsatz sollte es damit gehen. Gruß, Nils

Moin, entschuldigt, ich habe nicht reagiert. Gruß, Nils

Moin, das hat auch einen Grund: Datenbankreplikation war ein heißes Thema in den Neunzigern. So alt ist auch die Technik. Heute macht man das nicht mehr bzw. versucht es zu vermeiden - weil es eben sehr fehleranfällig ist und die allermeisten Use Cases dafür entfallen sind. In den Neunzigern war es noch undenkbar, von verschiedenen Standorten auf einen zentralen Datenbestand zuzugreifen. Heute schon lange nicht mehr. Möglicherweise habt ihr einen der seltenen Fälle, wo man Replikation noch braucht. Alle Kunden, mit denen ich in den letzten ca. 15 Jahren auf so ein Thema geguckt habe, hatten keinen echten Bedarf (mehr) für Replikation. Es lohnt also evtl., da noch mal kritisch draufzuschauen. Gruß, Nils