NilsK

Moin, nö. Wenn der Host ausfällt, auf dem die VM läuft, kann ja niemand mehr eine Quick Migration einleiten. Die VM ist dann aus (crash-consistent) und wird vom Cluster auf einem anderen Host neu gestartet. Der RAM-Inhalt und alle Sessions sind dann weg. Das macht jeder Failovercluster so, auch VMware HA. Fault Tolerance geht in Hyper-V nur mit Zusatzprodukten. In der Praxis wird das aber kaum gemacht - auch unter VMware nicht, weil die Szenarien meist dann doch nicht recht passen. Für eine Webserver-Farm wäre FT auch in der Regel Quatsch, denn Webserver sind in den allermeisten Designs zustandslos. Fällt einer aus, wird ein anderer genommen, die Daten kommen (wie oben schon richtig erwähnt wurde) aus dem Backend. Das wiederum kann man mit HA absichern, wobei es da heute zahlreiche Möglichkeiten gibt, mit denen die Applikation (also die Datenbank) praktisch unterbrechungsfrei bleibt. Gruß, Nils

Moin, auf keinen Fall macht der Host auch DC. Never-ever. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Der DC kommt in eine VM. Der Host ist nur Host. Und auch in einer kleinen Umgebung würde ich den DC von anderen Anwendungen trennen, besonders vom SQL Server. Bedeutet also minimal drei VMs, also zwei Standard-Lizenzen. Da du damit dann vier VMs betreibe kannst, würde ich auch noch SQL und Dateiserver trennen. Mit den zwei Platten wirst du ebenso wenig Freude haben wie mit vier Platten im RAID-5. Vermutlich wird das Plattensystem nach der Umstellung auf 4-HDD-RAID-5 sogar noch langsamer. Dein RAID-1 gibt dir effektiv weniger IOPS als eine Einzelplatte, und das ist bei 7,2 K schon sehr wenig. Gruß, Nils

Moin, ernsthaft jetzt? Ihr betreibt euer ERP auf SQL Express? Na, dann können wir uns ja jeden weiteren Aufwand sparen. Dir ist schon klar, dass SQL Express absichtlich Leistungsgrenzen eingebaut hat, weil Microsoft schließlich mit seiner Datenbank Geld verdienen will? Und dass es dafür keinen Support gibt - du im Fall des Falles also vielleicht einen freundlichen Gruß am anderen Ende der Leitung hörst, möglicherweise aber sogar schallendes Gelächter? Ja, das solltest du ändern. Gruß, Nils

Moin, wobei ich mich auch immer noch frage, warum in der IT alle so auf Unterstriche abfahren. Das hab ich noch nie verstanden. Gruß, Nils

Moin, kannst du bitte nächstes Mal den Fehler als Text angeben und nicht als Screenshot? Per Strg-C solltest du solche Meldungen in die Zwischenablage bekommen. Dann muss man den Link nicht abtippen. Hilft zwar in diesem Fall nicht, weil es die Webseite noch nicht gibt, aber in der Zukunft bitte beachten. Dein Server hat einen ungültigen Namen, weil er einen Unterstrich enthält. Das geht allerdings aus der Fehlermeldung auch schon hervor. Der Unterstricht ist in DNS kein gültiges Zeichen und darf nur bei SRV-Records eingesetzt werden. Gruß, Nils

Moin, hm, komisch. Dann funktioniert der Editor vom Smartphone aus wohl nicht so besonders. Gemeint war dies: [Die AD-DNS-Zone sicher konfigurieren | faq-o-matic.net] http://www.faq-o-matic.net/2015/04/08/die-ad-dns-zone-sicher-konfigurieren/ Ja, wenn du das Konto dort entfernst, sollte der "Normalzustand" wiederhergestellt sein. Besser ist es aber, dort ein Domänenkonto einzutragen, das extra für den Zweck gedacht ist. Normales Konto, keine Adminrechte, komplexes Kennwort. Gruß, Nils EDIT: Ich kann in meiner Antwort von vorhin den Link sehen, und er funktioniert auch. Vielleicht hattest du zu früh nachgesehen, ich habe ihn eine Minute später nachgetragen, weil das Telefon nicht so wollte wie ich.

Moin, Unabhängig vom Kennwort stehen dort immer Sternchen. Kein Konto = kein Kennwort. Siehe dazu auch: http://www.faq-o-matic.net/2015/04/08/die-ad-dns-zone-sicher-konfigurieren/ Gruß, Nils

Moin, die Klammeraffen sind Variablen. Die werden wohl weiter oben im Code definiert. Hast du schon mal den Indexerstellungs-Assistenten laufen lassen (oder wie der heißt)? Abfragen dieser Art sollten sich durch die passenden Indizes beschleunigen lassen. Sofern die passenden Indizes existieren, könnte auch eine Indexoptimierung helfen. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Trotzdem solltest du das im Auge behalten. Irgendwo muss es ja herkommen, dass die eine Stelle Erfolg meldet und die andere Fehler; normal ist das nicht. Nicht auszuschließen, dass da noch irgendwo was lauert. Hier noch ein paar Ergänzungen zum SQL-Backup: http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, wichtiger ist doch die Frage, warum https.sys überhaupt läuft. Offenbar hast du also Dienste eingerichtet, die den Mini-Webserver einsetzen. In deiner Dienstliste fällt mir dabei WinRM ins Auge - ich weiß nicht sicher, ob der http.sys auf Port 80 verwendet, aber allein dass du diesen Dienst auf einem Server aktiv hast, der im Web erreichbar sein soll, zeigt, dass die Kollegen hier mit ihren Warnungen recht haben. Das ist nicht off topic - das sind wichtige Warnungen. Einen vom Web aus erreichbaren Server musst du so konfigurieren, dass er kein Sicherheitsrisiko darstellt. Deine Konfiguration ist dazu nicht geeignet. Die Komponenten- und Diensteliste passt hinten und vorne nicht zu so einem System. Gruß, Nils

Moin, kamen Fehler zurück? Hast du die PowerShell als Admin aufgerufen? Was gibt Get-ClusterGroup jetzt aus? Vielleicht nur F5 im Failovercluster-Manager drücken? Gruß, Nils

Moin, so geht's für Windows 7: [Creating a Mandatory User Profile] https://technet.microsoft.com/de-de/library/gg241183%28v=ws.10%29.aspx Aber sei dir bewusst, dass solche schreibgeschützten Profile erhebliche Nachteile haben. Mach dich auf Datenverluste bei deinen Usern gefasst. Gruß, Nils

Moin, und das Entfernen der ClusterGroup per PowerShell funktioniert auch nicht? Gruß, Nils

Moin, aber du kannst dich jetzt anmelden? Acht Wochen wären wahrscheinlich noch kein Problem, das tritt erst ab 60 Tagen auf. Prüfe die Netzwerkkonfiguration und korrigiere sie bei Bedarf. Falls du die Maschine nicht wieder online kriegst, sichere die Daten, entferne den DC und sein Konto aus dem AD, mach ihn platt und installiere ihn neu. Gruß, Nils

Moin, per PowerShell entfernen: Get-ClusterGroup -> dort den Namen der zugehörigen Gruppe ablesen Remove-ClusterGroup 'Name-der-Gruppe' Danach die VM aus Hyper-V löschen. Gruß, Nils

Moin, das Problem wird sein, dass dein Router per DHCPv6 sich selbst als DNS-Server angibt. Über deine AD-Domäne kann er aber schlechterdings nichts sagen. Die allgemeinen Regeln für DNS im Zusammenhang mit AD gelten natürlich auch mit IPv6: Alle Clients nutzen nur die DCs als DNS-Server. Wenn man IPv6 nutzen will, muss man das auf der Ebene dann auch richtig konfigurieren. Da IPv6 im LAN für die meisten Netzwerke nur wenige handfeste Vorteile bringt, hat es sich dort noch nicht durchgesetzt. Daher gibt es dazu wenige Erfahrungen und wenige Anleitungen. Gruß, Nils

Moin, starte in den abgesicherten Modus und schau ins Eventlog. Gruß, Nils

Moin, bei 1,4 GB brauchst du erst recht kein Diff-Backup. Das ist für sehr große Datenbanken gedacht, bei denen man nicht täglich ein Full Backup machen kann. Heutztage dürfte sowas erst im höheren dreistelligen GB-Bereich beginnen. Und ein Log-Backup brauchst du nur, falls die Auflösung "1 Tag" beim Restore nicht reicht - bei Admin-Datenbanken würde mich das sehr wundern. Eigentlich sollte das natürlich unabhängig davon funktionieren. Aber die Fehlermeldung bezieht sich auf eine nicht vorhandene Sicherung, das müssen wir jetzt erst mal eingrenzen. Gruß, Nils

Moin, das interne Netzwerk hat mit IPv6 am externen Router-Interface erst mal nichts zu tun. Wenn dein Router nach innen kein IPv6 sprechen soll, wird man ihm das bestimmt sagen können. Parallel hatten wir die Tage gerade einen Thread, wo die Fritzbox "versehentlich" DHCPv6 nach innen gemacht hat. Wer ist denn bei deinen Clients als DNS-Server eingetragen? Das sollte der DC sein. Dass bei nslookup als Servername "unknown" steht, ist ganz normal, wenn der Server nicht selbst in der Reverse-Lookup-Zone eingetragen ist. Gruß, Nils

Moin, und wegen einer 14-GB-Datenbank machst du ein differenzielles Backup?! Da reicht Full + Log doch völlig aus, das macht beim Recovery viel weniger Umstände. Vermutlich brauchst du nicht mal ein Log-Backup - aber die Anforderungen wirst du besser kennen als ich. Schalt das Diff-Backup mal ab und guck, ob es dann geht. Die Fehlermeldung nimmt Bezug darauf, dass kein aktuelles Datenbank-Backup vorliege - und ohne nun mal kein Log-Backup. Die Option (Recovery Model) "Full" bzw. "Vollständig" ist gesetzt bei den Datenbanken? Gruß, Nils

Moin, möglicherweise ist das ein Grund, den SCVMM einzusetzen. Der ermöglicht für sowas eine recht komfortable Steuerung. Auf der Ebene von Hyper-V dürfte immer noch AzMan das nötige Werkzeug sein. Ist nicht komfortabel, aber geht. [How to delegate access in Hyper-VITPROCentral.com] http://itprocentral.com/how-to-delegate-access-in-hyper-v/ Gruß, Nils

Moin, die "enormen Kosten" fallen aber schon mit dem Betrieb des einen neuen DC an. Dann braucht der Kunde nämlich auch die passenden CALs. Die 500 Euro für eine weitere Serverlizenz dürften danach kaum noch ins Gewicht fallen. Gruß, Nils

Moin, man könnte auch das RAID auflösen - es gibt ja schon zwei identische Kopien der Platte. Lauter Möglichkeiten. Und keine davon ändert was an dem Problem und an der Tatsache, dass der Notfall hier gut geplant sein sollte. :p Gruß, Nils

Moin, Lizenzverträge und -bedingungen orientieren sich im allgemeinen nur selten daran, wie ein Kunde sie auslegt. Gruß, Nils

Moin, dem Log nach zu urteilen, ist das letzte Backup - wohl das differenzielle - fehlgeschlagen. Wie groß sind denn die Datenbanken? Brauchst du überhaupt ein dreistufiges Backup? Vielleicht reicht Full + Log ja auch aus. Gruß, Nils