NilsK

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

Moin, ja, das ist möglich. Gruß, Nils

Moin, die Vorgaben sind ja sehr generisch und überschreiten nach meiner Ansicht den Aufgabenbereich eines Datenschutzbeauftragten. Es besteht keine Verpflichtung, eine bestimmte Firewall einzusetzen. Insbesondere gibt es in Wirklichkeit keine "Hardwarefirewall", weil jede Firewall aus Software besteht. Ich würde zwar auch keine Lancom-Firewall empfehlen, aber man trifft sowas im Feld durchaus an. Das würde ich also im Zusammenhang mit den konkreten Anforderungen bewerten. Zur Notebook-Verschlüsselung eignet sich Windows Bitlocker (wenn Hardware und passende Lizenz vorhanden) oder als kostenlose Lösung Truecrypt. Darüber hinaus gibt es noch zahlreiche kommerzielle Produkte. Beim Virenschutz kann man heute eigentlich jedes Unternehmensprodukt nehmen, viel nehmen sich die alle nicht. Lasst euch von einem kompetenten Dienstleister etwas empfehlen, der bei Bedarf auch den Support leisten kann. Der Hinweis mit dem Schwachstellenscanner ist wahrscheinlich eher ein Textbaustein. Da kann man vieles machen, aber meiner Erfahrung nach ist das bei vielen Unternehmen eher der zweite oder dritte Schritt, weil dort schon die Grundlagen nicht in Ordnung sind (Kennwortsicherheit, Systemkonfiguration, Adminrechte, Updates ...). Als kostenloses Produkt verdient der MBSA einen Blick. Wichtig sind ja vor allem Windows-Updates. Für Applikationen ist auch der Secunia PSI interessant. Auch auf Serverseite lohnt sich ein Schwachstellenscanner frühestens dann, wenn Update-Stand und Konfiguration auf aktuellem Stand sind. Gruß, Nils

Moin, du weißt, dass bei Basic Auth das Kennwort im Klartext über das Netz geht? Gruß, Nils

Moin, eigentlich ist GFI Max für dein Szenario gut geeignet. Die Cloud-Integration macht das Monitoring darüber hinaus unabhängig von deiner Infrastruktur. Was spräche dagegen? Gruß, Nils

Moin, hier wäre jetzt die genaue Fehlermeldung und der relevante Ausschnitt aus dem Code hilfreich ... Gruß, Nils

Moin, wenn ich nicht ganz falsch liege, ist der Fehler 80005000 "An invalid ADSI pathname was passed". Vermutlich sind Sonderzeichen im Namen des Users, die dein Skript nicht maskiert. Lass dir nach der Zeile "strUser = objSysInfo.UserName" mal den Inhalt von strUser ausgeben, das sollte dich auf die Spur bringen. Gruß, Nils