NilsK

Moin, schon aus Gründen der Handhabung würde man das wohl eigentlich nacheinander machen wollen. Du kannst dir aber auch ein T-SQL-Skript bauen, das alle RESTORE-DATABASE-Befehle nacheinander ausführt. Wobei du die master ohnehin separat einspielen musst. model wird man nicht zurückspielen wollen. Gruß, Nils

Moin, dafür brauchst du gar nicht alle Eigenschaften anzufordern, und statt Select-Object nutzt du eine Ausgabefunktion, am besten Format-Table ohne Headers. Get-ADUser "don" | Format-Table Name -HideTableHeaders Gruß, Nils

Moin, nö. Das sind alles Workarounds, die dem von mir genannten Netzwerkzugriff entsprechen. Eine "Transfer Disk" wie bei 5Nine kann man auch manuell anlegen, der Komfortvorteil des Werkzeugs ist da gering. Das Risiko besteht immer in Datenkorruption, wenn man das An- und Abkoppeln nicht richtig macht. Der Zugriff per RDP entspricht ebenfalls dem Netzwerkzugriff, den ich meinte. Die Gastdienste erlauben nur das Kopieren in einer Richtung (vom Host in die VM) und nur per PowerShell. Geht alles, entspricht aber nicht der Integration, wie man sie in VMware Workstation oder in einer klassischen RDP-Sitzung hat. Das ist auch nicht gewollt, weil es in einem ernsthaften Servervirtualisierungs-Szenario ein Sicherheitsproblem wäre. Gruß, Nils

Moin, von einer VM kommst du nie auf Ressourcen des Hosts. Hyper-V ist anders als VMware Workstation. Du müsstest also die Host-Laufwerke freigeben und übers Netzwerk ansprechen. Gruß, Nils

Moin, ich meinte Doso. Der Hinweis kam mir bekannt vor. :) Gruß, Nils

Moin, hm. Hab ich so noch nicht gesehen, und eine richtige Idee habe ich dazu auch nicht. Da du ja anscheinend die Konfig im Zuge dieser Diskussion überarbeitet hast: Hast du die Nodes schon mal neu gestartet? Das wäre dann noch einen Versuch wert. Sonst fällt mir dazu leider jetzt nichts ein. Gruß, Nils

Moin, hm, heute in Bad Homburg gewesen? ;) Gruß, Nils

Moin, du kannst im "Rest" des Betriebssystems normal auf die genannte Disk zugreifen? Lesend und schreibend? Gibt es Unterschiede in der Anbindung zwischen der DB-Disk und der Backup-Disk? Ist die Backup-Disk auf dem Storage clusterfähig eingerichtet? Ist die Backup-Disk auf beiden Nodes identisch eingebunden? Habe ich es richtig verstanden, dass es sich um physische Cluster-Server handelt, oder sind es VMs? Gruß, Nils

Moin, danke für den unglaublich durchdachten und wirklich sachlichen Kommentar. Die Fehlermeldung gibt an, dass Berechtigungen fehlen oder aus anderem Grund kein Zugriff auf den gewählen Pfad möglich ist. Das ist bei einer SAN-Anbindung ungewöhnlich, weil dort ja auf der Systemebene der Zugriff bestehen sollte. Aus dem Grund habe ich gefragt, ob es wirklich um eine SAN-Anbindung geht oder um ein gemapptes SMB-Laufwerk (also NAS). In letzterem Fall besteht das Mapping ja immer für ein bestimmtes Userkonto, da wäre so eine Fehlermeldung dann wieder leicht erklärbar. Also, bitte noch mal der Reihe nach: Wie genau sind die Laufwerke eingebunden und konfiguriert? Sind für die eingebundenen Laufwerke Berechtigungen eingeschränkt? Wenn ja, wie genau? Mit welchem Konto läuft der SQL Server? Wo liegt die Datenbank? Wo soll das Backup liegen? Tritt der Fehler beim Sichern auf? Beim Wiederherstellungsversuch? Oder in beiden Fällen? Welche Aktion genau wird durchgeführt? Wie lautet exakt die Fehlermeldung? Gruß, Nils

Moin, also, zur Ehrenrettung des TO: Momentan hat das Board offenkundig ein technisches Problem, die Zeilenumbrüche beizubehalten. Zum Thema: Hier schlägt die UAC zu. Wenn es um Berechtigungsverwaltung oder um Dateiverwaltung mit professionellem Anspruch geht, solltest du das nicht mit dem Explorer machen. Ausgerechnet der kann nämlich (als nahezu einziges Programm) nicht richtig mit der UAC umgehen. Nimm in solchen Fällen einen anderen Dateimanager, der mit UAC richtig arbeitet (viele schwören auf Total Commander, es gibt aber auch zahlreiche andere). Und für die Berechtigungsverwaltung empfehle ich SetACL von Helge Klein. Gruß, Nils

Moin, ohne stänkern zu wollen: Wenn schon ein Auditor die Kennwortlänge anmahnt, dann ist sie meist viel zu kurz für aktuelle Ansprüche. Als "sicher" gelten heute keine 8-Zeichen-Kennwörter mehr. Um Brute-Force-Angriffe statistisch wirkungslos zu machen (also den zeitlichen Aufwand in eine Höhe zu treiben, die den Versuch aussichtslos macht), müssen Kennworter eine deutlich zweistellige Länge haben. Nicht umsonst predige ich seit über zehn Jahren die Verwendung von Kennwortsätzen: Kann man sich gut merken, kann man gut blind tippen und man erreicht leicht mehr als 20 Zeichen. Ja, so eine Länge sollte es für relevante Konten schon sein. Gruß, Nils

Moin, grundsätzlich ist die Konfiguration bezüglich des Ablaufs richtig. Aber: Das ist nicht die "Default Domain Policy". Es ist ein GPO namens "Default Domain Policy 2004". Gibt es das originale Objekt noch? Wenn ja, dann hat dies vermutlich Priorität. Auf jeden Fall sollte man die Kennworteinstellungen ausschließlich in der originalen DefDomPol machen und in keiner anderen. Der Grund dafür ist hier beschrieben: [besonderheiten der AD-Kennwortrichtlinie | faq-o-matic.net] http://www.faq-o-matic.net/2010/06/24/besonderheiten-der-ad-kennwortrichtlinie/ Du kannst die effektiven Policies im CMD-Fenster mit folgendem Kommando prüfen: net accounts /domain Die Komplexitätsanforderung würde ich nicht abschalten. Ihr fordert eine Kennworthistorie von 7 an, lasst aber sofortige Änderung zu (0 Tage). Damit kann ein User einfach direkt hintereinander siebenmal sein Kennwort ändern und wieder das alte nutzen. Kennworthistorie ist nur sinnvoll mit einem minimalen Kennwortalter von einem Tag. 3 Versuche falscher Kennwörter bis zur Sperrung ist nicht gut. http://www.gruppenrichtlinien.de/artikel/kontosperrungsschwelle-auf-50-definieren-warum/ Insgesamt betrachtet, ist die automatische Kontensperrung sowieso nicht gut: [DOS-Angriff für jedermann: AD-Konten sperren | faq-o-matic.net] http://www.faq-o-matic.net/2013/08/07/dos-angriff-fr-jedermann-ad-konten-sperren/ Zur Not könntest du bei den Anwendern, deren Kennwort "zu alt" ist, den Haken "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" setzen. Das lässt sich auch per PowerShell für mehrere Konten machen. Eigentlich sollte das neue Kennwortalter aber gelten; wie gesagt, prüf es mal. Gruß, Nils

Moin, dann aber bitte vollständig und nicht den nächsten, entscheidenden Satz unterschlagen: "Microsoft gewährt in diesem Zusammenhang nur Unterstützung in angemessenem Rahmen." Das bedeutet, dass Microsoft nicht dafür geradestehen kann, wenn die Treiber auf der Zielplattform nicht so wollen oder wenn Treiber so tief ins System integriert sind, dass man sie nur mit viel Aufwand ausgetauscht kriegt. Microsoft gewährt dann "Best effort"-Support, kann aber ggf. nicht in jedem Fall bis zum Ende supporten (einfach weil in solchen Situationen Drittanbieter im Boot sind). Es bedeutet eben nicht, dass Microsoft den Support für die Methode als solche verweigert! (Sonst gäbe es ja schließlich den Artikel nicht ...) Man sollte schon fair bleiben. Im Übrigen hat in diesem Thread auch niemand gefordert, dass der physische DC derjenige sein müsse, auf dem das Systemstate-Backup läuft. Ganz im Gegenteil, wurde hier deutlich und mehrfach darauf hingewiesen, dass es von Vorteil ist, das Backup (und das Recovery) auf Basis von VMs zu machen. Aber das spricht ja nicht gegen die Argumente, die einen physischen (bzw. separat betriebenen) DC sinnvoll machen. Und jetzt sollte endlich mal Schluss sein, es ist alles gesagt. Mittlerweile auch praktisch von jedem. Gruß, Nils

Moin, nein, ich spreche von deiner Behauptung, dass Microsoft das WIederherstellen des Systemstate auf anderer Hardware nicht unterstützen würde. Diese Aussage ist falsch, was ja auch der von dir angeführte Link belegt. Zu deiner erneut gestellten Frage ist mittlerweile alles gesagt worden, was es sinnvoll auf dieser Ebene dazu zu sagen gibt. Teilweise mehrfach. Du musst es ja nicht befolgen. Gruß, Nils

Moin, das ist falsch. Oder es wäre mir neu - was mich nach über 15 Jahren AD überraschen würde. Hast du Belege für diese Aussage? "Für nichts" trifft es ganz gut. Man sollte hinzufügen: Snapshots (oder Images) von DCs sind eine Methode, die sehr schnell dem AD gravierende Schäden zufügt. Die Argumente sind in diesem Board ja schon sehr oft gebracht worden. Hier noch mal eine übersicht: [Warum Images nicht als Datensicherung taugen | faq-o-matic.net] http://www.faq-o-matic.net/2006/08/04/warum-images-nicht-als-datensicherung-taugen/ In diesem Video zeige ich das auch, etwa ab Minute 38. [Active Directory – "Tu mir das nicht an", sagte der Domänencontroller | Techday@ice:2011] http://technet.microsoft.com/de-de/edge/active-directory-tu-mir-das-nicht-an-sagte-der-domanencontroller Gruß, Nils

Moin, also, bitte mal langsam. Hier gehen dann doch ein paar Dinge durcheinander. Es spricht nichts dagegen, DCs als VM zu betreiben. Wenn man DCs virtuell betreibt, sollte man ein paar Sachen bleiben lassen. Snapshots gehören immer noch dazu, auch mit Windows Server 2012. Windows Server 2012 und VM-Generation-ID schaffen das Risiko von Fehlern nicht aus der Welt. Auch mit VM-Generation-ID sind Snapshots zum DC-Recovery nicht empfohlen. VM-Snapshots sind für die meisten Applikationen nicht unterstützt. VM-Snapshots sind in der Regel nicht als Recovery-Methode geeignet. Es gibt mehr als nur einen Grund, einen DC pro Domäne physisch zu betreiben, mindestens aber außerhalb der "zentralen" Virtualisierungsumgebung. Man sollte mehr als nur ein Backup von einer Domäne haben. Es ist von Vorteil, (mindestens) ein Systemstate Backup auf einer VM zu erzeugen. Es ist durchaus möglich, den Systemstate eines physischen DC auf einem anderen Server wiederherzustellen, meist aber deutlich aufwändiger als einen VM-Systemstate auf einer anderen, gleichartigen VM wiederherzustellen. Windows-Clusterserver müssen Mitglied einer Domäne sein. Sofern die Clusterserver als Domänenmitglieder ordentlich laufen und nach der vollständigen Einrichtung sich an die Domäne erfolgreich angemeldet haben, brauchen sie bei späteren Neustarts nicht zwingend Kontakt zu einem DC. Sie kommen aber auch weiter nicht dauerhaft ohne Domäne aus. Es ist technisch nicht nötig, Hyper-V-Hostserver in eine Domäne aufzunehmen. Es ist in den meisten Situationen aber mit vielen Vorteilen für Betrieb und Verwaltung verbunden. Hyper-V-Hostserver müssen nicht in derselben Domäne sein wie die VMs, die auf ihnen laufen. Auch Virtualisierungsumgebungen, die nicht unter Hyper-V laufen, haben in der Praxis meist faktische Abhängigkeiten zum AD bzw. den Komponenten des AD, was einer der Gründe für mindestens einen phyisischen bzw. mindestens "separaten" DC ist. Und um zum Thread zurückzukehren: In Umgebungen mit mehr als ca. 10 Benutzern ist es dringend anzuraten, mehr als einen DC pro Domäne zu betreiben. Anderenfalls kann der Ausfall eines "einzigen" DCs unangemessen hohen Aufwand nach sich ziehen. Auch bei knappen Budgets ist ein zusätzlicher DC nicht unerschwinglich. Man kann ihn durchaus sinnvoll für einen Betrag von 1000 Euro inkl. Lizenz bekommen, wobei 1500 Euro i.d.R. schon ein wirklich brauchbares System ergeben. So. Gruß, Nils

Moin, "Tiered Storage" oder "Storage Tiering" bezeichnet i.d.R. zunächst mal nur, dass es verschiedene Speicherklassen gibt. Wodurch sich diese unterscheiden, ist damit erst mal noch nicht festgelegt. Ein automatisiertes Management auf Basis logischer Kriterien ist mit dem Begriff meistens nicht gemeint. Das ist keine Besonderheit von Microsoft. Die logische Ebene - nach welchen Kriterien verteile ich wie meine Daten auf die "Tiers" - wird durch separate Management- oder Software-Schichten bereitgestellt. Man sollte an der Stelle auch die Kirche im Dorf lassen. Microsoft kann in einem Allzweck-Betriebssystem nicht alle möglichen High-End-Features zur Verfügung stellen. Dadurch wäre das Betriebssystem schnell unbrauchbar. Vor allem aber würde Microsoft damit Dritten - unter anderem seinen eigenen Partnern - das Geschäftsmodell zerstören. Gruß, Nils

Moin, Pass-through Disks verwendet man eigentlich gar nicht (mehr). Sie sind nur noch in sehr seltenen Funktionen Fällen von Vorteil (etwa wenn das SAN besondere Features bietet, die sich sonst nicht nutzen lassen). Peformance ist jedenfalls in praktisch allen Situationen kein Grund (mehr). Dafür haben Pass-through Disks einige Nachteile, die dagegen sprechen. So sind Cluster-Failover, Live Migrations, Snapshots, Backups usw. je nach Situation damit eingeschränkt. Die Handhabung dieser Disks ist auch noch mal besonders, man braucht also eigene Schritte dafür. Und noch weitere Argumente dieser Art. Gruß, Nils EDIT: Oben war das Wort "Funktionen" falsch.

Moin, was du (vermutlich) suchst, nennt man auch "Hierarchical Storage Management". Das kann Windows nicht von selbst, und es hat auch weder mit Storage Spaces noch mit Storage Tiering (in der Windows-Lesart) zu tun. Gruß, Nils

Moin, weiter oben wurde schon die entscheidende Frage gestellt, auf die aber noch die Antwort fehlt: Was soll denn eigentlich erreicht werden? Gruß, Nils

Moin, da sind wir uns einig. ;) Gruß, Nils

Moin, es gibt keine Nur-SQL-Authentisierung. Die Windows-Authentisierung ist immer möglich. Gruß, Nils

Moin, was steht denn zu dem Anmeldefehler im SQL-Fehlerlog? http://technet.microsoft.com/de-de/library/ms366351%28v=SQL.105%29.aspx Wenn du im CMD-Fenster whoami /groups eingibst, taucht dann in der Ausgabe deine DB-Admin-Gruppe auf? Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

Moin, ja, gut, aber wenn die VMs alle auf demselben Host laufen, dann brauchen sie dafür ja überhaupt keinen Netzwerkkontakt. Dann richtest du in Hyper-V einen "privaten" vSwitch ein und konfigurierst die virtuellen Netzwerkkarten der VMs so, dass sie auf diesen vSwitch zugreifen. Der ganze Traffic bleibt dann host-intern und kommt nie an der physischen Netzwerkkarte an. Wenn jeder Azubi seine eigenen VMs haben soll, die von den anderen separiert sind, bekommt jeder Azubi einen eigenen privaten vSwitch, an den dann seine VMs angeschlossen sind. VLANs benötigst du dann nicht. Der Zugriff auf die VMs durch die Azubis erfolgt dann über vmconnect.exe von ihren jeweiligen Clients aus, die nur eine Netzwerkverbindung zum Host brauchen. Gruß, Nils