NilsK

Moin, nein, so lang ist nicht normal. Aber so aus der Ferne kann man da natürlich nix Sinnvolles dazu sagen. Gibt das Eventlog Aufschluss? Zeigt der Server sonst Auffälligkeiten? Grundsätzlich sind Windows-Updates sehr platten- und CPU-intensiv, möglicherweise deuten sich da Probleme an. Gruß, Nils

Moin, Äpfel und Birnen. Man könnte jetzt auch argumentieren, warum der Ansatz von vSphere "Mist" ist. Das ist aber nicht das Niveau, auf das ich sinken will. Gruß, Nils

Moin, der Performance-Unterschied von dynamischen und festen virtuellen Platten ist so gut wie nie das Thema, zumindest in kleinen und mittleren Umgebungen. Es geht vor allem darum, dass man bei dynamischen Disks wie bei allen "Thin-Provisioning"-Techniken Gefahr läuft, dass kein Platz mehr zur Erweiterung da ist. Ich nenne das auch gern das "Texas Chainsaw Massacre": [10 Dinge, die Hyper-V übel nimmt - Cloud & Datacenter Conference Germany 2016 - Channel 9] https://channel9.msdn.com/Events/community-germany/Cloud--Datacenter-Conference-Germany-2016/10-Dinge-die-Hyper-V-uebel-nimmt etwa ab Minute 26. Gruß, Nils

Moin, boah, ich kann es nicht mehr hören. Das Memory Management von Hyper-V ist genauso wenig lächerlich wie das von vSphere. Können wir uns das einfach sparen? Danke. Hot-Add oder Remove von fest zugewiesenem Arbeitsspeicher wird erst mit Hyper-V 2016 gehen. Bis dahin muss man eine so konfigurierte VM herunterfahren, um den RAM zu ändern. Aus meiner Sicht ist es eher ein Designfehler der Umgebung, wenn man die Funktion wirklich oft braucht. Egal ob vSphere, Hyper-V, KVM oder was auch immer. Und wenn man sie nicht oft braucht, wird das Herunterfahren der VM verschmerzbar sein. Gruß, Nils

Moin, freut mich! :) Gruß, Nils

Moin, zwei valide Beispiele, wo es Sinn ergibt. Ziemlich genau solche Überlegungen meinte ich. Für den interessierten Leser ergänze ich noch: Wie bei jeder "Thin-Provisioning"-Technik gehört auch hier ein adäquates Monitoring dazu. Gruß, Nils

Moin, [José Active-Directory-Dokumentation | faq-o-matic.net] http://www.faq-o-matic.net/jose/ [in welchen AD-Gruppen ist ein Benutzer Mitglied? | faq-o-matic.net] http://www.faq-o-matic.net/2010/07/27/in-welchen-ad-gruppen-ist-ein-benutzer-mitglied/ [Mitglieder einer AD-Gruppe mit Zusatzdaten ausgeben | faq-o-matic.net] http://www.faq-o-matic.net/2008/07/04/mitglieder-einer-ad-gruppe-mit-zusatzdaten-ausgeben/ [Wie kann ich die Mitglieder einer Gruppe in eine Datei schreiben? | faq-o-matic.net] http://www.faq-o-matic.net/2004/07/30/wie-kann-ich-die-mitglieder-einer-gruppe-in-eine-datei-schreiben/ [Wie kann ich sicher prüfen, ob ein Benutzer Mitglied einer bestimmten Gruppe ist? | faq-o-matic.net] http://www.faq-o-matic.net/2004/09/27/wie-kann-ich-sicher-pruefen-ob-ein-benutzer-mitglied-einer-bestimmten-gruppe-ist/ Gruß, Nils

Moin, letztlich ist es eine Strategiefrage. Technisch spricht nichts gegen Dynamic Memory, wenn die Applikationen das unterstützen (was im Einzelfall zu klären ist). Strategisch sollte man sich aber überlegen, warum man Dynamic Memory einsetzen will. Oft ist es eher eine Notlösung für zu gering dimensionierte RAM-Ausstattung auf dem Host - dann ist das natürlich nicht eben sinnvoll. In großen Umgebungen kann das Kalkül aufgehen, dass manche VMs mehr RAM brauchen, während andere weniger benötigen. Da kann sich das dann auf einem Host gut ausgleichen. Kritisch sind aber Lastsituationen, in denen "alle" VMs viel RAM brauchen. Da kann Dynamic Memory dann auch nach hinten losgehen. In solchen Fällen hat man mit einer festen Zuweisung und einer ausreichenden Dimensionierung der Hosts bessere Zuverlässigkeit. Dazu kommt das "Noisy Neighbor"-Problem: Eine VM fordert unverhältnismäßig viel RAM an und bremst dadurch andere aus. Das ist mit Dynamic Memory zwar (anders als Mitbewerber wie VMware behaupten) besser gelöst als bei anderen Plattformen, die reines "Overcommit" betreiben, weil Dynamic Memory immer nur wirklich freien RAM umverteilt und einer VM nichts wegnimmt, was sie eigentlich braucht. Trotzdem kann das zu unerwünschten Effekten führen. Die Lösung lautet dann, für eine solche VM das Maximum zu begrenzen - was aber dann schon wieder sehr in die Nähe einer festen Zuweisung geht, die vielleicht leichter zu handhaben wäre. Gruß, Nils

Moin, ohne Weiteres lässt sich das nicht erkennen. Man kann es höchstens pro DC (bzw. pro Replikationsverbindung) errechnen. Für eine Momentaufnahme eignet sich dafür die Ausgabe von Repadmin oder das AD Replication Status Tool. Gruß, Nils

Moin, meine Ansichten dazu habe ich recht ausführlich u.a. hier dargelegt: [10 Dinge, die Hyper-V übel nimmt - Cloud & Datacenter Conference Germany 2016 - Channel 9] https://channel9.msdn.com/Events/community-germany/Cloud--Datacenter-Conference-Germany-2016/10-Dinge-die-Hyper-V-uebel-nimmt dort Minuten 5:10 bis 18:40. In der Praxis setze ich Dynamic Memory höchst selten ein. Außerhalb von VDI und virtuellen Terminalservern ist es meist eher ein Kennzeichen von schlechter Planung. Gruß, Nils

Moin, bei den 15 bzw. 60 Minuten handelt es sich um ein Intervall. Es wird dann alles repliziert, was bis zu diesem Zeitpunkt geändert wurde. Zu deiner zweiten Frage such mal nach "urgent replication", da solltest du genügend finden. Gruß, Nils

Moin, die Informationen, auf die ich mich beziehe, stehen hier: [Neues Lizenzmodell für Windows Server 2016 | faq-o-matic.net] http://www.faq-o-matic.net/2015/12/04/neues-lizenzmodell-fr-windows-server-2016/ Ob es Aktuelleres gibt, weiß ich nicht. Im Zweifel Microsoft direkt fragen, Fachhändler bekommen solche Informationen meist sehr spät. Gruß, Nils

Moin, dann ist dein Storage dafür nicht geeignet. Ich wiederhole meinen Hinweis aber noch mal als Frage: Ist es bestätigt, dass das Storage den Engpass bildet und nicht die Netzwerkanbindung des Storages? Gruß, Nils

Moin, bei 16 Cores auf 2 CPUs, also 8 Cores pro CPU. Wenn es 16-Core-CPUs wären, wäre es nicht egal. ;) Und wie die "options" aussehen und was man bei seinen "considerations" herausgefunden hat, hat Microsoft, soweit ich sehe, noch nicht genauer gesagt. Gruß, Nils

Moin, naja, sowas bekommt man bei seriösen Anbietern für unter 250 Euro pro Jahr. Das ist Geld, aber nicht viel, wenn man es braucht. Gruß, Nils

Moin, meines Wissens gibt es dazu noch keine verbindlichen Aussagen von Microsoft. In der FAQ vom Dezember hieß es nur, man würde die Optionen für bestehende SA-Kunden prüfen. Wenn die SA ausläuft, kannst du das zugrunde liegende Produkt weiter nutzen, in der letzten Version, die du im Rahmen der SA erhalten hast. Alle Zusatzfunktionen der SA entfallen dann aber, also etwa Lizenzmobilität (bei Applikationen) oder das Recht, beim Client die Enterprise-Version zu nutzen (dort müsste man dann auf Pro umsteigen). Gruß, Nils

Moin, korrekt, danke für den Hinweis! Und falls sich noch jemand als Sprecher oder Experte bewerben möchte, geht das noch bis zum 15. Juni. Gruß, Nils

Moin, unter Hyper-V geht das nicht nur nicht zuverlässig, sondern gar nicht. ;) Ein USB-Server wäre hier das Mittel der Wahl. Oder der Umstieg auf eine andere Kopierschutztechnik, was viele Hersteller durchaus anbieten. Gruß, Nils

Moin, bist du sicher, dass José dafür das geeignete Tool ist? Wenn ja, kannst du einfach telephoneNumber und mail deiner Liste hinzufügen. Gruß, Nils

Moin, na gut. Dann versuche ich mir das zu merken. ;) Dann bleibt es aber dabei, dass solche Sachen der Auslegung durch Fachleute bedürfen - in dem Fall Juristen. Laien neigen dann doch zu oft zu Kochtopf-Vergleichen (siehe mein Beispiel oben). Im hier diskutierten Fall deuten die Umstände schon stark auf ein halbseidenes Geschäft, bei dem das Risiko für den Käufer kaum angemessen ist. Das ist der Teil, den wir hier diskutieren können. Gruß, Nils

Moin, dann gibt es evtl. irgendeine Logik außerhalb des SQL Servers, die für einen Abgleich oder sowas sorgen soll und sich dabei vertut. Wie du schon richtig sagst, haben AD-Konten und SQL-Logins nichts miteinander zu tun, einen direkten Zusammenhang zum Ändern des AD-Kennworts kann es also nicht geben. Gruß, Nils

Moin, handelt es sich innerhalb des SQL Servers um Windows-Logins? Oder sind es SQL-Logins? Gruß, Nils

Moin, du brauchst keine zweite Domain und keine Vertrauensstellung. Am einfachsten erzeugst du pro Standort eine OU (das ist ein Ordner innerhalb des AD, keine Subdomane!) und legst dort die jeweiligen User rein. Alles hübsch übersichtlich. Ich wiederhole meine Empfehlung: Hol dir dafür punktuell jemanden ins Haus, der sich mit AD und Exchange auskennt. Das spart insgesamt eine Menge Geld. Gruß, Nils

Moin, OK, in dem Fall brauchst du eine zweite Domäne. Da würde ich allerdings noch mal in Ruhe auf die Anforderungen schauen - vielleicht lässt sich auf eine zweite AD-Domäne (und allen Aufwand drumrum) verzichten. Nur um schon mal die Richtung anzudeuten: Warum sollen die User aus dem Tochterunternehmen nicht in das AD? Man könnte sie ja in eine OU tun, statt sie in eine eigene Domäne zu packen. Gruß, Nils

Moin, nein, da vermischst du zwei Dinge. Die AD-Domäne hat mit der Maildomain nichts zu tun. Daher kannst du dein Vorhaben ohne zweite AD-Domäne umsetzen. Im Wesentlichen würdest du die zweite Mail-Domain als zusätzliche "Accepted Domain" in Exchange einrichten und dafür sorgen, dass die User, die diese Domain nutzen sollen, (zusätzliche) Mail-Adressen dieser Domain erhalten. Das ist nicht wirklich wild, aber vielleicht solltest du dir jemanden ins Haus holen, der weiß, wie das geht. Gruß, Nils