Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    13.279
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

622 Exzellent

5 Benutzer folgen diesem Benutzer

Über NilsK

  • Rang
    Expert Member
  • Geburtstag 07.08.1970

Webseite

Letzte Besucher des Profils

2.835 Profilaufrufe
  1. Replikationsfehler zwischen den DCs

    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
  2. Replikationsfehler zwischen den DCs

    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
  3. Hyper-V Cluster - Storage Optionen?

    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
  4. Benutzerzertifikate nur einmal

    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
  5. GELÖST Azure Backup Restore

    Moin, gern. Viel Erfolg. Gruß, Nils
  6. Fileserver Migration unter VMware

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

    Moin, dies hier hilft nicht? https://docs.microsoft.com/de-de/azure/backup/backup-azure-arm-restore-vms Gruß, Nils
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×