NilsK

Moin, du kannst beruhigt davon ausgehen, dass Nachfragen einen Sinn haben. "Hab ich doch geschrieben" hilft i.A. nicht weiter. Warum besteht bei dir die Anforderung, einzelne Scopes wiederherzustellen? Welche Situation willst du dadurch absichern? Ist das DHCP-Clustering tatsächlich benötigt? Was spricht z.B. gegen Split Scope? Gruß, Nils

Moin, guter Trick und gute Anleitung. Muss ich mir mal merken! (Es bleibt aber meine Skepsis gegenüber dem Grundansatz. Man sollte gut überlegen, ob man den gewaltigen Overhead dieser Methode wirklich braucht - wenn es einen Sinn ergeben soll, sprechen wir hier von mehreren Tagen, wahrscheinlich sogar mehreren Wochen Verzug bei der Migration ... und ich erlaube mir die Anmerkung, dass der Network Monitor (NMCap), Ethereal et al. bei der Langzeitaufzeichnung durchaus zwischendurch mal abbrechen.) Gruß, Nils

Moin, jein. Der Builtin-Druckoperator gilt nur auf den Domänencontrollern. Er könnte die Drucker also nur dann verwalten, wenn der Printserver ein DC ist. Ja. Gruß, Nils

Moin, dafür, dass der Thread schon seit sechs Wochen inaktiv war, lehnst du dich ganz schön weit aus dem Fenster. Ich rate, dass du dich mal beruhigst und noch mal über deinen Ton nachdenkst. Gruß, Nils

Moin, bitte weniger Ausrufezeichen verwenden. faq-o-matic.net » Windows-Gruppen richtig nutzen Gruß, Nils

Moin, natürlich kann es das, es muss aber nicht. Viele glauben z.B., ein Windows-Dateiserver würde bei jedem Zugriff den DC fragen, um zu prüfen, ob der User denn zugreifen darf. Tut er aber nicht, denn genau um das zu vermeiden, wurde das Prinzip der SIDs und der Zugriffstoken entwickelt. Dass es Dienste gibt, die das anders machen, steht außer Frage. Das wird aber oft stark überschätzt. Gruß, Nils

Moin, und dann? Man erzeugt damit eine Unmenge Daten. Die Energie, die man zur Auswertung benötigt, sollte man dann doch lieber in eine Überprüfung und Dokumentation der Konfig stecken ... zumal fraglich ist, ob einem die Daten überhaupt was bringen. Ich rate entschieden davon ab, in der genannten Situation irgendwas am AD oder den vorgelagerten Diensten zu verändern. Erfahrungsgemäß führt sowas hinterher nur zu Problemen. Gruß, Nils

Moin, selbst wenn du User berechtigst, heißt das noch lange nicht, dass das betreffende Gerät den DC fragt. Aber das wäre jetzt Haarspalterei. Du wirst schlicht nicht drumrumkommen, deine kritischen Dienste zu prüfen, ob sie Abhängigkeiten haben. Für alles, was nicht in die Kategorie "kritisch" fällt, musst du eben nach der Umstellung bei Problemen Nacharbeit einplanen. Gruß, Nils

Moin, das wird dir nicht viel bringen. Da Anfragen an AD automatisch verteilt werden, wirst du mit größter Sicherheit viele Anfragen feststellen - bei denen fragt der Client halt "irgendeinen" DC der Domäne. Du kannst daran aber nicht unterscheiden, ob der Client "statisch" konfiguriert ist oder einfach einen anderen DC fragen könnte. Dasselbe gilt übrigens auch für DNS. Die Gerätschaften, die du nennst, werden übrigens kaum einen DC fragen wollen (wozu sollte ein Switch oder ein Drucker das tun?). Der sinnvollste Weg ist, die IP-Konfiguration der Clients zu überprüfen (und bei der Gelegenheit zu dokumentieren). Ja, das ist Arbeit. Gruß, Nils

Moin, man kann deine Fragen kaum beantworten, wenn man nicht weiß, wie ihr denn das Backend auf den SQL-Server "gepackt" habt. Allgemein aber: Wenn Access die Tabellen nicht direkt verwaltet, kann es seine grafischen Hilfsmittel auch nicht oder nur begrenzt einsetzen. Es muss also kein Fehler sein, wenn dir die Relationen nicht angezeigt werden. Ob sie übertragen wurden, kannst du im SQL Server Management Studio überprüfen (z.B. DB-Diagramm erzeugen). Gruß, Nils

Moin, es gibt ein Web-Interface, aber das ist nur für eingeschränkte Aufgaben da. Den vollen Funktionsumfang gibt es nur über die installierte Konsole. Gruß, Nils

Moin, Prometric Services: Testing and Assessment Gruß, Nils

Moin, Berechnungen innerhalb eines Feldes gibt es nicht. Das macht man üblicherweise in einer Abfrage oder einer View. Man kann das zwar auch per Trigger lösen, aber das ist nach der reinen RDBMS-Lehre nicht zulässig, weil es zu denormalisierten Daten führt (die Daten der Spalte ergeben sich ja direkt aus bereits vorhandenen Daten der anderen Spalten). Gruß, Nils

Moin, der Agent läuft nur auf Windows-Systemen, kann aber z.B. über SNMP auch remote andere Systeme überwachen. Gruß, Nils

Moin, was auf den Lancom-Router offenkundig zutrifft. Gruß, Nils

Moin, es werden keine Logins gespeichert. Auf den zu überwachenden Systemen laufen lokal Agenten (bzw. bei Systemen ohne Agent übernimmt ein Agent auf einem lokalen System die Überwachung), die dann die Ergebnisse an die Datenbank in der Cloud übertragen (Push-Verfahren). Die Cloud enthält keinerlei Zugangsdaten und auch keinen Ausschnitt der Produktionsdaten. Das Event-Logging bezieht sich standardmäßig auf System- und Applikationslogs, in denen normalerweise ja auch keine Login- oder Personaldaten stehen (was von der Applikation abhängt). Wie gesagt, ich verstehe den grundsätzlichen Vorbehalt, aber im konkreten Fall ist das durchaus diskutabel (sonst würde ich es ja auch nicht zur Bewertung empfehlen). Gruß, Nils

Moin, fast alle Entwickler brauchen Admin-Rechte, weil die meisten Windows-IDEs nicht ohne laufen. Das hängt u.a. mit dem Debug-Recht zusammen, aber natürlich auch mit der Notwendigkeit, im System DLLs, COM-Vernüpfungen usw. zu verankern. Gruß, Nils

Moin, das kann ich im Grundsatz verstehen, aber hier geht es ja weder um personenbezogene noch um direkt sicherheitsrelevante Informationen, sondern um Monitoring-Daten. (Das nur zur Einordnung.) Gruß, Nils

Moin, du hast gerade einen der Gründe benannt, warum man ein Entwickler-Netz vom Produktionsnetz trennen sollte. Gruß, Nils

Moin, natürlich. Ein generischer Fehler der Art "kann Dienst XY nicht starten" kann selbstverständlich durch Platten- bzw. IO-Probleme verursacht werden. Für das AD ist das folgenlos, das interessiert sich dafür nicht. Ich würde der Maschine aber nicht trauen, wenn sie mal eben Daten zerstört hat. Das liegt mit Sicherheit nicht am AD, sodass das Problem durch das Entfernen des AD auch nicht verschwinden wird. Gruß, Nils

Moin, ein Rollback kannst du nur für offene Transaktionen ausführen, nicht für abgeschlossene. Geht hier also nicht. Du hast zwei Möglichkeiten: 1. Letztes Backup wieder einspielen und damit die Original-DB ersetzen. 2. Letztes Backup in eine neue DB einspielen (Restore unter anderem Namen), dann per INSERT-SELECT die Daten der Tabelle aus der Restore-DB in die Original-DB übertragen. Geht natürlich nur, wenn keine referenzielle Integrität das verhindert. Gruß, Nils

Moin, für mich klingt das nach einem Hardwarefehler. Die Logik des AD kann nicht die Ursache für das Problem sein, also muss sie im lokalen Betriebssystem oder in der Hardware liegen. Aus dem Grund würde ich nicht den "harten Weg" nehmen, sondern die HW prüfen und den Server neu aufsetzen. Die DC-Metadaten sollte man natürlich auf jeden Fall bereinigen. Gruß, Nils

Moin, das wäre Punkt 1, den man ändern sollte. Erfordert ggf. Umkonfiguration im SAN und in den Speicherpfaden der DB, aber nicht in der Datenbanklogik. Da fehlt zwischen "dass das" und "die Vorgaben" aber ein "nicht", oder? Nein. Der Host hat auch selbst was zu tun und braucht dafür CPU-Leistung. Das ist bei allen Virtualisierern so (wie sollte es auch anders sein?), bei Hyper-V und Verwandten aber besonders. faq-o-matic.net » Hyper-V-Sizing: Virtuelle und echte CPUs Dann gibst du der VM natürlich auch nicht mehr als vier vCPUs. Siehe obiger Artikel. Gruß, Nils

Moin, den Artikel von Ben kenne ich auch, aber aus meiner Sicht ist er erstens in sich widersprüchlich und wird zweitens von der Praxis widerlegt. Daher: faq-o-matic.net » Virtuelle DCs: Zeitprobleme vermeiden Gruß, Nils

Moin, ihr solltet solche Aktionen nicht aufs Geratewohl unternehmen. Bei SQL Server (und anderen Datenbanken) gibt es hunderte von Faktoren, die die Performance beeinflussen können. IO gehört sicher als wesentlicher Punkt dazu, ist aber längst nicht immer die Ursache für Probleme. Sind z.B. DB und Logs getrennt? Wie sieht es mit der Nutzung der TempDB aus und wo liegt die? Sind alle notwendigen Indizes vorhanden? Gibt es Sperrkonflikte oder andere Verzögerungen durch die Applikationslogik? Ist das SAN korrekt angebunden und vom LAN getrennt? ... usw. usf. Gruß, Nils