christian23

Stimmt! Das was ich suche (z.B. einen Benutzer wieder auf einen früher gesicherten Stand zu setzen), kann mit dem "Authoritative Restore" nicht durchgeführt werden. Stattdessen scheint die "Erweiterte Überwachung" dies leisten zu können. Vielen Dank für Deine Hilfe! Christian

Wie gehe ich vor: Per RDesktop anmelden auf einem W2K8-Server mit AD. Ich möchte einen bestehenden (bzw. auch gelöschten) Benutzer auf einen früheren Stand zurücksetzen. Folgende Schritte: AD-Dienst stoppen (und abhängige Dienste). In Kommandozeile in das Systembackup-Verzeichnis gehen ntdsutil aufrufen, act inst NTDS, aut res, dann: authoritative restore: res obj CN=test,CN=Users,DC=tff,DC=firma-xyz,DC=de Die DIT-Datenbank wird geöffnet... Der Vorgang ist abgeschlossen. Aktuelle Zeit 08-11-10 14:35.34. Die letzte Datenbankaktualisierung erfolgte um 08-11-10 14:34.04. Die Versionsnummern des Attributs werden um 100000 erhöht. Die zu aktualisierenden Datensätze werden gezählt... Gefundene Einträge: 0000000001 Der Vorgang ist abgeschlossen. 1 Einträge wurden für die Aktualisierung gefunden. Datensätze werden aktualisiert... Verbleibende Datensätze: 0000000000 Der Vorgang ist abgeschlossen. 1 Datensätze wurden einwandfrei aktualisiert. Die folgenden Textdatei, die eine Liste autorisiert wiederhergestellter Objekte enthält, wurde im aktuellen Arbeitsverzeichnis erstellt: ar_20100811-143534_objects.txt Keines der angegebenen Objekte in dieser Domäne verfügt über rückwärtige Verknüpfungen. Es wurde keine Verknüpfungswiederherstellungsdatei erstellt. 2 x quit und AD wieder starten repadmin /Showobjmeta zeigt um 100000 erhöhte Versionsnummern der einzelnen Accountattribute. Aber im AD wird der Account nicht auf den Backupstand zurückgesetzt.

Nee. Ich hätte das Restore aus dem Verzeichnis starten sollen, in dem das Systembackup liegt. Sonst kann er keine Datensätze finden... Das klappt jetzt. Ich kann mir mit repadmin /Showobjmeta auch ansehen, dass die Versionsnummern der einzelnen Account-Attribute um 100000 hochgesetzt werden. Nur: Der Authoritative Restore ändert nichts am Account! Trotz erhöhter Versionsnummern bleiben die letzten Änderungen am Account erhalten, die durch das "aut res" doch wieder gelöscht werden sollten. Ein Rätsel!

Hallo Leute, auf einem W2K8-DC möchte ich einen Authoritative Restore mit NTDSUtil testen. Ich habe den User demo gelöscht, mit ADRestore.NET das gelöschte Objekt überprüft und den AD-Dienst beendet. Jetzt möchte ich den User demo wieder herstellen. So sieht es im NTDSUtil aus: authoritative restore: res obj CN=demo,CN=Users,DC=ttf,DC=firma-xyz,DC=de Die DIT-Datenbank wird geöffnet... Der Vorgang ist abgeschlossen. Aktuelle Zeit 08-10-10 13:44.53. Die letzte Datenbankaktualisierung erfolgte um 08-10-10 13:04.48. Die Versionsnummern des Attributs werden um 100000 erhöht. Die zu aktualisierenden Datensätze werden gezählt... Gefundene Einträge: 0000000000 Fehler beim Objekt mit dem Domänennamen in der Komponente "CN=demo". Fehler bei der autorisierenden Wiederherstellung. Ich nehme an, das liegt an dem Bindestrich, oder? Wie bekomme ich den dem NTDSUtil korrekt mitgeteilt? Gruss Christian

Hallo! Auf einem W2K8-Server habe ich eine Softwarespiegelung eingerichtet. Die möchte ich nun überwachen. In der Aufgabenplanung kann man zig Trigger einstellen, die das Ereignislog auswerten. Welcher ist derjenige, mit dem ich Fehler in der Datenträgerverwaltung (hier: Fehler bei Spiegelungen) abfragen kann, sodass mir automatisch eine Email gesendet wird, wenn eine Spiegelung Fehler aufweist? Eigentlich ein wichtiges Thema, denke ich. Aber weder meine dicken Fachbücher noch Google-Suche machen da schlauer. Gruss, Christian

Hallo Nils, ein einzelnes Installieren der Patches ergab: Der Patch KB979683 (MS10-021) verursacht die Verbindungsabbrüche! Ein Kernel-Update, dass mehrere Sicherheitslücken gleichzeitig patched. So, jetzt habe ich eine Info, mit der ich, wie du sagst, beim Hersteller der Applikation anfragen und bei Microsoft weiter suchen kann. Vielen Dank für deine Hilfe! Christian

Erstmal vielen Dank für die Antwort! Vorweg: Ich bin nicht der Admin der DB und der Applikation, sondern nur vom Windows-TS und den Benutzeraccounts. Daher kann ich nur eingeschränkt nachschauen und bin darauf angewiesen, dass mir der DB-Admin sagt, in seinem Log ist alles wie bisher, keine Fehlermeldungen. Aber das ist auch plausibel, da Zusammenhang mit Patchen (s.u.). Wie geht der Zugriff vonstatten - die User starten eine Applikation auf dem TS, die dann auf die Datenbank zugreift? Genau! Und: Ja, es hängt definitiv mit den letzten Patches zusammen (6 Windows-Patches, ein IE-Patch). Wenn ich die entferne, können alle Accounts wieder zugreifen. Was sagen Logs des Windows-TS-Servers: Nichts (ausser, wenn man die Applikation gewaltsam beendet, da dauerhaft "keine Rückmeldung" angezeigt wird) Log der Applikation (die sehe ich): Steht nichts drinne, wenn keine Verbindung zustandekommt Log des Datenbankservers: Nach Auskunft des Admins nichts. Was unterscheidet die Accounts, die sich anmelden können, von denen, die es nicht können? Hier muss man unterscheiden: Admins bekommen kein Login-Fenster der DB. Bei alle anderen (sind alle gleich eingerichtet, Benutzer-Level) geht es oder geht es nicht. Hier habe ich eine Lösung gefunden: Nach Löschen und Neueinrichten der Accounts können alle normalen Benutzer wieder zugreifen!!! Das funktioniert aber nicht für die Admins. Meine nächste Idee wäre, dass Microsoft mit den Patches z.B. eine neue Sicherheits-Gruppenrichtlinie eingeführt hat, die z.B. nur diejenigen betrifft, die auf dem Rechner schon einmal den IE gestartet haben (durch so etwas würde sich das uneinheitliche Verhalten der Accounts erklären). Dabei werden Admins und Nicht-Admins unterschiedlich behandelt. Gibt es ein Tool, um veränderte Gruppenrichtlinien (vor und nach dem Patchen) herauszufinden?

Hallo Leute, ein W2K3-SP2, neuester Patchstand, als Terminalserver genutzt, stellt über ein Frontend (HIS-FSV, _keine_ WEB-Anwendung) Datenbankanfragen an einen externen Datenbankserver (auf Solaris). Alles war gut. Seit dem letzten Microsoft Patchday habe ich folgende Situation: 1: Administratoren bekommen vom ext. DB-Server keine Einlog-Maske, um sich an der DB einzuloggen. 2: _Einige_ unprivilegierte Accounts (Gruppenmitgliedschaft Benutzer und Remotedesktopbenutzer) bekommen auch kein Einlogfenster. Bei _anderen_ geht es ohne Probleme. 3: Bei neuen (unprivilegierten) Accounts funktioniert das Einloggen an der DB. 4: Bei bestehenden Accounts, die ein neues (Default-)Profil erhalten, ändert sich nichts am Einlogverhalten. Die Firewall am Server ist aus, Antivirenprogramm zeitweilig ausgeschaltet (kein Effekt), verst. Sicherheitseinst. vom IE ausgeschaltet. Es scheint so, als sei da etwas User-Spezifisches im System, das die Verbindung zu dem ext. DB-Server blockiert. Bloss was? Irgendwelche Ideen? Die Sicherheitspatches zu entfernen, ist keine gute Option (da der Server ohne Firewall betrieben wird). Erwartungsvoll Christian