NilsK

Moin, ja: Die Benutzerkontensteuerung ist nicht deaktiviert. :) Gruß, Nils

Moin, das spricht dafür, dass die CALs deutlich teurer geworden sind ... es lag mal um die 400. Aber das nur am Rande. ;) Gruß, Nils

Moin, das sollte man einfach mal durchrechnen. Ist ja nicht weiter schwer. Es würde mich aber wundern, wenn schon bei 40 Usern der Break-Even erreicht wäre. Gruß, Nils

Moin, verstehe ich nicht ganz. Ihr kriegt keine Direktverbindung hin, aber jeder Standort kommt noch ins Internet? Warum macht ihr dann kein "richtiges" VPN? Schon als Fallbacklösung wäre das doch auch für den Normalbetrieb interessant. Mit Teamviewer würde ich da jedenfalls nicht rumbasteln, das ist dafür weder gedacht noch geeignet. Gruß, Nils

Moin, bei SQL Server gibt es zwei Modelle: Die Prozessor-Lizenzierung und die Server/CAL-Lizenzierung. In deiner Umgebunsgröße wird üblicherweise die Server/CAL-Variante eingesetzt, weil die Prozessor-Lizenzierung (quasi ein Pauschalpreis, der dann keine CALs mehr erfordert) sehr teuer ist. Die rechnet sich daher nur bei sehr großen Anwenderzahlen. Vielleicht hat dein Anbieter da was verwechselt. Auch im Server/CAL-Modell wird bei SQL Server 2014 die Anzahl der Cores berücksichtigt, aber damit sind die CALs dann noch nicht abgedeckt. Lass die das lieber noch mal prüfen und es dir schriftlich versichern. Gruß, Nils

Moin, eine Offline-Replikation gibt es nicht. Das Hochsetzen der Tombstone Lifetime würde das Problem nicht lösen, dafür bei Replikationsproblemen während des Änderungsvorgangs aber u.U. gravierende Probleme hervorrufen. Auf keinen Fall solltest du diese Änderung ausführen, wenn keine zuverlässige Verbindung vorhanden ist. Es gibt drei realistische Möglichkeiten: Du sorgst für eine stabile Verbindung der beiden DCs, bevor die Replikationspause die Tombstone Lifetime erreicht (rechtzeitig vorher!) Du nimmst den DC am entfernten Standort außer Betrieb (vom Netz nehmen und deinstallieren) und entfernst ihn aus dem AD Du tust nichts und lässt die Replikate auseinander laufen. Wenn dann irgendwann die Verbindung wieder zuverlässig funktioniert, versuchst du das AD um die Lingering Objects zu bereinigen. Achtung, das wird sehr wahrscheinlich zu Datenverlusten führen - die Änderungen auf dem entfernten DC nach Abbruch der Replikation wirst du verlieren Variante 3 ist am wenigsten erstrebenswert. Gruß, Nils

Moin, da diese Aufgabe ausgesprochen komplex ist, wirst du nach meiner Kenntnis nur Enterprise-Tools dafür finden. (Andere Schreibweise: Enter-Preis) Gruß, Nils

Moin, das Konzept leuchtet mir nicht ein. Zunächst finde ich die beiden separaten Hosts und die Replica-Funktion nicht einleuchtend. Und dann finde ich die Netzwerkanbindung etwas seltsam geplant: Zweimal 10 Gbit für iSCSI und für alles andere nur je 1 Gb ohne Redundanz? Ihr wolt also eure Hosts mit jeweils 24 Gbit in Summe ausstatten und alle VMs durch eine einzige, nicht redundante Gigabit-Leitung zwängen? Ich schlage als Alternative zum Nachdenken mal vor, die beiden 10-GbE-Adapter zu einem Team zusammenzufassen, über das ihr mit einem vSwitch alles laufen lasst. Die vier Gigabit-Adapter würde ich schon fast brachliegen lassen. Natürlich kann man dies ohne nähere Analyse nicht planen - mir geht es hier um eine deutlich anders gebaute Alternative, damit ihr euer Konzept noch mal prüft. Gruß, Nils

Moin, in dem Konstrukt hättest du keinen direkten Vorteil, wenn du die Daten-LUN direkt bei iSCSI in die VM einbindest. Zwar entfällt dadurch die VHDX-Ebene, was theoretisch ein Vorteil sein könnte. Dafür entfällt aber auch die Kontrolle des Hypervisors über die VHDX-Datei und die dazu gehörigen Optimierungen. Vor allem aber - was ich als ausschlaggebend ansehe - hast du bei einer iSCSI-Anbindung direkt in der VM immer den Nachteil, dass deine VM aus zwei (bzw. zwei "plus x") unabhängigen Elementen besteht. Die iSCSI-LUN unterliegt ja eben nicht der Kontrolle des Hypervisors, die musst du daher immer separat managen. Das stellt sich in vielen Umgebungen immer wieder als Problem dar, wenn auch nur in bestimmten Situationen. Der Performance-Nachteil der VHDX-Lösung ist in dem Szenario zu vernachlässigen. Gruß

Moin, du kannst bzw. solltest durchaus im Server-Management die richtige Uhrzeit oder eben noch besser einen verlässlichen NTP-Server setzen. Sofern dein Server-Management die Zeit an den Server weitergibt, kann es nämlich zu sehr hässlichen Effekten kommen, wenn diese Zeit nicht korrekt ist. Ein normal korrigiertes WIndows wird nämlich nach dem Booten die Zeot korrigieren, und wenn die vom Board falsch war, dann gibt es eben teils erhebliche Zeitsprünge. Das mag das AD nicht, und viele andere Komponenten auch nicht. Abschalten solltest du die Zeitsynchronisation des Betriebssystem deshalb aber nicht. Es ist dringend zu empfehlen, den Zeitabgleich flächendeckend und ausschließlich über das AD zu machen. Die Hyper-V-Zeitintegration nicht nur für die DCs abschalten, sondern für alle (!) Domänenmitglieder, damit das AD als maßgebende Quelle feststeht. Die Überlagerung mehrerer Zeitdienste sollte man unbedingt vermeiden, nicht nur in Hyper-V, sondern auch in VMware usw. (bei VMware gibt es dazu auch mittlerweile Best-Practice-Artikel, nur leider kann man da immer noch die Zeitsynchronisation mit dem Host nicht vollständig abschalten). Gruß, Nils

Moin, das ist zeitintensiv, aber gemacht haben das schon Leute. Es gibt eine ganze Reihe dynamischer und erweiterbarer Verwaltungstools. Nur da es eben zeitintensiv ist, kosten die dann meistens Geld. Gruß, Nils

Moin, naja. Sich mit nicht unterstützten Methoden aus den einzelnen Komponenten einer Applikation eine andere zusammensetzen, mag mit viel Aufwand vielleicht zum Erfolg führen. Mit einer dokumentierten und unterstützen Erweiterbarkeit hat das aber wenig zu tun. Solange es z.B. keine fest definierten, von außen ansprechbaren APIs gibt, kann sich mit einem Update was an der Funktion ändern, und schon funktionieren die Aufsätze nicht mehr. Da dürfte es dann schon sinnvoller sein, den Aufwand in die eigene Entwicklung eines Werkzeugs zu stecken, das auf definierte APIs (z. B. die schon erwähnten Webservices) zugreift. Das hat dann aber eben mit ADAC nichts mehr zu tun. Leider ist das ADAC nicht nur an dieser Stelle sehr lieblos gemacht. Gruß, Nils

Moin, interessanter Hinweis, den kannte ich noch nicht. Danke! Aber: Erstens nimmt das nur Anzeigespalten auf, zur Bearbeitung der Werte taugt es nicht. Und zweitens geht es hier auch um ADUC, der TO wollte aber eine Lösung für ADAC. Und da geht sowas nach aktuellem Kenntnisstand nicht. Gruß, Nils

Moin, wenn sie nicht angezeigt werden, sind sie vielleicht gar nicht mehr eingebunden. Kannst du die Datei evtl. einfach löschen? Gruß, Nils

Moin, wir hatten so eine ähnliche Frage hier kürzlich. Das Ergebnis war (und mir ist auch nichts anderes bekannt), dass man das ADAC nicht anpassen kann. Vielleicht wäre die Arbeit mit ADUC und folgendem Ansatz eine Möglichkeit: [Kostenstelle in AD integrieren | faq-o-matic.net] http://www.faq-o-matic.net/2007/02/27/kostenstelle-in-ad-integrieren/ Gruß, Nils

Moin, grundsätzlich kann man VMs auch im laufenden Betrieb sichern. Dazu sollte das eingesetzte Sicherungsprogramm die VSS-Schnittstelle ansprechen, und die Applikationen in den VMs sollten das auch tun. Das geht auch mit Windows Server Backup, aber Altaro und Veeam können das besser. Ich würde sowas aber nicht blind bzw. pauschal machen, sondern immer auf den Einzelfall schauen. Gruß, Nils

Moin, bitte keine Akrobatik mit Images und Dateikopien. Das sind prima Möglichkeiten, einem problematischen AD endgültig den Garaus zu machen. AD-Backup ist so einfach: Systemstate sichern, mindestens auf einem DC per Windows Server Backup. Wenn ein zusätzliches AD-kompatibles (!) Backupprogramm vorhanden ist, dann ergänzend (!) damit. Und zur Wiederherstellung: [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, wie immer, kommt es auch hier darauf an. ;) Das CPU-Überbuchungsverhältnis 1:8 war nur eine Supportgrenze, keine technische Grenze. Wenn man das überschritten hat und hatte ein Problem mit Hyper-V, konnte es sein, dass einen der MS-Support im Lauf eines Supportcalls auffordert, VMs von dem betreffenden Host wegzumigrieren. Technisch kann es sehr gut sein, dass auch bei deutlich höherer Überbuchung alles rund läuft. Umgekehrt kann es aber durchaus auch vorkommen, dass bei deutlich geringerem Verhältnis einzelne VMs nicht so laufen, wie sie sollen. Das kann etwa bei Applikationen der Fall sein, die sehr wenig Latenz vertragen. Daher gilt etwa für Exchange auch weiterhin eine Supportgrenze von 1:2 für die Hosts, auf denen Exchange-VMs laufen. Für VoIP sehen die Empfehlungen auch so aus, dass man möglichst wenig überbucht. Man kann sich sein Problem auch selbst bauen: Viele Kunden weisen pauschal allen VMs 4 vCPUs zu, auch wenn die Applikationen das nicht brauchen. Das bedeutet aber, dass jede dieser VMs nur dann versorgt werden kann, wenn gerade vier Cores gleichzeitig frei sind. Hätte der Host in einem Zyklus nur zwei Cores frei, dann kommt die VM eben nicht dran und muss noch einen Zyklus warten (vereinfacht ausgedrückt). [Hyper-V-Sizing: Virtuelle und echte CPUs | faq-o-matic.net] http://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/ [Virtuelle CPUs in Hyper-V: Ein Überblick | faq-o-matic.net] http://www.faq-o-matic.net/2014/10/01/virtuelle-cpus-in-hyper-v-ein-berblick/ Was heißt denn "Probleme bei der Performance"? Gibt es Hinweise darauf, dass tatsächlich die CPUs das Problem sind? Gruß, Nils

Moin, die Verzeichnisdienstwiederherstellung macht auch nichts. Sie stellt den Verzeichnsdienst nicht wieder her. Es handelt sich um einen Betriebsmodus, in dem man manuell das AD reparieren kann. Wenn du tatsächlich noch einen funktionierenden DC hast, ist es wahrscheinlich die beste Variante, den kaputten DC abzuschreiben, aus dem AD zu entfernen und neu zu installieren. Gruß, Nils

Moin, dazu gibt es eine simple Antwort: Das kommt darauf an. :D Und zwar auf die Anforderungen. Generell gilt, dass es zwei typische Engpässe in Hostsystemen gibt: RAM und Disk-IO. Was man aber "braucht", kann ohne genaue Kenntnis des Einzelfalls nicht gesagt werden. Und das ist wieder eine Sache, für die ein Forum nun mal nicht geeignet ist. Dieser umfangreiche Blogpost spiegelt eine sehr pragmatische Grundhaltung zu solchen Fragen: [42 Best Practices for Balanced Hyper-V Systems] http://www.altaro.com/hyper-v/42-best-practices-balanced-hyper-v-systems/ Für die konkrete Frage nach der Blockgröße noch die Anmerkung: In den allermeisten Umgebungen spielt das keine Rolle. Gruß, Nils

Moin, die Lösung ist dann nicht Unsinn, wenn sie zu den Anforderungen passt. Unsinn ist es, eine "Lösung" vorzuschlagen, bevor die Anforderungen geklärt sind. Darüber hinaus finde ich, dass wir hier den Bereich verlassen, in dem ein Forum sinnvoll etwas beitragen kann. Ein Forum ist gut für technische Hilfestellung. Designfragen sind dort i.d.R. prinzipbedingt nicht gut zu diskutieren. Gruß, Nils

Moin, grundsätzlich liegt der Fehler im System hier natürlich nicht bei Microsoft, sondern bei dem Hersteller der Applikationen bzw. bei der Art, wie sie genutzt werden. Software der Art, wie du sie beschreibst, sollte als Dienst laufen und nicht in einer interaktiven User-Session. Dann würde sich das ganze Problem gar nicht stellen. Spontan käme mir bei deinem Szenario aber Fast User Switching in den Sinn, d.h. das Bedienpersonal nutzt nicht die bestehende Session, sondern öffnet sich eigene parallel. Das sollte auch mit Smartcards funktionieren. Konkrete Erfahrungen habe ich damit aber nicht. Gruß, Nils

Moin, ich will niemandem zu nahe treten, aber hat dein Systemhaus nicht vorher mit dir die Anforderungen besprochen und dann die Möglichkeiten und Grenzen mit dir abgestimmt? Das gehört zu einem Lösungsvorschlag doch irgendwie dazu. Ohne ist es nur ein Vorschlag, aber kann keine Lösung sein. Gruß, Nils

Moin, ist schon OK, man kann ja nur einen Beitrag als Lösung markieren. :) Wichtig ist ja, dass es wieder geht, und die Rückmeldung ist prima für die Tippgeber und für alle, die das auch mal lesen. Gruß, Nils

Moin, zu dem Phänomen kann ich nichts sagen - aber dein Ansatz erscheint mir seltsam. Warum soll ein Hardlink ein versehentliches Löschen verhindern? Gruß, Nils