NilsK

Moin, This. Abgesehen von Folgen, an die man erst gar nicht denkt. Etwa Termine für Bewerbergespräche, bei denen das Display den Namen des Bewerbers für alle Besucher sichtbar ausposaunt, weil der Client auf dem Gerät leider das Flag "privat" nicht auswertet. Schön auch bei Terminen wie "Eskalation Kunde XY". Gruß, Nils

Moin, Ja, hatten wir in der früheren Firma. Hat manchmal toll funktioniert. Gruß, Nils

Moin, Warum macht ihr einen DR-Test, wenn ihr die Ergebnisse nicht exakt dokumentiert? Gruß, Nils

Moin, euer AD hat gar keine Standorte. "Es war nicht möglich, sich anzumelden" ist auch keine ausreichende Fehlerbeschreibung. Da müsstest du jetzt noch mal nach den Details forschen. Gruß, Nils

Moin, es sollte ohnehin jeder DC ein Global Catalog sein. Der ist in Wirklichkeit nicht optional. Wichtig ist vor allem, dass die Clients anhand der Subnet-Konfiguration wissen, zu welchem Standort sie gehören. Dann fragen sie von selbst den richtigen DC. Im gegebenen Fall haben die FSMO-Rollen nichts damit zu tun. Der Klassiker ist, dass die Clients keinen DNS-Server finden, weil sie nur den am eigenen Standort konfiguriert haben. Oder hier vermutlich eher umgekehrt - nur den anderen. Gruß, Nils

Moin, es gibt Neues von der cim Lingen. Sie wird in diesem Jahr wieder stattfinden, und zwar am 17. September 2021. Leicht verändertes Konzept, aber es ist die cim, die wir kennen und lieben. Was auf der Webseite im Moment vielleicht nicht klar genug ist: Die cim ist als Präsenzveranstaltung geplant, wie immer in Lingen. Mit Catering und viel Liebe zum Detail. Parallel werden alle Beiträge ins Netz gestreamt. (Sollte es die Lage nicht zulassen, das Event mit Publikum zu machen, dann gibt es nur Online. Aber wir wollen, wenn es irgend geht, uns alle in Lingen wiedersehen.) https://cim-lingen.de/ Gruß, Nils PS. Bis Sonntag sind auch noch Bewerbungen als Speaker möglich.

Moin, Access ist ja auch eine Entwicklungsumgebung und RAD-Plattform, SQL Server ist eine Datenbank. Man kann immer noch mit Access die Anwendungslogik bauen und SQL Server als Backend einsetzen. Ist nur aus der Mode gekommen. Was der TO für die Applikationslogik verwendet, hat er ja noch nicht gesagt - anscheinend gibt es da auch noch keine Architektur. Gruß, Nils

Moin, in dem Fall würde ich auch so vorgehen wie Sunny: Erst roh importieren in eine Interimstabelle. Von dort aus mit SQL-Kommandos die Daten in die Zieltabellen verteilen. (Schrieb ich auch oben schon mal.) Ob es dazu MERGE sein muss oder ein einfacherer Weg funktioniert, hängt von deiner Anwendungslogik ab. Gruß, Nils

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