NilsK

Moin, prima, danke für die Rückmeldung. Dann wäre die Markierung "Beste Lösung" aber bei dem Beitrag von Dukel richtig angebracht. Gruß, Nils

Moin, man würde beim SQL Server (und bei nahezu allen anderen Datenbanken) jedenfalls kein Restore machen, um Performanceprobleme, fragmentierte Indizes oder ähnliches zu lösen. Dafür gibt es erheblich bessere Mechanismen, die hier ja auch schon genannt wurden. Gruß, Nils

Moin, dann würde ich folgenden Ansatz empfehlen: Import in zwei Schritten getrennt nach Artikeln und Artikelvarianten Dazu die Ausgangsdaten in Excel passend filtern - einmal nur die Artikeldaten, die du brauchst, das zweite Mal die Varianten noch effizienter wäre es natürlich, wenn du die Daten schon so bekommen würdest Und dann mit einem geeigneten Mechanismus in den SQL Server bringen je nachdem, wie viele Daten es sind und was damit in der Datenbank noch so geschieht, könnte man die Tabellen jedes Mal löschen und neu importieren nur neue Daten importieren neue Daten importieren und vorhandene aktualisieren neue Daten importieren und vorhandene regelbasiert aktualisieren was ein geeigneter Mechanismus ist, wäre anhand der Auswahl zu identifizieren Du siehst also auch hier, dass die Tücke im Detail steckt und man ohne Kenntnis des Zusammenhangs keine Methode empfehlen kann. Ein scheinbar simpler Task wie ein "Import" entpuppt sich oft als hochkomplexe Angelegenheit. Gruß, Nils

Moin, du hast nicht das Ziel beschrieben, sondern dein mutmaßliches Werkzeug dafür. Wozu brauchst du die Tabellen im SQL Server? Was soll damit geschehen, wie verwendest du die Daten dort? Warum reicht die Excel-Tabelle nicht? Du schreibst ferner davon, dass die Excel-Tabelle regelmäßig aktualisiert wird - was steckt dahinter? Könnte man stattdessen nicht gleich die Daten im SQL Server aktualisieren? Oder vielleicht gleich die Originaldaten verwenden? Hast du einen Weg, die Excel-Tabelle als solche in den SQL Server zu bekommen und könntest die Daten von dort aus weiterverarbeiten und "verteilen"? Wie hoch muss oder soll der Automatisierungsgrad sein? Reichen manuelle Schritte, brauchst du am Ende ein Programm, das den Import regelmäßig macht? Fragen über Fragen, wie du merkst. Wir können jetzt Annahmen treffen und dir -zig unpassende Lösungswege vorschlagen ... daher wäre es passender, wenn wir wüssten, was das denn am Ende werden soll. Gruß, Nils

Moin, vielleicht sollten wir doch zwischendurch mal darüber reden, was du denn eigentlich erreichen willst, bevor wir hier weiter wild mit Vorschlägen und Begriffen um uns werfen. Was ist das eigentliche Problem, das du zu lösen versuchst? Gruß, Nils

Moin, auch wenn es in diesem Thread OT ist ... Warum sollte Bitlocker an dem Problem etwas lösen oder auch nur mildern, dass Credentials eines hochberechtigten Kontos in einer Windows-Instanz hinterlegt sind? Gruß, Nils

Moin, das ist sicher alles machbar, aber du müsstest noch mal genau beschreiben, was in der Tabelle "Artikel" landen soll. Gruß, Nils

Moin, ich ergänze: lege als erstes den Namen fest, und zwar gleich mit einem URL, der auch von außen erreichbar wäre - selbst dann, wenn ihr das jetzt (noch) nicht nutzen wollt. Beispiel: fed.meine-firma.de Auf diesen Namen lässt du das SSL-Zertifikat ausstellen, das du dann zur Definition der Farm nutzt. Für weitere Details, die man besser oder schlechter machen kann, verweise ich auf meinen Hinweis weiter oben. Gruß, Nils

Moin, vielleicht sollten wir dann doch jetzt langsam mal über die eigentliche Anforderung sprechen. Die Datensammlung ist ja nur ein Werkzeug. Wofür werden die Daten denn benötigt? Was soll mit ihnen geschehen? Gruß, Nils

Moin, man hätte es schon vor zehn Jahren z.B. bei OBI lesen können. [Cindy: WMI-Dokuskript für Windows-Rechner | faq-o-matic.net] https://www.faq-o-matic.net/2011/01/24/cindy-wmi-dokuskript-fr-windows-rechner/ Gruß, Ni"so eine Vorlage lass ich doch nicht liegen"ls

Moin, ein USN Rollback tritt, wenn es denn auftritt, auf einzelnen DCs auf. Der DC, der das bei sich feststellt, schaltet seinen Anmeldedienst ab (und schreibt dies in sein Eventlog). Der Rest läuft weiter. Das Problem ist, dass in der Zwischenzeit vor dem Entdecken des Rollbacks schon Dinge passiert sein können - etwa falsch vergebene Berechtigungen. Ein ordentliches AD-Recovery erzeugt niemals ein USN Rollback. Es setzt ein Flag, dass das AD auf diesem DC aus einem Backup wiederhergestellt wurde. Dadurch weiß der DC bei der Replikation, was er zu tun hat. Daher sollte man das AD nur mit Methoden sichern, die diese Mechanismen umfassen. Ob der gesicherte DC die FSMO-Rollen innehatte oder nicht, ist weder für das Backup noch für das Recovery relevant. Ach, und: "Untergeordnete DCs" gibt es seit Windows 2000 nicht mehr. Gruß, Nils

Moin, Systemstate ist auch bei mehreren DCs die richtige Methode. Ich würde nie darauf verzichten und alle anderen Backuptechniken nur ergänzend einsetzen. Ein "ordentliches" AD-Backup verhält sich beim Recovery immer so, dass USN-Rollbacks ausgeschlossen sind. Die Gefahr besteht nur dann, wenn man glaubt, man könne selbst was Besseres basteln. (Kann man nicht.) Nein, das lass bitte bleiben. Ein DC ist ein DC und ein Host ist ein Host. Niemals beides. Gruß, Nils

Moin, das hängt vor allem davon ab, was die Anwendung unterstützt. Es ist durchaus üblich, auch interne Web-Applikationen per SAML/ADFS anzusprechen. Ist auch keine große Sache - wenn ADFS nicht so gruselig einzurichten wäre. Auch dies muss die Applikation allerdings unterstützen. Was Norbert sagt, ist völlig korrekt. Wenn es eine interne Applikation ist, ist der übliche Aufbau ein einzelner ADFS ohne Anbindung nach außen. Wenn man es selber noch nicht gemacht hat, empfehle ich, in einen bis zwei Tage Dienstleistung zu investieren. Gruß, Nils

Moin, Ist länger her, aber ich meine, du suchst Subqueries. Gruß, Nils

Moin, also, mit deinen Gedanken bist du absolut auf dem richtigen Weg. Nur, wie du ja selbst feststellst, gibt es da eben keine einfache Lösung. Das ist das, was wir ja schon mehrfach in diesem Thread betont haben. Wenn der Fall eintritt, werden dir auch alle Vorbereitungen und Checklisten nur begrenzt was bringen. Dann braucht es strukturiertes Improvisieren - und ja, je nach Szenario und Unternehmenswert durchaus auch ein professionelles Emergency-Response-Team, das empfindlich hohe Tagessätze kostet. Selbst dann, wenn man noch so viel vorbereitet hat. Ist ärgerlich, aber so ist mittlerweile die Lage. Kannst du zurzeit fast täglich in den Nachrichten sehen. Eine wichtige Grundregel nach Sicherheitsvorfällen: Wenn du es vermeiden kannst, ein System weiterzubetreiben oder "komplett" wiederherzustellen (VM- oder Image-Recovery), dann vermeide es. Gruß, Nils

Moin, der Witz an den SIDs ist ja gerade, dass diese unabhängig vom Namen sind. Die sind dazu da, ein System (bzw. weiter gefasst auch einen User oder eine Gruppe) auch dann eindeutig zu identifizieren, wenn sich der Name geändert hat. Umgekehrt ist ein neues Objekt mit einem "alten" Namen eben ein neues Objekt, das mit dem altern (bis eben auf den Namen) nichts zu tun hat. Und wie Evgenij schon schreibt, geht es beim Beibehalten des Namens und der IP-Adresse eigentlich nie um irgendwas "im AD", sondern eigentlich immer um Dinge wie Namen in vorhandenen Skripten, in vorhandenen Konfigurationen auf anderen Systemen usw. Und bezüglich deines Recovery-Tests: Das kann man schon so machen. Ob es zur Situation passt, ist innerhalb eines Forums nicht sinnvoll festzustellen, aber die Schritte passen prinzipiell schon. Gruß, Nils

Moin, du kannst deine Überlegungen hier gern posten. Wir können dann sicher zu dem einen oder anderen auch etwas sagen. Aber vorsichtshalber: Erwarte bitte keine umfassende Analyse und Beratung. Das ist eine Dienstleistung, die einfach Geld kostet. Die meisten hier verdienen ihren Unterhalt mit sowas. Ein Forum ist gut geeignet, um technische Detailprobleme zu diskutieren. Es ist nicht geeignet für Konzepte und Beratung. Gruß, Nils

Moin, was ist denn das für eine ominöse Aufgabe bzw. was macht das Skript denn? Eine Aufgabe mit einem Adminkonto auf Clients zu verteilen, ist i.d.R. die Kategorie "Murks, den man auf jeden Fall vermeiden sollte". Vielleicht (bzw. wahrscheinlich) gibt es bessere Wege, das eigentliche Ziel zu erreichen. Gruß, Nils

Moin, je nach Perspektive gibt es in KMU nichts anderes als "Restore from nothing". Oder eher "Restore from klaubing anything zusammen that you can find". Der Normalfall in KMU ist, dass irgendwas gesichert wird, aber eben nicht mit einem Blick auf Wiederherstellbarkeit. In sehr kleinen Umgebungen ist es ja oft sogar denkbar, "von nichts" wieder anzufangen. Wir diskutieren hier ein Netzwerk von "10-15 Usern". Wie lange wird es da schon dauern, die Berechtigungen neu zu machen, wenn man die eigentlichen Datenbestände irgendwie wieder an den Start kriegt? Je größer die Umgebung, desto mehr sollte man über mehrere Alternativen für das Recovery nachdenken. Aber wenn man erst mal anfangen muss, einem Kunden zu erklären, dass er sich nicht um das Backup, sondern um das Recovery kümmern sollte und dass es nicht nur das Szenario "Worst Case" gibt, dann weiß man eigentlich schon, dass man auch aufhören kann zu reden. Gruß, Nils

Moin, gut, dann müssen die Zertifikate also im Store des Computers liegen. Alle simplen Verteilmechanismen scheiden damit aus - es muss im Systemkontext oder als Admin importiert werden. Der kostengünstigste Weg wäre, dem WSUS ein kommerzielles Zertifikat zu geben, dem alle Clients von selbst vertrauen. Soll es das nicht sein, dann führt kaum ein Weg daran vorbei, die beiden Zertifikate in den Kundendomains jeweils per GPO zu verteilen, weil es sich dort ja um separate Forests handelt. Man muss dazu nicht "alle Kunden-DCs" bearbeiten, sondern nur ein GPO pro Kunde. Gruß, Nils

Moin, dann habe ich so keine Idee dazu. Ich vermute, dass da andere Effekte im Spiel sind, das ergibt dann aber über ein Forum keinen Sinn. Gruß, Nils

Moin, spätestens an dieser Stelle sollte man konkret werden und genau beschreiben, was erreicht werden soll. Sonst werden ab hier alle aneinander vorbeireden. Fangen wir mal an: Wozu sollen denn die Zertifikate verwendet werden? Warum sollen die Root- und Sub-Zertifikate "ohne Import ... und ohne Verteilung per GPO" verteilt werden? Über die Frage, ob es sinnvoll ist, Kunden-Domänen per Trust anzubinden, sprechen wir hier jetzt mal nicht. Gruß, Nils

Moin, das heißt, der PC ist in beiden Fällen derselbe? Der ist mal langsam, mal schnell? Oder handelt es sich um unterschiedliche Mitarbeiter und Geräte? Gruß, Nils

Moin, findest du nicht, dass ein Thread zu dem Thema reicht? Gruß, Nils

Moin, gut, dann nimm das, was ich geschrieben habe, als Appell. Gruß, Nils