NilsK

Moin, wenn man es wirklich will, kriegt man das sicher auch per Batch hin. Da die "Sprache" aber eigentlich keine ist und auch für sowas nie entworfen wurde, wird das aber sehr umständlich. Die PowerShell hingegen ist ausdrücklich auch für komplexere Aufgaben gemacht und hat ein gutes Handling von Variablen, Schleifen, Strings usw. Auf jeden Fall müsstest du für dich erst mal die Logik genauer definieren. Unter welchen exakten Umständen soll exakt was passieren? Mit so einer Definition ist man dann oft schon nah an der Lösung. Gruß, Nils

Moin, Schulaufgabe? Gruß, Nils

Moin, interessante Behauptung - was hat denn die Person genau gesagt? Gruß, Nils

Moin, nein, das sind unterschiedliche Dinge. Das krbtgt-Kennwort ändert man nur manuell, die Computerkennwörter handeln die Rechner regelmäßig mit dem AD aus. Gruß, Nils

Moin, ein DC darf maximal so lange offline sein, bis die Tombstone Lifetime erreicht wird. Das sind entweder 60 oder 180 Tage. Ich weiß nicht, von was für einem Kerberos-Passwort du sprichst. Vielleicht ein Missverständnis? Kerberos akzeptiert keine Zeitabweichung zwischen DC und Client von mehr als 5 Minuten. Das hat mit deinem Problem aber nichts zu tun. Bei dem Phänomen, das anscheinend bei dir vorlag, geht es um das Computerkennwort des DCs. Wie es zu der Versionsabweichung kommt, kann ich grad nicht aus dem Kopf sagen, aber es ist ein eher unübliches Phänomen. Kann es sein, dass die Verbindung zwischen den Standorten nicht ausreichend zuverlässig ist? Gruß, Nils

Moin, Lass die Replikation in Ruhe. Die berechnet das AD selbst. Wenn es die nötigen Informationen dazu hat, klappt zuverlässig. Dass ab vier DCs nicht jeder mit jedem repliziert, ist normal. Gruß, Nils

Moin, erstens würde ich mit 2019 noch warten. Das macht noch einen ziemlich unausgegorenen Eindruck. Und zweitens würde ich immer was vom Hersteller unterstütztes nehmen, also entweder Hyperconverged von einem "Komplettanbieter" oder ein herkömmliches Server-und-SAN-System mit definiertem Support. S2D ist von der Idee her nett, aber in der Praxis hat man eben selbst die Support-Sorgen damit, weil es am Ende meist ein Eigenbau ist. Uns haben in den letzten Monaten mehrere Kunden angerufen, denen ein in der Community bekannter S2D-Verfechter sowas gebaut hat, der es jetzt aber nicht mehr supporten kann, weil er die Leute (besser: den Leut) nicht mehr hat. Wir fassen so ein System aber nicht an - und dann stehen die Kunden halt da ... da mag man von Hersteller-Support halten, was man will, aber damit hat man wenigstens eine definierte Grundlage, wenn mal was ist. Gruß, Nils

Moin, hier sollte man sich genau ansehen, was man braucht und was technisch passiert. In dem VPN-Szenario wird das Zertifikat für die Traffic-Verschlüsselung verwendet, also sozusagen "nur ad-hoc". Es ist daher grundsätzlich unproblematisch, wenn auf verschiedenen Rechnern unterschiedliche Zertifikate für denselben User vorliegen. Da die verschlüsselten Daten nicht gespeichert werden, müssen sie nicht zu einem späteren Zeitpunkt entschlüsselt werden. Daher kann man den derzeitigen Zustand, den du beschreibst, für dieses Szenario durchaus akzeptieren. Anders sieht es aus, wenn die verschlüsselten Daten gespeichert werden, etwa bei der Mail- oder Dateiverschlüsselung. In dem Fall ist es unabdingbar, dass derselbe User immer dasselbe Zertifikat verwendet. Hier kann Credential Roaming eine Lösung sein. Andere Ansätze verzichten in solchen Situationen darauf, dass derselbe User verschiedene Rechner verwendet. Noch eine Variante wäre, den Private Key gar nicht auf dem Rechner zu halten, sondern auf einer Smartcard - das setzt aber drumrum natürlich einiges an Infrastruktur voraus. Was nicht hilft, ist das Speichern des Private Keys in der CA-Datenbank. Zwar bietet die Windows-CA so eine Option (Key Archival), die ist aber nur für Recovery-Zwecke vorgesehen und würde in dem Roaming-Szenario gar nicht helfen (weil der Client nicht auf die Idee käme, dort zu suchen). Daher in der Regel Finger weg davon - Key Recovery benötigt man nur, wenn verschlüsselte Daten aufbewahrt werden und auch dann nur für den Recovery-Prozess, der dann genau definiert und speziell abgesichert sein muss. Gruß, Nils

Moin, gern. Viel Erfolg. Gruß, Nils

Moin, ja, aber die vorgeschlagene Lösung kommt mit viel weniger Downtime aus und führt zu einem "sauberer" eingerichteten Betriebssystem. Gruß, Nils

Moin, dies hier hilft nicht? https://docs.microsoft.com/de-de/azure/backup/backup-azure-arm-restore-vms Gruß, Nils

Moin, gut, also ... ich denke, das ist durch diesen Passus auf Seite 6 implizit beantwortet: Hervorhebung von mir. Daraus geht hervor: Wenn ich dem Host eine 2016-Lizenz zuweise, ist dieser aus Microsoft-Lizenzsicht eben ein 2016-Host, dann erfüllt eine parallel zugewiesene 2012-Lizenz nicht die Bedingungen, die die bereits vorhandene 2016-Lizenz vorgibt. Jetzt habe ich keine Lust, noch weiter nach Belegen zu suchen. Die Situation ist aus meiner Sicht eindeutig, wer juristische Klarheit braucht, muss wie immer einen zugelassenen Rechtsberater befragen. Gruß, Nils

Moin, weil man dann immer noch nicht die VMs lizenziert, sondern den Host. Vermutlich meinst du das auch, aber für Leser, die damit nicht vertraut ist, war deine Formulierung ggf. missverständlich. Daher hier noch mal ausdrücklich: OS-Lizenzen für Windows-Server-VMs werden immer über den Host zugewiesen und niemals der betreffenden VM. Und was eure Downgrade-Diskussion angeht: Ihr scheint aneinander vorbei zu reden. Relevant dafür, welche VMs auf einem Host laufen dürfen, ist die Lizenzversion, die dem Host zugewiesen ist (Version und Edition). Im Falle von Hyper-V dürfte es durchaus zulässig sein, den Host mit 2012 R2 zu betreiben, darauf aber 2016-VMs laufen zu lassen - vorausgesetzt, dem Host ist eine 2016-Lizenz mit Downgrade-Recht zugewiesen. (Technisch sinnvoll ist das nicht, aber das ist lizenzrechtlich ja egal.) Gruß, Nils

Moin, also, die Frage nach dem "Mischen" ist in den verbindlichen Bestimmungen ja schon durch diesen Passus geregelt: selbe Quelle und selbe Seite wie von Lizenzdoc angegeben. Dadurch dass alle Cores lizenziert sein müssen, erübrigt sich die Frage nach dem Mischen. Bei 20 verfügbaren Cores müssen 20 Cores lizenziert werden. Das Downgrade-Recht hat damit erst mal nichts zu tun, das ist ein zusätzliches Vertragsfeature. @Gulp nein, man kann keine einzelnen VMs lizenzieren. Das ist ja eben der Punkt. Gruß, Nils

Moin, deshalb schrob ich ja auch: Weshalb diskutieren wir das jetzt? Bin ich in der Nachweispflicht? Mir ist es am Ende egal, ob der TO richtig lizenziert ist. Ich trage hier, genau wie alle anderen, meine Kenntnisse bei, damit der Fragesteller eine Falschlizenzierung besser vermeiden kann. Gruß, Nils

Moin, hier steht's ausdrücklich in einem FAQ. Ich bin mir sicher, dass sich ein Passus dieses Inhalts auch in den Vertragsunterlagen findet. Wie gesagt: Das war "schon immer" so, also spätestens seit 2012. https://download.microsoft.com/download/F/3/9/F39124F7-0177-463C-8A08-582463F96C9D/Windows_Server_2012_R2_Licensing_Datasheet.pdf Gruß, Nils

Moin, ah, OK, jetzt verstehe ich. Ich habe die Quelle nicht zur Hand, bin mir aber sicher, dass das Mischen verschiedener Lizenzen auf einem Host nicht erlaubt ist. Alles muss durch denselben Lizenztyp (Version und Edition) abgedeckt sein. Gruß, Nils

Moin, wenn die Lizenz ein Downgrade-Recht enthält, dann kann der Kunde natürlich VMs verschiedener Versionen mischen. In dem Fall könnte er, meinem Verständnis nach, durchaus auch auf dem Host 2012 R2 laufen lassen und VMs mit 2016 betreiben - voausgesetzt, dem Host ist eben eine 2016-Lizenz zugewiesen. Da das aber technisch dann keinen Sinn ergibt, ist es eben am besten, den Host gleich mit der lizenzierten Version zu installieren. Wichtig ist nur immer der Punkt, dass niemals die VMs direkt lizenziert werden, sondern immer der Host. https://www.youtube.com/watch?v=6tH3QGSRP00 Gruß, Nils

Moin, Wieso? Das war schon immer so. Die Lizenz muss auf dem Host vorliegen. Also muss ihm die Lizenz der höchsten Windows-Version zugewiesen werden, die in einer VM läuft. Gruß, Nils

Moin, Wenn du VMs mit Windows 2016 betreiben willst, musst du denn Host mit 2016 lizenzieren. Bei insgesamt 3 VMs sind das also zwei "Sets" Standard-Lizenzen (weil ein"Set" zwei VMs lizenziert). Oder konkret gesagt 20 Core-Lizenzen. Dann solltest du der Gelegenheit auch gleich 2016 auf dem Host installieren. Gruß, Nils

Moin, hier sind die Begriffe nicht ganz klar. Welche der genannten Server sind Hosts (= physisch), welche VMs? Gruß, Nils

Moin, ah, dann habe ich den Namen des ISOs falsch gedeutet. Ja, ich denke, da solltest du den Support involvieren. Vielleicht ist das eine der (vielen) Stellen, an denen dem Server 2019 irgendwie die Reife fehlt ... Gruß, Nils

Moin, Microsoft hat die Architektur des Core-Servers verändert. Einige Funktionen sind nur noch "on demand" verfügbar, was die Installation von Paketen voraussetzt. Ich hab es nicht verifiziert, aber es sieht ja so aus, als würde die deutsche Tastatur auf einem EN-System die Installation des Basis-Sprachpakets erfordern. Bei Systemen, die keinen Zugriff aufs Internet haben, kann man ein separates ISO nutzen, das die Pakete enthält. Das ist schlauerweise so groß, dass es zwei DVD-ISOs umfasst ... wirst du finden, und ich denke, mit der Information findest du auch die nötigen Schritte, um das einzurichten (die hab ich nicht parat). Möglicherweise liege ich falsch, aber so ist erst mal meine Interpretation. Gruß, Nils

Moin, ja, sag ich ja. Das Voodoo namens HDMI. @Nobbyaushb die Version siehst du, wenn du die App installierst und aufrufst, während der Rechner mit dem Adapter verbunden ist. (Was irgendwie nach Henne und Ei klingt.) Gruß, Nils

Moin, nein, da ist kein Bluetooth im Spiel. Gruß, Nils