NilsK

Moin, dann würde ich den Anwendern gar keinen Desktop bereitstellen, sondern nur die Applikationen. Gruß, Nils

Moin, Mandatory Profiles sind eine Technik aus NT-Zeiten - über 20 Jahre alt und damals schon alles andere als zuverlässig. Zudem sorgen solche Profile vorhersagbar für Datenverluste. Anforderungen definieren und passende Lösungen finden. Also: Was soll genau erreicht und was genau verhindert werden? Und warum? Gruß, Nils

Moin, das war dann aber auch keine Storage Live Migration. Mir sind keine Probleme bei der Storage Live Migration bekannt, die vom Gast-OS abhängen. Das sollte davon, genau wie bei einer "normalen" Live Migration, gar nichts mitbekommen. Höhere Sicherheit erzeugt ein Test unter realistischen Bedingungen. Gruß, Nils

Moin, ja, davon kannst du auch ausgehen. Seit Windows Server 2016 gibt es keine separaten Updates mehr für die Integrationsdienste, die sind Teil der "allgemeinen" Updates und innerhalb dieser auch leider nicht zu identifizieren. Dein Checkpoint-Problem kann eine ganze Reihe von Ursachen haben. Generell sollte man in Produktionsumgebungen nicht mit Checkpoints arbeiten, sondern eine sinnvolle Backup-Restore-Strategie aufbauen. Da alle Versuche, an dem Problem etwas zu ändern, ein hohes Risiko erzeugen, empfehle ich einen Supportcall bei Microsoft. Kannst du den Checkpoint exportieren, der das Problem hat? Oder schlägt das ebenfalls fehl? Gruß, Nils

Moin, wobei es mich schon wundern würde, wenn während einer Flugzeuglandung oder einer OP Online-Wetten gespielt werden. In solchen Applikationsfällen gibt es andere Verfügbarkeitsmechanismen. Und nebenbei ist Shared-Nothing Live Migration kein Verfügbarkeitsmechanismus, sondern eine Management-Technik. Beim Ausfall eines VM-Hosts ist die Wiederanlaufzeit i.d.R. im Bereich zwischen 30 Sekunden und 10 Minuten. Wenn das nicht OK ist, dann ist der Aufbau eben nicht passend und man braucht einen anderen. Gruß, Nils

Moin, ja und, dann ist der Artikel eben 12 Jahre alt. Auf meinem IT-Blog habe ich Artikel, die sind an die 20 Jahre alt und treffen immer noch zu. Nicht alles, was alt ist, ist überholt. Genau wie nicht alles, was neu ist, zutrifft. Zahni hat dir einen Artikel verlinkt, der den technischem Umstand erläutert, auf den er hinzuweisen versucht. Du musst das nicht annehmen, aber es arrogant abzutun, bringt dich ganz sicher nicht weiter. Gruß, Nils

Moin, naja, in dem Fall leg doch die VMs gleich auf der Systemplatte an, sofern da übergangsweise genug Zeit Platz ist. Wenn dann das RAID fertig ist, verschiebst du die VHDX-Dateien lokal auf das RAID, das geht ohne Downtime. So sparst du einen Verschiebevorgang. Oder du erzeugst die VMs auf einem ganz separaten System und verschiebst sie auf den Zielhost, wenn der fertig ist. Möglichkeiten über Möglichkeiten. ;) Gruß, Nils

Moin, im Wesentlichen kann man so vorgehen, wie Norbert beschreibt. Das erzeugt dann eine Downtime für die VMs. Da du den Host aber wohl ohnehin abschalten würdest, um die Platten einzubauen, gäbe es die Downtime ja sowieso. Falls ein zweiter Host zu Hand ist, könntest du die VMs auch im laufenden Betrieb dorthin verschieben ("Shared-Nothing Live Migration"), dann gibt es keine Downtime für die Anwender. Wenn der eigentliche Host dann fertig ist, verschiebst du die VMs auf demselben Weg zurück. Gruß, Nils

Moin, was hat die DSGVO mit einem AD zu tun? Und wie kommt man auf die Idee, dass die DSGVO mit irgendwas aus der Kategorie "kurzerhand" oder "mal eben" kompatibel wäre? Was dort schief läuft, lässt sich aus der Ferne nicht sagen. Wenn du allerdings mit nativen AD-Funktionen arbeiten willst, warum dann einen AD-Nachbau nutzen und kein echtes AD? Ihr werdet ja kaum eine Umgebung völlig ohne Windows-Server haben, sodass Lizenzkosten nicht das Argument sein können. Ein echtes AD ist supportfähig, ein unechtes nicht. Gruß, Nils

Moin, in deinen ursprünglichen Anforderungen steht nichts von einer Pre-boot Authentication. Du könntest, sofern das zutrifft, also schlicht auf den PIN verzichten. Bevor jetzt alle an die Decke gehen: Das ist ein typischer Fall, in dem man die Anforderungen genau klären muss. Bitlocker (oder eine andere Lösung) ohne PIN (aber mit TPM) sichert "Data at rest", also die Daten auf der abgeschalteten Platte. Bleibt die Platte im selben Gerät, kann jeder sie starten, dann geht der Schutzbedarf auf das laufende Windows über. Das kann ausreichen und es kann nicht ausreichen - das muss der TO klären. Eine Methode, die Pre-Boot-Auth erfordert und gleichzeitig für wechselnde Anwender geeignet ist, wäre mir zumindest nicht bekannt. Mag sein, dass es welche gibt, aber ich vermute mal, dass es dann teuer wird. Gruß, Nils

Moin, aufs Geratewohl rumprobieren kann man viel. Mit systematischer Fehlersuche hat das aber wenig zu tun. Vermutlich wäre es wirklich am besten, du holst dir mal jemand ins Haus, der sich mit der Materie auskennt, und der schaut sich das in Ruhe an. Nach dem Verlauf dieses Threads glaube ich nicht, dass das auf die bisherige Weise noch viel Sinn ergibt. Gruß, Nils

Moin, schau an, wieder was gelernt. Also war mein Verständnis der Anfrage ungefähr richtig? Sehr schön übrigens mal wieder die französische Sprache, es ist ja offenbar ein französisches Projekt: Gestionnaire libre de parc informatique - "parc informatique", das hat was. Gruß, Nils

Moin, da kann ich mir ehrlich gesagt den Bedarf grad nicht so richtig vorstellen. Welches Grundproblem soll das System lösen? Dass ihr sehr viele Büros, sehr viele Mitarbeiter und viele Umzüge habt? Oder worum geht es im Kern? Gruß, Nils

Moin, ganz ehrlich: Bei so einer kleinen Umgebung kein Hyperconverged. Hyperconverged kommt aus dem Hyperscale-Bereich, also sehr große Umgebungen. Da ist das toll. In KMU-Umgebungen ist das nicht nur viel zu teuer, sondern auch viel zu komplex und viel zu unflexibel. Bezüglich "unterbrechungsfrei" ... auch da solltest du noch mal mit deinen Anbietern sprechen. "Unterbrechungsfrei" ist für eine ganze VM-Umgebung faktisch nicht machbar. Allerdings ist es in Wirklichkeit auch so, dass fast niemand das bräuchte. Ein gutes Beratungshaus diskutiert das in der Tiefe mit dir. Klärt, was ihr wirklich braucht. Ich erlebe es oft, dass Kunden erst meinen, sie bräuchten "Jeder, immer, alles", und wenn man dann gemeinsam draufschaut, tut es auch was viel Kleineres. Beispielsweise würde eine Replica-Lösung mit kürzerem Intervall auch eine bessere Wiederherstellbarkeit ergeben. Wichtig sind ja die Applikationen, nicht die Infrastruktur. Gruß, Nils

Moin, es geht hier ja um Windows Server 2016, nicht um Windows 10. Technisch wird es da nur darum gehen, ein paar optische Features ein- oder auszuschalten und ein paar Serverdienste bewusst wegzulassen. Das ist keine große Magie. Windows Server 2016 Standard und Datacenter unterscheiden sich technisch in der Hinsicht auch nicht - wäre aber auch egal, wenn auf dem Host Datacenter installiert ist (soweit ich verstanden habe, darf man dann die VMs ja auch als Standard installieren, aber selbst wenn nicht, wäre das technisch kein Unterschied). In der VDI-Szene ist das ein völlig übliches Vorgehen, um Microsofts, naja, wenig durchdachte Lizenzbestimmungen daran zu hindern, die VDI-Technik zu massakrieren. Wenn man auf die RDS-Lizenzen achtet, wüsste ich auch nicht, was daran rechtlich nicht OK wäre. Das ist nichts anderes als ein herkömmlicher Terminalserver, der von genau einem Anwender verwendet wird. EDIT 2: Habe gerade noch mal den Eröffnungspost nachgelesen - falls der Kunde meint, er brauche in seinem Szenario keine RDS-CAL, dann ist das natürlich nicht korrekt. Der Witz an VDI besteht ja gerade darin, dass er die RDS-Funktion nutzt, ohne die geht es nicht. (Dass mir der Vorteil von VDI gegenüber "klassischem" Server-RDS in fast keinem Szenario einleuchtet, steht auf einem anderen Blatt.) Gruß, Nils

Moin, [OT] hier in Hannover selbstverständlich nur der mit den Zähnen. [/OT] Gruß, Nils

Moin, ich würde eher vermuten, dass die dort die Hände über dem Kopf zusammenschlagen und das für nicht supported erklären ... Gruß, Nils

Moin, du meinst sicher einen Registry-Keks, oder? *SCNR* Gruß, Nils

Moin, dann sehe ich keinen Weg. Gruß, Nils

Moin, das sind halt zwei verschiedene Attribute. Du kannst ja mal in einer Auflistung des Schemas nachsehen, das AD kennt noch zahlreiche weitere Namensattribute. Dummerweise nehmen die Standard-AD-Tools den CN als Anzeigenamen, während Outlook und Exchange dafür den displayName nutzen. Gruß, Nils

Moin, wer nutzt denn Öffentliche Ordner als Speicher für Mail-Archivierung? 100 GB sind nicht ohne Grund eine Grenze. Öffentliche Ordner waren für solche Volumina nie gedacht. Sowohl Mailboxen als auch Öffentliche Ordner dieser Größenordnung führen erfahrungsgemäß auch zu Instabilitäten des gesamten Systems. Selbst wenn das nicht so wäre - glaubst du wirklich, dass man bei einem Mail-Archiv mit "Tricks" arbeiten wollen würde, um eine Speicherbegrenzung zu umgehen? Der einzige sinnvolle Weg ist ein Redesign. Gruß, Nils

Moin, wie soll man das beantworten, ohne eure Organisation zu kennen? Als allgemeine Aussage dazu vielleicht: Bei den meisten Unternehmen ist so viel Personal vorhanden, dass das übliche Geschäft geleistet werden kann. Für ein größeres Projekt fehlen dann oft Ressourcen, weswegen man sich für sowas extern verstärkt. Ein ISMS-Projekt mit dem Ziel der Zertifizierung hat schnell höhere zweistellige externe Beratertage. Die internen Aufwände, die ein Externer nicht machen kann, kommen noch dazu, die können durchaus noch höher sein. Wenn man dann auch noch selbst den Aufwand leisten muss, das nötige Know-how für eine zertifizierbare ISMS-Implementierung aufzubauen, kann das unwirtschaftlich werden. Betrieb und Weiterentwicklung erfordern natürlich auch Kenntnisse in der Systematik, aber die Grundlagenkenntnisse zum Erstaufbau würdet ihr danach nicht wieder brauchen, wenn ihr kein eigenes Geschäft daraus macht. Gruß, Nils

Moin, wenn das genau das ist, was du eingegeben hast, dann ist da vor "Exchange" ein Anführungszeichen zu viel. Versuch mal, die Ressource, die auf "OnlinePending" steht, ausdrücklich offline zu setzen. Dann könntest du versuchen, dir mit einem Get-Befehl nur die Ressourcen ausgeben zu lassen, die "EXCHANGE" im Namen haben. Wenn genau diese vier zurückkommen, pipe den Befehl an Remove-ClusterResource. Dass da grundsätzlich was kaputt sei, glaube ich nicht. Gruß, Nils

Moin, *seufz* ... Na, aber gut, dass es jetzt gelöst ist. Gruß, Nils

Moin, genau für solche Kofigurationen legt man RDS-Server normalerweise in einer eigene OU ab. Dann kann man sich WMI-Filter und sowas sparen. Wenn du es so baust und das GPO auf diese OU wirken lässt, dann sollte es auch funktionieren. Wichtig: Nach dem OU-Wechsel des Server-Computerkontos den Server neu starten. Gruß, Nils